Индикация памяти утечки это приложение [дубликат]
Вы скомпилировали свой Java-класс с JDK 7, и вы пытаетесь запустить тот же класс на JDK 6.
5 ответов
Max memory = [-Xmx] + [-XX:MaxPermSize] + number_of_threads * [-Xss]
здесь максимальная память кучи как -Xmx, минимальная память кучи как -Xms, стек памяти как -Xss и -XX maxPermSize
Следующий пример иллюстрирует эту ситуацию. Я запустил свой tomcat со следующими параметрами запуска:
-Xmx168m -Xms168m -XX:PermSize=32m -XX:MaxPermSize=32m -Xss1m
Вы пытались использовать JVisualVM?
http://docs.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html
Я часто находил, что это помогает мне отслеживать этот материал. Он покажет вам, сколько из каждого типа памяти используется, даже позволяя вам разобраться и узнать.
-
1
-
2Он должен находиться в каталоге bin JDK (а не JRE); который не может быть на вашем PATH. – danpaq 8 March 2013 в 19:08
Команда Top отражает общий объем памяти, используемой приложением Java. Это включает в себя, среди прочего:
- Основная накладная память самой JVM
- пустое пространство (ограниченное -Xmx)
- Постоянное поколение space (-XX: MaxPermSize - не стандартно во всех JVM)
- пространство стека потоков (-Xss за стек), которое может значительно увеличиться в зависимости от количества потоков
- Пространство, используемое native распределения (с использованием класса ByteBufer или JNI)
-
1Нет байтовых буферов (если только в них не используется структура коллекций), ограничение PermGen, похоже, ничего не меняет. Я называю System.arraycopy, который, я считаю, использует JNI, верно? Может ли это так? – dspyz 7 March 2013 в 23:42
-
2@dspyz: Я не думаю, что arrayCopy использует дополнительное пространство вне пространства кучи. Он копирует данные из одного места кучи в другое. Я бы пересмотрел количество потоков, созданных вашим приложением. – Eyal Schneider 7 March 2013 в 23:47
-
3Нет, однопоточный. Все, что я вижу (в отладчике eclipse), это Main thread, Signal Dispatcher, Finalizer и Reference Handler – dspyz 7 March 2013 в 23:49
-
4@dspyz: Как насчет общей памяти процесса? Я думаю, вы можете проверить это с помощью jmap (jmap & lt; process id & gt;). Когда вы запускаете несколько java-процессов, их общая память не является суммой, отображаемой сверху, так как они используют общие библиотеки. – Eyal Schneider 8 March 2013 в 00:05
-
5Он также включает в себя размер разделяемых библиотек / dll и, возможно, пространство, которое ОС использует для кэширования загруженных файлов классов и т. Д. – Ingo 8 March 2013 в 00:38
С -Xmx вы настраиваете размер кучи. Для настройки размера стека используйте параметр -Xss. Сумма этих двух параметров должна быть примерно такой, какой вы хотите:
-Xmx150m -Xss50m
например.
Кроме того, имеется также параметр -XX:MaxPermSize, который управляет. Этот параметр для -client имеет значение по умолчанию 32 МБ и для -server 64 МБ. В соответствии с вашей конфигурацией вычислите его также. Пространство PermGen:
Постоянное поколение используется для отображения отражающей самой виртуальной машины, такой как объекты класса и объекты метода.
Таким образом, в основном он хранит внутренние данные JVM, такие как определения классов и встроенные строки.
В конце я должен сказать, что есть одна часть, которую вы не можете контролировать, то есть память, используемая собственным процессом Java. Java - это программа, как и любая другая, поэтому она также использует память. Если вы просматриваете использование памяти в диспетчере задач, вы также увидите эту память вместе с потреблением вашей программной памяти.
-
1
-
2Спасибо, я только что нашел и попробовал это. Это не имело значения. Я не использую память стека. Где еще это могло произойти, если это не куча или стек – dspyz 7 March 2013 в 23:38
-
3
-
4Загруженные классы идут туда, и я думаю, может быть, какая-то статика. Вы можете установить его с помощью -XX: MaxPermSize = 128M – danpaq 7 March 2013 в 23:44
-
5
Важно отметить, что «используемая общая память» (RSS на территории Linux) включает кучу JDK (+ другие области JDK), а также выделенную «родную память».
Например, эти люди обнаружил, что выделение слишком большого количества jaxbcontexts (которые связаны с родной памятью) между GC может заставить его использовать много дополнительной ОЗУ. Другой распространенный, по-видимому, ZipInflater, если вы не вызываете его близко (или GZipStream и т. Д.)
http://sleeplessinslc.blogspot.com/2014/08/jvm-native- memory-leak.html
. Его последнее решение об обходе / исправлении было более «GC» чаще всего (с помощью сборщика мусора GC1 или указав меньший [иронически] -Xmx) или путем кэширования объектов JaxBContext (поскольку у них нет метода close, поэтому вы не можете контролировать утечку).
Также обратите внимание, что иногда вы можете найти виновников памяти, просто изучив jstack: http://javaeesupportpatterns.blogspot.com/2011/09/jaxbcontext-performance-problem-case.html
Иногда также возможно «пропустить» закрытие, например, GZipStreams случайно http://kohsuke.org/2011/11/03/quiz-time-memory-leak-in-java