ThreadLocal详解

 

转自hakunamatata2008的专栏

 

在使用Hibernate开发DAO模块以及通过Session管理服务层业务时，如何合理的管理Session，以保证每个线程独立的维护自己的Session，避免Session的频繁创建和销毁，以提高系统的性能呢？我们知道Session是由SessionFactory负责创建的，而SessionFactory的实现是线程安全的，多个并发的线程可以同时访问一个SessionFactory并从中获取Session实例，那么Session是否是线程安全的呢？很遗憾，答案是否定的。Session中包含了与数据库操作相关的状态信息，它们不能在同一时刻被多个线程共享。这给并发访问以及线程安全带来了难题。
    按照传统经验，如果某个对象是非线程安全的，在多线程环境下，对对象的访问必须采用synchronized进行线程同步。但是线程同步却限制了并发访问，这种“以时间换空间”的多线程资源共享方式往往会带来很大的性能开销。 
    在众多管理方案中，ThreadLocal为我们提供了有效的解决方案。
    早在Java1.2推出之时，Java平台中就引入了一个新的支持：java.lang.ThreadLocal，给我们在编写多线程程序时提供了一种新的选择。ThreadLocal是什么呢？也许有人会望文生义，想当然地认为是一个“本地线程”，其实ThreadLocal并非是一个线程的本地实现版本，它并不是一个Thread，而是thread local variable(线程局部变量)。也许把它命名为ThreadLocalVariable更加合适。当使用ThreadLocal维护变量时，ThreadLoacl为每一个使用该变量的线程提供一个独立的变量副本，以至于每个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。从线程的角度看，就好像每一个线程都完全拥有一个该变量，这也是类名中“Local”所要表达的意思。
    线程局部变量并不是Java的新发明，很多语言在语法层面就提供线程局部变量。在 Java中没有提供在语言级支持，而是通过ThreadLocal类来提供支持。
    ThreadLocal是如何做到为每一个线程维护变量的副本的呢？其实实现的思路很简单，在ThreadLocal类中有一个Map，用于存储每一个线程的变量副本。Map中元素的键为线程对象，而值对应线程的变量副本。
    考察ThreadLocal类的API可知，ThreadLocal类的实现很简单，只有四个方法，现介绍如下：
    1. public void set(T value)

       设置当前线程副本中的线程局部变量的值。
    2. public T get()

       返回此线程局部变量的当前线程副本中的值。

       如果这是线程第一次调用该方法，则创建并初始化此副本。
    3. public void remove()

       移除此线程局部变量的值。
       该方法是JDK 5.0新增的方法。目的是为了减少内存的占用，这可能有助于减少线程局部变量的

       存储需求。如果再次访问此线程局部变量，那么在默认情况下它将拥有其 initialValue。需要

       指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，所以显式调用该方法清除

       线程的局部变量并不是必须的操作，但它可以加快内存回收的速度。
    4. protected T initialValue()

       返回此线程局部变量的当前线程的初始值。

       最多在每次访问线程来获得每个线程局部变量时调用此方法一次，即在线程第一次使用 get()

       方法访问变量的时候。如果线程先于 get 方法调用 set(T) 方法，则不会在线程中再调用

       initialValue 方法。

       该方法是一个protected的方法，显然是为了让子类覆盖而设计的。因该缺省实现只返回 null；

       如果程序员希望将线程局部变量初始化为 null 以外的某个值，则必须为 ThreadLocal 创建子

       类，并重写此方法。通常，将使用匿名内部类。initialValue 的典型实现将调用一个适当的构

       造方法，并返回新构造的对象。

    值得注意的是，在JDK5.0中，ThreadLocal已经支持泛型（ThreadLocal<T>），API方法也相应进行了调整，使得ThreadLocal的使用变得更加强大。

 

    通过上面的分析，我们可以根据JDK所提供的ThreadLocal类的实现思路，来提供一个简单的实现版本，来清晰直观的说明ThreadLocal的实现原理：

