Что делает флаг JVM, который на самом деле делают CMSClassUnloadingEnabled?

Я не могу ни за что в жизни найти определение какой флаг Java VM CMSClassUnloadingEnabled на самом деле делает, кроме некоторых очень нечетких высокоуровневых определений тех, которые "избавляются от Ваших проблем PermGen" (который это не делает, btw).

Я считал сайт Sun/Oracle, и даже в списке опций на самом деле не говорится, что он делает.

Основанный на названии флага, я предполагаю, что Сборщик "мусора" CMS по умолчанию не разгружает классы, и этот флаг включает его - но я не могу быть уверен.

182
задан Community 23 May 2017 в 02:03
поделиться

2 ответа

Обновление Этот ответ актуален для Java 5-7, в Java 8 это исправлено: https://blogs.oracle.com/poonam/about-g1-garbage -collector, -permanent-generation-and-metaspace Престижность mt.uulu

Для Java 5-7:

Стандартный взгляд на мир Oracle / Sun VM: Классы навсегда . Так что после загрузки они остаются в памяти, даже если никому нет до них дела. Обычно это не проблема, так как у вас не так много чисто "установочных" классов (= используется один раз для установки, а затем больше никогда). Так что даже если они занимают 1 МБ, кого это волнует.

Но в последнее время у нас есть такие языки, как Groovy, которые определяют классы во время выполнения.Каждый раз, когда вы запускаете скрипт, создается один (или несколько) новых классов, которые навсегда остаются в PermGen. Если вы используете сервер, это означает, что у вас утечка памяти.

Если вы включите CMSClassUnloadingEnabled , GC также очистит PermGen и удалит классы, которые больше не используются.

[РЕДАКТИРОВАТЬ] Вам также необходимо включить UseConcMarkSweepGC (спасибо Sam Hasler ). См. Этот ответ: https://stackoverflow.com/a/3720052/2541

215
ответ дан 23 November 2019 в 06:07
поделиться

Согласно сообщению в блоге Самый полный список параметров -XX для Java JVM , он определяет, включена ли выгрузка классов в сборщике мусора CMS. По умолчанию ложь . Существует еще одна опция, называемая ClassUnloading , которая по умолчанию true , которая (предположительно) влияет на другие сборщики мусора.

Идея состоит в том, что если GC обнаруживает, что ранее загруженный класс больше не используется в JVM, он может освободить память, используемую для хранения байт-кода классов и / или собственного кода.

Настройка CMSClassUnloadingEnabled может помочь с вашей проблемой перманента , если вы в настоящее время используете сборщик CMS . Но есть вероятность, что вы не используете CMS или у вас есть настоящая утечка памяти, связанная с загрузчиком классов. В последнем случае ваш класс никогда не будет казаться сборщику мусора неиспользованным ... и, следовательно, никогда не будет выгружен.


Аарон Дигулла говорит: «Уроки вечны». Это не совсем так, даже в чисто Java-мире. Фактически, время жизни класса привязано к его загрузчику классов. Поэтому, если вы можете организовать сборщиком классов мусора (а это не всегда легко сделать), загруженные им классы также будут сборщиком мусора.

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

35
ответ дан 23 November 2019 в 06:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: