SUN公司早在JDK1.2的时候就为我们提供了java.lang.ThreadLocal,低版本的JDK所提供的get()返回的是Object对象，需要强制类型转换，使用起来不方便，而在JDK1.5引入了泛型，在一定程度地简化ThreadLocal的使用。
我们知道在spring容器中获取实例的时候都是默认单例模式，这在多线程开发的时候是尤其要注意的地方，下面先简单总结一下在开发中都有哪些情况需要考虑线程安全问题。
1）常量始终是线程安全的，它的值在初始化之后不可以改变，所以只存在读操作。
2）每次调用方法前都新建一个实例是线程安全的，因为不会访问共享的资源。
3）局部变量是线程安全的。因为每执行一个方法，都会在独立的栈空间创建局部变量，它不是共享的资源。局部变量包括方法的参数变量和方法内变量。
4）无状态的bean是线程安全的，所谓无状态就是一次操作，不能保存数据。无状态对象(Stateless Bean)，就是没有实例变量的对象，不能保存数据，是不变类，是线程安全的。无状态的Bean适合用不变模式，技术就是单例模式，这样可以共享实例，提高性能。
5）有状态的Bean，多线程环境下不安全。所谓有状态就是有数据存储功能，有状态对象(Stateful Bean)，就是有实例变量的对象，可以保存数据，是非线程安全的。有状态的bean适合用Prototype原型模式。Prototype: 每次对bean的请求都会创建一个新的bean实例。
6）静态变量在多线程环境下不安全。
总的来说，线程安全问题都是由全局变量及静态变量引起的。 若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作，一般都需要考虑线程同步，否则就可能影响线程安全。Struts2默认的实现是Prototype模式。也就是每个请求都新生成一个bean实例，所以不存在线程安全问题。需要注意的是，如果由Spring管理bean的生命周期， scope要配成prototype作用域，同时在每次获取bean时都要从上下文对象中去取，而不仅仅是在配置文件中将scope配置成prototype。
通常来讲当我们遇到线程安全问题，第一反应就是采用同步机制synchronize，通过对象的锁机制保证同一时间只有一个线程访问变量，这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。在Spring中，绝大部分Bean都可以声明为singleton作用域。就是因为Spring对一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非线程安全状态采用ThreadLocal进行处理，让它们也成为线程安全的状态，因为有状态的Bean就可以在多线程中共享了。
下面让我们打开源码，看一下ThreadLocal是怎样实现多线程环境下变量共享，首先看ThreadLocal接口：
它主要有下4个方法，void set(Object value)设置当前线程的线程局部变量的值；public Object get()该方法返回当前线程所对应的线程局部变量；public void remove()将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK 5.0新增的方法。需要指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，所以显式调用该方法清除线程的局部变量并不是必须的操作，但它可以加快内存回收的速度；protected Object initialValue()返回该线程局部变量的初始值，该方法是一个protected的方法，显然是为了让子类覆盖而设计的。这个方法是一个延迟调用方法，在线程第1次调用get()或set(Object)时才执行，并且仅执行1次。ThreadLocal中的缺省实现直接返回一个null。
我们仔细来看其set方法的实现，获取当前线程，根据线程获取一个ThreadLocalMap（ThreadLocal的一个静态内部类）对象。如果存在，则set进去一组值，key就是当前的ThreadLocal对象，value就是当前线程下该变量副本的值；如果不存在则创建一个ThreadLocalMap对象，我们点开creatMap方法发现，它会创建一个新的ThreadLocalMap对象，并且把当前ThreadLocal对象作为key，把初始化的值作为value放进去，然后赋值给当前线程的threadLocals属性,它的类型是ThreadLocalMap。
由此我们可以得知每个线程都有一个ThreadLocalMap类型的属性threadLocals，它的初始值为null，当我们第一次在线程中调用ThreadLocal的set方法时，他会根据线程去找对应的ThreadLocalMap对象，此时对象为null，则创建一个新的ThreadLocalMap对象（初始key当前threadLocal对象，初始value当前threadLocal对象执行initialValue()方法后的值），并把它赋值给threadLocals，当第二次再调用ThreadLocal的set方法时则直接给当前线程的threadLocals属性里面的value值覆盖掉，因为key值始终不变，当第一次调用ThreadLocal的get方法时，首先获取当前线程，根据线程找到对应的ThreadLocalMap对象，然后根据当前的ThreadLocal对象去获取对应的value值。总的来说就是每个线程都有自己的ThreadLocalMap类型的一个属性，它是一个集合，里面的key类型为ThreadLocal，value就是各个ThreadLocal对象的变量副本的值，一个线程中有几个ThreadLocal类型的对象，那么这个线程的属性threadLocals就有几组值。
下面我们通过实例来演示一下使用ThreadLocal和不使用的区别，代码如下：
我们可以看到使用ThreadLocal后，我们有状态的bean在多线程环境下可以正确的显示出结果，不互相影响，当我们不用ThreadLocal将全局变量包裹时，修改TestThreadLocal类，测试结果如下：
此时如果有过个线程同时对一个单例对象进行修改操作时，就会出现线程安全问题。
ThreadLocal是解决线程安全问题一个很好的思路，它通过为每个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。