Проблема слишком большого количества мусора в Java

У меня есть приложение, в основном создающее новый массив байтов (менее 1 КБ), сохраняющее некоторые данные через несколько секунд (обычно менее 1 минуты, но некоторые данные хранятся до 1 часа), записывающие на диск, и данные будут отправлены в мусор. Создано около 400 пакетов в секунду. Я читал некоторые статьи, в которых говорится, что не беспокойтесь о том, что GC особенно быстро создает и освобождает части памяти (на Java 6). GC работает слишком долго, что вызывает некоторые проблемы с моим приложением. Я установил некоторые параметры GC (Bigger XMX и ParalelGC), это уменьшило время полного GC, но этого недостаточно. У меня есть 2 идеи: я фокусирую параметры GC или создаю механизм пула памяти байтового массива? Какой из них лучше?


java garbage-collection memory-pool
person Erdinç Taşkın    schedule 17.01.2011    source источник
comment
Почему вы увеличиваете Xmx? Если вам на самом деле нужна память, она обычно замедляет ваше приложение (поскольку остается больше места для ненужного мусора, и сборщику мусора придется работать больше). В общем, вы должны предоставить достаточно памяти. Не больше!   -  person Joachim Sauer    schedule 17.01.2011
comment
увеличение -mx может уменьшить частоту выполнения GC, но увеличить продолжительность их выполнения.   -  person Peter Lawrey    schedule 17.01.2011
comment
В качестве альтернативы, возможно, вы могли бы переложить часть обработки на другой поток, что позволило бы вам использовать больше доступной пропускной способности ЦП (при условии, что у вас многоядерный процессор)?   -  person clstrfsck    schedule 17.01.2011
comment
Я думаю, что мой пост немного неправильно понят. Мои значения xmx (а также xms) не являются ненужными большими значениями. Примерно больше подходит для использования памяти моего приложения. В документах Sun (Oracle) говорится, что если вы хотите улучшить параметры GC, вам следует начать с изменения подходящего значения XMX.   -  person Erdinç Taşkın    schedule 17.01.2011
comment
Увеличение mx иногда может сработать, но только по стечению обстоятельств. Поскольку он пропорционально увеличивает все части кучи, это даст вам большее пространство для молодых поколений, и это может быть все, что вам нужно. Тем не менее, проще просто увеличить долю молодого поколения, если слишком много недолговечных объектов перемещается в зрелое поколение.   -  person biziclop    schedule 17.01.2011

Ответы (3)


arrow_upward
0
arrow_downward

Я предлагаю вам проанализировать, почему GC работает недостаточно хорошо для вас. Вы можете использовать jmap для вывода кучи а затем используйте jhat или Анализатор памяти Eclipse, чтобы увидеть, какие объекты в нем живут. Вы можете обнаружить, что держитесь за ссылки, которые вам больше не нужны.

Сборщик мусора очень умен, и вы можете усугубить ситуацию, пытаясь перехитрить его с помощью собственного кода управления памятью. Попробуйте настроить параметры и, возможно, вы также сможете попробовать новый сборщик мусора G1.

Также помните, что сборщик мусора любит недолговечные неизменяемые объекты.

person dogbane    schedule 17.01.2011

arrow_upward
4
arrow_downward

Частота выполнения GC зависит от размера объекта, но стоимость (время очистки) больше зависит от количества объектов. Я подозреваю, что долгоживущие массивы копируются между пространствами, пока не окажутся в старом пространстве и, наконец, не будут удалены. Очистка старого поколения относительно дорогая.

Я предлагаю вам попробовать использовать ByteBuffer для хранения данных. Они похожи на byte[], но имеют переменный размер и могут быть немного более эффективными, если вы можете использовать прямые байтовые буферы с NIO. Предварительное выделение ваших буферов может быть более эффективным, чем предварительное выделение ваших буферов. (хотя может тратить виртуальную память)

Кстати: прямые буферы байтов используют мало места в куче, поскольку они используют память в пространстве «C».

person Peter Lawrey    schedule 17.01.2011

arrow_upward
0
arrow_downward

  1. Используйте профилировщик для идентификации фрагмента кода
  2. Попробуйте через WeakReferences.
  3. Предложить алгоритм GC для виртуальной машины
-Xgc: parallel
  1. Установите большую кучу и разделяемый мем
-XX:+UseISM -XX:+AggressiveHeap
  1. установить ниже для сбора мусора.

-XX:SurvivorRatio 8

  1. Это может помочь http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/JVMTuning.html#wp1130305
person Dead Programmer    schedule 17.01.2011