Live a simple life

【摘要】
        前面系統(tǒng)討論過java類型加載(loading)的問題，在這篇文章中簡要分析一下java類型卸載(unloading)的問題，并簡要分析一下如何解決如何運(yùn)行時加載newly compiled version的問題。

【相關(guān)規(guī)范摘要】
    首先看一下，關(guān)于java虛擬機(jī)規(guī)范中時如何闡述類型卸載(unloading)的：
    A class or interface may be unloaded if and only if its class loader is unreachable. The bootstrap class loader is always reachable; as a result， system classes may never be unloaded.
    Java虛擬機(jī)規(guī)范中關(guān)于類型卸載的內(nèi)容就這么簡單兩句話，大致意思就是：只有當(dāng)加載該類型的類加載器實(shí)例(非類加載器類型)為unreachable狀態(tài)時，當(dāng)前被加載的類型才被卸載.啟動類加載器實(shí)例永遠(yuǎn)為reachable狀態(tài)，由啟動類加載器加載的類型可能永遠(yuǎn)不會被卸載.

    我們再看一下Java語言規(guī)范提供的關(guān)于類型卸載的更詳細(xì)的信息(部分摘錄)：
    //摘自JLS 12.7 Unloading of Classes and Interfaces
    1、An implementation of the Java programming language may unload classes.
    2、Class unloading is an optimization that helps reduce memory use. Obviously，the semantics of a program should not depend  on whether and how a system chooses to implement an optimization such as class unloading.
    3、Consequently，whether a class or interface has been unloaded or not should be transparent to a program

    通過以上我們可以得出結(jié)論： 類型卸載(unloading)僅僅是作為一種減少內(nèi)存使用的性能優(yōu)化措施存在的，具體和虛擬機(jī)實(shí)現(xiàn)有關(guān)，對開發(fā)者來說是透明的.

    縱觀java語言規(guī)范及其相關(guān)的API規(guī)范，找不到顯示類型卸載(unloading)的接口， 換句話說： 
    1、一個已經(jīng)加載的類型被卸載的幾率很小至少被卸載的時間是不確定的
    2、一個被特定類加載器實(shí)例加載的類型運(yùn)行時可以認(rèn)為是無法被更新的

