How to clean up ThreadLocals

Question

Does any one have an example how to do this? Are they handled by the garbage collector? I'm using Tomcat 6.

Presumptive

Answer 1

The javadoc says this:

"Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist).

If your application or (if you are talking about request threads) container uses a thread pool that means that threads don't die. If necessary, you would need to deal with the thread locals yourself. The only clean way to do this is to call the ThreadLocal.remove() method.

There are two reasons you might want to clean up thread locals for threads in a thread pool:

• to prevent memory (or hypothetically resource) leaks, or
• to prevent accidental leakage of information from one request to another via thread locals.

Thread local memory leaks should not normally be a major issue with bounded thread pools since any thread locals are likely to get overwritten eventually; i.e. when the thread is reused. However, if you make the mistake of creating a new ThreadLocal instances over and over again (instead of using a static variable to hold a singleton instance), the thread local values won't get overwritten, and will accumulate in each thread's threadlocals map. This could result in a serious leak.

---

Assuming that you are talking about thread locals that are created / used during a webapp's processing of an HTTP request, then one way to avoid the thread local leaks is to register a ServletRequestListener with your webapp's ServletContext and implement the listener's requestDestroyed method to cleanup the thread locals for the current thread.

Note that in this context you also need to consider the possibility of information leaking from one request to another.

Dagda

thanks for the reply. The problem is that i can only remove the threadlocal once im done with the request. and i have no easy way to know when im done with the request. the way im doing is i have an interceptor at the start of the request that sets the threadlocal (its a static). so i reset it at the start of each request... – Presumptive

If the threadlocal object is a static, leak is more manageable issue; i.e. you only leak (up to) one instance (one thread local value) per thread in the thread pool. Depending on what the thread local values are, this leak could be not worth bothering about. – Dagda

Even if you use static ThreadLocal you can have a class loader leak when you redeploy your webapp if your value refer to some class loaded by the same class loader. It can happen if you use double brace initialization because that would create an anonymous class. I created a fix for that: github.com/codesinthedark/ImprovedThreadLocal – Idaho

Answer 2

Here is some code to clean all thread local variables from the current thread when you do not have a reference to the actual thread local variable. You can also generalize it to cleanup thread local variables for other threads:

    private void cleanThreadLocals() {
        try {
            // Get a reference to the thread locals table of the current thread
            Thread thread = Thread.currentThread();
            Field threadLocalsField = Thread.class.getDeclaredField("threadLocals");
            threadLocalsField.setAccessible(true);
            Object threadLocalTable = threadLocalsField.get(thread);

            // Get a reference to the array holding the thread local variables inside the
            // ThreadLocalMap of the current thread
            Class threadLocalMapClass = Class.forName("java.lang.ThreadLocal$ThreadLocalMap");
            Field tableField = threadLocalMapClass.getDeclaredField("table");
            tableField.setAccessible(true);
            Object table = tableField.get(threadLocalTable);

            // The key to the ThreadLocalMap is a WeakReference object. The referent field of this object
            // is a reference to the actual ThreadLocal variable
            Field referentField = Reference.class.getDeclaredField("referent");
            referentField.setAccessible(true);

            for (int i=0; i < Array.getLength(table); i++) {
                // Each entry in the table array of ThreadLocalMap is an Entry object
                // representing the thread local reference and its value
                Object entry = Array.get(table, i);
                if (entry != null) {
                    // Get a reference to the thread local object and remove it from the table
                    ThreadLocal threadLocal = (ThreadLocal)referentField.get(entry);
                    threadLocal.remove();
                }
            }
        } catch(Exception e) {
            // We will tolerate an exception here and just log it
            throw new IllegalStateException(e);
        }
    }

Whitford

This deletes everyone's global variables for the thread, which bit me in Java 6. java.util.concurrent.locks.ReentrantReadWriteLock would occasionally throw an IllegalMonitorStateException because we had deleted its cachedHoldCounter, so it tried to decrement it below 0. This particular issue doesn't happen in Java 8, but who knows how other ThreadLocals react to this, like Spring connections or log4j MDC. – Angst

Do we need to check threadLocal value is loaded by this webapp's classloader? threadLocal.get().getClass().getClassLoader() == Thread.currentThread().getContextClassLoader() – Cad

Answer 3

There is no way to cleanup ThreadLocal values except from within the thread that put them in there in the first place (or when the thread is garbage collected - not the case with worker threads). This means you should take care to clean up your ThreadLocal's when a servlet request is finished (or before transferring AsyncContext to another thread in Servlet 3), because after that point you may never get a chance to enter that specific worker thread, and hence, will leak memory in situations when your web app is undeployed while the server is not restarted.

