spring 与ThreadLocal

Spring使用ThreadLocal解决线程安全问题

我们知道在一般情况下，只有无状态的Bean才可以在多线程环境下共享，在Spring中，绝大部分Bean都可以声明为singleton作用域。就是因为Spring对一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非线程安全状态采用ThreadLocal进行处理，让它们也成为线程安全的状态，因为有状态的Bean就可以在多线程中共享了。

一般的Web应用划分为展现层、服务层和持久层三个层次，在不同的层中编写对应的逻辑，下层通过接口向上层开放功能调用。在一般情况下，从接收请求到返回响应所经过的所有程序调用都同属于一个线程
这样你就可以根据需要，[color=red]将一些非线程安全的变量以ThreadLocal存放[/color]，在同一次请求响应的调用线程中，所有关联的对象引用到的都是同一个变量。

下面的实例能够体现Spring对有状态Bean的改造思路：

代码清单3 TopicDao：非线程安全

public class TopicDao {

private Connection conn;①一个非线程安全的变量

public void addTopic(){

Statement stat = conn.createStatement();②引用非线程安全变量

…

}

}

由于①处的conn是成员变量，因为addTopic()方法是非线程安全的，必须在使用时创建一个新TopicDao实例（非singleton）。下面使用ThreadLocal对conn这个非线程安全的“状态”进行改造：

代码清单4 TopicDao：线程安全

import java.sql.Connection;

import java.sql.Statement;

public class TopicDao {

①使用ThreadLocal保存Connection变量

private static ThreadLocal<Connection> connThreadLocal = new ThreadLocal<Connection>();

public static Connection getConnection(){

②如果connThreadLocal没有本线程对应的Connection创建一个新的Connection，

并将其保存到线程本地变量中。

if (connThreadLocal.get() == null) {

Connection conn = ConnectionManager.getConnection();

connThreadLocal.set(conn);

return conn;

}else{

return connThreadLocal.get();③直接返回线程本地变量

}

}

public void addTopic() {

④从ThreadLocal中获取线程对应的Connection

Statement stat = getConnection().createStatement();

}

}

不同的线程在使用TopicDao时，先判断connThreadLocal.get()是否是null，如果是null，则说明当前线程还没有对应的Connection对象，这时创建一个Connection对象并添加到本地线程变量中；如果不为null，则说明当前的线程已经拥有了Connection对象，直接使用就可以了。这样，就保证了不同的线程使用线程相关的Connection，而不会使用其它线程的Connection。因此，这个TopicDao就可以做到singleton共享了。

当然，这个例子本身很粗糙，将Connection的ThreadLocal直接放在DAO只能做到本DAO的多个方法共享Connection时不发生线程安全问题，但无法和其它DAO共用同一个Connection，要做到同一事务多DAO共享同一Connection，必须在一个共同的外部类使用ThreadLocal保存Connection。

小结

ThreadLocal是解决线程安全问题一个很好的思路，它通过为每个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。
“原始”的数据访问写法

访问任何带有事务特性的资源系统，像数据库，都有着相同的特点：首先你需要获得一个访问资源的“管道”，对于数据库来说，这个所谓的“管道”是JDBC里的Connection,是Hibernate里的Session.然后你会通过“管道”下达一系列的读写指令，比如数据库的SQL，最后你会断开这个“管道”，释放对这个资源的连接。在Spring里，用访问资源的“管道”来指代资源，因此JDBC的Connection和Hibernate的Session都被称之为“资源”(Resource)(本文会交替使用这两种称呼)。另一方面，资源与事务又有着紧密的关系，事务的开启与提交都是在某个“Resource”上进行的。以Hibernate为例，一种“原始”的数据访问程序往往会写成这样：

[java] view plaincopy
Session session = sessionFactory.openSession();//获取“资源”
Transaction tx = null;
try {
tx = session.beginTransaction(); //开始事务
....
DomainObject domainObject = session.load(...); //数据访问操作
....
domainObject.processSomeBusinessLogic();//业务逻辑计算
....
session.save(domainObject); //另一个数据访问操作
....
session.save(anotherDomainObject); //又一个数据访问操作
....
session.commit(); //提交事务
}
catch (RuntimeException e) {
tx.rollback();
throw e;
}
finally {
session.close(); //释放资源
}

上述代码的思路很直白：首先获得数据库“资源”，然后在该资源上开始一个事务，经过一系列夹杂着业务计算和数据访问的操作之后，提交事务,释放资源。

分层带来的困扰

相信很多人一下就能看出上面代码的问题：业务逻辑与数据访问掺杂在了一起，犯了分层的“忌讳”。一个良好的分层系统往往是这样实现上述代码的：使用Service实现业务逻辑，使用DAO向Service提供数据访问支持。

某个Service的实现类：
[java] view plaincopy
public class MyServiceImpl implements MyService {

public void processBusiness(){

//在这里获得资源并开启事务么？NO！会引入数据访问的API，“污染"Service，破坏了分层!
//Session session = sessionFactory.openSession();
//session.beginTransaction();
....
DomainObject domainObject = myDao.getDomainObject(...); //数据访问操作
....
domainObject.processSomeBusinessLogic();//业务逻辑计算
....
myDao.save(domainObject); //另一个数据访问操作
....
myDao.save(anotherDomainObject); //又一个数据访问操作
....
}
....
}

某个DAO的Hibernate实现类：
[java] view plaincopy
public class MyDaoHibernateImpl implements MyDao {

public void save(DomainObject domainObject){
//在这里获得资源并开启事务么？NO！你怎么确定这个方法一定是一个独立的事务
//而不会是某个事务的一部分呢？比如我们上面的Service。
//Session session = sessionFactory.openSession();
//session.beginTransaction();
....
session.save(domainObject);
}
....
}


