Що насправді робить прапор JVM CMSClassUnloadingEnabled?

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

Я заглянув на сайт Sun / Oracle, і навіть список параметрів насправді не говорить про те, що він робить.

Виходячи з назви прапора, я здогадуюсь, що CMS Garbage Collector за замовчуванням не розвантажує класи, і цей прапор вмикає його - але я не можу бути впевнений.

Оновлення Ця відповідь стосується 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 назавжди. Якщо ви працюєте на сервері, це означає, що у вас є витік пам'яті.

Якщо ввімкнути, CMSClassUnloadingEnabledGC також змістить PermGen і видалить класи, які більше не використовуються.

[EDIT] Також вам доведеться ввімкнути UseConcMarkSweepGC(завдяки Сем Хаслер ). Дивіться цю відповідь: https://stackoverflow.com/a/3720052/2541

Відповідно до публікації в блозі Найповніший список опцій -XX для Java JVM , він визначає, чи включено розвантаження класів під колектором сміття CMS. Типовим є false. Існує ще один варіант називається ClassUnloadingце trueза замовчуванням , які (ймовірно) впливають на інші збирач сміття.

Ідея полягає в тому, що якщо GC виявить, що завантажений раніше клас більше не використовується ніде в JVM, він може відновити пам'ять, що використовується для утримання байт-коду та / або нативного коду класів.

Налаштування CMSClassUnloadingEnabled може допомогти з вашою проблемою permgen, якщо ви зараз використовуєте колектор CMS . Але ймовірність полягає в тому, що ви не використовуєте CMS або у вас є витоку пам'яті, пов’язаної з справжнім завантажувачем. В останньому випадку ваш клас ніколи не виявиться в GC невикористаним ... і тому ніколи не буде завантажений.

Аарон Дігулла каже, що "заняття навіки". Це не зовсім вірно, навіть у суто явському світі. Насправді, термін експлуатації класу пов'язаний з його завантажувачем. Тож якщо ви можете домовитись, що завантажувач класів збирає сміття (а це не завжди легко зробити), класи, які він завантажував, також будуть збирати сміття.

Насправді, це те, що відбувається, коли ви робите гарячу передислокацію веб-сторінки. (Або, принаймні, саме це має статися, якщо ви зможете уникнути проблем, які призводять до витоку накопичувача пермгену.)

Приклад, коли це корисно:

Встановлення -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