A good place to do such cleanup is ServletRequestListener.requestDestroyed().

If you use Spring, all the necessary wiring is already in place, you can simply put stuff in your request scope without worrying about cleaning them up (that happens automatically):

RequestContextHolder.getRequestAttributes().setAttribute("myAttr", myAttr, RequestAttributes.SCOPE_REQUEST);
. . .
RequestContextHolder.getRequestAttributes().getAttribute("myAttr", RequestAttributes.SCOPE_REQUEST);

Wayworn

Answer 4

Reading again the Javadoc documentation carefully:

'Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist). '

There is no need to clean anything, there is an 'AND' condition for the leak to survive. So even in a web container where thread survive to the application, as long as the webapp class is unloaded ( only beeing reference in a static class loaded in the parent class loader would prevent this and this has nothing to do with ThreadLocal but general issues with shared jars with static data ) then the second leg of the AND condition is not met anymore so the thread local copy is eligible for garbage collection.

Thread local can't be the cause of memory leaks, as far the implementation meets the documentation.

Earthbound

And the actual link reference to the link: docs.oracle.com/javase/7/docs/api/java/lang/…). In general you have few container request handling threads each with one thread local holding one computationally expensive to create item (can be updated per request) and referenced/used only within that request/thread. – Gastronome

Answer 5

I would like to contribute my answer to this question even though it's old. I had been plagued by the same problem (gson threadlocal not getting removed from the request thread), and had even gotten comfortable restarting the server anytime it ran out of memory (which sucks big time!!).

In the context of a java web app that is set to dev mode (in that the server is set to bounce every time it senses a change in the code, and possibly also running in debug mode), I quickly learned that threadlocals can be awesome and sometime be a pain. I was using a threadlocal Invocation for every request. Inside the Invocation. I'd sometimes also use gson to generate my response. I would wrap the Invocation inside a 'try' block in the filter, and destroy it inside a 'finally' block.

What I observed (I have not metrics to back this up for now) is that if I made changes to several files and the server was constantly bouncing in between my changes, I'd get impatient and restart the server (tomcat to be precise) from the IDE. Most likely than not, I'd end up with an 'Out of memory' exception.

How I got around this was to include a ServletRequestListener implementation in my app, and my problem vanished. I think what was happening is that in the middle of a request, if the server would bounce several times, my threadlocals were not getting cleared up (gson included) so I'd get this warning about the threadlocals and two or three warning later, the server would crash. With the ServletResponseListener explicitly closing my threadlocals, the gson problem vanished.

I hope this makes sense and gives you an idea of how to overcome threadlocal issues. Always close them around their point of usage. In the ServletRequestListener, test each threadlocal wrapper, and if it still has a valid reference to some object, destroy it at that point.

I should also point out that make it a habit to wrap a threadlocal as a static variable inside a class. That way you can be guaranteed that by destroying it in the ServeltRequestListener, you won't have to worry about other instances of the same class hanging around.

Malefactor

Answer 6

@lyaffe's answer is the best possible for Java 6. There are a few issues that this answer resolves using what is available in Java 8.

@lyaffe's answer was written for Java 6 before MethodHandle became available. It suffers from performance penalties due to reflection. If used as below, MethodHandle provides zero overhead access to fields and methods.

@lyaffe's answer also goes through the ThreadLocalMap.table explicitly and is prone to bugs. There is a method ThreadLocalMap.expungeStaleEntries() now available that does the same thing.

The code below has 3 initialization methods to minimize the cost of invoking expungeStaleEntries().

private static final MethodHandle        s_getThreadLocals     = initThreadLocals();
private static final MethodHandle        s_expungeStaleEntries = initExpungeStaleEntries();
private static final ThreadLocal<Object> s_threadLocals        = ThreadLocal.withInitial(() -> getThreadLocals());

public static void expungeThreadLocalMap()
{
   Object threadLocals;

   threadLocals = s_threadLocals.get();

   try
   {
      s_expungeStaleEntries.invoke(threadLocals);
   }
   catch (Throwable e)
   {
      throw new IllegalStateException(e);
   }
}

private static Object getThreadLocals()
{
   ThreadLocal<Object> local;
   Object result;
   Thread thread;

   local = new ThreadLocal<>();

   local.set(local);   // Force ThreadLocal to initialize Thread.threadLocals

   thread = Thread.currentThread();

   try
   {
      result = s_getThreadLocals.invoke(thread);
   }
   catch (Throwable e)
   {
      throw new IllegalStateException(e);
   }

   return(result);
}