public class SimpleThreadLocal {     private Map valueMap = Collections.synchronizedMap(new HashMap());     public void set(Object newValue) {     valueMap.put(Thread.currentThread(), newValue);     //键为线程对象，值为本线程的变量副本     }     public Object get() {         Thread currentThread = Thread.currentThread();         Object o = valueMap.get(currentThread);//返回本线程对应的变量         if (o == null && !valueMap.containsKey(currentThread)) {         //如果在Map中不存在，放到Map中保存起来。         o = initialValue();         valueMap.put(currentThread, o);         }         return o;     }     public void remove() {         valueMap.remove(Thread.currentThread());     }     public Object initialValue() {         return null;     } }

    在实际使用中，怎样做到一个线程一个独立的对象呢？
    以Hibernate的Session为例，不同的线程在使用Session时，先判断ThreadLocal.get()是否为null，如果是null，则说明当前线程还没有对应的Session对象，这时创建一个Session对象并添加到本地线程变量中；如果不为null，则说明当前的线程已经拥有了Session对象，那么直接使用就可以了。这样，就保证了不同的线程只使用一个与该线程相关的Session，而不会使用其它线程的Session。这样就保证了线程与对象的独立相关性。
    ThreadLocal为解决线程安全问题提供了一个很好的思路，它通过为每个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。

    ThreadLocal和synchronized线程同步机制的比较：
    ThreadLocal和线程同步机制相比有什么优势呢？ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。
    在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。
而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。另外，JDK 5.0中新的ThreadLocal<T>版本，通过泛型更好的解决了ThreadLocal中持有对象的类型问题，在一定程度地更加简化了ThreadLocal的使用。
    概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。

    对ThreadLocalde几种认识误区： 
1.  ThreadLocal是java线程的一个实现
    ThreadLocal的确是和java线程有关，不过它并不是java线程的一个实现，它只是用来维护本地变

    量。针对每个线程，提供自己的变量版本，主要是为了避免线程冲突，每个线程维护自己的版本。

    彼此独立，修改不会影响到对方。
2.  ThreadLocal是相对于每个session的
    ThreadLocal顾名思义，是针对线程。在java web编程上，每个用户从开始到会话结束，都有自己的

    一个session标识。但是ThreadLocal并不是在会话层上。其实，Threadlocal是独立于用户session

    的。它是一种服务器端行为，当服务器每生成一个新的线程时，就会维护自己的ThreadLocal。对于

    这个误解，个人认为应该是开发人员在本地基于一些应用服务器测试的结果。众所周知，一般的应

    用服务器都会维护一套线程池，也就是说，对于每次访问，并不一定就新生成一个线程。而是自己

    有一个线程缓存池。对于访问，先从缓存池里面找到已有的线程，如果已经用光，才去新生成新的

    线程。所以，由于开发人员自己在测试时，一般只有他自己在测，这样服务器的负担很小，这样导

    致每次访问可能是共用同样一个线程，导致会有这样的误解：每个session有一个ThreadLocal
3.  ThreadLocal是相对于每个线程的，用户每次访问会有新的ThreadLocal
    理论上来说，ThreadLocal是的确是相对于每个线程，每个线程会有自己的ThreadLocal。但是上面

    已经讲到，一般的应用服务器都会维护一套线程池。因此，不同用户访问，可能会接受到同样的线

    程。因此，在做基于TheadLocal时，需要谨慎，避免出现ThreadLocal变量的缓存，导致其他线程访

    问到本线程变量
4.  对每个用户访问，ThreadLocal可以多用
    可以说，ThreadLocal是一把双刃剑，用得来的话可以起到非常好的效果。但是，ThreadLocal如果

    用得不好，就会跟全局变量一样。代码不能重用，不能独立测试。因为，一些本来可以重用的类，

    现在依赖于ThreadLocal变量。如果在其他没有ThreadLocal场合，这些类就变得不可用了。个人觉

    得ThreadLocal用得很好的几个应用场合，值得参考
    (1). 存放当前session用户：quake want的jert
    (2). 存放一些context变量，比如webwork的ActionContext
    (3). 存放session，比如Spring hibernate orm的session