Lots of ThreadLocalMap entries in memory

Consider a very large Java VM with a great many threads running a web server.

Now consider a sample of the output generated by jmap -histo that looks something like this:

  4:       5989163      191653216  java.lang.ThreadLocal$ThreadLocalMap$Entry
 10:         46786       49012000  [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;
 86:         23384        2619008  java.lang.Thread
144:         46750        1122000  java.lang.ThreadLocal$ThreadLocalMap

If you do the division, it turns out we have 25开发者_如何学JAVA6 instances of java.lang.ThreadLocal$ThreadLocalMap$Entry per thread. Kind of a high number, and more than I'd expect given that most of the ThreadLocals shouldn't be storing a whole lot of values. I don't see that many in Tomcat when I use its ThreadLocal-leak-detection feature.

Any reason these ThreadLocalMaps should be so memory-hungry?

---

Can you figure out what the values in the thread local map are? Have you poked around with jhat or equivalent to see what they're referencing?

---

Could be running into this bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6625723

---

The problem seems to be the actual number of thread locals, not the values that they contain.

I suspect that you might be using ThreadLocal incorrectly. The ThreadLocal object should be created (once) and assigned to a static variable, as shown in the example in the javadoc.

If you create the ThreadLocal object in the initializer of a non-static variable, then each time the variable declaration is executed you get a new thread local. If you combine this with thread pooling, then you'll get lots of useless thread local map entries.