[concurrency-interest] NullPointerExceptionin ThreadLocal$ThreadLocalMap.replaceStaleEntry

Doug Lea dl at cs.oswego.edu
Fri Jun 30 12:46:51 EDT 2006

Taras Tielkes wrote:
> T
> Now for a bit off-topic...I heard that a new implementation of 
> ThreadLocal will make it into Dolphin, eliminating both the lingering 
> stale entries, and the value->key reference path limitation. Any thuth 
> to this, or better, details?

I think that's the plan.

Here's how I see some of the story behind it.

1. ThreadLocals were originally designed as a way to maintain
very fast access (mainly by avoiding synchronization) to little
bits of context needed mainly in infrastructure/middleware stuff.
As an example, ReentrantReadWriteLock uses one to track reader
recursion. 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.

2. Web frameworks, especially, discovered that you could use
ThreadLocals to maintain full session state more cheaply than
any other way, basically by making everything a ThreadLocal.
By not having programmers think about what would even make
sense as a ThreadLocal, and instead using them for everything,
ThreadLocal itself turns into a mini-garbage-collector. Which
it will never do as well as platform-level GC. Even doing it
as well as it does costs the "classic" uses a bit of performance,
and doing it better will cost more.

So the fun algorithmic issue here is how to make life better
for both styles of use. Not knowing any better compromise, it
may be that there is an additional SlowerButBetterAtGCThreadLocal
class people can use when applicable.


More information about the Concurrency-interest mailing list