private static MethodHandle initThreadLocals()
{
   MethodHandle result;
   Field field;

   try
   {
      field = Thread.class.getDeclaredField("threadLocals");

      field.setAccessible(true);

      result = MethodHandles.
         lookup().
         unreflectGetter(field);

      result = Preconditions.verifyNotNull(result, "result is null");
   }
   catch (NoSuchFieldException | SecurityException | IllegalAccessException e)
   {
      throw new ExceptionInInitializerError(e);
   }

   return(result);
}

private static MethodHandle initExpungeStaleEntries()
{
   MethodHandle result;
   Class<?> clazz;
   Method method;
   Object threadLocals;

   threadLocals = getThreadLocals();
   clazz        = threadLocals.getClass();

   try
   {
      method = clazz.getDeclaredMethod("expungeStaleEntries");

      method.setAccessible(true);

      result = MethodHandles.
         lookup().
         unreflect(method);
   }
   catch (NoSuchMethodException | SecurityException | IllegalAccessException e)
   {
      throw new ExceptionInInitializerError(e);
   }

   return(result);
}

Isotonic

MethodHandle is fast but it is not zero overhead. In some cases its even slower than reflection. It's also not even supported by Graal VM static-image where as reflection is so long as the class and method name can be statically determined (ie constants).... so yeah at the present state of method handle @lyaffe's answer is probably better. – Teenyweeny

MethodHandles used in the first way in "even slower than reflection" web page is definitely slow. However, if you put the MethodHandle in a static final field (the second way in the web page and the way in my answer), then JIT eliminates the overhead. The article says this is useless; however, I have used static final MethodHandles in many places in my code. I find it useful. I guess the usefulness depends on the usecase. – Isotonic

Well the bigger issue for me/us is we hope to eventually target Graal VM for our microservices. We don't need the above particular code for these services but Graal VM not supporting MethodHandle does give me pause. Since you work for Oracle (yes I clicked on your profile :) ) maybe you know if they ever plan on supporting them (methodhandles)? – Teenyweeny

Unfortunately, I cannot answer if Graal VM will or will not support MethodHandle. I do not even know who is on the Graal VM team. – Isotonic

Answer 7

The JVM would automatically clean-up all the reference-less objects that are within the ThreadLocal object.

Another way to clean up those objects (say for example, these objects could be all the thread unsafe objects that exist around) is to put them inside some Object Holder class, which basically holds it and you can override the finalize method to clean the object that reside within it. Again it depends on the Garbage Collector and its policies, when it would invoke the finalize method.

Here is a code sample:

public class MyObjectHolder {

    private MyObject myObject;

    public MyObjectHolder(MyObject myObj) {
        myObject = myObj;
    }

    public MyObject getMyObject() {
        return myObject;
    }

    protected void finalize() throws Throwable {
        myObject.cleanItUp();
    }
}

public class SomeOtherClass {
    static ThreadLocal<MyObjectHolder> threadLocal = new ThreadLocal<MyObjectHolder>();
    .
    .
    .
}

Prone

Answer 8

final ThreadLocal<T> old = backend;

// try to clean by reflect
try {
    // BGN copy from apache ThreadUtils#getAllThreads
    ThreadGroup systemGroup = Thread.currentThread().getThreadGroup();
    while (systemGroup.getParent() != null) {
        systemGroup = systemGroup.getParent();
    }
    int count = systemGroup.activeCount();
    Thread[] threads;
    do {
        threads = new Thread[count + (count / 2) + 1]; //slightly grow the array size
        count = systemGroup.enumerate(threads, true);
        //return value of enumerate() must be strictly less than the array size according to javadoc
    } while (count >= threads.length);
    // END

    // remove by reflect
    final Field threadLocalsField = Thread.class.getDeclaredField("threadLocals");
    threadLocalsField.setAccessible(true);

    Class<?> threadLocalMapClass = Class.forName("java.lang.ThreadLocal$ThreadLocalMap");
    Method removeMethod = threadLocalMapClass.getDeclaredMethod("remove", ThreadLocal.class);
    removeMethod.setAccessible(true);

    for (int i = 0; i < count; i++) {
        final Object threadLocalMap = threadLocalsField.get(threads[i]);
        if (threadLocalMap != null) {
            removeMethod.invoke(threadLocalMap, old);
        }
    }

}
catch (Exception e) {
    throw new ThreadLocalAttention(e);
}

Gamete