ThreadLocal 使用及源码详解（四）

偏执的太偏执、 2022-11-21 11:35 213阅读 0赞

ThreadLocal 作为线程副本，开发过程经常使用，今天我们详细分析一下：

***1、首先与***  ***Synchonized***  ***的比较***

ThreadLocal  和  Synchonized  都用于解决多线程并发訪问。可是  ThreadLocal 与 synchronized  有本质的差别。 synchronized  是利用锁的机制，使变量或代码块 在某一时该仅仅能被一个线程訪问。而 ThreadLocal  为每个线程都提供了变量的 副本，使得每个线程在某一时间訪问到的并非同一个对象，这样就隔离了多个线 程对数据的数据共享。 Spring 的事务就借助了 ThreadLocal  类。Spring 会从数据库连接池中获得一个 connection，然会把  connection  放进  ThreadLocal  中，也就和线程绑定了，事务需 要提交或者回滚，只要从 ThreadLocal  中拿到  connection  进行操作。为何  Spring 的事务要借助 ThreadLocal  类？

以  JDBC  为例，正常的事务代码可能如下：

dbc = new DataBaseConnection();// 第  1  行

Connection con = dbc.getConnection();// 第  2  行

con.setAutoCommit(false);// // 第  3  行

con.executeUpdate(...);// 第  4  行

con.executeUpdate(...);// 第  5  行

con.executeUpdate(...);// 第  6  行

con.commit(); 第  7  行

上述代码，可以分成三个部分 :

事务准备阶段：第  1 ～ 3  行

业务处理阶段：第  4 ～ 6  行

事务提交阶段：第  7  行

可以很明显的看到，不管我们开启事务还是执行具体的  sql  都需要一个具体 的数据库连接。 现在我们开发应用一般都采用三层结构，如果我们控制事务的代码都放在

DAO(DataAccessObject) 对象中，在  DAO  对象的每个方法当中去打开事务和关闭 事务，当 Service  对象在调用  DAO  时，如果只调用一个  DAO ，那我们这样实现则

效果不错，但往往我们的  Service  会调用一系列的  DAO  对数据库进行多次操作， 那么，这个时候我们就无法控制事务的边界了，因为实际应用当中，我们的 Service

调用的  DAO  的个数是不确定的，可根据需求而变化，而且还可能出现  Service  调 用 Service  的情况。 如果不使用 ThreadLocal ，代码大概就会是这个样子：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

但是需要注意一个问题，如何让三个  DAO  使用同一个数据源连接呢？我们 就必须为每个 DAO  传递同一个数据库连接，要么就是在  DAO  实例化的时候作为 构造方法的参数传递，要么在每个 DAO  的实例方法中作为方法的参数传递。这 两种方式无疑对我们的 Spring  框架或者开发人员来说都不合适。为了让这个数据 库连接可以跨阶段传递，又不显示的进行参数传递，就必须使用别的办法。 Web 容器中，每个完整的请求周期会由一个线程来处理。因此，如果我们 能将一些参数绑定到线程的话，就可以实现在软件架构中跨层次的参数共享（是 隐式的共享）。而 JAVA  中恰好提供了绑定的方法 \-- 使用  ThreadLocal 。 结合使用 Spring  里的  IOC  和  AOP ，就可以很好的解决这一点。 只要将一个数据库连接放入 ThreadLocal  中，当前线程执行时只要有使用数 据库连接的地方就从 ThreadLocal  获得就行了。

***2、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 。

public final static ThreadLocal<String> RESOURCE = new ThreadLocal<String>();RESOURCE代表一个能够存放 String 类型的 ThreadLocal 对象。 此时不论什么一个线程能够并发访问这个变量，对它进行写入、读取操作，都是 线程安全的。

举例：

/**
     *类说明：演示ThreadLocal的使用
     */
    public class UseThreadLocalTest {
    	
    	private static ThreadLocal<Integer> intLocal
                = new ThreadLocal<Integer>(){
            @Override
            protected Integer initialValue() {
                return 1;
            }
        };
    
        private static ThreadLocal<String> stringThreadLocal;
    
        /**
         * 运行3个线程
         */
        public void StartThreadArray(){
            Thread[] runs = new Thread[3];
            for(int i=0;i<runs.length;i++){
                runs[i]=new Thread(new TestThread(i));
            }
            for(int i=0;i<runs.length;i++){
                runs[i].start();
            }
        }
        
        /**
         *类说明：测试线程，线程的工作是将ThreadLocal变量的值变化，并写回，看看线程之间是否会互相影响
         */
        public static class TestThread implements Runnable{
            int id;
            public TestThread(int id){
                this.id = id;
            }
            public void run() {
                System.out.println(Thread.currentThread().getName()+":start");
                Integer s = intLocal.get();
                s = s+id;
                intLocal.set(s);
                System.out.println(Thread.currentThread().getName()
                        +":"+ intLocal.get());
                //intLocal.remove();
            }
        }
    
        public static void main(String[] args){
        	UseThreadLocalTest test = new UseThreadLocalTest();
            test.StartThreadArray();
        }
    }

