tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Memory leak with ThreadGroups
Date Fri, 24 Jan 2003 00:49:18 GMT

On Thu, 23 Jan 2003, Tolles, James wrote:

> Date: Thu, 23 Jan 2003 15:23:05 -0800
> From: "Tolles, James" <>
> Reply-To: Tomcat Users List <>
> To: 'Tomcat Users List' <>
> Subject: RE: Memory leak with ThreadGroups
> I've noticed this when using jswat debugger. Each time we use the
> manager app to reload and updated class, we can see a new instace of the
> class in the jswat class list - each as a extra little number assigned
> to it. Its beyond my skill level but is seems odd that there can be two
> instances of the exact same class loaded in the VM? My guess is that the
> classloader loads in a new instance that is used but the previous one is
> still in the vm - not sure how this is possible.

Classes have to be unique only within a class loader hierarchy, not
JVM-wide.  For instance, it's perfectly reasonable for two different
webapps to have a class named com.mycompany.mypackage.Foo, even if those
classes are totally different.

Java does not provide any way to remove a previously loaded class from a
class loader.  The only way to implement webapp reloading, then, is to
have Tomcat throw away its reference to the webapp class loader and create
a new one.

If your application is well behaved (i.e. it doesn't have classes in
common/lib or shared/lib that maintain references to things loaded from
the webapp), then this will cause the entire webapp to become garbage.  If
*any* references to *any* classes inside the webapp still exist, though,
then essentially nothing from your webapp can be collected.

Of course, this should only be an issue during development -- you should
not use auto-reloading in a production environment.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message