从本质上讲，当您需要一个变量的值依赖于当前线程，并且不方便您以其他方式将值附加到线程(例如，子类化线程)。

典型的情况是，其他框架创建了运行代码的线程，例如servlet容器，或者使用ThreadLocal更有意义，因为你的变量“在它的逻辑位置”(而不是挂在thread子类或其他哈希映射中的变量)。

在我的网站上，我有一些关于何时使用ThreadLocal的进一步讨论和示例，您可能也会感兴趣。

有些人主张使用ThreadLocal作为一种方法，在某些并发算法中，当你需要线程号时，将“线程ID”附加到每个线程上(参见Herlihy & Shavit)。在这种情况下，检查你是否真的得到了好处!

从本质上讲，当您需要一个变量的值依赖于当前线程，并且不方便您以其他方式将值附加到线程(例如，子类化线程)。

典型的情况是，其他框架创建了运行代码的线程，例如servlet容器，或者使用ThreadLocal更有意义，因为你的变量“在它的逻辑位置”(而不是挂在thread子类或其他哈希映射中的变量)。

在我的网站上，我有一些关于何时使用ThreadLocal的进一步讨论和示例，您可能也会感兴趣。

有些人主张使用ThreadLocal作为一种方法，在某些并发算法中，当你需要线程号时，将“线程ID”附加到每个线程上(参见Herlihy & Shavit)。在这种情况下，检查你是否真的得到了好处!

在《Java并发实践》一书中有一个很好的例子。作者(Joshua Bloch)解释了线程限制是实现线程安全的最简单方法之一，而ThreadLocal是维护线程限制的更正式的方法。最后，他还解释了人们如何滥用它作为全局变量。

我已经从提到的书中复制了文本，但代码3.10是缺失的，因为它不太重要，了解ThreadLocal应该在哪里使用。

Thread-local variables are often used to prevent sharing in designs based on mutable Singletons or global variables. 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. ThreadLocal is widely used in implementing application frameworks. For example, J2EE containers associate a transaction context with an executing thread for the duration of an EJB call. This is easily implemented using a static Thread-Local holding the transaction context: when framework code needs to determine what transaction is currently running, it fetches the transaction context from this ThreadLocal. This is convenient in that it reduces the need to pass execution context information into every method, but couples any code that uses this mechanism to the framework. It is easy to abuse ThreadLocal by treating its thread confinement property as a license to use global variables or as a means of creating “hidden” method arguments. Like global variables, thread-local variables can detract from reusability and introduce hidden couplings among classes, and should therefore be used with care.

一种可能的(也是常见的)用途是，当您有一些不是线程安全的对象，但您希望避免同步访问该对象(我正在看您，SimpleDateFormat)。相反，给每个线程它自己的对象实例。

例如:

public class Foo
{
    // SimpleDateFormat is not thread-safe, so give one to each thread
    private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){
        @Override
        protected SimpleDateFormat initialValue()
        {
            return new SimpleDateFormat("yyyyMMdd HHmm");
        }
    };

    public String formatIt(Date date)
    {
        return formatter.get().format(date);
    }
}

文档。

正如@unknown(谷歌)所提到的，它的用途是定义一个全局变量，其中引用的值在每个线程中都是唯一的。它的使用通常需要存储某种链接到当前执行线程的上下文信息。

我们在Java EE环境中使用它来将用户标识传递给不支持Java EE的类(不能访问HttpSession或EJB SessionContext)。通过这种方式，代码可以从任何地方访问标识，而不必在每个方法调用中显式地传递它。

大多数Java EE调用中的操作的请求/响应周期使得这种类型的使用很容易，因为它提供了定义良好的入口和出口点来设置和取消设置ThreadLocal。

什么时候?

当一个对象不是线程安全的时候，为了避免影响可伸缩性的同步，给每个线程一个对象，并保持它的线程作用域，即ThreadLocal。最常用但不是线程安全的对象之一是数据库Connection和JMSConnection。

如何?

例如，Spring框架通过将这些连接对象保存在ThreadLocal变量中，在幕后大量使用ThreadLocal来管理事务。在高层，当事务启动时，它获得连接(并禁用自动提交)并将其保存在ThreadLocal中。在进一步的db调用中，它使用相同的连接与db通信。最后，它从ThreadLocal获取连接，提交(或回滚)事务并释放连接。

我认为log4j也使用ThreadLocal来维护MDC。