Java: очистка памяти после выполнения потока

Question

Java: очистка памяти после выполнения потока

1

У нас есть пакетная программа Java, которая обрабатывает большие объемы данных.

После обработки этих данных, почему JVM не очищает мусор немедленно, а не ждет следующего выполнения?

Исходя из того, что я наблюдал, данные предыдущего запуска остаются такими, какими они есть, пока я не выключу вручную JVM или запуск следующего запланированного запуска.

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

Ценю вашу помощь.

Редактировать:

Внимательно оцените ваш быстрый ответ.

Я не вижу значительного влияния на производительность моего процесса из-за этого существования мусора в памяти. Но он все время отгоняет системную оперативную память и влияет на доступность памяти для других программ вне этой JVM.

Еще одна проблема, с которой я сталкиваюсь, заключается в том, что во время разработки и отладки этой программы, в то время как программа запускается, я позволяю ей работать, но как только это делается, чтобы проанализировать результаты, мне нужно открыть несколько других приложений, которые, очевидно, нуждаются в немного оперативной памяти, но JVM doesn ' t освободить пространство оперативной памяти, если я не остановлю его, что повлияет на удобство и производительность других программ.

Bharat Chowdary 28 авг. 2014, в 16:09

Источник

3

Как правило, не рекомендуется запускать GC слишком часто, поэтому оставить его позже - хорошая компромиссная стратегия. Но вы можете настроить GC, чтобы следовать другой стратегии.
biziclop 28 авг. 2014, в 13:33

Теги:

java

multithreading

memory-management

jvm

4 ответа

Ещё вопросы

Как правило, не рекомендуется запускать GC слишком часто, поэтому оставить его позже - хорошая компромиссная стратегия. Но вы можете настроить GC, чтобы следовать другой стратегии.

Enno Shioji · Answer 1 · 2014-08-28T10-55-00.000Z

JVM GC очень эффективен, как и нелегко сделать его "более эффективным". Если у вас нет серьезных проблем с производительностью, я бы не стал ничего делать.

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

Сказав это, мое практическое предложение состоит в том, чтобы увидеть, что что-то сохраняет ссылку на данные. Если ссылка только очищается в силу следующего прогона, это объясняет симптом. Независимо от того, есть ли у вас потоки, не имеет никакого отношения к приемлемости GC. Все, что имеет значение, - есть ли у вас живая ссылка на данные.

С оговоркой, что «живая ссылка» означает любой объект, который доступен через сильные ссылки из потока, который запущен или еще не запущен. Так что есть небольшая связь.

ortis · Answer 2 · 2014-08-28T10-47-00.000Z

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

techuser · Answer 3 · 2014-08-28T23-02-00.000Z

Не рекомендуется выделять большую память JVM, если вы думаете, что это может повлиять на другие приложения. Параметры GC могут быть настроены на основе версии jvm и используемых параметров gc. В jvm может использоваться серийный сборщик по умолчанию, который не является хорошим выбором для больших размеров кучи. Взгляните на параллельный сборщик меток, который одновременно выполняет сбор мусора. http://docs.oracle.com/javase/8/docs/technotes/guides/vm/cms-6.html

Взгляните на сборщик мусора g1, если используете 1.7

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

mbsau · Answer 4 · 2014-08-28T12-16-00.000Z

JVM запускает сборщик мусора, используя политику gc. Почти все GC происходит при отключении распределения. Вы можете вызвать System.gc(); но этот способ не рекомендуется.