Как контролировать использование памяти Java?

Как было предложено, попробуйте VisualVM, чтобы получить базовое представление.

Вы также можете использовать Eclipse MAT, чтобы выполнить более подробный анализ памяти.

Это нормально, чтобы сделать Систему .gc (), если вы не зависите от него, для правильности вашей программы.

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

Однако, если вы, например, работаете в очень состояние ограниченного объема памяти, как и на мобильном устройстве, System.gc позволяет вручную выделять больше времени на сборку мусора, но за счет времени процессора (но, как вы сказали, вас не беспокоят проблемы с производительностью gc) .

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

Все учтено, так как вы просто беспокоитесь об использовании памяти , не стесняйтесь позвонить в gc или, что еще лучше, посмотрите, сильно ли это влияет на память в вашем случае, а затем решите.

Если вы используете java 1.5, вы можете посмотреть ManagementFactory.getMemoryMXBean (), который дает вам числа на все виды памяти. heap и non-heap, perm-gen.

Хороший пример можно найти там http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space

Явный запуск System.gc () в производственной системе - ужасная идея. Если память вообще достигнет любого размера, вся система может зависнуть, пока работает полный сборщик мусора. На сервере размером в несколько гигабайт это может быть легко очень заметно, в зависимости от того, как настроен jvm, какой у него запас и т. Д. И т. Д. Я видел паузы более 30 секунд.

Другая проблема заключается в том, что, явно вызывая GC, вы на самом деле не отслеживаете, как JVM запускает GC, вы фактически меняете его - в зависимости от того, как вы настроили JVM, он будет собирать мусор, когда это необходимо, и обычно постепенно (он не просто запускает полный сборщик мусора, когда ему не хватает памяти). То, что вы будете распечатывать, будет совсем не похоже на то, что JVM сделает сама по себе - во-первых, вы Вероятно, вы увидите меньше автоматических / инкрементных сборщиков мусора, поскольку вы будете очищать память вручную.

Как указано в сообщении Ника Холта, параметры для печати активности сборщика мусора уже существуют в виде флагов JVM.

У вас может быть поток, который просто распечатывает бесплатно и доступен через разумные промежутки времени, это покажет вам фактическое использование памяти.

Если вам нравится хороший способ сделать это из командной строки, используйте jstat:

http://java.sun.com/j2se/1.5.0/docs/tooldocs/share /jstat.html

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

Я бы сказал, что консультант прав в теории, а вы правы на практике. Как говорится в поговорке :

Теоретически теория и практика одинаковы. На практике это не так.

В спецификации Java говорится, что System.gc предлагает вызвать сборку мусора. На практике он просто порождает поток и сразу запускается на Sun JVM.

Хотя теоретически вы можете испортить некоторую точно настроенную реализацию сборки мусора JVM, если вы не пишете общий код, предназначенный для развертывания на любой JVM. там, не беспокойтесь об этом. Если это работает для вас, сделайте это.

Вы пробовали JMX?

http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

_{(источник: sun.com )}

Существуют инструменты, позволяющие контролировать использование памяти виртуальной машиной. ВМ может предоставлять статистику памяти с помощью JMX . Вы также можете распечатать статистику GC , чтобы увидеть, как память работает с течением времени.

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

Взгляните на аргументы JVM: http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#DebuggingOptions

XX: -PrintGC Print сообщения при сборке мусора. Управляемый.

-XX: -PrintGCDetails Распечатать более подробную информацию о сборке мусора. Manageable. (Introduced in 1.4.0.)

-XX:-PrintGCTimeStamps Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)

-XX:-PrintTenuringDistribution Print tenuring age information.

While you're not going to upset the JVM with explicit calls to System.gc() they may not have the effect you are expecting. To really understand what's going on with the memory in a JVM with read anything and everything the Brian Goetz writes.