javaspecialist 14 апр 2011 в 05:02

Какие бывают типы OutOfMemoryError или из каких частей состоит память java процесса

3 мин

210K

Java *

+70

Комментарии 39

ghosthope 14 апр 2011 в 05:10

Вот тебе бабушка и garbage collector.

kekekeks 14 апр 2011 в 05:32

Наличие GC не освобождает от обязанности задействовать мозг при написании кода.

ghosthope 14 апр 2011 в 06:03

Приведите пример программного кода в Java для принудительной очистки памяти?

atd 14 апр 2011 в 06:05

System.gc();?

ghosthope 14 апр 2011 в 06:07

Методы System.gc() и Runtime.gc() выглядят, как «запустить сборщик мусора», но и на них нельзя полагаться, поскольку другие более приоритетные потоки могут отложить их выполнение. И на самом деле, документация для методов gc() гласит: «Вызов этих методов подразумевает, что JVM приложит усилия для переработки неиспользуемых объектов».

ghosthope 14 апр 2011 в 06:11

When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

javaspecialist 14 апр 2011 в 06:20

Вчера на javaone говорили, что реализация HotSpot JVM с большим пристрастием относится к этим указаниям, и можно быть уверенным, что она, действительно, очень быстро запустит сборку мусора.

barker 14 апр 2011 в 06:10

Приведите пример программного кода в Java для принудительной очистки памяти?

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

НЛО прилетело и опубликовало эту надпись здесь

barker 14 апр 2011 в 05:32

Интересно пишете.

barker 14 апр 2011 в 05:40

на машинах с 32-битной архитектурой. Особенно на windows, где по умолчанию, память на один процесс ограничена двумя гигабайтами.

Почему «особенно»? А где по другому?

javaspecialist 14 апр 2011 в 05:46

На UNIX больше можно. Сколько точно не знаю, но там только один хип (-Xmx) можно выдавать до 3G.

atd 14 апр 2011 в 06:03

в винде с флагом /3GB тоже 3 будет

pyatigil 14 апр 2011 в 06:18

не будет, см мой коммент ниже

barker 14 апр 2011 в 06:07

Ну так больше 4G процесс не может адресовать физически, какой бы чудесной система ни была) А сколько в чистом отдать процессу за вычетом системы — это уже от ОС только зависит. И в винде можно отдать 3+ гб и в линуксах.

pyatigil 14 апр 2011 в 06:36

Бтв, где-то читал, что на «родной» solaris под джаву можно выделить практически полные 4Гб (типа 3.9 там было)

pyatigil 14 апр 2011 в 06:17

Дело в том, что JVM требует непрерывный кусок виртуальной памяти, а винда по легаси причинам мапит в вирт память в районе отметки 3Гб всякий хлам: куски ядра, видео память и т.п. Поэтому память для JVM можно выделить только от конца ядра и до 3Гб. Именно поэтому под виндой трудно создать джава машину с хипом более 1.2-1.4Гб.

javaspecialist 14 апр 2011 в 06:29

Я тогда абзац про флаг в windows из своей статьи удаляю? pyatigil, можете дать ссылку про то что вы говорите? Или есть еще эксперты в этой области подтвердить сказанное pyatigil?

pyatigil 14 апр 2011 в 06:33

Вот пруф, на сановском блоге: blogs.sun.com/moazam/entry/why_can_t_i_allocate

pyatigil 14 апр 2011 в 06:35

по ссылке интересен не столько сам пост, сколько коммент от одного из инженеров sun jvm

Lamaster 16 сен 2015 в 10:00

Новый линк https://blogs.oracle.com/moazam/entry/why_can_t_i_allocate

Blackened 14 апр 2011 в 06:13

Размер задается параметрами -Xms и -Xmx.

Возможно, -Xmn на рисунке — это опечатка, и должно значиться -Xms?

pyatigil 14 апр 2011 в 06:18

Xms это память с которой джвм стартует. Xmn на картинке — это размер young generation, он к теме отношения в общем-то не имеет, т.к. указывает внутреннюю структуру heap (какую часть хип выделать для GC на т.н. young generation)

