閱讀1001 返回首頁    go 阿裏雲 go 技術社區[雲棲]

對org.springframework.beans.CachedIntrospectionResults的再次解讀

這個類在spring2.01前沒有被改寫,spring2.06似乎已經改寫了,還未看源碼。不過這不是我所在意的問題。我在《org.springframework.beans簡單解讀》中的對這個類的理解是不正確的。我們先看看Guillaume Poirier對這個類中為什麼使用WeakHashMap的解釋：

WeakHashMap is implemented with WeakReference for keys, and strong reference for values. That means if the value has a strong reference on the key, then the key cannot be garbage collected until the WeakHashMap is ready for collection. However, if the value has no strong reference on its key, then being in the WeakHashMap won't prevent the key and value from being garbage collected if it is otherwise ready. The WeakHashMap knows when to remove the key (and the value with it) by using the notification provided by the java.lang.ref package. For more information on this, see: https://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html

So the problem here with the CachedIntrospectionResults is that it uses BeanInfo and PropertyDescriptor that both have strong reference to the class (indirectly by a reference on Methods of the class). That will be solved with JDK 1.5 that uses a combinaison of Weak and Soft Reference to the Class and Method objects, but for 1.4.2, there's not really any better solution than to flush the Introspector's cache and/or use WeakReference on CachedIntrospectionResults. Using WeakReference on the CachedIntrospectionResults is safer, but decrease performance, and in such case a manual Instrospector.flushFromCaches(Class) must be used, so that the Instrospector does not keep a strong reference on the BeanInfo.

When a webapp is hot-redeployed, a new ClassLoader is created to load the webapp, and the old one is thrown away, expected to be garbage collected. For the collection to happen, the server must clear any strong reference to the ClassLoader or its classes, and also the webapp must make sure that any code in parent ClassLoaders (or siblings) clear any reference it might have to any of the webapp's class.

    照他的說法和參考《深入JVM》一書，對Class有強引用的有：ClassLoader，java.beans.BeanInfo，java.beans.PropertyDescriptor,java.lang.reflect.Method。因為在這個緩存中使用Class作為key，而Value是CachedIntrospectionResults，CachedIntrospectionResults中持有BeanInfo和Method的引用，這兩個都對Class對象有強引用（這一點據說在jdk5中已經修改，被改成軟引用和弱引用的組合,而在jdk1.4.2需要這樣的處理），導致在web應用關閉或者熱部署的時候，舊的ClassLoader和它引用的類不能被回收，因此使用弱引用包裝CachedIntrospectionResults對象作為Value。web應用關閉或者熱部署的時候，會new新的ClassLoader用於裝載類，這就是CachedIntrospectionResults判斷緩存是否safe的根據所在，判斷要緩存的Class引用的ClassLoader是否相同。
    當使用JavaBean的內省時，使用Introspector，jdk會自動緩存內省的信息（BeanInfo），這一點可以理解，因為內省通過反射的代價是高昂的。當ClassLoader關閉的時候，Introspector的緩存持有BeanInfo的信息，而BeanInfo持有Class的強引用，這將導致ClassLoader和它引用的Class等對象不能被垃圾收集器回收，因此在關閉前，需要手工清除Introspector中的緩存，調用Introspector.flushFromCaches，這就是CachedIntrospectionResults中當得到BeanInfo後為什麼要執行下麵這段代碼的原因：
            this.beanInfo = Introspector.getBeanInfo(clazz);

            // Immediately remove class from Introspector cache, to allow for proper
            // garbage collection on class loader shutdown - we cache it here anyway,
            // in a GC-friendly manner. In contrast to CachedIntrospectionResults,
            // Introspector does not use WeakReferences as values of its WeakHashMap!
            Class classToFlush = clazz;
            do {
                Introspector.flushFromCaches(classToFlush);
                classToFlush = classToFlush.getSuperclass();
            }
            while (classToFlush != null);

說到這裏，spring中有一個比較少人注意的Listener——org.springframework.web.util.IntrospectorCleanupListener,這個類的說明如下：

它是一個在web應用關閉的時候,清除JavaBeans Introspector緩存的監聽器.在web.xml中注冊這個listener.可以保證在web 應用關閉的時候釋放與掉這個web 應用相關的class loader 和由它加載的類
 
如果你使用了JavaBeans Introspector來分析應用中的類,係統級Introspector 緩衝中會保留這些類的hard引用。結果在你的web應用關閉的時候,這些類以及web 應用相關的class loader沒有被垃圾收集器回收.
 
不幸的是,清除Introspector的唯一方式是刷新整個緩存。這是因為我們沒法判斷哪些是屬於你的應用的引用.所以刪除被緩衝的introspection會導致把這台server上的所有應用的introspection（內省）結果都刪掉.
 
需要注意的是,spring容器托管的bean不需要使用這個監聽器.因為spring它自己的introspection所使用的緩衝在分析完一個類之後會被馬上從javaBeans Introspector緩衝中清除掉(上麵提到的代碼說明了這一點）。

一般的應用基本不會直接用到JavaBean的內省方法，所以一般不用考慮遇到此類內省資源泄露，但是，很多的類庫或者框架（比如struts,Quartz）沒有清除Introspector。這個Listener就是為它們“擦屁股”的。請注意，這個監聽器需要注冊在web.xml中的所有應用監聽器之前（比如ContentLoaderListener之前）。
<listener>
   <listener-class>org.springframework.web.util.IntrospectorCleanupListener</listener-class>
</listener>


    參考資料：
 《深入Java虛擬機》
 《Class對象什麼時候被回收？》
 《Spring API Doc》
  《ss目前的設計有引起內存泄露而導致down機的隱患》
 以及一篇非常好的解釋java引用類的文章《Java對象的強、軟、弱和虛引用》

文章轉自莊周夢蝶  ，原文發布時間5.17

最後更新：2017-05-17 14:02:05

  上一篇：go  sicp習題2.33-2.39嚐試解答
  下一篇：go  Erlang入門（四）——錯誤處理和魯棒性