Spring中的线程安全性

Spring作为一个IOC/DI容器，帮助我们管理了许许多多的“bean”。但其实，Spring并没有保证这些对象的线程安全，需要由开发者自己编写解决线程安全问题的代码。

Spring对每个bean提供了一个scope属性来表示该bean的作用域。它是bean的生命周期。例如，一个scope为singleton的bean，在第一次被注入时，会创建为一个单例对象，该对象会一直被复用到应用结束。

• singleton：默认的scope，每个scope为singleton的bean都会被定义为一个单例对象，该对象的生命周期是与Spring IOC容器一致的（但在第一次被注入时才会创建）。

• prototype：bean被定义为在每次注入时都会创建一个新的对象。

• request：bean被定义为在每个HTTP请求中创建一个单例对象，也就是说在单个请求中都会复用这一个单例对象。

• session：bean被定义为在一个session的生命周期内创建一个单例对象。

• application：bean被定义为在ServletContext的生命周期中复用一个单例对象。

• websocket：bean被定义为在websocket的生命周期中复用一个单例对象。

我们交由Spring管理的大多数对象其实都是一些无状态的对象，这种不会因为多线程而导致状态被破坏的对象很适合Spring的默认scope，每个单例的无状态对象都是线程安全的（也可以说只要是无状态的对象，不管单例多例都是线程安全的，不过单例毕竟节省了不断创建对象与GC的开销）。

无状态的对象即是自身没有状态的对象，自然也就不会因为多个线程的交替调度而破坏自身状态导致线程安全问题。无状态对象包括我们经常使用的DO、DTO、VO这些只作为数据的实体模型的贫血对象，还有Service、DAO和Controller，这些对象并没有自己的状态，它们只是用来执行某些操作的。例如，每个DAO提供的函数都只是对数据库的CRUD，而且每个数据库Connection都作为函数的局部变量（局部变量是在用户栈中的，而且用户栈本身就是线程私有的内存区域，所以不存在线程安全问题），用完即关（或交还给连接池）。

有人可能会认为，我使用request作用域不就可以避免每个请求之间的安全问题了吗？这是完全错误的，因为Controller默认是单例的，一个HTTP请求是会被多个线程执行的，这就又回到了线程的安全问题。当然，你也可以把Controller的scope改成prototype，实际上Struts2就是这么做的，但有一点要注意，Spring MVC对请求的拦截粒度是基于每个方法的，而Struts2是基于每个类的，所以把Controller设为多例将会频繁的创建与回收对象，严重影响到了性能。

Spring根本就没有对bean的多线程安全问题做出任何保证与措施。对于每个bean的线程安全问题，根本原因是每个bean自身的设计。不要在bean中声明任何有状态的实例变量或类变量，如果必须如此，那么就使用ThreadLocal把变量变为线程私有的，如果bean的实例变量或类变量需要在多个线程之间共享，那么就只能使用synchronized、lock、CAS等这些实现线程同步的方法了。

下面将通过撸一撸ThreadLocal来了解它的实现与作用

ThreadLocal翻译成中文的话大概可以说是：线程局部变量，也就是只有当前线程能够访问。它的设计作用是为每一个使用该变量的线程都提供一个变量值的副本，每个线程都是改变自己的副本并且不会和其他线程的副本冲突，这样一来，从线程的角度来看，就好像每个线程都拥有了该变量。

下面是一个简单的实例：

public class ThreadLocalDemo {

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

    public static class MyRunnable implements Runnable{

        @Override
        public void run() {
            for (int i = 0;i<3;i++){
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                int value = local.get();
                System.out.println(Thread.currentThread().getName() + ":" + value);
                local.set(value + 1);
            }
        }
    }

    public static void main(String[] args) {
        MyRunnable runnable = new MyRunnable();
        Thread t1 = new Thread(runnable);
        Thread t2 = new Thread(runnable);
        t1.start();
        t2.start();
    }
}

上面的代码不难理解，首先是定义了一个名为 local 的ThreadLocal变量，并初识变量的值为0，然后是定义了一个实现Runnable接口的内部类，在其run方法中对local 的值做读取和加1的操作，最后是main方法中开启两个线程来运行内部类实例。

