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】
发表回复