Что на самом деле делает флаг JVM CMSClassUnloadingEnabled?

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

Для Java 5-7:

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

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

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

[EDIT] Вам также необходимо включить UseConcMarkSweepGC (спасибо Сэму Хаслеру). См. этот ответ: https://stackoverflow.com/a/3720052/2541

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

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

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

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

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

Пример, где это полезно:

Установка -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled в нашей Weblogic 10.3 JVM помогла решить проблему, когда реализация JAX-WS создавала новый прокси-класс для каждого вызова веб-службы, что в конечном итоге приводило к ошибкам нехватки памяти.

Проследить было не просто. Следующий код всегда возвращал один и тот же прокси-класс для port

final MyPortType port = 
Service.create(
        getClass().getResource("/path/to.wsdl"), 
        new QName("http://www.example.com", "MyService"))
    .getPort(
        new QName("http://www.example.com", "MyPortType"), 
        MyPortType.class);

Внутри этот прокси делегируется экземпляру weblogic.wsee.jaxws.spi.ClientInstance, который снова делегируется новому классу $Proxy[nnnn], где n увеличивается при каждом вызове. При добавлении флагов n по-прежнему увеличивалось, но, по крайней мере, эти временные классы были удалены из памяти.

В более общем плане это может быть очень полезно при интенсивном использовании отражения Java и прокси через java.lang.reflect.Proxy