以上就是代码的大概逻辑，运行main函数后，程序的输出结果如下：

Thread-0:0
Thread-1:0
Thread-1:1
Thread-0:1
Thread-1:2
Thread-0:2

从结果可以看出，虽然两个线程都共用一个Runnable实例，但两个线程中所展示的ThreadLocal的数据值并不会相互影响，也就是说这种情况下的local 变量保存的数据相当于是线程安全的，只能被当前线程访问。

ThreadLocal实现原理

那么ThreadLocal内部是怎么保证对象是线程私有的呢？毫无疑问，答案需要从源码中查找。回顾前面的代码，可以发现其中调用了ThreadLocal的两个方法set 和 get，我们就从这两个方法入手。

先看 set() 的源码：

public void set(T value) {
    Thread t = Thread.currentThread();
    // 获取线程的ThreadLocalMap，返回map
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
    	//map为空，创建
        createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}
void createMap(Thread t, T firstValue) {
	t.threadLocals = new ThreadLocalMap(this, firstValue);
}

set的代码逻辑比较简单，主要是把值设置到当前线程的一个ThreadLocalMap对象中，而ThreadLocalMap可以理解成一个Map，它是定义在Thread类中内部的成员，初始化是为null，

ThreadLocal.ThreadLocalMap threadLocals = null;

不过，与常见的Map实现类，如HashMap之类的不同的是，ThreadLocalMap中的Entry是继承于WeakReference类的，保持了对 “键” 的弱引用和对 “值” 的强引用，这是类的源码：

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;
        }
    }
    
    //省略剩下的源码
    ....................
}

从源码中中可以看出，Entry构造函数中的参数 k 就是ThreadLocal实例，调用super(k) 表明对 k 是弱引用，使用弱引用的原因在于，当没有强引用指向 ThreadLocal 实例时，它可被回收，从而避免内存泄露，那么为何需要防止内存泄露呢？原因下面会说到。

接着说set方法的逻辑，当调用set方法时，其实是将数据写入threadLocals这个Map对象中，这个Map的key为ThreadLocal当前对象，value就是我们存入的值。而threadLocals本身能保存多个ThreadLocal对象，相当于一个ThreadLocal集合。

接着看 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;
        }
    }
    //设置初识值到ThreadLocal中并返回
    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);
        return value;
    }

get方法的逻辑也是比较简单的，就是直接获取当前线程的ThreadLocalMap对象，如果该对象不为空就返回它的value值，否则就把初始值设置到ThreadLocal中并返回。

看到这，我们大概就能明白为什么ThreadLocal能实现线程私有的原理了，其实就是每个线程都维护着一个ThreadLocal的容器，这个容器就是ThreadLocalMap，可以保存多个ThreadLocal对象。而调用ThreadLocal的set或get方法其实就是对当前线程的ThreadLocal变量操作，与其他线程是分开的，所以才能保证线程私有，也就不存在线程安全的问题了。

然而，该方案虽然能保证线程私有，但却会占用大量的内存，因为每个线程都维护着一个Map，当访问某个ThreadLocal变量后，线程会在自己的Map内维护该ThreadLocal变量与具体实现的映射，如果这些映射一直存在，就表明ThreadLocal 存在引用的情况，那么系统GC就无法回收这些变量，可能会造成内存泄露。

针对这种情况，上面所说的ThreadLocalMap中Entry的弱引用就起作用了。

TheadLocal与同步机制的区别

最后，总结一下ThreadLocal和同步机制之间的区别吧。

实现机制：

同步机制采用了“以时间换空间”的方式，控制资源保证同一时刻只能有一个线程访问。

ThreadLocal采用了“以空间换时间”的方式，为每一个线程都提供一份变量的副本，从而实现同时访问而互不影响，但因为每个线程都维护着一份副本，对内存空间的占用会增加。

数据共享：

同步机制是对公共资源做控制访问的方式来保证线程安全，但资源仍是共享状态，可用于线程间的通信；

ThreadLocal是每个线程都有自己的资源(变量)副本，互相之间不影响，也就不存在共享的说法了。