Большинство людей не знает, что такое RMI DGC. И большинству людей не нужно знать, что такое RMI DGC. Это я к тому, что мы с вами не входим в это большинство, так что по ссылке сходить стоит. Благо, текста там немного.

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

Короче, чтобы JBOSS работал побыстрее, вставь эту строку в run.conf (который, напоминаю, расположен в $JBOSS_HOME/bin) куда-нибудь после того IF-a, что мы изменяли в предыдущей статье:

JAVA_OPTS="$JAVA_OPTS -Dsun.rmi.dgc.client.gcInterval=3600000 
-Dsun.rmi.dgc.server.gcInterval=3600000"

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

Есть еще один вариант. Можно запретить любому коду (в том числе и RMI подсистеме) запускать принудительную очистку мусора ,так что вместо вышеуказанных опций можно указать XX:+DisableExplicitGC. В этом случае сборка мусора будет запускаться если куча будет заполнена примерно на 70% (это дефолтное значение и оно тоже настраивается).

Какой из двух вариантов использовать? Не знаю, пока тестирую оба, посмотрим, что получится.

Возникает вопрос, а когда нужно это поведение-по-умолчанию RMI DGC? Никогда. Конечно, если твой код выполняет кучу вызовов удаленных объектов (remote object calls) (EJB, привет! :) и при этом не кэширует ваши LOCAL или REMOTE объекты, то тогда, _возможно_, очистки мусора раз в час будет недостаточно.

Те, кто хотят узнать побольше про управлению памятью, могут почитать вот эти мои статьи.

Прежде чем рассказать о том, как работает сборка мусора в современной JVM (1.4, 1.5), давайте поговорим о поколениях объектов. В динамической памяти приложения некоторые объекты становятся мусором вскоре после создания, некоторые живут в течение долгого времени и только затем становятся мусором, другие могут остаться в живых в течение всего времени работы программы. Как показывает практика, в большинстве объектно-ориентированных языков, включая Java, огромное количество объектов, приблизительно 98 % , умирают молодыми. Возраст объектов можно измерять в секундах настенных часов, в общем количестве байтов, выделенных подсистемой управления памятью, с тех пор, как объект был размещен, или в числе сборок мусора с момента размещения объекта. Но как бы Вы не измеряли, большинство исследований показывает, что объекты умирают молодыми. Тут я даже постарался и с помощью Google Chart Creator нарисовал график: Так как мы живем в неидеальном мире, у каждого из этих алгоритмов есть как преимущества, так и недостатки. Например, копирование хорошо работает, когда большой процент объектов является мусором (потому что этот вид сборщиков мусора не посещает мертвые объкты – он просто копирует живые объекты), но плохо работает с большим количеством долгоживущих объектов (периодически выполняя их копирование). Наоборот, маркировка-сжатие вполне хорошо работает с долгоживущими объектами (копируя их только один раз), но не так хорошо с большим количеством объектов, живущих недолго. Теперь, зная это, можно сделать вывод, что лучшим вариантом сборки мусора было бы использование копирующего сборщика мусора, а для долгоживущих – маркирующе-сжимающего. На основе подобных рассуждений, в Java был введен метод сборки мусора, берущий лучшее от обоих алгоритмов и нивелирующих их недостатки: так называемая «основанная на поколениях сборка мусора». Дополнительно он обеспечивает очень низкие затраты на размещение объектов.

Сборка мусора на основе поколений