【類型卸載進(jìn)一步分析】
     前面提到過，如果想卸載某類型，必須保證加載該類型的類加載器處于unreachable狀態(tài)，現(xiàn)在我們再看看有 關(guān)unreachable狀態(tài)的解釋：
    1、A reachable object is any object that can be accessed in any potential continuing computation from any live thread.
    2、finalizer-reachable: A finalizer-reachable object can be reached from some finalizable object through some chain of references, but not from any live thread. An unreachable object cannot be reached by either means.

    某種程度上講，在一個稍微復(fù)雜的java應(yīng)用中，我們很難準(zhǔn)確判斷出一個實(shí)例是否處于unreachable狀態(tài)，所    以為了更加準(zhǔn)確的逼近這個所謂的unreachable狀態(tài)，我們下面的測試代碼盡量簡單一點(diǎn).
    
    【測試場景一】使用自定義類加載器加載， 然后測試將其設(shè)置為unreachable的狀態(tài)
    說明：
    1、自定義類加載器(為了簡單起見， 這里就假設(shè)加載當(dāng)前工程以外D盤某文件夾的class)
    2、假設(shè)目前有一個簡單自定義類型MyClass對應(yīng)的字節(jié)碼存在于D：/classes目錄下
    

        我們增加虛擬機(jī)參數(shù)-verbose：gc來觀察垃圾收集的情況，對應(yīng)輸出如下：   
    【測試場景二】使用系統(tǒng)類加載器加載，但是無法將其設(shè)置為unreachable的狀態(tài)
      說明：將場景一中的MyClass類型字節(jié)碼文件放置到工程的輸出目錄下，以便系統(tǒng)類加載器可以加載
                 
        我們增加虛擬機(jī)參數(shù)-verbose：gc來觀察垃圾收集的情況， 對應(yīng)輸出如下： 

        由于系統(tǒng)ClassLoader實(shí)例(AppClassLoader@197d257">sun.misc.Launcher$AppClassLoader@197d257)加載了很多類型，而且又沒有明確的接口將其設(shè)置為null，所以我們無法將加載MyClass類型的系統(tǒng)類加載器實(shí)例設(shè)置為unreachable狀態(tài)，所以通過測試結(jié)果我們可以看出，MyClass類型并沒有被卸載.(說明： 像類加載器實(shí)例這種較為特殊的對象一般在很多地方被引用， 會在虛擬機(jī)中呆比較長的時間)

    【測試場景三】使用擴(kuò)展類加載器加載， 但是無法將其設(shè)置為unreachable的狀態(tài)

        說明：將測試場景二中的MyClass類型字節(jié)碼文件打包成jar放置到JRE擴(kuò)展目錄下，以便擴(kuò)展類加載器可以加載的到。由于標(biāo)志擴(kuò)展ClassLoader實(shí)例(ExtClassLoader@7259da">sun.misc.Launcher$ExtClassLoader@7259da)加載了很多類型，而且又沒有明確的接口將其設(shè)置為null，所以我們無法將加載MyClass類型的系統(tǒng)類加載器實(shí)例設(shè)置為unreachable狀態(tài)，所以通過測試結(jié)果我們可以看出，MyClass類型并沒有被卸載.
        

        我們增加虛擬機(jī)參數(shù)-verbose：gc來觀察垃圾收集的情況，對應(yīng)輸出如下：

    關(guān)于啟動類加載器我們就不需再做相關(guān)的測試了，jvm規(guī)范和JLS中已經(jīng)有明確的說明了.


    【類型卸載總結(jié)】
    通過以上的相關(guān)測試(雖然測試的場景較為簡單)我們可以大致這樣概括：
    1、有啟動類加載器加載的類型在整個運(yùn)行期間是不可能被卸載的(jvm和jls規(guī)范).
    2、被系統(tǒng)類加載器和標(biāo)準(zhǔn)擴(kuò)展類加載器加載的類型在運(yùn)行期間不太可能被卸載，因?yàn)橄到y(tǒng)類加載器實(shí)例或者標(biāo)準(zhǔn)擴(kuò)展類的實(shí)例基本上在整個運(yùn)行期間總能直接或者間接的訪問的到，其達(dá)到unreachable的可能性極小.(當(dāng)然，在虛擬機(jī)快退出的時候可以，因?yàn)椴还蹸lassLoader實(shí)例或者Class(java.lang.Class)實(shí)例也都是在堆中存在，同樣遵循垃圾收集的規(guī)則).
    3、被開發(fā)者自定義的類加載器實(shí)例加載的類型只有在很簡單的上下文環(huán)境中才能被卸載，而且一般還要借助于強(qiáng)制調(diào)用虛擬機(jī)的垃圾收集功能才可以做到.可以預(yù)想，稍微復(fù)雜點(diǎn)的應(yīng)用場景中(尤其很多時候，用戶在開發(fā)自定義類加載器實(shí)例的時候采用緩存的策略以提高系統(tǒng)性能)，被加載的類型在運(yùn)行期間也是幾乎不太可能被卸載的(至少卸載的時間是不確定的).

      綜合以上三點(diǎn)，我們可以默認(rèn)前面的結(jié)論1， 一個已經(jīng)加載的類型被卸載的幾率很小至少被卸載的時間是不確定的.同時，我們可以看的出來，開發(fā)者在開發(fā)代碼時候，不應(yīng)該對虛擬機(jī)的類型卸載做任何假設(shè)的前提下來實(shí)現(xiàn)系統(tǒng)中的特定功能.

    
      【類型更新進(jìn)一步分析】
    前面已經(jīng)明確說過，被一個特定類加載器實(shí)例加載的特定類型在運(yùn)行時是無法被更新的.注意這里說的
         是一個特定的類加載器實(shí)例，而非一個特定的類加載器類型.
    
        【測試場景四】
        說明：現(xiàn)在要刪除前面已經(jīng)放在工程輸出目錄下和擴(kuò)展目錄下的對應(yīng)的MyClass類型對應(yīng)的字節(jié)碼 
                 輸出如下：
        true
        true

        通過結(jié)果我們可以看出來，兩次加載獲取到的兩個Class類型實(shí)例是相同的.那是不是確實(shí)是我們的自定義
       類加載器真正意義上加載了兩次呢(即從獲取class字節(jié)碼到定義class類型…整個過程呢)?
      通過對java.lang.ClassLoader的loadClass(String name，boolean resolve)方法進(jìn)行調(diào)試，我們可以看出來，第二
      次  加載并不是真正意義上的加載，而是直接返回了上次加載的結(jié)果.

       說明：為了調(diào)試方便， 在Class classLoaded2 = classLoader.loadClass("MyClass");行設(shè)置斷點(diǎn)，然后單步跳入， 可以看到第二次加載請求返回的結(jié)果直接是上次加載的Class實(shí)例. 調(diào)試過程中的截圖? 最好能自己調(diào)試一下).
      
     
        【測試場景五】同一個類加載器實(shí)例重復(fù)加載同一類型
        說明：首先要對已有的用戶自定義類加載器做一定的修改，要覆蓋已有的類加載邏輯， MyURLClassLoader.java類簡要修改如下：重新運(yùn)行測試場景四中的測試代碼
       說明： this.findClass(name)會進(jìn)一步調(diào)用父類URLClassLoader中的對應(yīng)方法，其中涉及到了defineClass(String name)的調(diào)用，所以說現(xiàn)在類加載器MyURLClassLoader會針對D：/classes/目錄下的類型進(jìn)行真正意義上的強(qiáng)制加載并定義對應(yīng)的類型信息.

        測試輸出如下：
        Exception in thread "main" java.lang.LinkageError： duplicate class definition： MyClass
       at java.lang.ClassLoader.defineClass1(Native Method)
       at java.lang.ClassLoader.defineClass(ClassLoader.java：620)
       at java.security.SecureClassLoader.defineClass(SecureClassLoader.java：124)
       at java.net.URLClassLoader.defineClass(URLClassLoader.java：260)
       at java.net.URLClassLoader.access$100(URLClassLoader.java：56)
       at java.net.URLClassLoader$1.run(URLClassLoader.java：195)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java：188)
       at MyURLClassLoader.loadClass(MyURLClassLoader.java：51)
       at Main.main(Main.java：27)
      
       結(jié)論：如果同一個類加載器實(shí)例重復(fù)強(qiáng)制加載(含有定義類型defineClass動作)相同類型，會引起java.lang.LinkageError: duplicate class definition.
    
       【測試場景六】同一個加載器類型的不同實(shí)例重復(fù)加載同一類型
       
      測試對應(yīng)的輸出如下：
      false
     
    
        【類型更新總結(jié)】   
     由不同類加載器實(shí)例重復(fù)強(qiáng)制加載(含有定義類型defineClass動作)同一類型不會引起java.lang.LinkageError錯誤， 但是加載結(jié)果對應(yīng)的Class類型實(shí)例是不同的，即實(shí)際上是不同的類型(雖然包名+類名相同). 如果強(qiáng)制轉(zhuǎn)化使用，會引起ClassCastException.(說明： 頭一段時間那篇文章中解釋過，為什么不同類加載器加載同名類型實(shí)際得到的結(jié)果其實(shí)是不同類型， 在JVM中一個類用其全名和一個加載類ClassLoader的實(shí)例作為唯一標(biāo)識，不同類加載器加載的類將被置于不同的命名空間).


        應(yīng)用場景：我們在開發(fā)的時候可能會遇到這樣的需求，就是要動態(tài)加載某指定類型class文件的不同版本，以便能動態(tài)更新對應(yīng)功能.
         建議：
        1. 不要寄希望于等待指定類型的以前版本被卸載，卸載行為對java開發(fā)人員透明的.
        2. 比較可靠的做法是，每次創(chuàng)建特定類加載器的新實(shí)例來加載指定類型的不同版本，這種使用場景下，一般就要犧牲緩存特定類型的類加載器實(shí)例以帶來性能優(yōu)化的策略了.對于指定類型已經(jīng)被加載的版本， 會在適當(dāng)時機(jī)達(dá)到unreachable狀態(tài)，被unload并垃圾回收.每次使用完類加載器特定實(shí)例后(確定不需要再使用時)， 將其顯示賦為null， 這樣可能會比較快的達(dá)到j(luò)vm 規(guī)范中所說的類加載器實(shí)例unreachable狀態(tài)， 增大已經(jīng)不再使用的類型版本被盡快卸載的機(jī)會.
        3. 不得不提的是，每次用新的類加載器實(shí)例去加載指定類型的指定版本，確實(shí)會帶來一定的內(nèi)存消耗，一般類加載器實(shí)例會在內(nèi)存中保留比較長的時間. 在bea開發(fā)者網(wǎng)站上找到一篇相關(guān)的文章(有專門分析ClassLoader的部分)：http：//dev2dev.bea.com/pub/a/2005/06/memory_leaks.html

           寫的過程中參考了jvm規(guī)范和jls， 并參考了sun公司官方網(wǎng)站上的一些bug的分析文檔。

           歡迎大家批評指正！

本博客中的所有文章、隨筆除了標(biāo)題中含有引用或者轉(zhuǎn)載字樣的，其他均為原創(chuàng)。轉(zhuǎn)載請注明出處，謝謝！