Предлагает ли вызов System.gc () в java сборку мусора как для поколения, так и для молодого поколения? - PullRequest
5 голосов
/ 20 мая 2010

При вызове System.gc() в java (через JMX) он покорно (попытается) очистить молодое поколение. Это обычно работает очень хорошо. Я никогда не видел, чтобы это попыталось очистить штатное поколение. Это приводит меня к двум вопросам:

  1. Может ли даже быть собрано заимствованное поколение (т. Е. Есть ли на самом деле мусор в этом поколении, или все объекты в застрахованном поколении на самом деле все еще имеют живые ссылки на них)?
  2. Если можно получить заимствованное поколение, это можно сделать с помощью System.gc (), или есть ли другой способ сделать это (маловероятно), или мне просто придется подождать, пока я выполню не хватает места в заемном поколении?

Ответы [ 4 ]

4 голосов
/ 20 мая 2010

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#other_considerations гласит, что System.gc () запускает коллекцию major, т. Е. В том числе в режиме владения

Вы видели, что это не так в журналах GC?

3 голосов
/ 20 мая 2010

Исключительная статья о сборке мусора в Java здесь: Настройка сборки мусора с виртуальной машиной Java 5 Это специально для Java 5, но большая часть ее, вероятно, все еще применяется к более поздним виртуальным машинам.

2 голосов
/ 20 мая 2010

Прошу отличаться. Руководство по настройке Java 6 GC на самом деле гласит:

Это может заставить основную коллекцию быть выполненной, когда она может не потребоваться (то есть, когда незначительная коллекция будет достаточной), и поэтому в целом следует избегать.

Обратите внимание на использование слова «может», а не «будет». Мое прочтение этого предложения состоит в том, что в нем не говорится о том, что большая коллекция будет сделана. Это может быть сделано или нет. Я думаю, что авторы действительно пытаются сделать это здесь (и в других местах), что вызов System.gc() может привести к тому, что сборщик сделает много ненужной работы.

Теперь может случиться так, что вызов System.gc() вызывает каждый раз для большой коллекции ... для определенных версий JVM. Но вы не должны полагаться на то, что это относится ко всем версиям, особенно к будущим.

0 голосов
/ 20 мая 2010

Простое правило большого пальца для сборки мусора в Java:

  • Используйте методы очистки памяти, такие как очистка ресурсов, элементов и экземпляров, когда они не нужны.
  • Закройте то, что вы открываете. (W.R.T. соединение, Hibernate сеанс и т. Д ...)
  • Использование методов буферизации при использовании файлового ввода-вывода.
  • Использовать новый NIO вместо старого File IO.
  • Используйте Collections класс из утилит java для манипуляций с коллекцией.
  • Используйте Array, когда это возможно.
  • Изучите методы, специфичные для фреймворков. Скажем, в спящем режиме не используйте ArrayList для отношений один-ко-многим, потому что списки упорядочены, и это создаст дополнительный столбец для упорядочения детей. Вместо этого используйте Set.

  • Не используйте Hsql. Используйте какую-то реляционную базу данных, такую ​​как postgres и т. Д. HSQL потребляет больше памяти Я столкнулся с проблемами по этому поводу.

  • Также имейте в виду, что при использовании обработки XML не используйте DOM, если вы просто хотите прочитать небольшое количество данных из XML. DOM создаст всю структуру XML в памяти, поэтому займет больше памяти.

  • Старайтесь не хранить объекты в памяти, которые со временем будут расти. В противном случае приложения могут не хватить памяти.

  • определить размеры для ваших списков, карт и т. Д. *

  • Только не используйте какие-либо рамки для небольших нужд. Если это так, то внимательно проверьте, как можно настроить конфигурации для улучшения и уменьшения площади кучи.

Просто вызов System.gc() не освобождает вашу память и не очищает объекты.

Ребята, пожалуйста, добавьте подробности, если я пропустил. Так что другие могут проверить это для лучшей производительности. спасибо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...