莊周夢蝶

    這個類在spring2.01前沒有被改寫,spring2.06似乎已經(jīng)改寫了,還未看源碼。不過這不是我所在意的問題。我在《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: http://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對象有強引用（這一點據(jù)說在jdk5中已經(jīng)修改，被改成軟引用和弱引用的組合,而在jdk1.4.2需要這樣的處理），導致在web應用關閉或者熱部署的時候，舊的ClassLoader和它引用的類不能被回收，因此使用弱引用包裝CachedIntrospectionResults對象作為Value。web應用關閉或者熱部署的時候，會new新的ClassLoader用于裝載類，這就是CachedIntrospectionResults判斷緩存是否safe的根據(jù)所在，判斷要緩存的Class引用的ClassLoader是否相同。
    當使用JavaBean的內(nèi)省時，使用Introspector，jdk會自動緩存內(nèi)省的信息（BeanInfo），這一點可以理解，因為內(nèi)省通過反射的代價是高昂的。當ClassLoader關閉的時候，Introspector的緩存持有BeanInfo的信息，而BeanInfo持有Class的強引用，這將導致ClassLoader和它引用的Class等對象不能被垃圾收集器回收，因此在關閉前，需要手工清除Introspector中的緩存，調(diào)用Introspector.flushFromCaches，這就是CachedIntrospectionResults中當?shù)玫紹eanInfo后為什么要執(zhí)行下面這段代碼的原因：

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

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

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

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