ThreadLocal

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its {@code get} or {@code set} method) has its own, independently initialized copy of the variable. {@code ThreadLocal} instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

上文节选自ThreadLocal的 JavaDoc，从描述的内容上看我们就可以看出 ThreadLocal 的作用是提供线程局部变量，这些局部变量是原变量的副本；ThreadLocal 是为每个线程提供一份变量的副本，由此不会影响到其他线程的变量副本。

源码浅析

我们先来看看 ThreadLocal下支持的几个常用操作。set(T value)，get()，remove();

set(T value)

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        map.set(this, value);
    } else {
        createMap(t, value);
    }
}

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

 void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}

从源代码可以看出，set 操作先获取当前线程，再获取当前线程的 ThreadLocalMap，如果 map 不为空则把当前 ThreadLocal 对象实例作为key，传进来的value作为值，否则创建一个map，再按照键值对放进去。从这里可以看出，实质上我们最后的存储介质就是这个ThreadLocalMap ，那这个ThreadLocalMap是什么呢？接着往下看。

public class Thread implements Runnable {
    ...
    ThreadLocal.ThreadLocalMap threadLocals = null;
    ...
 }
==================================================================
static class ThreadLocalMap {    
    static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;
    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
        }
    }
...    
}

每个Thread对象都维护一个ThreadLocalMap 类型的变量 threadLocals ；这个ThreadLocalMap 是 ThreadLocal 的一个内部类， ThreadLocalMap 内部维护了一个Entry （键值对），这里可以看到 Entry 继承了 WeakReference ，其对应的构造方法里，key值调用了父类的方法，那么意味着Entry 所对应的key（ThreadLocal对象实例）的引用是一个弱引用。

WeakReference 是java四种引用用中的弱引用，当有gc发生时就会被回收。还有其他三种分别是强引用，虚引用，软引用。

那为什么这里设置成弱引用呢？主要是为了防止内存泄漏，下面我们来分析一下。

假设我们在方法内部new了一个ThreadLocal对象，并往里面set 值。此时堆内存中的 ThreadLocal 对象有两块引用指向它，第一个引用是栈内存的强引用；另外一个是当set 值之后Entry的key作为的弱引用。方法结束时，当指向 ThreadLocal 对象的强引用消失时，对应的弱引用也会自动被回收。
我们假设Entry 中的引用是强引用，当指向ThreadLocal 对象的强引用消失时，ThreadLocal对象应该被回收但却因为Entry中的强引用无法回收，我们知道 ThreadlocalMap 是属于Thread的，如果是服务端线程的话，因为Thread长期存在，ThreadLocalMap 也必然长期存在，那么对应的这个Entry也会长期存在，那这个ThreadLocal 对象就不会被回收，就造成了内存泄漏。所以这就是为什么要使用弱引用的原因。
除此之外，JDK的设计者已经帮我们使用弱引用来避免了内存泄漏，仔细想想这样就不会再产生内存泄漏了吗？当对应的Entry 中的key被回收，那这个value是不是就无法获取到了呢，但由于Thread长期存在，ThreadLocalMap也长期存在，Entry也会长期存在，value也会永远都无法释放了，这样还是会造成内存泄漏。所以，在每次使用完之后，都需要调用remove 方法进行资源清除。

说到这里，回想一下如果在拦截器里使用ThreadLocal，就能理解为什么在 afterCompletion 需要remove方法了吧，如果不进行资源清除，就会导致线程在第二次请求中get到第一次请求的set进去的值。

remove()

public void remove() {
    ThreadLocalMap m = getMap(Thread.currentThread());
    if (m != null) {
        m.remove(this);
    }
}

remove 操作还是比较简单的，就是通过当前Thread 对象获取 ThreadLocalMap ，若不为空则再根据 ThreadLocal 对象作为key删除value。

get()

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

private T setInitialValue() {
    T value = initialValue();
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        map.set(this, value);
    } else {
        createMap(t, value);
    }
    if (this instanceof TerminatingThreadLocal) {
        TerminatingThreadLocal.register((TerminatingThreadLocal<?>) this);
    }
    return value;
}