Blackened 14 апр 2011 в 06:29

Всё ясно, спасибо.

atd 14 апр 2011 в 06:16

Вопрос к автору: а в пункте 4 вы не рассматривали вариант с пулом потоков? Или он вам не подошёл?

javaspecialist 14 апр 2011 в 06:26

Ну у меня вебсервер был. Тогда еще Servlet API 3.0 не было. Так что пул добавить для асинхронной обработки каких-то действий пользователя я не мог.

Хотя на самом деле томкат-то использует внути пул, чтобы обрабатывать запросы клиентов. Просто если он маленький, а клиентов много, то они начинают отваливаться по HTTP с таймаутом, поэтому размер этого пула и пришлось увеличивать все больше и больше.

drunken 14 апр 2011 в 06:40

У нас на build-сервере tomcat 6.0.30, ежедневно он валится с PermGen Space.
Мы считаем, что это от постоянных редеплоев аппликух. Доктор, это лечится? :)

javaspecialist 14 апр 2011 в 06:48

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

Конечно каждый конкретный случай надо разбирать отдельно. Если же не хочется разбираться, профайлить и искать причину, чтобы её фиксить, то если у вас CMS, попробуйте

-XX:+CMSPermGenSweepingEnabled 

-XX:+CMSClassUnloadingEnabled

Или еще вариант — возьмите JRocket (попробовать можно бесплатно), там говорят вообще проблем нет.

Или дождитесь пока oracle JRocket смержит в HotSpot.

xonix 14 апр 2011 в 08:38

JRockit, а так плюс

apangin 14 апр 2011 в 19:43

CMSPermGenSweepingEnabled устаревший параметр. Достаточно -XX:+CMSClassUnloadingEnabled

Неправда, что в JRockit нет этой проблемы. Просто она проявляется позже. Если Hotspot ограничивает размер class metadata, то JRockit позволяет забивать невыгружаемыми классами всю доступную виртуальную память. Однако если утечка памяти есть, она в любом случае проявится рано или поздно, причем в случае исчерпания виртуальной памяти последствия могут крайне неприятными: тормоза, уход в своп, блокировка работы других процессов на машине.

В принципе, уже можно потихоньку начинать радоваться избавлению Hotspot'а от PermGen. Уже сейчас вынесены из PermGen в C-heap symbols, interned strings и static fields. Впрочем, спорное решение, на мой взгляд.

javaspecialist 15 апр 2011 в 04:24

> CMSPermGenSweepingEnabled устаревший параметр. Достаточно -XX:+CMSClassUnloadingEnabled

Правильно, надо или нет добавлять CMSPermGenSweepingEnabled зависит от версии Java. Тем кто еще сидит на пятерке вполне может понадобиться.

В JRockit я не силен. Просто об этом сказали на javaone. За что купил, за то и продаю.

1nd1go 14 апр 2011 в 06:50

Возможно у вас проблемы с log4j на томкате. Погуглите log4j tomcat permgen. В ранних версиях томката класслоудер не освобождал классы log4j при андеплое, что приводило к увеличению их, когда приложуха несколько раз передеплоивалась

1nd1go 14 апр 2011 в 06:54

Да, вот статья по теме: blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java

1nd1go 14 апр 2011 в 06:55

И еще одна, про решение проблемы: www.samaxes.com/2007/10/classloader-leaks-and-permgen-space/

pyatigil 14 апр 2011 в 06:52

если есть настроение — нужно просто посмотреть, что туда лоадится, а потом не анлоадится. Попробуйте ключи -XX:+TraceClassLoading -XX:+TraceClassUnloading. Другой кандидат — intern строк.

НЛО прилетело и опубликовало эту надпись здесь

javaspecialist 14 апр 2011 в 07:10

Формально вы конечно же правы. Хотя никто не будет спорить, что доминирующая реализация — это HotSpot, так что, если ничего об этом не написано, то стоит предполагать что имеется ввиду именно она.

maxcom 14 апр 2011 в 07:23

это не все варианты — есть еще нехватка direct buffers, которая по своему выглядит и проявляется

javaspecialist 14 апр 2011 в 07:40

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий