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 256 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?