Сборщик мусора, основанный на поколениях, делит динамическую память на несколько поколений – youth (молодые), tenured (Дословно – выжившие. На мой взгляд, очень поэтично :), perm – вечные. Youth дополнително делится на область генерации объектов Eden (совсем поэтично) и две полузоны для работы копирующего сборщика. Я еще не говорил. Объекты, отвечающие некоторым критериям продвижения, например, они пережили определенное число сборок мусора, затем переводятся в более старшее поколение – сначала Tenured (убирается маркирующе-сжимающим сборщиком мусора), затем и Perm (вообще не убирается). Одно из преимуществ сборки мусора на основе поколений заключается в том, что она может сократить паузы, не обрабатывая все поколения сразу. Если распределитель ресурсов не способен выполнить запросы на размещение, то он сначала запускает вспомогательные сборки мусора, которые обрабатывают только самое младшее поколение. Так как многие объекты в молодом поколении будут уже мертвы, а копирующему сборщику мусора совсем не надо проверять мертвые объекты, то паузы на вспомогательные сборки мусора могут быть достаточно малыми, и зачастую могут возвращать значительный объем динамической памяти. Если вспомогательная сборка мусора освобождает достаточно места в динамической памяти, то мутатор может немедленно возобновить работу. Если же она освобождает недостаточно места в динамической памяти, то сборка продолжится в более старших поколениях до тех пор, пока не будет возвращен достаточный объем памяти. (В случае если сборщик мусора не может возвратить достаточный объем памяти после полной сборки мусора, то он или расширит динамическую память, или выдаст OutOfMemoryError.) В принципе, уже из этого понятно, что такое PermGen, и почему у него заканчивается место при redeploy’е. Желающие узнать больше о принципах работы поколенного сборщика мусора могут обратиться к еще одной статье Брайна Гетца «Сборка мусора в HotSpot JVM«. Отдельно стоит упомянуть про многопроцессорные системы. В ранних версиях JDK сборка мусора в параллельных потоках сильно замедляла работу систему. Я даже спиздел из статьи Tuning Collection with the 5.0 Java[tm] Virtual Machine классную картинку, которая визуализирует зависимость между временем сборки мусора и количеством процессоров:   К счастью, в JDK 1.4 добавили специально для таких систем еще три сборщика мусора: параллельный копирующий сборщик мусора, параллельный утилизирующий сборщик мусора и синхронизированный маркирующе-чистящий сборщик. Эти новые сборщики призваны решить проблему сборки мусора, которая является основным припятствием для решения проблемы масштабируемости на многопроцессорных системах. Ну и напоследок еще одна пизженная у Брайна Гетца картинка, на которой проиллюстрированы рекомендации для выбора сборщика мусора:   

Настройка JBOSS AS

PermGen Space : OutOfMemory exception вылетает от того, что оставшиеся от предыдущего deploy’я вечные объекты так и остаются в PermGen (это я не знаю, а предполагаю – и могу ошибаться) и PermGen Space рано или поздно переполняется. Соответственно, для решения этой проблемы нам надо как-то заставить сборщик мусора убирать более не нужные объекты в PermGen. На практике это выглядит так: 1. открываем файл run.conf в папке bin jboss’a, находим строку, начинающуюся с JAVA_OPTS и добавляем в нее следующие параметры: 2. Разрешаем сборщику мусора убирать PermGen: -XX:+CMSPermGenSweepingEnabled 3. Так как JVM так просто не отдаст на растерзание Perm объекты, надо умилостивить ее: -XX:+CMSClassUnloadingEnabled 4. Для того, чтобы сборщик мусора не прибил нужные нам объекты, нам нужно увеличить размер PermGen: -XX:MaxPermSize=128m 5. (Опционально) Если jboss вертится на многопроцессорной системе, то не забудьте включить синхронизированный сборщик мусора: -XX:+UseConcMarkSweepGC Для удобства использования выложу мою строку JAVA_OPTS:

JAVA_OPTS="-Xms256m -Xmx1024m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m"

Примерно так же я относился до недавнего времени к регулярно вылетающим PermGen: OutOfMemory exception от JBOSS Application Server на моем ноуте. Ну, бывает иногда, и хуй с ним.

Пока однажды я не заметил, что перезапускаю сервер по три-четыре раза в час, теряя на этом минут пять. Пять минут в час, если кто не понял – это 730 часов в год или 30 дней, или месяц. Месяц тупого пяленья в мелькающие в консоли строки загрузки сервера и initial deploy’я проекта! Блядь!

И я решил раскопать, что именно вызывает этот самый PermGen: OutOfMemory exception. Чтобы, разумеется, «протянуть нормальную проводку».

Прежде чем начинать разговор о том, что такое PermGen, и почему в нем заканчивается место, а также как это поправить, я расскажу на пальцах, как Java^TM работает с памятью, что такое сборщики мусора, какие виды сборщиков мусора бывают и как они работают в современных JVM.

I. Общие слова

Так уж исторически сложилось, что в отношении работы с памятью Java сравнивают с c++. Корни такого подхода лежат еще в тех временах, когда Java нигде толком не использовалась, но уже активно рекламировалась и им нужно было как-то перетягивать разработчиков с c++.

В c++ в общем случае выделение памяти происходит явно с помощью явно написанного конструктора, в котором разработчик часто вручную управляет выделением памяти с помощью операторов malloc/calloc, причем разработчику надо явно проинициализировать переменные, с которыми он работает. Удаление объекта производится вызовом деструктора, который также пишется вручную, и лучше бы ему не забыть очистить всю память, которую он выделил под объект, иначе он замудохается искать, куда утекает память приложения.