矛盾的焦点

从“分层”的角度看，上述方案算是“完美”了，但却回避了一个现实的技术问题：如何安置“获取资源”(也就是session)和“开启事务”的代码呢？像代码中注释的那样，好像放在哪里都有问题，看上去像是一个“不可调和”的矛盾。如果要解决这个“不可调和”的矛盾，在技术上需要解决两个难题：
如何“透明”地进行事务定界(Transaction Demarcation)?
如何构建一个“上下文”，在事务开始与事务提交时，以及在事务过程中所有数据访问方法都能“隐式”地得到“同一个资源”(数据库连接/Hibernate Session)。所谓“隐式”是指不能把同一个资源实例用参数的方式传给数据访问方法，否则必然会出现数据访问层的上层代码受到数据访问专有API污染的问题(即破获了分层)，而使用全局变量显然是不行的，因为全局变量是唯一的，没有哪个应用能容忍只使用一个数据库连接，对于一个用户请求一个线程的多线程Web应用环境更是如此。

Spring的解决之道

Spring使用基于AOP的声明式事务定界解决了第一个问题，而使用基于ThreadLocal的资源与事务线程绑定成功地解决了第二个问题。(关于spring的具体实现，可以参考我的另一篇文章：Spring源码解析(一) Spring事务控制之Hibernate ，第一个问题所涉及源码主要是：
org.springframework.aop.framework.JdkDynamicAopProxy 和 org.springframework.transaction.interceptor.TransactionInterceptor
第二个问题所涉及源码主要是：
org.springframework.transaction.support.AbstractPlatformTransactionManager 和 org.springframework.transaction.support.TransactionSynchronizationManager)

本文我们重点关注Spring是如何解决第二个问题的，对于这个问题有两点需要特别地解释：

“上下文”：Spring使用的是“线程上下文”，也就是TreadLocal,原因非常简单，做为一种线程作用域变量，它能很好地被“隐式”获取，即在当前线程下可以直接得到该变量(避免了参数传递)，同时又不会像全局变量那样作用域过大且全局只有一个实例。实际上，从更大的背景上来看，大多数的spring应用为B/S架构的web应用，受servlet线程模型的影响，此类web应用都是一个用户请求到达开启一个新的线程进行处理，在此背景下，spring这种以线程作为上下文绑定资源和事务的处理方式无疑是非常合适的。
“资源与事务的生命周期”：如果只从“线程绑定”的字面上理解，很容易让人误解为绑定到线程上的资源和事务的生命周期与线程是等长的，这是错误的。实际上，资源和事务的生命周期与线程生命周期没有必然联系，只是当资源和事务存在时，它们会以TreadLocal的形式绑定到线程上而已。而资源的生命周期与事务的生命周期才是等长的，我们把资源-事务这种生命周期关系称为：Connection-Per-Transaction 或是 Session-Per-Transaction。

Hibernate自己动手丰衣足食

作为一小段插曲，我们聊聊Hibernate。大概是为满足对Session-Per-Transaction的普遍需求，Hibernate也实现了自己的Session-Per-Transaction模型，就是大家所熟知的SessionFactory.getCurrentSession(),该方法返回绑定在当前线程上session实例，若当前线程没有session实例，创建一个新的实例以ThreadLocal的形式绑定到当前线程上，同时，该方法生成的session其实是一个session代理，这个代理会对内部的实际session附加如下动作：
对session的数据操作方法进行拦截，确认在执行操作前已经调用过begainTranscation()开启了一个事务，否则会抛出异常。这一点确保了对session的使用必须总是从创建一个事务开始的。
当事务在commit或rollback后session会自动关闭。这一点确保了事务提交后session也将不可用。
正是这两点确保了Session与Transaction保持了一致的生命周期。

一切是这样进行的

结合上述场景和Spring的解决方案，一个使用了Spring声明性事务，实现了良好分层的程序，它的资源和事务在Spring的控制下是这样工作的：

若当前线程执行到了一个需要进行事务控制的方法(如某个service的方法)，通过AOP拦截，spring会在方法执行前申请一个数据库连接或者一个hibernate session.
成功获得资源后，开启一个事务。
将资源也就是数据库连接或是hibernate session的实例存放于当前线程的ThreadLocal里(也就是进行所谓的线程绑定)
在方法执行过程中，任何需要获得数据库连接或是hibernate session进行数据访问的地方都会从当前线程的ThreadLocal里取出同一个数据库连接或是hibernate session的实例进行操作(这个动作由Spring提供的各种Template类实现)。
方法执行结束，同样通过AOP拦截，spring取出绑定到当前线程上的事务(对于hibernate来说就是取出绑定在当前线程上一个SessionHolder实例，它保存着当前的session与transaction实例)，执行提交。
事务提交之后，释放资源，清空当前线程上绑定的所有对象！
如果该线程之后有新的事务发起，一切会重新开始，Spring会使用新的数据库连接或是hibernate session实例，开始新的事务，两个事务之间没有任何关系。

一个小小的总结
Connection-Per-Transaction/Session-Per-Transaction几乎总是你需要的。
在分层架构中，有些变量或对象确实需要跨越分层工作（比如本文示例中的Connection/Session/Transaction),你可能需一种“上下文”(或者说是一种跨层的作用域)来存放这种变量或是对象，从而避免以“参数”的形式在层间传递它，线程局部变量ThreadLocal可能正是你需要的.
整理自http://blog.csdn.net/bluishglc/article/details/7784502
http://blog.csdn.net/qjyong/article/details/2158097