Advice on using ThreadLocals to wrap mutable singleton objects

Question

From Java Concurrency in practice Chapter 3.3.3. ThreadLocal

Thread-local variables are often used to prevent sharing in designs based on mutable Singletons or global variables.

If we wrap the mutable Singleton guy in a ThreadLocal each thread will have its own copy of the Singleton ? How will it remain a singleton then ? Is this what the authors meant or am I missing something pretty obvious here ?

Answer 1

If we wrap the mutable Singleton guy in a ThreadLocal

AFAIK you do not wrap the singleton class with ThreadLocal, but the object contained within the singleton which is mutable or non-thread safe. As the example discusses correctly that the JDBC Connection is not thread safe and will require additional protection, which in turn increases contention.

So in the cases when the Singletons are used just for the purpose of sharing, then replacing those things with ThreadLocal is a good idea, as all the threads have their own Connection and no more added protection is required.

Other good example of use case of ThreadLocal is Random generation, if there is a single Random object then there is contention within threads for the "seed", so if each thread has its own Random object then there is no contention any more and that makes sense.

Answer 2

If you wrap a Singleton (as a design pattern) in a ThreadLocal it will remain a Singleton. There is no big magic in a ThreadLocal, if you check the source of the ThreadLocal you just saw it. It uses a Map and uses the current thread as a key. So it is quite useless to put a Singleton (a well implemented one) in a ThreadLocal. As you only get the same Singleton in various ways.

I suppose the author means that if your design heavily using Singletons and/or global variables the ThreadLocal is a good choice if you need something unique per thread, and do not want to pass all the way down the call hierarchy. But this thing is different from a Singleton. Of course you can have a ThreadLocal encapsulated in your Singleton so it will have some thread specific state (but that I would not call a Singleton anymore)

Answer 3

what I understood with this line is that when an application has been design in a manner where a Singleton class has mutable state which is being read and written by many threads will require thread safety so you need to serialize all access to that state. You may consider creating a ThreadLocal on that mutable singleton. (from the book:-) For example, a single‐threaded application might maintain a global database connection that is initialized at startup to avoid having to pass a Connection to every method. Since JDBC connections may not be thread‐safe, a multithreaded application that uses a global connection without additional coordination is not thread‐safe either. By using a ThreadLocal to store the JDBC connection, as in ConnectionHolder in Listing 3.10, each thread will have its own connection.

private static ThreadLocal<Connection> connectionHolder= new ThreadLocal<Connection>() {
      public Connection initialValue() {
  return DriverManager.getConnection(DB_URL);
  }
 };
   public static Connection getConnection() {
     return connectionHolder.get();
     }