接着我们来看下get 操作，get 操作同样也是先获取当前Thread 的ThreadLocalMap，再根据ThreadLocal对象获取对应的Entry，最后获取值。若map为空，则初始化值然后将初始化的值返回。

应用实践

Spring事务管理

在Web项目编程中，我们都会与数据库进行打交道，往往通常的做法是一个Service层里包含了多个Dao层的操作，要保证Service层操作的原子性，就要保证这些Dao操作是在同一个事务里，在同一个事务里就要确保多个Dao层的操作都是同一个Connection，那如何保证呢？我们可以确定的是该多个Dao层的操作都是由相同的线程进行处理的，那只要把Connection与线程绑定就可以了，所以Spring这里就巧妙的使用ThreadLocal来解决了这个问题。
Spring中有一个类 DataSourceUtils 其中有方法是获取数据源的Connection的，里面有一个getConnection方法，如下所示。

public static Connection getConnection(DataSource dataSource) throws CannotGetJdbcConnectionException {
    try {
        return doGetConnection(dataSource);
    }
    catch (SQLException ex) {
        throw new CannotGetJdbcConnectionException("Failed to obtain JDBC Connection", ex);
    }
    catch (IllegalStateException ex) {
        throw new CannotGetJdbcConnectionException("Failed to obtain JDBC Connection: " + ex.getMessage());
    }
}

for example when using {@link DataSourceTransactionManager}. Will bind a Connection to the thread if transaction synchronization is active 这里的注释有一个细节要关注到就是注释中提及到如果使用数据源事务管理器，当开启事务时，那么就会绑定连接到当前线程。

/**
* Actually obtain a JDBC Connection from the given DataSource.
* Same as {@link #getConnection}, but throwing the original SQLException.
* <p>Is aware of a corresponding Connection bound to the current thread, for example
* when using {@link DataSourceTransactionManager}. Will bind a Connection to the thread
* if transaction synchronization is active (e.g. if in a JTA transaction).
* <p>Directly accessed by {@link TransactionAwareDataSourceProxy}.
* @param dataSource the DataSource to obtain Connections from
* @return a JDBC Connection from the given DataSource
* @throws SQLException if thrown by JDBC methods
* @see #doReleaseConnection
*/
public static Connection doGetConnection(DataSource dataSource) throws SQLException {
    Assert.notNull(dataSource, "No DataSource specified");
    ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);
    if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) {
        conHolder.requested();
        if (!conHolder.hasConnection()) {
            logger.debug("Fetching resumed JDBC Connection from DataSource");
            conHolder.setConnection(fetchConnection(dataSource));
        }
        return conHolder.getConnection();
    }
    // Else we either got no holder or an empty thread-bound holder here.
    logger.debug("Fetching JDBC Connection from DataSource");
    Connection con = fetchConnection(dataSource);
    if (TransactionSynchronizationManager.isSynchronizationActive()) {
        try {
            // Use same Connection for further JDBC actions within the transaction.
            // Thread-bound object will get removed by synchronization at transaction completion.
            ConnectionHolder holderToUse = conHolder;
            if (holderToUse == null) {
                holderToUse = new ConnectionHolder(con);
            }
            else {
                holderToUse.setConnection(con);
            }
            holderToUse.requested();
            TransactionSynchronizationManager.registerSynchronization(
                new ConnectionSynchronization(holderToUse, dataSource));
            holderToUse.setSynchronizedWithTransaction(true);
            if (holderToUse != conHolder) {
                TransactionSynchronizationManager.bindResource(dataSource, holderToUse);
            }
        }
        catch (RuntimeException ex) {
            // Unexpected exception from external delegation call -> close Connection and rethrow.
            releaseConnection(con, dataSource);
            throw ex;
        }
    }
    return con;
}