В Java^TM возлагает на виртуальную машину управление памятью – выделение памяти под объекты, удаление объектов, освобождение памяти. В том же самом общем случае объекты хранятся в куче, а не в стеке (за исключением примитивных типов), что увеличивает время выделение памяти и доступа к объекту. Зато JVM их 100% проинициализирует, так что вы не получите -44441222, обратившись к непроинициалированному явно int’у.

Во-вторых, удалением объекта и освобождением памяти занимается не вручную написанный деструктор, а сборщик мусора (garbage collector), работающий в параллельном потоке. Что, с одной стороны, очень хорошо – теперь программисту не нужно думать о том, прибрался ли он за собой, а также о том, где взять память, но, с другой стороны, неизвестно, когда именно сборщик мусора утилизует объект и отдаст свободную память. Не говоря уж о том, что сборщик мусора тоже требует для своей работы системных ресурсов.

II. Выделение памяти

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

Рассмотрим простейший пример:

public class FuckingExample {
    int x;
}
FuckingExample boolShit = new FuckingExample();

С помощью оператора new мы можем создать новый объект. При этом JVM самостоятельно выделит память под объект и проинициализирует его поля (в данном примере – x). В отличии от C++ в Java не нужно писать конструктор по умолчанию – JVM в случае его отсутствия самостоятельно справится с инициализацией объекта.

В отличии от все того же многострадального C++ не нужно явно инициализировать поля с примитивными типами – JVM дает гарантию, что присвоит переменной примитивного типа значение этого типа по умолчанию. Другими словами, вы можете быть уверенными, что в случае, если вы явно не проинициалируете переменную, как в примере, то значение x будет равно 0, а не мусору, как было бы в C++.

Впрочем, не все объекты располагаются в куче. Для примитивных типов сделано исключение, они располагаются в стеке. Если же нужен не примитивный тип int, а объект типа Integer (ну, к примеру, тебе понадобились специфические метода этого объекта), то надо объявить его так:

Integer x = new Integer(2);

В этом случае x является экземляром класса Integer и располагаться в куче.

На этом месте я закончу с выделением памяти, интересующиеся могут обратиться к книге Брюса Экеля «Философия JAVA» или к спецификации языка

III. Освобождение памяти. Алгоритмы сборщиков мусора

Надеюсь, все заметили, что в примере, приведенном выше, у класса FuckingExample нет деструктора. Это потому, что он не нужен. После того, как объект станет (на него не будет ссылки из статической переменной или активного фрейма стека), он будет передан сборщику мусора, который очистит от него память и вернет эту свободную память приложению.

Как же именно работают эти самые сборщики мусора? Ответ на это дает нам статья Брайана Гетца «Краткая история развития технологии утилизации памяти«, которую я бессовестно спиздел, слегка переработав.

Выделяют два типа алгоритмов сборщика мусора: подсчет ссылок и трассирующие сборщики мусора.

Подсчет ссылок

Идея очень простая: Каждый объект имеет ассоциированное с ним количество ссылок – число активных ссылок на данный объект. Если количество ссылок равно нулю – это мусор (недоступный для пользовательской программы), и он может быть переработан.
Но эта простая идея требует значительной поддержки от компилятора и даёт дополнительную избыточность для мутатора (термин для пользовательской программы с точки зрения сборщика мусора). Каждый раз, когда модифицируется ссылка на указатель, например, с помощью оператора присваивания, или когда ссылка выходит за границу, компилятор должен генерировать код для того, чтобы обновить количество ссылок на указываемый объект. Если количество ссылок на объект доходит до нуля, среда выполнения может вернуть блок информации немедленно (и уменьшить количество ссылок для всех блоков, на которые ссылается возвращаемый блок) или поместить его в очередь для отсроченной утилизации.

Собственно, это все, что нужно знать про этот алгоритм сборки мусора. Все равно он на практике сейчас не используется.

Трассирующие сборщики мусора

Трассирующий сборщик останавливает приложение (хоть это и не нужно на весь период сборки мусора) и начинают трассировать объекты, начиная с корневого набора, и проходят по всем ссылкам, пока все доступные объекты не будут проверены. Корни могут быть найдены в регистрах программ, в локальных (стековых) переменных, в стеке каждого из потоков и в статических переменных.

