Java并发编程：深入剖析ThreadLocal

　　除了控制资源的访问外，我们还可以通过增加资源来保证所有对象的线程安全。比如，让100个人填写个人信息表，如果只有一支笔，那么大家就得挨个填写，对于管理人员来说，必须保证大家不会去哄抢这仅存的一支笔，否则，谁也填不完。从另外一个角度出发，我们可以干脆就准备100支笔，人手一支，那么所有人就可以各自为营，很快就能完成表格的填写工作了。如果说锁是第一种思路，那么ThreadLocal就是使用第二种思路了。

在多线程使用SimpleDateFormat来解析字符串类型的日期，很可能会得到异常：

java.lang.NumberFormatException:For input string " "

java.lang.NumberFormatException:multiple points

出现这些问题的原因是，SimpleDateFormat.parse()方法并不是线程安全的。因此在创建的多个线程或线程池中共享这个对象很可能报错。

一种可行的方案是在sdf.parse()前后加锁，这也是我们一般的处理思路。这里我们不这样做，我们使用ThreadLocal为每一个线程都产生一个SimpleDateFormat对象实例：

 1 static ThreadLocal<SimpleDateFormat> tl = new ThreadLocal<SimpleDateFormat>();
 2     public static class ParseDate implements Runnable{
 3          int i = 0;
 4          public ParseDate(int i) {
 5              this.i = i;
 6          }
 7         public void run() {
 8             try {
 9                 if(tl.get() == null) {
10                     tl.set(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
11                 }
12                 Date t = tl.get().parse("2018-08-02 00:38:" + i%60);
13                 System.out.println(i + ":" + t);
14             } catch (ParseException e) {
15                 e.printStackTrace();
16             }
17         }
18      }

一般情况下，每一个线程的ThreadLocal存储的都是一个全新的对象（通过new关键字创建），如果多线程的ThreadLocal存储了同一个对象的引用，那么其还是会将面临资源竞争，数据不一致等并发问题。

　　在了解了ThreadLocal的内部实现后，我们自然会引出一个问题。那就是这些变量是维护在Thread类内部的（ThreadLocalMap 定义所在类），这也意味着只要线程不退出，对象的引用将一直存在。

当线程退出时，Thread类会进行一些清理工作，其中就包括清理ThreadLocalMap。

　　因此，如果我们使用线程池，那就意味着当前线程未必会退出（比如固定大小的线程池，线程总是存在）。如果这样，将一些大大的对象设置到ThreadLocal中（它实际保存在线程持有的threadLocals Map 内），可能会使系统出现内存泄漏的可能（这里我的意思是：你设置了对象到ThreadLocal中，但是不清理它，在你使用几次后，这个对象也不再有用了，但是它却无法被回收）。

此时，如果你希望及时回收对象，最好使用ThreadLocal.remove()方法将这个变量移除。就像我们习惯性地关闭数据库连接一样。如果你确定不需要这个对象了，那么就告诉虚拟机，请把它回收掉，防止内存泄漏。

　　另外一种有趣的情况是JDK也可能允许你像释放普通变量一样释放ThreadLocal。比如，我们有时候为了加速垃圾回收，会特意写出类似obj == null之类的代码。如果这么做，obj所指向的对象就会更容易地被垃圾回收器发现，从而加速回收。

同理，如果对于ThreadLocal的变量，我们也手动将其设置为null，比如tl == null。那么这个ThreadLocal对应的所有线程的局部变量都有可能被回收。

　　——《Java高并发程序设计实战》

一、对ThreadLocal的理解

ThreadLocal，很多地方叫做线程本地变量，也有些地方叫做线程本地存储，其实意思差不多。可能很多朋友都知道ThreadLocal为变量在每个线程中都创建了一个副本，那么每个线程可以访问自己内部的副本变量。

这句话从字面上看起来很容易理解，但是真正理解并不是那么容易。

我们还是先来看一个例子：

class ConnectionManager {
     
    private static Connection connect = null;
     
    public static Connection openConnection() {
        if(connect == null){
            connect = DriverManager.getConnection();
        }
        return connect;
    }
     
    public static void closeConnection() {
        if(connect!=null)
            connect.close();
    }
}

假设有这样一个数据库链接管理类，这段代码在单线程中使用是没有任何问题的，但是如果在多线程中使用呢？很显然，在多线程中使用会存在线程安全问题：第一，这里面的2个方法都没有进行同步，很可能在openConnection方法中会多次创建connect；第二，由于connect是共享变量，那么必然在调用connect的地方需要使用到同步来保障线程安全，因为很可能一个线程在使用connect进行数据库操作，而另外一个线程调用closeConnection关闭链接。

所以出于线程安全的考虑，必须将这段代码的两个方法进行同步处理，并且在调用connect的地方需要进行同步处理。

这样将会大大影响程序执行效率，因为一个线程在使用connect进行数据库操作的时候，其他线程只有等待。

那么大家来仔细分析一下这个问题，这地方到底需不需要将connect变量进行共享？事实上，是不需要的。假如每个线程中都有一个connect变量，各个线程之间对connect变量的访问实际上是没有依赖关系的，即一个线程不需要关心其他线程是否对这个connect进行了修改的。

到这里，可能会有朋友想到，既然不需要在线程之间共享这个变量，可以直接这样处理，在每个需要使用数据库连接的方法中具体使用时才创建数据库链接，然后在方法调用完毕再释放这个连接。比如下面这样：

class ConnectionManager {
     
    private  Connection connect = null;
     
    public Connection openConnection() {
        if(connect == null){
            connect = DriverManager.getConnection();
        }
        return connect;
    }
     
    public void closeConnection() {
        if(connect!=null)
            connect.close();
    }
}
 
 
class Dao{
    public void insert() {
        ConnectionManager connectionManager = new ConnectionManager();
        Connection connection = connectionManager.openConnection();
         
        //使用connection进行操作
         
        connectionManager.closeConnection();
    }
}

　这样处理确实也没有任何问题，由于每次都是在方法内部创建的连接，那么线程之间自然不存在线程安全问题。但是这样会有一个致命的影响：导致服务器压力非常大，并且严重影响程序执行性能。由于在方法中需要频繁地开启和关闭数据库连接，这样不尽严重影响程序执行效率，还可能导致服务器压力巨大。

那么这种情况下使用ThreadLocal是再适合不过的了，因为ThreadLocal在每个线程中对该变量会创建一个副本，即每个线程内部都会有一个该变量，且在线程内部任何地方都可以使用，线程之间互不影响，这样一来就不存在线程安全问题，也不会严重影响程序执行性能。

但是要注意，虽然ThreadLocal能够解决上面说的问题，但是由于在每个线程中都创建了副本，所以要考虑它对资源的消耗，比如内存的占用会比不使用ThreadLocal要大。

二、深入解析ThreadLocal类

在上面谈到了对ThreadLocal的一些理解，那我们下面来看一下具体ThreadLocal是如何实现的。

先了解一下ThreadLocal类提供的几个方法：

public T get() { }
public void set(T value) { }
public void remove() { }
protected T initialValue() { }

get()方法是用来获取ThreadLocal在当前线程中保存的变量副本，set()用来设置当前线程中变量的副本，remove()用来移除当前线程中变量的副本，initialValue()是一个protected方法，一般是用来在使用时进行重写的，它是一个延迟加载方法，下面会详细说明。

首先我们来看一下ThreadLocal类是如何为每个线程创建一个变量的副本的。

先看下get方法的实现：

第一句是取得当前线程，然后通过getMap(t)方法获取到一个map，map的类型为ThreadLocalMap。然后接着下面获取到<key,value>键值对，注意这里获取键值对传进去的是 this，而不是当前线程t。

如果获取成功，则返回value值。

如果map为空，则调用setInitialValue方法返回value。

我们上面的每一句来仔细分析：

首先看一下getMap方法中做了什么：

可能大家没有想到的是，在getMap中，是调用当期线程t，返回当前线程t中的一个成员变量threadLocals。

那么我们继续取Thread类中取看一下成员变量threadLocals是什么：

实际上就是一个ThreadLocalMap，这个类型是ThreadLocal类的一个内部类，我们继续取看ThreadLocalMap的实现：

可以看到ThreadLocalMap的Entry继承了WeakReference，并且使用ThreadLocal作为键值。

然后再继续看setInitialValue方法的具体实现：

很容易了解，就是如果map不为空，就设置键值对，为空，再创建Map，看一下createMap的实现：

至此，可能大部分朋友已经明白了ThreadLocal是如何为每个线程创建变量的副本的：

首先，在每个线程Thread内部有一个ThreadLocal.ThreadLocalMap类型的成员变量threadLocals，这个threadLocals就是用来存储实际的变量副本的，键值为当前ThreadLocal变量，value为变量副本（即T类型的变量）。

初始时，在Thread里面，threadLocals为空，当通过ThreadLocal变量调用get()方法或者set()方法，就会对Thread类中的threadLocals进行初始化，并且以当前ThreadLocal变量为键值，以ThreadLocal要保存的副本变量为value，存到threadLocals。

然后在当前线程里面，如果要使用副本变量，就可以通过get方法在threadLocals里面查找。

下面通过一个例子来证明通过ThreadLocal能达到在每个线程中创建变量副本的效果：

public class Test {
    ThreadLocal<Long> longLocal = new ThreadLocal<Long>();
    ThreadLocal<String> stringLocal = new ThreadLocal<String>();
 
     
    public void set() {
        longLocal.set(Thread.currentThread().getId());
        stringLocal.set(Thread.currentThread().getName());
    }
     
    public long getLong() {
        return longLocal.get();
    }
     
    public String getString() {
        return stringLocal.get();
    }
     
    public static void main(String[] args) throws InterruptedException {
        final Test test = new Test();
         
         
        test.set();
        System.out.println(test.getLong());
        System.out.println(test.getString());
     
         
        Thread thread1 = new Thread(){
            public void run() {
                test.set();
                System.out.println(test.getLong());
                System.out.println(test.getString());
            };
        };
        thread1.start();
        thread1.join();
         
        System.out.println(test.getLong());
        System.out.println(test.getString());
    }
}

这段代码的输出结果为：

从这段代码的输出结果可以看出，在main线程中和thread1线程中，longLocal保存的副本值和stringLocal保存的副本值都不一样。最后一次在main线程再次打印副本值是为了证明在main线程中和thread1线程中的副本值确实是不同的。

总结一下：

　　1）实际的通过ThreadLocal创建的副本是存储在每个线程自己的threadLocals中的；

　　2）为何threadLocals的类型ThreadLocalMap的键值为ThreadLocal对象，因为每个线程中可有多个threadLocal变量，就像上面代码中的longLocal和stringLocal；

　　3）如果想在get之前不需要调用set就能正常访问的话，可以重写initialValue()方法。

　　　因为在上面的代码分析过程中，我们发现如果没有先set的话，即在map中查找不到对应的存储，则会通过调用setInitialValue方法返回i，而在setInitialValue方法中，有一个语句是T value = initialValue()，而默认情况下，initialValue方法返回的是null。

看下面这个例子：

public class Test {
    ThreadLocal<Long> longLocal = new ThreadLocal<Long>();
    ThreadLocal<String> stringLocal = new ThreadLocal<String>();
 
    public void set() {
        longLocal.set(Thread.currentThread().getId());
        stringLocal.set(Thread.currentThread().getName());
    }
     
    public long getLong() {
        return longLocal.get();
    }
     
    public String getString() {
        return stringLocal.get();
    }
     
    public static void main(String[] args) throws InterruptedException {
        final Test test = new Test();
         
        System.out.println(test.getLong());
        System.out.println(test.getString());
 
        Thread thread1 = new Thread(){
            public void run() {
                test.set();
                System.out.println(test.getLong());
                System.out.println(test.getString());
            };
        };
        thread1.start();
        thread1.join();
         
        System.out.println(test.getLong());
        System.out.println(test.getString());
    }
}

如果改成下面这段代码，即重写了initialValue方法：

public class Test {
    ThreadLocal<Long> longLocal = new ThreadLocal<Long>(){
        protected Long initialValue() {
            return Thread.currentThread().getId();
        };
    };
    ThreadLocal<String> stringLocal = new ThreadLocal<String>(){;
        protected String initialValue() {
            return Thread.currentThread().getName();
        };
    };
 
     
    public void set() {
        longLocal.set(Thread.currentThread().getId());
        stringLocal.set(Thread.currentThread().getName());
    }
     
    public long getLong() {
        return longLocal.get();
    }
     
    public String getString() {
        return stringLocal.get();
    }
     
    public static void main(String[] args) throws InterruptedException {
        final Test test = new Test();
 
        test.set();
        System.out.println(test.getLong());
        System.out.println(test.getString());
     
         
        Thread thread1 = new Thread(){
            public void run() {
                test.set();
                System.out.println(test.getLong());
                System.out.println(test.getString());
            };
        };
        thread1.start();
        thread1.join();
         
        System.out.println(test.getLong());
        System.out.println(test.getString());
    }
}

就可以直接不用先set而直接调用get了。

三、ThreadLocal的应用场景

最常见的ThreadLocal使用场景为用来解决数据库连接、Session管理等。

private static ThreadLocal<Connection> connectionHolder
= new ThreadLocal<Connection>() {
public Connection initialValue() {
    return DriverManager.getConnection(DB_URL);
}
};
 
public static Connection getConnection() {
return connectionHolder.get();
}

private static final ThreadLocal threadSession = new ThreadLocal();
 
public static Session getSession() throws InfrastructureException {
    Session s = (Session) threadSession.get();
    try {
        if (s == null) {
            s = getSessionFactory().openSession();
            threadSession.set(s);
        }
    } catch (HibernateException ex) {
        throw new InfrastructureException(ex);
    }
    return s;
}

利用ThreadLocal存储用户信息

public class UserContextHolder {

    private static ThreadLocal<UserVo> local = new ThreadLocal<>();

    public static void add(UserVo userVo) {
        local.set(userVo);
    }

    /**
     * local.get() 该方法返回当前线程所对应的线程局部变量
     */
    public static UserVo getUserInfo() {
        return local.get();
    }

    /**
     * local.remove() 将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK 5.0新增的方法。
     * 需要指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，
     * 所以显式调用该方法清除线程的局部变量并不是必须//的操作，但它可以加快内存回收的速度。
     */
    public static void remove() {
        local.remove();
    }
}

四、ThreadLocal可能导致内存泄漏原因探索

引用自 https://www.toutiao.com/i6760183342961787406 部分文章篇幅：

　　前几天在京东的同学给我打了个电话，聊了下家常，技术宅的我多嘴问了最近有没有学啥? 他说最近有点忙，但抽空也看了几篇博客，他说我考考你吧，我说可以啊，他问我: ThreadLocal 使用不当会导致 OOM 吗?我不假思索的回答:会。他继续追问道:为什么? 我说:因为 ThreadLocal 和操作它的线程绑定在一起，如果操作他的线程不被销毁，与之关联的 ThreadLocal 不会被 GC 。因为使用线程大多都是通过线程池来创建的，因此只要该线程活跃，就不会被线程池销毁，如果我们使用的时候忘记调用 ThreadLocal 的 remove 方法，则 ThreadLocal 保存的值无法被 GC ，如此多了就会发生 OOM 。然后他突然问了一句:为啥 Thread 里的threadLocals 属性的key是弱引用类型的? 这个之前我是不知道的。然后他给我解释了一下，这也是这篇文章的由来，好记性不如烂笔头，顺便验证一下他说的，也是对知识的巩固。

ThreadLocal

　　多个线程间共享变量，可能会造成线程不安全的问题，需要加锁来实现线程安全，但是加锁会降低系统的吞吐量。
但是有些变量就不需要线程间共享。比如数据库连接池里的连接，我们可以通过串行线程封闭技术来安全的使用连接池中的连接。一个线程A从连接池中把连接拿走，连接池保证不把该连接给别的线程，线程A同样不会把连接发布出去，用完之后返回给连接池，这样一个连接总是在一个线程中使用，不会同时被两个线程操作。线程A保存数据库连接就可以使用 ThreadLocal 来保存，可以在多个方法中获取操作数据库，用完删除即可。(生产者和消费者模式也是使用串行线程封闭技术，大家可以考虑下。)
ThreadLocal 里的数据，其它线程无法访问，只要使用者不把数据发布出去，就可以安全操作它们。

　　ThreadLocal操作不当会引发内存泄露，最主要的原因在于它的内部类ThreadLocalMap中的Entry的设计。

　　Entry继承了WeakReference<ThreadLocal<?>>，即Entry的key是弱引用，所以key'会在垃圾回收的时候被回收掉，而key对应的value则不会被回收，这样会导致一种现象：key为null，value有值。

key为空的话value是无效数据，久而久之，value累加就会导致内存泄漏。

ThreadLocal 的 get方法：

public T get() { 
 Thread t = Thread.currentThread();
 //获取当前线程的 threadLocals 属性
 ThreadLocalMap map = getMap(t);
 if (map != null) {
 //若threadLocals属性不为空，以 this(当前 ThreadLocal)实例为健获取对应的值
 ThreadLocalMap.Entry e = map.getEntry(this);
 if (e != null) {
 //若已经设置过值或者有初始值就直接返回
 @SuppressWarnings("unchecked")
 T result = (T)e.value;
 return result;
 }
 }
 //当前线程的threadLocals属性为空或者没有设置过值时设置初始值
 return setInitialValue();
 }
 /**
 * 获取与给定线程相关联的ThreadLoal散列表 
 * @param t 当前线程
 */
 ThreadLocalMap getMap(Thread t) {
 return t.threadLocals;
 }

 private T setInitialValue() {
 //调用 initialValue 获取初始值默认为 null
 T value = initialValue();
 Thread t = Thread.currentThread();
 //获取当前线程的 threadLocals 属性
 ThreadLocalMap map = getMap(t);
 if (map != null)
 //如果已经创建与当前线程关联的 ThreadLoal 散列表，则直接设值
 map.set(this, value);
 else
 //创建与当前线程相关的 ThreadLocal 散列表 并设值
 createMap(t, value);
 return value;
 }
 /**
 * 创建与当前线程关联的 ThreadLocal 散列表，
 * 并将它赋值给给定线程的 threadLocals 属性
 * @param t 当前线程
 * @param ThreadLocal散列表第一个Entry的初始值
 */
 void createMap(Thread t, T firstValue) {
 t.threadLocals = new ThreadLocalMap(this, firstValue);
 }

View Code

ThreadLocal 中的set 方法

/**
 * 向当前线程的线程私有变量设置指定的值
 */
 public void set(T value) {
 Thread t = Thread.currentThread();
 //获取当前线程的 threadLocals 属性
 ThreadLocalMap map = getMap(t);
 if (map != null)
 //如果已经创建与当前线程关联的 ThreadLoal 散列表，则直接设值
 map.set(this, value);
 else
 //创建与当前线程相关的 ThreadLocal 散列表, 并设值
 createMap(t, value);
 }

View Code

下面我们用一张图来概括下线程，线程私有变量以及用户定义的数据之间的关系，加深我们的理解：

　　上图中 Entry 中的 key 是弱引用类型的，因此用户程序使用完ThreadLocal 对象之后忘记调用 remove 方法，下一次 GC 会把只有一个弱引用的ThreadLocal 回收掉，此时 key 指向 null,则无论谁都不能访问到该key 对应的 value 对象，只要线程实例不退出就无法释放，如果value 对象占用内存很大，则可能会造成OOM。

怎么解决这个内存泄漏问题

　　每次使用完ThreadLocal都调用它的remove()方法清除数据。因为它的remove方法会主动将当前的key和value(Entry)进行清除。

e.clear()用于清除Entry的key，它调用的是WeakReference中的方法:this.referent = null

expungeStaleEntry(i)用于清除Entry对应的value，这个后面会详细讲。

JDK开发者是如何避免内存泄漏的

　　ThreadLocal的设计者也意识到了这一点(内存泄漏)，他们在一些方法中埋了对key=null的value擦除操作。

　　这里拿ThreadLocal提供的get()方法举例，它调用了ThreadLocalMap#getEntry()方法，对key进行了校验和对null key进行擦除。

如果key为null，则会调用getEntryAfterMiss()方法，在这个方法中，如果k == null ，则调用expungeStaleEntry(i);方法。

expungeStaleEntry(i)方法完成了对key=null 的key所对应的value进行赋空，释放了空间避免内存泄漏。

同时它遍历下一个key为空的entry，并将value赋值为null，等待下次GC释放掉其空间。

同理， set()方法最终也是调用该方法(expungeStaleEntry)，调用路径:

set(T value)->

map.set(this, value)->

rehash()->

expungeStaleEntries()

remove方法

remove()->

ThreadLocalMap.remove(this)->

expungeStaleEntry(i)

　　这样做，也只能说尽可能避免内存泄漏，但并不会完全解决内存泄漏这个问题。比如极端情况下我们只创建ThreadLocal但不调用set、get、remove方法等。所以最能解决问题的办法就是用完ThreadLocal后手动调用remove().

手动释放ThreadLocal遗留存储?你怎么去设计/实现？

这里主要是强化一下手动remove的思想和必要性，设计思想与连接池类似。

包装其父类remove方法为静态方法，如果是spring项目，可以借助于bean的声明周期，在拦截器的afterCompletion阶段进行调用。

弱引用导致内存泄漏，那为什么key不设置为强引用

这个问题就比较有深度了，是你谈薪的小小资本。

如果key设置为强引用，当threadLocal实例释放后， threadLocal=null，但是threadLocal会有强引用指向threadLocalMap，threadLocalMap.Entry又强引用threadLocal，这样会导致threadLocal不能正常被GC回收。

弱引用虽然会引起内存泄漏，但是也有set、get、remove方法操作对null key进行擦除的补救措施，方案上略胜一筹。

线程执行结束后会不会自动清空Entry的value

一并考察了你的gc基础。

事实上，当currentThread执行结束后， threadLocalMap变得不可达从而被回收，Entry等也就都被回收了，但这个环境就要求不对Thread进行复用，但是我们项目中经常会复用线程来提高性能，所以currentThread一般不会处于终止状态。

Spring如何处理Bean多线程下的并发问题

ThreadLocal天生为解决相同变量的访问冲突问题，所以这个对于spring的默认单例bean的多线程访问是一个完美的解决方案。spring也确实是用了ThreadLocal来处理多线程下相同变量并发的线程安全问题。

spring 如何保证数据库事务在同一个连接下执行的

要想实现jdbc事务，就必须是在同一个连接对象中操作，多个连接下事务就会不可控，需要借助分布式事务完成。那spring 如何保证数据库事务在同一个连接下执行的呢？

DataSourceTransactionManager 是spring的数据源事务管理器，它会在你调用getConnection()的时候从数据库连接池中获取一个connection，然后将其与ThreadLocal绑定，事务完成后解除绑定。这样就保证了事务在同一连接下完成。

概要源码：

1.事务开始阶段：

org.springframework.jdbc.datasource.DataSourceTransactionManager#doBegin

->TransactionSynchronizationManager#bindResource

->org.springframework.transaction.support.TransactionSynchronizationManager#bindResource

2.事务结束阶段:

org.springframework.jdbc.datasource.DataSourceTransactionManager#doCleanupAfterCompletion

->TransactionSynchronizationManager#unbindResource

->org.springframework.transaction.support.TransactionSynchronizationManager#unbindResource

->TransactionSynchronizationManager#doUnbindResource

本文整理自：

https://www.cnblogs.com/dolphin0520/p/3920407.html

https://www.toutiao.com/i6764905475558343180

《Java高并发程序设计实战》

posted @ 2018-08-02 20:02 字节悦动阅读(237) 评论(0) 编辑收藏举报

刷新页面返回顶部

北冥有鱼