For example, we have a static ThreadLocal field an a setter:
private static final ThreadLocal threadLocalField = new ThreadLocal;
public static void getSXTransaction() {
threadLocalField.set(new MyValue());
}
I wonder, what are the guarantees of thread safety here as there is no implicit synchronization in the java.lang.ThreadLocal#set method? I know it makes sense for the TreadLocal class to be fully thread safe by it's nature but I cannot understand how it's being accomplished.
Here is the source code for it:
/**
* Sets the current thread's copy of this thread-local variable
* to the specified value. Most subclasses will have no need to
* override this method, relying solely on the {@link #initialValue}
* method to set the values of thread-locals.
*
* @param value the value to be stored in the current thread's copy of
* this thread-local.
*/
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
It's safe because getMap
returns the map for the given (i.e. current) thread. No other thread is going to be messing with that. So it's really down to the implementation of getMap
to make sure that's is okay for any thread - and as far as I can see, that just delegates to a field within the Thread
object. It's not clear to me whether getMap
is ever passing in any thread other than the current thread - if it were, that could be potentially tricky - but I suspect it's all been written carefully to make sure that's not a problem :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With