[concurrency-interest] NullPointerExceptionin ThreadLocal$ThreadLocalMap.replaceStaleEntry

Doug Lea dl at cs.oswego.edu
Fri Jun 30 14:08:14 EDT 2006

Taras Tielkes wrote:
> The main design goals here are to make the common
>> fast path very fast (usually less than a dozen simple instructions).
>> And implicit limitations of not dealing well with cyclic garbage
>> never even arose.
> Were such consideration there at the beginning (1.1?), long before 
> ReentrantReadWriteLock?

Performance of ThreadLocals has been an issue just about forever.
See for example some of the old JMM postings about it more than 5 years ago.

(Without care, nearly every class in java.lang, java.util, and
java.util.concurrent is likely to be the performance bottleneck
in many real applications. It keeps life interesting for library

> What about a method to forcefully clean the ThreadLocals for the current 
> thread (and the CCL to) ?

This has been proposed many times, and each time it is argued that
no one piece of code will ever know enough to kill exactly all
the right ThreadLocals, since some are buried in unknown subsystems,
including some that may be critical in security code.

A better bet would be to establish some new scoping construct
such that you could declare ThreadLocals to be in particular
scopes, and then support a method that would kill all in that
scope. I don't believe anyone has ever made a concrete proposal
along those lines though.

> Or a method to force cleanup. Frameworks usually know when a request is 
> at the end of it's lifecycle.
> Just curious, what is the pre-Thread amount of ThreadLocals you're 
> optimizing for?

They default to only 16 but resizing is quick and not usually the issue


More information about the Concurrency-interest mailing list