CMSClassUnloadingEnabled JVM bayrağı gerçekte ne yapar?

Hayatım boyunca Java VM bayrağının CMSClassUnloadingEnabledgerçekte ne yaptığının bir tanımını bulamıyorum , "PermGen problemlerinizden kurtuluyor" gibi bazı çok yüksek seviyeli tanımlar dışında ( ki öyle değil , btw).

Sun'ın / Oracle'ın sitesine baktım ve seçenekler listesi bile aslında ne yaptığını söylemiyor.

Bayrağın ismine dayanarak, CMS Çöp Toplayıcısı'nın varsayılan olarak sınıfları kaldırmadığını ve bu bayrağın açıldığını tahmin ediyorum - ama emin olamıyorum.

Güncelleme Bu cevap Java 5-7 için geçerlidir, Java 8'de şu düzeltmeler yapılmıştır : https://blogs.oracle.com/poonam/about-g1-garbage-collector,-permanent-generation-and-metaspace Kudos mt'a gider . Uulu

Java 5-7 için:

Dünyadaki standart Oracle / Sun VM görünümü: Sınıflar sonsuza dek. Yüklendikten sonra, artık kimsenin umurunda olmasa bile hafızada kalırlar. Çok fazla "kurulum" sınıfına sahip olmadığınız için bu genellikle sorun olmaz (= kurulum için bir kez ve daha sonra bir daha asla kullanılmaz). Yani 1MB alırlarsa bile kimin umurunda.

Ancak son zamanlarda, Groovy gibi, çalışma zamanında sınıfları tanımlayan dillerimiz var. Her komut dosyasını çalıştırdığınızda, bir (veya daha fazla) yeni sınıf oluşturulur ve sonsuza dek PermGen'de kalırlar. Bir sunucu çalıştırıyorsanız, bellek sızıntısı olduğu anlamına gelir.

CMSClassUnloadingEnabledGC'yi etkinleştirirseniz PermGen'i de süpürür ve artık kullanılmayan sınıfları kaldırır.

[EDIT] Ayrıca etkinleştirmeniz gerekecek UseConcMarkSweepGC( Sam Hasler sayesinde ). Bu yanıta bakın: https://stackoverflow.com/a/3720052/2541

Blog gönderisine göre Java JVM için -XX seçeneklerinin en eksiksiz listesi , CMS çöp toplayıcısı altında sınıf boşaltma özelliğinin etkin olup olmadığını belirler. Varsayılan değer false. Adlı başka bir seçenek var ClassUnloadingolduğu true(muhtemelen) başka çöp toplayıcıları etkileyen varsayılan olarak.

Fikir şu ki, GC daha önce yüklenmiş bir sınıfın JVM'de artık kullanılmadığını tespit ederse, sınıfların bayt kodunu ve / veya yerel kodu tutmak için kullanılan belleği geri kazanabilir.

CMSClassUnloadingEnabled öğesini ayarlamak , şu anda CMS toplayıcısını kullanıyorsanız permgen sorununuza yardımcı olabilir . Ancak, CMS kullanmamanız ya da sınıf yükleyiciyle ilgili gerçek bir bellek sızıntısı olma ihtimaliniz vardır. İkinci durumda, sınıfınız asla GC'ye kullanılmamış gibi görünmeyecektir ... ve bu nedenle asla boşaltılmayacaktır.

Aaron Digulla "sınıflar sonsuza dek" diyor. Bu tamamen Java dünyasında bile kesinlikle doğru değildir. Aslında, bir sınıfın ömrü sınıf yükleyicisine bağlıdır. Dolayısıyla, bir sınıf yükleyicinin çöp toplandığını (ve bu her zaman kolay bir şey değildir) ayarlayabilirseniz, yüklediği sınıflar da çöp toplanır.

Aslında, bir web uygulamasının sıcak yeniden dağıtımını yaptığınızda olan şey budur. (Ya da en azından, kalıcı bir depolama sızıntısına yol açan sorunları önleyebiliyorsanız, olması gereken budur.)

Bunun yararlı olduğu bir örnek:

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabledWeblogic 10.3 JVM ürünümüzü ayarlamak , JAX-WS uygulamasının her web hizmeti çağrısı için yeni bir proxy sınıfı oluşturması ve sonunda bellek yetersizliğine yol açması sorununu çözmeye yardımcı oldu.

İzlemek önemsiz değildi. Aşağıdaki kod her zaman için aynı proxy sınıfını döndürdü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);

Dahili olarak, bu vekil , her çağrıda artırılan weblogic.wsee.jaxws.spi.ClientInstanceyeni bir $Proxy[nnnn]sınıfa yeniden temsil edilen bir örneğine devredildi n. Bayrakları eklerken n, hala artırıldı, ancak en azından bu geçici sınıflar bellekten kaldırıldı.

Daha genel bir not olarak, Java yansıması ve proxy'leri yoğun bir şekilde kullanırken bu çok yararlı olabilir. java.lang.reflect.Proxy