ThreadLocal Resource Leak and WeakReference

Question

My limited understanding of ThreadLocal is that it has resource leak issues. I gather this problem can be remedied through proper use of WeakReferences with ThreadLocal (although I may have misunderstood this point.) I would simply like a pattern or example for correctly using ThreadLocal with WeakReference, if one exists. For instance, in this code snippet where would the WeakReference be introduced?

static class DateTimeFormatter {
    private static final ThreadLocal<SimpleDateFormat> DATE_PARSER_THREAD_LOCAL = new ThreadLocal<SimpleDateFormat>() {
        protected SimpleDateFormat initialValue() {
            return new SimpleDateFormat("yyyy/MM/dd HH:mmz");
        }
    };
    public String format(final Date date) {
        return DATE_PARSER_THREAD_LOCAL.get().format(date);
    }
    public Date parse(final String date) throws ParseException
    {
      return DATE_PARSER_THREAD_LOCAL.get().parse(date);
    }
}

Answer 1

ThreadLocal uses a WeakReference internally. If the ThreadLocal is not strongly referenced, it will be garbage-collected, even though various threads have values stored via that ThreadLocal.

Additionally, ThreadLocal values are actually stored in the Thread; if a thread dies, all of the values associated with that thread through a ThreadLocal are collected.

If you have a ThreadLocal as a final class member, that's a strong reference, and it cannot be collected until the class is unloaded. But this is how any class member works, and isn't considered a memory leak.

---

Update: The cited problem only comes into play when the value stored in a ThreadLocal strongly references that ThreadLocal—sort of a circular reference.

In this case, the value (a SimpleDateFormat), has no backwards reference to the ThreadLocal. There's no memory leak in this code.

Answer 2

I'm guessing you're jumping through these hoops since SimpleDateFormat is not thread-safe.

Whilst I'm aware I'm not solving your problem above, can I suggest you look at Joda for your date/time work ? Joda has a thread-safe date/time formatting mechanism. You won't be wasting your time learning the Joda API either, as it's the foundation for the new standard date/time API proposal.

Answer 3

There shouldn't be such a problem.

A thread's ThreadLocal reference is defined to exist only as long as the corresponding thread is alive (see the javadoc)-- or put another way, once the thread is not alive, if the ThreadLocal was the only reference to that object, then the object becomes eligible for garbage collection.

So either you've found a genuine bug and should be reporting it, or you're doing something else wrong!

Answer 4

I realise this isn't strictly an answer to your question but as a general rule I won't suggest using a ThreadLocal in situration where there isn't a clear tear down at the end of a request/interaction. The classic is doing this sort of thing in a servlet container, at first glance it seems fine, but since the threads are pooled it becomes a issue with the ThreadLocal hanging onto the resource even after each request has been processed.

Suggestions:

1. Use a filter of similar wrapper for each interaction to clear the ThreadLocal at the end of each interaction
2. You could use a alternative to SimpleDateFormat like FastDateFormat from commons-lang or Joda as somebody has already suggested
3. Just create a new SimpleDateFormat every time you need it. Seems wasteful I know, but in most applications you just won't notice the difference