您必须非常小心地使用ThreadLocal模式。有一些主要的缺点，如Phil所提到的，但其中一个没有提到的是，要确保设置ThreadLocal上下文的代码不是“可重入的”。

当设置信息的代码第二次或第三次运行时，可能会发生糟糕的事情，因为线程上的信息可能会在您没有预料到的时候开始发生变化。因此，在再次设置ThreadLocal信息之前，请注意确保没有设置它。

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

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

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

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

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

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

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

文档说得很好:“每个访问[线程局部变量]的线程(通过它的get或set方法)都有它自己的、独立初始化的变量副本”。

当每个线程必须有自己的某个副本时，可以使用一个。默认情况下，数据在线程之间共享。

什么时候?

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

如何?

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

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

[参考]ThreadLocal无法解决共享对象的更新问题。建议使用staticThreadLocal对象，该对象由同一线程中的所有操作共享。 [必选]remove()方法必须由ThreadLocal变量实现，特别是在使用经常重用线程的线程池时。否则，可能会影响后续的业务逻辑，并导致意想不到的问题，如内存泄漏。