执行后，结果一一对应：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

***3、实现解析***

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

每个线程都有自己的 一个  ThreadLocalMap ，每个线程可能有都多种类型的ThreadLocal ,比如：ThreadLocal<String>、 ThreadLocal<Integer>、 ThreadLocal<User>

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

![20201101135043851.png][]

![20201101135050414.png][]

上面先取到当前线程，然后调用  getMap  方法获取对应的  ThreadLocalMap ， ThreadLocalMap 是  ThreadLocal  的静态内部类，然后  Thread  类中有一个这样类型 成员，所以 getMap  是直接返回  Thread  的成员。 看下 ThreadLocal  的内部类  ThreadLocalMap  源码：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

可以看到有个  Entry  内部静态类，它继承了  WeakReference ，总之它记录了 两个信息，一个是 ThreadLocal<?> 类型，一个是  Object  类型的值。 getEntry  方法 则是获取某个 ThreadLocal  对应的值，set 方法就是更新或赋值相应的  ThreadLocal 对应的值。

![20201101135133880.png][]

![20201101135138754.png][]

回顾我们的  get  方法，其实就是拿到 **每个线程独有的 ThreadLocalMap**  然后再用 ThreadLocal  的当前实例，拿到  Map  中的相应的  Entry ，然后就可 以拿到相应的值返回出去。当然，如果 Map  为空，还会先进行  map  的创建，初 始化等工作。

***4、引发的内存泄漏分析***

预备知识

引用Object o = new Object();这个  o ，我们可以称之为对象引用，而  new Object() 我们可以称之为在内存 中产生了一个对象实例。 当写下 **o=null**  时，只是表示  o  不再指

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

当写下  **o=null**  时，只是表示  o  不再指向堆中  object  的对象实例，不代表这 个对象实例不存在了。

**强引用** 就是指在程序代码之中普遍存在的，类似“ Object obj=new Object （）” 这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象实例。

**软引用** 是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象， 在系统将要发生内存溢出异常之前，将会把这些对象实例列进回收范围之中进行

第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在  JDK 1.2 之后，提供了  SoftReference  类来实现软引用。

**弱引用** 也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱 引用关联的对象实例只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，

无论当前内存是否足够，都会回收掉只被弱引用关联的对象实例。在  JDK 1.2  之 后，提供了 WeakReference  类来实现弱引用。

**虚引用** 也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象 实例是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用 来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象 实例被收集器回收时收到一个系统通知。在 JDK 1.2  之后，提供了 PhantomReference 类来实现虚引用。

5、内存泄漏的现象

执行  cn.enjoyedu.ch1.threadlocal  下的  ThreadLocalOOM ，并将堆内存大小设 置为-Xmx256m ，

代码：

/**
     * 类说明：ThreadLocal造成的内存泄漏演示
     */
    public class ThreadLocalOOM {
        private static final int TASK_LOOP_SIZE = 100;
    
        final static ThreadPoolExecutor poolExecutor
                = new ThreadPoolExecutor(5, 5,
                1,
                TimeUnit.MINUTES,
                new LinkedBlockingQueue<>());
    
        static class LocalVariable {
            private byte[] a = new byte[1024*1024*5];/*5M大小的数组*/
        }
    
        ThreadLocal<LocalVariable> localVariable;
                //= new ThreadLocal<>();
    
        public static void main(String[] args) throws InterruptedException {
            /*5*5=25*/
            for (int i = 0; i < TASK_LOOP_SIZE; ++i) {
                poolExecutor.execute(new Runnable() {
                    public void run() {
                        ThreadLocalOOM oom = new ThreadLocalOOM();
                        oom.localVariable = new ThreadLocal<>();
                        oom.localVariable.set(new LocalVariable());
                        //new LocalVariable();
                        System.out.println("use local varaible");
                        //oom.localVariable.remove();//用完删除，防止内存泄漏
                    }
                });
    
                Thread.sleep(100);
            }
            System.out.println("pool execute over");
        }
    
    }

我们启用一个线程池，大小固定为  5  个线程

![20201101135313306.png][]

