Guice + Tomcat memoria de fuga potencial

yo sólo han empezado a utilizar Google Guice con mi webapp Tomcat, y se han dado cuenta de lo siguiente en el archivo catalina.out cada vez que el archivo WAR se Undeployed:Guice + Tomcat memoria de fuga potencial

May 16, 2011 5:37:24 PM org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [/app]

 May 16, 2011 5:37:24 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [com.google.inject.internal.util.$Finalizer] but has failed to stop it. This is very likely to create a memory leak.

May 16, 2011 5:37:24 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [null] (value [[email protected]]) and a value of type [java.lang.Object[]] (value [[Ljava.lang.Object;@7e9bed]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.

¿Hay alguien ¿Sabes qué causa esto o cómo puedo evitar que suceda?

Sólo he seguido las instrucciones de aquí http://code.google.com/docreader/#p=google-guice&s=google-guice&t=ServletModule

... y no han hecho nada de fantasía con ella todavía. Solo tengo 2 servlets y un filtro.

Gracias!

Fuente

2011-05-17 Peter Sankauskas

Si está recibiendo esto cuando apaga la aplicación web, no me preocupe demasiado. Este tipo de pérdida de recursos en la aplicación. el cierre es común. Se convierten en un problema cuando realiza despliegues con frecuencia (es decir, desinstala muchas veces sin matar a la JVM), pero no serán problemáticos cuando se realice una implementación en frío (el despliegue/despliegue se realiza al matar la JVM antes volver a implementar).

Una táctica común es que realiza despliegues en caliente durante el desarrollo (ya que suelen ser más rápidos que los despliegues en frío), y solo realiza una implementación en frío cuando la pérdida de recursos comienza a afectar su rendimiento. Luego, en producción, realiza una implementación en frío en cada implementación. Dada la cantidad de códigos/bibliotecas que tienen este tipo de fuga, tratar de eliminarlos sería difícil IMO.

Fuente

2011-05-17 01:24:59

Estoy de acuerdo en que probablemente no es nada de lo que preocuparse, pero me gusta que mis registros estén limpios. Lo publiqué como Issue 630: http://code.google.com/p/google-guice/issues/detail?id=630 –

Volver a implementar una aplicación web es un caso de uso real y reiniciar todas las aplicaciones web (la JVM) solo para uno de ellos puede ser un verdadero dolor operacional. –

"se supone que el subproceso se comparte en una JVM, y Guice no crea otro cuando la aplicación se implementa de nuevo": ¿Cómo puede ser? Esto significa que no solo los objetos (y sus clases) permanecen definidos en la memoria dinámica (y permgen también) con el contexto no desplegado detenido, sino que también significa que Guice utiliza objetos definidos con clases que no puede ver, ya que son de otro cargador de clases. – Plap

De acuerdo con Guice issue 630, se debe corregir en la siguiente versión de Guice (a partir de 11/2011), es decir, cuando la Guava dependency is upgraded a r10 +.

Parece que la solución no está aún, según Guice issue 288.

Fuente

2011-12-20 10:08:58

Sí ... dijo eso en el comentario anterior en mayo ... gracias. –

Esto me ayudó a deshacerme de "grave" entrada de registro para com.google.inject.internal.InjectorImpl:

injector = null; 
System.gc();

Dónde inyector fue el resultado de Guice.createInjector(...modules...)

admito, parece que no he leído acerca bad habit of calling System.gc() , pero tiene mucho sentido, ya que Guice usa referencias débiles internamente.

P.S. Tomcat 8, Java 8, Guice 3.0

Fuente

2015-06-25 21:38:37

Guice + Tomcat memoria de fuga potencial

Respuesta

Cuestiones relacionadas