這個(gè)類在spring2.01前沒有被改寫,spring2.06似乎已經(jīng)改寫了,還未看源碼。不過這不是我所在意的問題。我在《
org.springframework.beans簡單解讀》中的對這個(gè)類的理解是不正確的。我們先看看Guillaume Poirier對這個(gè)類中為什么使用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.htmlSo
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有強(qiáng)引用的有：ClassLoader，java.beans.BeanInfo，java.beans.PropertyDescriptor,java.lang.reflect.Method。因?yàn)樵谶@個(gè)緩存中使用Class作為key，而Value是CachedIntrospectionResults，CachedIntrospectionResults中持有BeanInfo和Method的引用，這兩個(gè)都對Class對象有強(qiáng)引用（這一點(diǎn)據(jù)說在jdk5中已經(jīng)修改，被改成軟引用和弱引用的組合,而在jdk1.4.2需要這樣的處理），導(dǎo)致在web應(yīng)用關(guān)閉或者熱部署的時(shí)候，舊的ClassLoader和它引用的類不能被回收，因此使用弱引用包裝CachedIntrospectionResults對象作為Value。web應(yīng)用關(guān)閉或者熱部署的時(shí)候，會(huì)new新的ClassLoader用于裝載類，這就是CachedIntrospectionResults判斷緩存是否safe的根據(jù)所在，判斷要緩存的Class引用的ClassLoader是否相同。
當(dāng)使用JavaBean的內(nèi)省時(shí)，使用Introspector，jdk會(huì)自動(dòng)緩存內(nèi)省的信息（BeanInfo），這一點(diǎn)可以理解，因?yàn)閮?nèi)省通過反射的代價(jià)是高昂的。當(dāng)ClassLoader關(guān)閉的時(shí)候，Introspector的緩存持有BeanInfo的信息，而BeanInfo持有Class的強(qiáng)引用，這將導(dǎo)致ClassLoader和它引用的Class等對象不能被垃圾收集器回收，因此在關(guān)閉前，需要手工清除Introspector中的緩存，調(diào)用Introspector.flushFromCaches，這就是CachedIntrospectionResults中當(dāng)?shù)玫紹eanInfo后為什么要執(zhí)行下面這段代碼的原因：
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中有一個(gè)比較少人注意的Listener——org.springframework.web.util.IntrospectorCleanupListener,這個(gè)類的說明如下：
它是一個(gè)在web應(yīng)用關(guān)閉的時(shí)候,清除JavaBeans Introspector緩存的監(jiān)聽器.在web.xml中注冊這個(gè)listener.可以保證在web 應(yīng)用關(guān)閉的時(shí)候釋放與掉這個(gè)web 應(yīng)用相關(guān)的class loader 和由它加載的類
如果你使用了JavaBeans Introspector來分析應(yīng)用中的類,系統(tǒng)級Introspector 緩沖中會(huì)保留這些類的hard引用。結(jié)果在你的web應(yīng)用關(guān)閉的時(shí)候,這些類以及web 應(yīng)用相關(guān)的class loader沒有被垃圾收集器回收.
不幸的是,清除Introspector的唯一方式是刷新整個(gè)緩存。這是因?yàn)槲覀儧]法判斷哪些是屬于你的應(yīng)用的引用.所以刪除被緩沖的introspection會(huì)導(dǎo)致把這臺server上的所有應(yīng)用的introspection（內(nèi)省）結(jié)果都刪掉.
需要注意的是,
spring容器托管的bean不需要使用這個(gè)監(jiān)聽器.因?yàn)閟pring它自己的introspection所使用的緩沖在分析完一個(gè)類之后會(huì)被馬上從javaBeans Introspector緩沖中清除掉(上面提到的代碼說明了這一點(diǎn)）。
一般的應(yīng)用基本不會(huì)直接用到JavaBean的內(nèi)省方法，所以一般不用考慮遇到此類內(nèi)省資源泄露，但是，很多的類庫或者框架（比如struts,Quartz）沒有清除Introspector。這個(gè)Listener就是為它們“擦屁股”的。
請注意，這個(gè)監(jiān)聽器需要注冊在web.xml中的所有應(yīng)用監(jiān)聽器之前（比如ContentLoaderListener之前）。
<listener>
<listener-class>org.springframework.web.util.IntrospectorCleanupListener</listener-class>
</listener>
參考資料：
《深入Java虛擬機(jī)》
《
Class對象什么時(shí)候被回收？》
《
Spring API Doc》
《
ss目前的設(shè)計(jì)有引起內(nèi)存泄露而導(dǎo)致down機(jī)的隱患》
以及一篇非常好的解釋java引用類的文章《
Java對象的強(qiáng)、軟、弱和虛引用》