Маркирующе-зачищающие сборщики мусора

Наиболее простая форма трассирующего сборщика мусора, впервые предложенная создателем языка Lisp Джоном Маккарти в 1960г., – это маркирующе-зачищающий сборщик, в котором среда выполнения останавливается, и сборщик посещает каждый живой узел, начиная с корней, и маркирует каждый посещённый узел. Когда не существует больше не отслеженных ссылок, сборка мусора завершена, и затем динамическая память зачищается (то есть каждый объект динамической памяти проверяется), а любой непомеченный объект регенерируется как мусор и возвращается в список свободной памяти.

Маркировка-зачистка проста для реализации, может легко восстанавливать циклические структуры и не даёт дополнительной нагрузки на компилятор или мутатор как подсчёт ссылок. Но у неё есть недостатки – паузы на сбор мусора могут быть долгими, и вся динамическая память посещается в фазе зачистки, что может иметь весьма негативные последствия на работу систем с виртуальной памятью, где динамическая память может быть разбита на страницы.

Большая проблема с маркировкой-зачисткой состоит в том, что каждый активный (то есть, распределённый) объект, доступен он или нет, посещается в фазе зачистки. Потому что значительный процент объектов, вероятно, окажется мусором, что означает, что сборщик тратит значительные усилия на проверку и обработку мусора. Маркирующе-зачищающие сборщики мусора также имеют тенденцию фрагментировать динамическую память, что может вызвать проблемы с локализацией и может также стать причиной ошибок выделения памяти, даже когда доступно достаточное количество свободной памяти.

Копирующие сборщики мусора

В копирующем сборщике, другом виде маркирующего сборщика, динамическая память делится на две равные по размеру части, одна из которых содержит активные данные, а другая не используется. Когда активная часть заполнена, среда выполнения останавливается, и действующие объекты копируются из активной части в неактивную. При этом части меняются своими ролями: старая неактивная часть становится активной и наоборот.

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

Копирующие сборщики приносят пользу ещё и тем, что живые объекты уплотняются в нижнюю часть динамической памяти. Это не только улучшает локальность ссылок пользовательской программы и позволяет избежать фрагментации динамической памяти, но и значительно уменьшает затраты на размещение объекта. Эта процедура становится просто добавлением ссылки к указателю вершины динамической памяти. Нет необходимости поддерживать списки свободной памяти или сохраняющиеся списки или выполнять алгоритмы наилучшей подгонки или первого подходящего – выделение места для N байт сводится к добавлению N к указателю вершины динамической памяти и возвращению его предыдущего значения.

Разработчики, которые использовали сложные схемы управления памятью для языков, не использующих сборщики мусора, могли бы сильно удивиться тому, насколько незатратным может быть распределение памяти – простое добавление ссылки – в копирующем сборщике мусора. Это может быть одной из причин распространённого мнения, что распределение объектов связанно с затратами, в более ранних версиях виртуальной машины Java не использовались копирующие сборщики мусора, и разработчики все еще подспудно считают, что затраты на распределение такие же, как в других языках, типа C, тогда как на самом деле они могут быть значительно меньше в исполняемой среде Java. Но не только издержки на распределение памяти меньше, но также для объектов, которые превратились в мусор до начала следующего цикла сборки, затраты на освобождение памяти равны нулю, так как утилизируемый объект не будет ни проверяться, ни копироваться.

Маркирующе-сжимающие сборщики мусора

Копирующий алгоритм имеет прекрасные рабочие характеристики, но его основным недостатком является потребность в объёме памяти большем в два раза, чем объём, необходимый для маркирующе-зачищающего сборщика мусора. Алгоритм маркировки-сжатия сочетает маркировку-зачистку и копирование таким образом, что эта проблема исчезает за счет того, что процесс сборки мусора усложняется. Как и маркировка-зачистка, маркировка-сжатие состоит из двух фаз. В фазе маркировки каждый действующий объект рассматривается и маркируется. Затем маркированные объекты копируются таким образом, что все действующие объекты уплотняются в самом низу динамической памяти. Если полное сжатие совершается при каждой сборке мусора, полученная в результате динамическая память такая же как и результат работы копирующего сборщика – между активной частью динамической памяти и свободной существует чёткая граница, так что затраты на размещение сравнимы с затратами при использовании копирующего сборщика мусора. Долгоживущие объекты имеют тенденцию накапливаться в самом низу динамической памяти, поэтому они не копируются циклически, как при использовании копирующего сборщика мусора.