Java
Comments 39
+15
Наличие GC не освобождает от обязанности задействовать мозг при написании кода.
-3
Приведите пример программного кода в Java для принудительной очистки памяти?
+2
Методы System.gc() и Runtime.gc() выглядят, как «запустить сборщик мусора», но и на них нельзя полагаться, поскольку другие более приоритетные потоки могут отложить их выполнение. И на самом деле, документация для методов gc() гласит: «Вызов этих методов подразумевает, что JVM приложит усилия для переработки неиспользуемых объектов».
+2
Вчера на javaone говорили, что реализация HotSpot JVM с большим пристрастием относится к этим указаниям, и можно быть уверенным, что она, действительно, очень быстро запустит сборку мусора.
0
Приведите пример программного кода в Java для принудительной очистки памяти?
Нет такого кода, да и речь не о том. Даже с GC от программиста сильно зависит насколько рационально будет использоваться память и как часто будет вызываться GC.
0
Принудительно не очистите. Но помочь можете. За null-айте массивные долгоживущие объекты когда они вам не нужны. Ему станет полегче)
+1
на машинах с 32-битной архитектурой. Особенно на windows, где по умолчанию, память на один процесс ограничена двумя гигабайтами.
Почему «особенно»? А где по другому?
0
На UNIX больше можно. Сколько точно не знаю, но там только один хип (-Xmx) можно выдавать до 3G.
-1
Ну так больше 4G процесс не может адресовать физически, какой бы чудесной система ни была) А сколько в чистом отдать процессу за вычетом системы — это уже от ОС только зависит. И в винде можно отдать 3+ гб и в линуксах.
0
Бтв, где-то читал, что на «родной» solaris под джаву можно выделить практически полные 4Гб (типа 3.9 там было)
+8
Дело в том, что JVM требует непрерывный кусок виртуальной памяти, а винда по легаси причинам мапит в вирт память в районе отметки 3Гб всякий хлам: куски ядра, видео память и т.п. Поэтому память для JVM можно выделить только от конца ядра и до 3Гб. Именно поэтому под виндой трудно создать джава машину с хипом более 1.2-1.4Гб.
0
Я тогда абзац про флаг в windows из своей статьи удаляю? pyatigil, можете дать ссылку про то что вы говорите? Или есть еще эксперты в этой области подтвердить сказанное pyatigil?
0
по ссылке интересен не столько сам пост, сколько коммент от одного из инженеров sun jvm
0
Размер задается параметрами -Xms и -Xmx.

Возможно, -Xmn на рисунке — это опечатка, и должно значиться -Xms?
+4
Xms это память с которой джвм стартует. Xmn на картинке — это размер young generation, он к теме отношения в общем-то не имеет, т.к. указывает внутреннюю структуру heap (какую часть хип выделать для GC на т.н. young generation)
0
Вопрос к автору: а в пункте 4 вы не рассматривали вариант с пулом потоков? Или он вам не подошёл?
+1
Ну у меня вебсервер был. Тогда еще Servlet API 3.0 не было. Так что пул добавить для асинхронной обработки каких-то действий пользователя я не мог.

Хотя на самом деле томкат-то использует внути пул, чтобы обрабатывать запросы клиентов. Просто если он маленький, а клиентов много, то они начинают отваливаться по HTTP с таймаутом, поэтому размер этого пула и пришлось увеличивать все больше и больше.
0
У нас на build-сервере tomcat 6.0.30, ежедневно он валится с PermGen Space.
Мы считаем, что это от постоянных редеплоев аппликух. Доктор, это лечится? :)
0
Я же давал ссылку в на свой блок в этой статье в пункте про PermGen, где подробно описывается почему это может происходить и что с этим делать.

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


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

Или дождитесь пока oracle JRocket смержит в HotSpot.
+1
CMSPermGenSweepingEnabled устаревший параметр. Достаточно -XX:+CMSClassUnloadingEnabled

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

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

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

В JRockit я не силен. Просто об этом сказали на javaone. За что купил, за то и продаю.
+1
Возможно у вас проблемы с log4j на томкате. Погуглите log4j tomcat permgen. В ранних версиях томката класслоудер не освобождал классы log4j при андеплое, что приводило к увеличению их, когда приложуха несколько раз передеплоивалась
0
если есть настроение — нужно просто посмотреть, что туда лоадится, а потом не анлоадится. Попробуйте ключи -XX:+TraceClassLoading -XX:+TraceClassUnloading. Другой кандидат — intern строк.
UFO landed and left these words here
+2
Формально вы конечно же правы. Хотя никто не будет спорить, что доминирующая реализация — это HotSpot, так что, если ничего об этом не написано, то стоит предполагать что имеется ввиду именно она.
+1
это не все варианты — есть еще нехватка direct buffers, которая по своему выглядит и проявляется
0
Я не спорю, что нет других случаев. Я написал только о тех с которыми сам сталкивался. Возможно я не очень явно это в топике обозначил…
Only those users with full accounts are able to leave comments. , please.