ThreadLocalvariables in our web applications. The reason was that they created classloader leaks and we coudn't undeploy our applications properly anymore. Classloader leaks happen when a GC root keeps referencing an application object after the application was undeployed. If an application object is still referenced after undeploy, then the whole class loader can't be garbage collected cause the considered object references your applications class file which in turn references the classloader. This will cause an
OutOfMemoryErrorafter you've undeployed and redeployed a couple of times.
ThreadLocalis one classic candidate that can easily create classloader leaks in web applications. The server is managing its threads in a pool. These threads live longer then your web application. In fact they don't die at all until the underlying JVM dies. Now, if you put a
ThreadLocalin a pooled thread that references an object of your class you *must* be careful. You need to make sure that this variable is removed again using
ThreadLocal.remove(). The issue in web applications is: where is the right place to safely remove
ThreadLocalvariables? Also, you may not want to modify that "removing code" every time a colleague decided to add another
ThreadLocalto the managed threads.
We've developed a wrapper class around thread local that keeps all the thread local variables in one single
ThreadLocalvariable. Here is the code.
The advantage of the utility class is that no developer needs to manage the thread local variable lifecycle individually. The class puts all the thread locals in one map of variables. The
destroy()method can be invoked where you can safely remove all thread locals in your web application. In our case thats a
ServletRequestListener -> requestDestroyed()method. You will also need to place finally blocks elsewhere. Typical places are near the
HttpServlet, in the
doGet()methods. This may remove all thread locals in the pooled worker threads after the request is done or an exception is thrown unexpectedly. Sometimes it happens that the
mainthread of the server leaks thread local variables. If that is the case you need to find the right places where to call the
ThreadLocalUtil -> destroy()method. To do that figure out where the main thread actually *creates* the thread variables. You could use your debugger to do that.
Many guys out there suggest to ommit
ThreadLocalin web applications for several reasons. It can be very difficult to remove them in a pooled thread environment so that you can undeploy the applications safely.
ThreadLocalvariables can be useful, but it's fair to consider other techniques before applying them. An alternative for web applications to carry request scope parameters is the
HttpServletRequest. Many web frameworks allow for generic request parameter access as well as request/session attribute access, without ties to the native Servlet/Portlet API. Also many framework support request scoped beans to be injected into an object tree using dependency injection. All these options fulfill most requirements and should be considered prior to using