多线程基础总结四--ThreadLocal

   说到ThreadLocal，首先说说这个类的命名。直观上看好像是个Thread的什么亲戚，但其实它想表达的意思是线程本地变量，也就是说每个线程自己的变量。它作为一个JDK5以后支持范型的类，主要是想利用范型把非线程安全的共享变量，封装成绑定线程的安全不共享变量。这样的解释我想我们多半能猜出它的实现思路：把一个共享变量在每个线程使用时，初始化一个副本，并且和线程绑定。以后所有的线程对共享变量的操作都是对线程内部那个副本，完全的线程内部变量的操作。

   要实现这样功能类的设计，主要技术点是要能把副本和线程绑定映射，程序可以安全查找到当前线程的副本，修改后安全的绑定给线程。所以我们想到了Map的存储结构，ThreadLocal内部就是使用了线程安全的Map形式的存储把currentThread和变量副本一一映射。
既然要把共享的变成不共享的，那么就要变量满足一个场景：变量的状态不需要共享。例如无状态的bean在多线程之间是安全的，因为线程之间不需要同步bean的状态，用了就走（很不负责啊），想用就用。但是对于有状态的bean在线程之间则必须小心，线程A刚看到状态是a，正想利用a做事情，线程B把bean的状态改为了b，结果做了不该做的。但是如果有状态的bean不需要共享状态，每个线程看到状态a或者b都可以做出自己的行为，这种情况下不同步的选择就是ThreadLocal了。

   利用ThreadLocal的优势就在于根本不用担心有状态的bean为了状态的一致而牺牲性能，去使用synchronized限制只有一个线程在同一时间做出关于bean状态的行为。而是多个线程同时根据自己持有的bean的副本的状态做出行为，这样的转变对于并发的支持是那么的不可思议。例如一个Dao内有个Connection的属性，当多个线程使用Dao的同一个实例时，问题就来了：多个线程用一个Connection，而且它还是有连接，关闭等等的状态转变的，我们很敏感的想到这个属性不安全！再看这个属性，其实它是多么的想告诉线程哥哥们：我的这些状态根本就不想共享，不要因为我的状态而不敢一起追求。线程哥哥们也郁闷：你要是有多胞胎姐妹该多好啊！这时候ThreadLocal大哥过来说：小菜，我来搞定！你们这些线程一人一个Connection，你想关就关，想连接就连接，再也不用抱怨说它把你的连接关了。这样Dao的实例再也不用因为自己有个不安全的属性而自卑了。当然ThreadLocal的思路虽然是很好的，但是官方的说法是最初的实现性能并不好，随着Map结构和Thread.currentThread的改进，性能较之synchronized才有了明显的优势。所以要是使用的是JDK1.2,JDK1.3等等，也不要妄想麻雀变凤凰...

   再看ThreadLocal和synchronized的本质。前者不在乎多占点空间，但是绝对的忍受不了等待；后者对等待无所谓，但是就是不喜欢浪费空间。这也反映出了算法的一个规律：通常是使用场景决定时间和空间的比例，既省时又省地的算法多数情况下只存在于幻想之中。下面写个简单的例子解释一下，不过个人觉得设计的例子不太好，以后有实际的启发再替换吧。

import java.util.concurrent.atomic.AtomicInteger;

/**
 * User: yanxuxin
 * Date: Dec 14, 2009
 * Time: 9:26:41 PM
 */
public class ThreadLocalSample extends Thread {
    private OperationSample2 operationSample;

    public ThreadLocalSample(OperationSample2 operationSample) {
        this.operationSample = operationSample;
    }

    @Override
    public void run() {
        operationSample.printAndIncrementNum();
    }

    public static void main(String[] args) {

        final OperationSample2 operation = new OperationSample2();//The shared Object for threads.

        for (int i = 0; i < 5; i++) {
            new ThreadLocalSample(operation).start();
        }
    }
}

class OperationSample {
    private int num;

