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

在《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。最常用但不是线程安全的对象之一是数据库Connection和JMSConnection。

如何?

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

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

ThreadLocal是JVM专门提供的功能，仅为线程提供隔离的存储空间。与实例作用域变量的值一样，变量只能绑定到类的给定实例。每个对象都有其唯一的值，它们不能看到彼此的值。ThreadLocal变量的概念也是如此，在对象实例的意义上，它们是线程的本地线程，除了创建它的线程之外，其他线程看不到它。在这里看到的

import java.util.concurrent.atomic.AtomicInteger;
import java.util.stream.IntStream;


public class ThreadId {
private static final AtomicInteger nextId = new AtomicInteger(1000);

// Thread local variable containing each thread's ID
private static final ThreadLocal<Integer> threadId = ThreadLocal.withInitial(() -> nextId.getAndIncrement());


// Returns the current thread's unique ID, assigning it if necessary
public static int get() {
    return threadId.get();
}

public static void main(String[] args) {

    new Thread(() -> IntStream.range(1, 3).forEach(i -> {
        System.out.println(Thread.currentThread().getName() + " >> " + new ThreadId().get());
    })).start();

    new Thread(() -> IntStream.range(1, 3).forEach(i -> {
        System.out.println(Thread.currentThread().getName() + " >> " + new ThreadId().get());
    })).start();

    new Thread(() -> IntStream.range(1, 3).forEach(i -> {
        System.out.println(Thread.currentThread().getName() + " >> " + new ThreadId().get());
    })).start();

}
}

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

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

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

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

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