从源代码大致可以看出首先从TransactionSynchronizationManager中获取ConnectionHolder，若存在则直接返回Connection，若不存在则新生成一个Connection并装到ConnectionHolder中然后注册到TransactionSynchronizationManager 中，然后再返回Connection。由此，我们可以看出TransactionSynchronizationManager 在这其中起到了管理Connection的作用。

接着看下TransactionSynchronizationManager 类。其中getResource方法和bindResource方法都在上面的doGetConnection方法中有过调用，那我们就注重看下这几个方法。

public abstract class TransactionSynchronizationManager {
private static final ThreadLocal<Map<Object, Object>> resources =
            new NamedThreadLocal<>("Transactional resources");
    private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations =
            new NamedThreadLocal<>("Transaction synchronizations");
    private static final ThreadLocal<String> currentTransactionName =
            new NamedThreadLocal<>("Current transaction name");
    private static final ThreadLocal<Boolean> currentTransactionReadOnly =
            new NamedThreadLocal<>("Current transaction read-only status");
    private static final ThreadLocal<Integer> currentTransactionIsolationLevel =
            new NamedThreadLocal<>("Current transaction isolation level");
    private static final ThreadLocal<Boolean> actualTransactionActive =
            new NamedThreadLocal<>("Actual transaction active");
...
public static Object getResource(Object key) {
    Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
    Object value = doGetResource(actualKey);
    if (value != null && logger.isTraceEnabled()) {
        logger.trace("Retrieved value [" + value + "] for key [" + actualKey + "] bound to thread [" +
                     Thread.currentThread().getName() + "]");
    }
    return value;
}
private static Object doGetResource(Object actualKey) {
    Map<Object, Object> map = resources.get();
    if (map == null) {
        return null;
    }
    Object value = map.get(actualKey);
    // Transparently remove ResourceHolder that was marked as void...
    if (value instanceof ResourceHolder && ((ResourceHolder) value).isVoid()) {
        map.remove(actualKey);
        // Remove entire ThreadLocal if empty...
        if (map.isEmpty()) {
            resources.remove();
        }
        value = null;
    }
    return value;
}
...
public static void bindResource(Object key, Object value) throws IllegalStateException {
    Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
    Assert.notNull(value, "Value must not be null");
    Map<Object, Object> map = resources.get();
    // set ThreadLocal Map if none found
    if (map == null) {
        map = new HashMap<>();
        resources.set(map);
    }
    Object oldValue = map.put(actualKey, value);
    // Transparently suppress a ResourceHolder that was marked as void...
    if (oldValue instanceof ResourceHolder && ((ResourceHolder) oldValue).isVoid()) {
        oldValue = null;
    }
    if (oldValue != null) {
        throw new IllegalStateException("Already value [" + oldValue + "] for key [" +
                                        actualKey + "] bound to thread [" + Thread.currentThread().getName() + "]");
    }
    if (logger.isTraceEnabled()) {
        logger.trace("Bound value [" + value + "] for key [" + actualKey + "] to thread [" +
                     Thread.currentThread().getName() + "]");
    }
}

从以上代码可以得出TransactionSynchronizationManager 类维护了ThreadLocal对象来进行资源的存储，包括事务资源（Spring中对JDBC的Connection或Hibernate的Session都称之为资源），事务隔离级别等。
名为resources变量的ThreadLocal对象存储的是DataSource生成的actualKey为key值和ConnectionHolder作为value值封装成的Map。
再结合DataSourceUtils的doGetConnection方法和TransactionSynchronizationManager的bindResource和getResource方法可知：在某个线程第一次调用时候，封装Map资源为：key值为DataSource生成actualKey和value值为DataSource获得的Connection对象封装后的ConnectionHolder。等这个线程下一次再次访问中就能保证使用的是第一次创建的ConnectionHolder中的Connection对象。

参考链接

【死磕Java并发】—–深入分析ThreadLocal
Spring事务之如何保证同一个Connection对象
 Spring是如何保证同一事务获取同一个Connection的？使用Spring的事务同步机制解决：数据库刚插入的记录却查询不到的问题【享学Spring】

并发编程系列

重新认识ThreadLocal