IntrospectorCleanupListener应用
IntrospectorCleanupListener使用
IntrospectorCleanupListener使用
刚发现一个异常：
view sourceprint?1 Exception in thread "sfb_QuartzSchedulerThread" java.lang.OutOfMemoryError: Java heap space
2 at java.util.TreeMap.key(TreeMap.java:1206)
3 at java.util.TreeMap.firstKey(TreeMap.java:267)
4 at java.util.TreeSet.first(TreeSet.java:377)
5 at org.quartz.simpl.RAMJobStore.acquireNextTrigger(RAMJobStore.java:1209)
6 at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:266)
看这个信息，就是quartz引起了内存溢出问题。
网上资料都说IntrospectorCleanupListener能解决这种问题，但我的web.xml中是配置了这个监听器的。
网上的资料：
spring 中的提供了一个名为org.springframework.web.util.IntrospectorCleanupListener的监听器。它主 要负责处理由 JavaBeans Introspector的使用而引起的缓冲泄露。spring中对它的描述如下：
它是一个在web应用关闭的时候,清除JavaBeans Introspector的监听器.在web.xml中注册这个listener.可以保证在web 应用关闭的时候释放与掉这个web 应用相关的class loader 和由它管理的类
如果你使用了JavaBeans Introspector来分析应用中的类,Introspector 缓冲中会保留这些类的引用.结果在你的应用关闭的时候,这些类以及web 应用相关的class loader没有被垃圾回收.
不幸的是,清除Introspector的唯一方式是刷新整个缓冲.这是因为我们没法判断哪些是属于你的应用的引用.所以删除被缓冲的 introspection会导致把这台电脑上的所有应用的introspection都删掉.
需要注意的是,spring 托管的bean不需要使用这个监听器.因为spring它自己的introspection所使用的缓冲在分析完一个类之后会被马上从javaBeans Introspector缓冲中清除掉.
应用程序中的类从来不直接使用JavaBeans Introspector.所以他们一般不会导致内部查看资源泄露.但是一些类库和框架往往会产生这个问题.例如:Struts 和Quartz.
单个的内部查看泄漏会导致整个的web应用的类加载器不能进行垃圾回收.在web应用关闭之后,你会看到此应用的所有静态类资源(例如单例). 这个错误当然不是由这个类自身引起的.
对于这个解释，有点不明白了，为什么是在web应用关闭的时候才清除。web应用都关闭了，内存还不会释放吗？奇怪。
还是看看官方解释吧。
Listener that flushes the JDK's JavaBeans Introspector cache on web app shutdown. Register this listener in your web.xml to guarantee proper release of the web application class loader and its loaded classes.
If the JavaBeans Introspector has been used to analyze application classes, the system-level Introspector cache will hold a hard reference to those classes. Consequently, those classes and the web application class loader will not be garbage-collected on web app shutdown! This listener performs proper cleanup, to allow for garbage collection to take effect.
Unfortunately, the only way to clean up the Introspector is to flush the entire cache, as there is no way to specifically determine the application's classes referenced there. This will remove cached introspection results for all other applications in the server too.
Note that this listener is not necessary when using Spring's beans infrastructure within the application, as Spring's own introspection results cache will immediately flush an analyzed class from the JavaBeans Introspector cache and only hold a cache within the application's own ClassLoader. Although Spring itself does not create JDK Introspector leaks, note that this listener should nevertheless be used in scenarios where the Spring framework classes themselves reside in a 'common' ClassLoader (such as the system ClassLoader). In such a scenario, this listener will properly clean up Spring's introspection cache.
Application classes hardly ever need to use the JavaBeans Introspector directly, so are normally not the cause of Introspector resource leaks. Rather, many libraries and frameworks do not clean up the Introspector: e.g. Struts and Quartz.
Note that a single such Introspector leak will cause the entire web app class loader to not get garbage collected! This has the consequence that you will see all the application's static class resources (like singletons) around after web app shutdown, which is not the fault of those classes!
This listener should be registered as the first one in web.xml, before any application listeners such as Spring's ContextLoaderListener. This allows the listener to take full effect at the right time of the lifecycle.
注意下加粗部分。
没有释放的地方是被类加载器强引用了。
这个监听器还得放在第一个。
还有网友也给出了建议
只知道servlet标准不允许在web容器内自行做线程管理，quartz的问题确实存在。
对于Web容器来说，最忌讳应用程序私自启动线程，自行进行线程调度，像Quartz这种在web容器内部默认就自己启动了10线 程进行异步job调度的框架本身就是很危险的事情，很容易造成servlet线程资源回收不掉，所以我一向排斥使用quartz。
quartz还有一个问题就是不支持cluster。导致使用quartz的应用都没有办法做群集。
如果是我的话，我采取的办法就是自己单独启动一个Job Server，来跑job，不会部署在web容器中。
IntrospectorCleanupListener使用
刚发现一个异常：
view sourceprint?1 Exception in thread "sfb_QuartzSchedulerThread" java.lang.OutOfMemoryError: Java heap space
2 at java.util.TreeMap.key(TreeMap.java:1206)
3 at java.util.TreeMap.firstKey(TreeMap.java:267)
4 at java.util.TreeSet.first(TreeSet.java:377)
5 at org.quartz.simpl.RAMJobStore.acquireNextTrigger(RAMJobStore.java:1209)
6 at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:266)
看这个信息，就是quartz引起了内存溢出问题。
网上资料都说IntrospectorCleanupListener能解决这种问题，但我的web.xml中是配置了这个监听器的。
网上的资料：
spring 中的提供了一个名为org.springframework.web.util.IntrospectorCleanupListener的监听器。它主 要负责处理由 JavaBeans Introspector的使用而引起的缓冲泄露。spring中对它的描述如下：
它是一个在web应用关闭的时候,清除JavaBeans Introspector的监听器.在web.xml中注册这个listener.可以保证在web 应用关闭的时候释放与掉这个web 应用相关的class loader 和由它管理的类
如果你使用了JavaBeans Introspector来分析应用中的类,Introspector 缓冲中会保留这些类的引用.结果在你的应用关闭的时候,这些类以及web 应用相关的class loader没有被垃圾回收.
不幸的是,清除Introspector的唯一方式是刷新整个缓冲.这是因为我们没法判断哪些是属于你的应用的引用.所以删除被缓冲的 introspection会导致把这台电脑上的所有应用的introspection都删掉.
需要注意的是,spring 托管的bean不需要使用这个监听器.因为spring它自己的introspection所使用的缓冲在分析完一个类之后会被马上从javaBeans Introspector缓冲中清除掉.
应用程序中的类从来不直接使用JavaBeans Introspector.所以他们一般不会导致内部查看资源泄露.但是一些类库和框架往往会产生这个问题.例如:Struts 和Quartz.
单个的内部查看泄漏会导致整个的web应用的类加载器不能进行垃圾回收.在web应用关闭之后,你会看到此应用的所有静态类资源(例如单例). 这个错误当然不是由这个类自身引起的.
对于这个解释，有点不明白了，为什么是在web应用关闭的时候才清除。web应用都关闭了，内存还不会释放吗？奇怪。
还是看看官方解释吧。
Listener that flushes the JDK's JavaBeans Introspector cache on web app shutdown. Register this listener in your web.xml to guarantee proper release of the web application class loader and its loaded classes.
If the JavaBeans Introspector has been used to analyze application classes, the system-level Introspector cache will hold a hard reference to those classes. Consequently, those classes and the web application class loader will not be garbage-collected on web app shutdown! This listener performs proper cleanup, to allow for garbage collection to take effect.
Unfortunately, the only way to clean up the Introspector is to flush the entire cache, as there is no way to specifically determine the application's classes referenced there. This will remove cached introspection results for all other applications in the server too.
Note that this listener is not necessary when using Spring's beans infrastructure within the application, as Spring's own introspection results cache will immediately flush an analyzed class from the JavaBeans Introspector cache and only hold a cache within the application's own ClassLoader. Although Spring itself does not create JDK Introspector leaks, note that this listener should nevertheless be used in scenarios where the Spring framework classes themselves reside in a 'common' ClassLoader (such as the system ClassLoader). In such a scenario, this listener will properly clean up Spring's introspection cache.
Application classes hardly ever need to use the JavaBeans Introspector directly, so are normally not the cause of Introspector resource leaks. Rather, many libraries and frameworks do not clean up the Introspector: e.g. Struts and Quartz.
Note that a single such Introspector leak will cause the entire web app class loader to not get garbage collected! This has the consequence that you will see all the application's static class resources (like singletons) around after web app shutdown, which is not the fault of those classes!
This listener should be registered as the first one in web.xml, before any application listeners such as Spring's ContextLoaderListener. This allows the listener to take full effect at the right time of the lifecycle.
注意下加粗部分。
没有释放的地方是被类加载器强引用了。
这个监听器还得放在第一个。
还有网友也给出了建议
只知道servlet标准不允许在web容器内自行做线程管理，quartz的问题确实存在。
对于Web容器来说，最忌讳应用程序私自启动线程，自行进行线程调度，像Quartz这种在web容器内部默认就自己启动了10线 程进行异步job调度的框架本身就是很危险的事情，很容易造成servlet线程资源回收不掉，所以我一向排斥使用quartz。
quartz还有一个问题就是不支持cluster。导致使用quartz的应用都没有办法做群集。
如果是我的话，我采取的办法就是自己单独启动一个Job Server，来跑job，不会部署在web容器中。