    //public synchronized void printAndIncrementNum() {
    public void printAndIncrementNum() {
        for (int i = 0; i < 2; i++) {
            System.out.println(Thread.currentThread().getName() + "[id=" + num + "]");
            num += 10;
        }
    }
}

class OperationSample2 {

    private static ThreadLocal<Integer> threadArg = new ThreadLocal<Integer>() {
        @Override
        protected Integer initialValue() {
            return 0;
        }
    };

    public void printAndIncrementNum() {
        for (int i = 0; i < 2; i++) {
            int num = threadArg.get();
            threadArg.set(num + 10);
            System.out.println(Thread.currentThread().getName() + "[id=" + num + "]");
        }
    }
}

class OperationSample3 {

    private static final AtomicInteger uniqueId = new AtomicInteger(0);
    private static ThreadLocal<Integer> threadArg = new ThreadLocal<Integer>() {
        @Override
        protected Integer initialValue() {
            return uniqueId.getAndIncrement();
        }
    };

    public void printAndIncrementNum() {
        for (int i = 0; i < 2; i++) {
            int num = threadArg.get();
            threadArg.set(num + 10);
            System.out.println(Thread.currentThread().getName() + "[id=" + num + "]");
        }
    }
}

这个例子中ThreadLocalSample继承自Thread持有OperationSample三个版本中的一个引用，并且在线程运行时执行printAndIncrementNum()方法。

   首先看版本1：OperationSample有个共享变量num，printAndIncrementNum()方法没有同步保护，方法就是循环给num赋新值并打印改变值的线程名。因为没有任何的同步保护，所以原本打算每个线程打印出的值是相邻递加10的结果变成了不确定的递加。有可能线程1的循环第一次打印0，第二次就打印50。这时候我们使用被注释的方法声明，结果就是预想的同一个线程的两次结果是相邻的递加，因为同一时刻只有一个线程获得OperationSample实例的隐式锁完成循环释放锁。

   再看版本2：假设我们有个递增10的简单计数器，但是是对每个线程的计数。也就是说我们有一个Integer计数器负责每个线程的计数。虽然它是有状态的，会变的，但是因为每个线程之间不需要共享变化，所以可以用ThreadLocal管理这个Integer。在这里看到我们的ThreadLocal变量的initialValue()方法被覆写了，这个方法的作用就是当调用ThreadLocal的get()获取线程绑定的副本时如果还没绑定则调用这个方法在Map中添加当前线程的绑定映射。这里我们返回0，表示每个线程的初始副本在ThreadLocal的Map的纪录都是0。再看printAndIncrementNum()方法，没有任何的同步保护，所以多个线程可以同时进入。但是，每个线程通过threadArg.get()拿到的仅仅是自己的Integer副本，threadArg.set(num + 10)的也是自己的副本值。所以结果就是虽然线程的两次循环打印有快有慢，但是每个线程的两次结果都是0和10。

   最后是版本3：和版本2的不同在于新加了一个uniqueId的变量。这个变量是java.util.concurrent.atomic包下的原子变量类。这是基于硬件支持的CAS(比较交换)原语的实现，所以保证了++,--,+=,-=等操作的原子性。所以在ThreadLocal变量的initialValue()方法中使用uniqueId.getAndIncrement()将为每个线程初始化唯一不会重复的递加1的Integer副本值。而结果就会变成5个线程的首次打印是0～4的5个数字，第二次每个线程的打印是线程对应的首次数字加10的值。

   对于ThreadLocal的使用，Spring的源码中有大量的应用，主要是要支持Singleton的实例管理，那么自身的一些Singleton的实现内非线程安全的变量，属性要用ThreadLocal隔离共享。同时我们在使用Spring的IOC时也要注意有可能多线程调用的注册到IOC容器的Singleton型实例是否真的线程安全。另外java.util.concurrent.atomic内的原子变量类简单的提了一下，再看看怎么能瞎编出东西来吧。