У меня есть программа которая делает множество вычислений с помощью рекурсий. Программа отлаженна, работает как надо: переполнений стэка или кучи нет; в функция рекурсии почти не имеет аргументов, чтобы небыло переполнения стэка.
Есть проблемма: программа при работе создаёт множество экземпляров небольшо класса, причём то создаёт, то удаляет их. Всё бы ничего, но при удалении некоторой кучи этих объектов программа подвисает на секунду или больше(я так понимаю из-за работы сборщика мусора). При интенсивной работе этой программы подвисания сильно увеличивают время работыпрограммы, что не приемлемо.
Для лечения этой болезни я создал специальный класс Memory, который в статичных полях создаёт, перед работой программы, 4 миллиона экземпляров того класса. И когда программе нужен объекта, этот класс даёт ссылку на один из созданных жкземпляров, а когда объект отработает свою работу, программа возвращает ссылку в класс Memory.
Так вот, теперь при работе программы она спустя недолгое время стала выдавать фатальную ошибку : java.lang.StackOverflowError: stack size 954MB (у меня размер стэка потока, в котором всё работает, задан около 1гб). Тоже бывает и при создании 4000 экземпляров.
Не понимаю в чем причина, ведь эти экземпляры находятся в глобальной переменной???
Т. е. если ОЗУ будет меньше 1 ГБ крэш будет практически сразу-же?
Подойдите к кодингу в стиле Си, не полагаясь на сборщика.
Создали - поюзали - удалили ( если это уже не нужно).
ИМХО. Так будет эфективней и менее ресурсоемко.
Из-за давности описанния данной проблемы я уже подзабыл почти всё что я хотел узнать.
Скажу только, что проблему я решил, потому, что перестал ею заниматься.
Помню, что мне удалось написать правильно программу с классом Memory. Однако, то ли из-за того что memory описан в другом файле, то ли сама джава виновата, но при обращении к memory для получения объекта программа медленнее работает чем если просто создать его через new. Это главная причина почему я отказался от этого подхода. И ещё, я узнал что, джава-приложение, которому выделяется всего 512мб max heap-size (не больше), запускает сборщик мусора при использовании почти всей этой памяти, освобождая из памяти удалённые объекты. У меня же это (моё приложение подолгу создавало и удаляло объекты) так часто было, что меня это не устраивало. Но ничего не поделаешь, разве что, может, в будущем будет придумана более шустрая джава-машина или процессоры станут быстрее. А в ручную память не освободить - такой уж он джава-язык.