內存泄漏的異常

Question

誰能幫助我與此異常：

Jul 23, 2012 11:00:57 AM org.apache.catalina.loader.WebappClassLoader loadClass 
INFO: Illegal access: this web application instance has been stopped already. Could not load com.mchange.v2.sql.SqlUtils. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. 
java.lang.IllegalStateException 
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1597) 
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556) 
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:531) 
    at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) 
    at org.hibernate.connection.C3P0ConnectionProvider.getConnection(C3P0ConnectionProvider.java:78) 
    at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446) 
    at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167) 
    at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:142) 
    at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:85) 
    at net.customware.gwt.dispatch.server.AbstractDispatch.doExecute(AbstractDispatch.java:81) 
    at net.customware.gwt.dispatch.server.AbstractDispatch.execute(AbstractDispatch.java:68) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
    at java.lang.reflect.Method.invoke(Method.java:601) 
    at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569) 
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208) 
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248) 
    at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) 
    at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:216) 
    at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:141) 
    at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:93) 
    at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:63) 
    at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:122) 
    at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:110) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) 
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) 
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) 
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) 
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999) 
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565) 
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
    at java.lang.Thread.run(Thread.java:722) 

而且也爲它提供了可能的解決方案..？

在此先感謝...

Answer 1

的基本問題是tomcat的每個Web應用程序創建一個新的類加載器，當你重新設置程序禁用的classloader，例如通過熱部署新版本。 c3p0創建助手線程。如果c3p0已加載到Web應用程序的類加載器中，然後該應用程序被重置，則c3p0的線程可能仍處於活動狀態並持有對從現已不存在的ClassLoader加載的對象的引用，導致出現新類時必須顯示的錯誤類型加載。

多線程組件與tomcat的「熱」ClassLoading方案之間的交互可能具有挑戰性。一些建議：

1）如果您的Web應用程序構造自己的c3p0 DataSource（例如在ContextListener中），請確保在應用程序關閉時（在同一個ContextListener中）DataSource也是close（）的

2）嘗試讓c3p0和您的JDBC驅動程序類加載到除web-app特定的ClassLoader之外的其他類中。將c3p0 jar文件，change-commons-java jar文件以及您的JDBC驅動程序jar文件放在common，system或bootstrap ClassLoader可以找到的地方。確保將這些文件從Web應用程序的lib目錄中取出，因爲首先嚐試了Web應用程序ClassLoader。有關更多信息，請參閱http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html。

我希望這有助於！