ThreadLocale Variable

[Rufus BugleWeed]

I am reading Joshua Bloch's book Effective Java Programming.
I am reading what Sun is serving for free here.
I am in chapter 7 on item 32 entitled Avoid Strings where Other Types are More Appropriate.
The problem statement is ... consider the design of a thread-local variable facility. Such a facility provides variables for which each thread has its own value.
fair enough... the elegant solution is
public class ThreadLocal {
public ThreadLocal() { }
public void set(Object value);
public Object get();
}
Certainly I am missing something because I have no idea how one thread cannot get and set another thread's value? I forgot to mention instances of ThreadLocal are nested, or in my interpretation non-static inner classes.
Bloch refers to an API java.util.ThreadLocal. In JDK's 1.3 and 1.4, I am finding java.lang.ThreadLocal which appears to have entered the JDK in the 1.2 release. I don't research back that far.
This java.lang.ThreadLocale class uses some dicriminator like the hashkey or thread name to provide a separate storage facilities for each thread in the JVM? Is that what Bloch is getting at?

[Jim Yingst]

This is one of the more difficult parts of Bloch's book. He's really only discussing one particular part of the ThreadLocal design, and glossing over the implementation details. You can see the implementation yourself by unjarring src.jar in your JDK, and looking in java/lang to see code for ThreadLocal.java and Thread.java. It's a bit complex to follow, but possible. Basically the ThreadLocal implementation determines which Thread is trying to read a variable value by invoking Thread.currentThread(). The variable values for a given thread are actually stored in a data structure attached to the Thread instance, called threadLocals. This variable has package access, so once ThreadLocal has looked up the invoking Thread, it can access the threadLocals (which is a Map-like structure storing all the thread local values, keyed by ThreadLocal instances.
To get to the starting point of Bloch's discussion, forget the actual implementation just discussed, and consider a more naive way to do this, e.g. something like

    public static Object getValueForThread(Thread t, String variableName)
    {
      Map localMapForThread = mapOfAllThreads.get(t);
      Object value = localMapForThread.get(variableName);
    }

where mapOfAllThreads is a Map containing a bunch of other Maps, each of which contains the thread local values for one particular thread. Here it's easy for one thread to access another's variables. This can be fixed with:

    public static Object getValueForThread(String variableName)
    {
      Map localMapForThread = mapOfAllThreads.get(Thread.currentThread());
      Object value = localMapForThread.get(variableName);
    }

Then the question is how can you improve on that String key representing the variable's name - that's the main point Bloch is actually discussing in item 32. (My second getValueForThread(String variableName) method corresponds to Bloch's get(String key) method, for which no implementation is shown. The actual implementation doesn't use a Map of Maps as I did, instead opting for fasster alternatives - but I wanted to keep my code relatively simple. (Plus, I don't have the authority to modify the java.lang.Thread class the way Josh Bloch does.)