场景  1 ，首先任务中不执行任何有意义的代码，当所有的任务提交执行完成 后，可以看见，我们这个应用的内存占用基本上为 25M  左右

ThreadLocal<LocalVariable> localVariable = new ThreadLocal<>();
    
        public static void main(String[] args) throws InterruptedException {
            /*5*5=25*/
            for (int i = 0; i < TASK_LOOP_SIZE; ++i) {
                poolExecutor.execute(new Runnable() {
                    public void run() {
                        
                        System.out.println("use local varaible");
                     
                    }
                });
    
                Thread.sleep(100);
            }
            System.out.println("pool execute over");
        }

场景  2 ，然后我们只简单的在每个任务中  new  出一个数组，执行完成后我们 可以看见，内存占用基本和场景 1  同

public static void main(String[] args) throws InterruptedException {
            /*5*5=25*/
            for (int i = 0; i < TASK_LOOP_SIZE; ++i) {
                poolExecutor.execute(new Runnable() {
                    public void run() {
                        new LocalVariable();
                        System.out.println("use local varaible");      
                    }
                });
    
                Thread.sleep(100);
            }
            System.out.println("pool execute over");
        }

场景  3 ，当我们启用了  ThreadLocal  以后：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6][]

执行完成后我们可以看见，内存占用变为了  100  多  M

场景  4 ，于是，我们加入一行代码，再执行，看看内存情况 :

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7][]

可以看见，内存占用基本和场景  1  同。

这就充分说明，场景  3 ，当我们启用了  ThreadLocal  以后确实发生了内存泄 漏。

6、分析

根据我们前面对  ThreadLocal  的分析，我们可以知道每个  Thread  维护一个 ThreadLocalMap，这个映射表的  key  是  ThreadLocal  实例本身， value  是真正需

要存储的  Object ，也就是说  ThreadLocal  本身并不存储值，它只是作为一个  key 来让线程从 ThreadLocalMap  获取  value 。仔细观察  ThreadLocalMap ，这个  map

是使用  ThreadLocal  的弱引用作为  Key  的，弱引用的对象在  GC  时会被回收。 因此使用了 ThreadLocal  后，引用链如图所示

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8][]

图中的虚线表示弱引用。

这样，当把  threadlocal  变量置为  null  以后，没有任何强引用指向  threadlocal 实例，所以 threadlocal  将会被  gc  回收。这样一来， ThreadLocalMap  中就会出现 key  为  null  的  Entry ，就没有办法访问这些  key  为  null  的  Entry  的  value ，如果当前 线程再迟迟不结束的话，这些 key  为  null  的  Entry  的  value  就会一直存在一条强 引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value ，而这块  value  永 远不会被访问到了，所以存在着内存泄露。 只有当前 thread  结束以后， current thread  就不会存在栈中，强引用断开， Current Thread、 Map value  将全部被  GC  回收。最好的做法是不在需要使用 ThreadLocal 变量后，都调用它的  remove() 方法，清除数据。 所以回到我们前面的实验场景，场景 3  中，虽然线程池里面的任务执行完毕 了，但是线程池里面的 5  个线程会一直存在直到  JVM  退出，我们  set  了线程的 localVariable 变量后没有调用  localVariable.remove() 方法，导致线程池里面的  5  个 线程的 threadLocals  变量里面的  new LocalVariable() 实例没有被释放。 其实考察 ThreadLocal  的实现，我们可以看见，无论是  get() 、 set() 在某些时 候，调用了 expungeStaleEntry  方法用来清除  Entry  中  Key  为  null  的  Value ，但是 这是不及时的，也不是每次都会执行的，所以一些情况下还是会发生内存泄露。 只有 remove() 方法中显式调用了  expungeStaleEntry  方法。 从表面上看内存泄漏的根源在于使用了弱引用，但是另一个问题也同样值得

思考：为什么使用弱引用而不是强引用？

下面我们分两种情况讨论：

key  使用强引用：对  ThreadLocal  对象实例的引用被置为  null  了，但是 ThreadLocalMap 还持有这个  ThreadLocal  对象实例的强引用，如果没有手动删除， ThreadLocal 的对象实例不会被回收，导致  Entry  内存泄漏。 key 使用弱引用：对  ThreadLocal  对象实例的引用被被置为  null  了，由于 ThreadLocalMap 持有  ThreadLocal  的弱引用，即使没有手动删除， ThreadLocal  的 对象实例也会被回收。value  在下一次  ThreadLocalMap  调用  set ， get ， remove  都 有机会被回收。 比较两种情况，我们可以发现：由于 ThreadLocalMap 的生命周期跟  Thread 一样长，如果都没有手动删除对应 key ，都会导致内存泄漏，但是使用弱引用可 以多一层保障。 因此，ThreadLocal  内存泄漏的根源是：由于  ThreadLocalMap  的生命周期跟 Thread 一样长，如果没有手动删除对应  key  就会导致内存泄漏，而不是因为弱引 用。

