由于ThreadLocal是对给定线程中的数据的引用，因此在使用线程池的应用服务器中使用ThreadLocal时，可能会导致类加载泄漏。在使用ThreadLocal的remove()方法清理你get()或set()的任何ThreadLocals时，你需要非常小心。

如果你在完成时不清理，它持有的任何类的引用作为部署的webapp的一部分将保留在永久堆中，永远不会被垃圾收集。重新部署/取消部署webapp不会清除每个线程对你的webapp类的引用，因为线程不是你的webapp所拥有的。每次后续部署都将创建该类的新实例，该实例永远不会被垃圾收集。

由于java.lang.OutOfMemoryError: PermGen空间，你最终会出现内存不足的异常，在谷歌搜索之后可能只是增加-XX:MaxPermSize，而不是修复这个错误。

如果您最终遇到了这些问题，您可以通过使用Eclipse的Memory Analyzer和/或遵循Frank Kieviet的指南和后续内容来确定哪个线程和类保留了这些引用。

更新:重新发现Alex Vasseur的博客条目，它帮助我找到了一些我遇到的ThreadLocal问题。

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

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

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

在《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.

由于ThreadLocal是对给定线程中的数据的引用，因此在使用线程池的应用服务器中使用ThreadLocal时，可能会导致类加载泄漏。在使用ThreadLocal的remove()方法清理你get()或set()的任何ThreadLocals时，你需要非常小心。

如果你在完成时不清理，它持有的任何类的引用作为部署的webapp的一部分将保留在永久堆中，永远不会被垃圾收集。重新部署/取消部署webapp不会清除每个线程对你的webapp类的引用，因为线程不是你的webapp所拥有的。每次后续部署都将创建该类的新实例，该实例永远不会被垃圾收集。

由于java.lang.OutOfMemoryError: PermGen空间，你最终会出现内存不足的异常，在谷歌搜索之后可能只是增加-XX:MaxPermSize，而不是修复这个错误。

如果您最终遇到了这些问题，您可以通过使用Eclipse的Memory Analyzer和/或遵循Frank Kieviet的指南和后续内容来确定哪个线程和类保留了这些引用。

更新:重新发现Alex Vasseur的博客条目，它帮助我找到了一些我遇到的ThreadLocal问题。

Threadlocal提供了一种非常简单的零成本实现对象可重用性的方法。

我遇到过这样一种情况，在每次更新通知时，多个线程都在创建可变缓存的映像。

我在每个线程上使用Threadlocal，然后每个线程只需要重置旧映像，然后在每次更新通知时从缓存中再次更新它。

来自对象池的通常可重用对象具有与之相关的线程安全成本，而此方法没有。

缓存，有时你必须计算相同的值很多时间，所以通过存储最后一组输入到一个方法和结果，你可以加快代码。通过使用线程本地存储，您可以避免考虑锁定问题。