7、小结：

JVM  利用设置  ThreadLocalMap  的  Key  为弱引用，来避免内存泄露。 JVM 利用调用  remove 、 get 、 set  方法的时候，回收弱引用。 当 ThreadLocal  存储很多  Key  为  null  的  Entry  的时候，而不再去调用  remove 、 get、 set  方法，那么将导致内存泄漏。 使用**线程池** **+**  ThreadLocal  时要小心，因为这种情况下，线程是一直在不断的 重复运行的，从而也就造成了 value  可能造成累积的情况。

***8、错误使用***  ***ThreadLocal***  ***导致线程不安全   *** 参见如下代码：

/**
     * 类说明：ThreadLocal的线程不安全演示
     */
    public class ThreadLocalUnsafe implements Runnable {
    
        public Number number = new Number(0);
    
        public void run() {
            //每个线程计数加一
            number.setNum(number.getNum()+1);
          //将其存储到ThreadLocal中
            value.set(number);
            SleepTools.ms(2);
            //输出num值
            System.out.println(Thread.currentThread().getName()+"="+value.get().getNum());
        }
    
        public static ThreadLocal<Number> value = new ThreadLocal<Number>() {
        };
    
        public static void main(String[] args) {
            for (int i = 0; i < 5; i++) {
                new Thread(new ThreadLocalUnsafe()).start();
            }
        }
    
        private static class Number {
            public Number(int num) {
                this.num = num;
            }
    
            private int num;
    
            public int getNum() {
                return num;
            }
    
            public void setNum(int num) {
                this.num = num;
            }
    
            @Override
            public String toString() {
                return "Number [num=" + num + "]";
            }
        }
    
    }

运行后的结果为

![20201101135533274.png][]

如果我们  改变参数：  public static Number number = new Number(0);就会变成线程不安全，static 修饰的变量，是线程共享的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9][]

为什么每个线程都输出  5 ？难道他们没有独自保存自己的  Number  副本吗？ 为什么其他线程还是能够修改这个值？仔细考察 ThreadLocal  和  Thead  的代码， 我们发现 ThreadLocalMap  中保存的其实是对象的一个引用，这样的话，当有其 他线程对这个引用指向的对象实例做修改时，其实也同时影响了所有的线程持有 的对象引用所指向的同一个对象实例。这也就是为什么上面的程序为什么会输出 一样的结果：5  个线程中保存的是同一  Number  对象的引用，在线程睡眠的时候， 其他线程将 num  变量进行了修改，而修改的对象  Number  的实例是同一份，因 此它们最终输出的结果是相同的。 而上面的程序要正常的工作，应该的用法是让每个线程中的 ThreadLocal  都 应该持有一个新的 Number  对象。

ThreadLocal 使用及源码详解分析完毕，不懂地方可以留言。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221120/efe078ee16ea4fa7ac11f28df22a5c9c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221120/1051c1e03a394bd59cf687a59ac76cfe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221120/55516113525145d88e2a4f40594ab56a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221120/5e2d4728667b46d4b0afbc6a6ce8c020.png
[20201101135043851.png]: /images/20221120/9ba31f49eec74319b0b32079f9361cf4.png
[20201101135050414.png]: /images/20221120/475ebd1230c847f78d039e8783b489ce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221120/5fdaa66a9bfe4155b49d604e0a96acc6.png
[20201101135133880.png]: /images/20221120/ea475a0ef9744bd7807b2a35c51aa624.png
[20201101135138754.png]: /images/20221120/0b0e7642c95441a1aeffa2a8c109d8c9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221120/f9e376c44d8a4f9fbc30b2f2c69be209.png
[20201101135313306.png]: /images/20221120/5b786c422aaf4c499733efa7e6422cd6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6]: /images/20221120/20fc615d26a04cc5873f3b63aa2680da.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7]: /images/20221120/a07dc52beeb84ac69f6bfb6fb4a482ce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8]: /images/20221120/96f60548f97844ebbe2a106fef6b6aee.png
[20201101135533274.png]: /images/20221120/85b7f231d460421fafee71e2318b5def.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9]: /images/20221120/d6089a4d4c79455cab6cf6c1434f147a.png