ThreadLocal

最新推荐文章于 2024-08-06 17:56:45 发布

so1ucky

最新推荐文章于 2024-08-06 17:56:45 发布

阅读量37

点赞数

文章标签： java

本文链接：https://blog.csdn.net/so1ucky/article/details/131809604

版权

导致 JVM 内存泄露的 ThreadLocal

为什么要有 ThreadLocal

package com.xhtest.tl.jdbc;

import java.sql.*;

/**
 * 类说明：JDBC常见用法
 */
public class UseJdbc {
    /*获得数据库连接*/
    private static Connection getConn() {
        String driver = "com.mysql.jdbc.Driver";
        String url = "jdbc:mysql://localhost:3306/samp_db";
        String username = "root";
        String password = "";
        Connection conn = null;
        try {
            Class.forName(driver); //classLoader,加载对应驱动
            conn = (Connection) DriverManager.getConnection(url, username, password);
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (SQLException e) {
            e.printStackTrace();
        }
        return conn;
    }

    /*Insert数据，Update,Delete用法与之类似*/
    private static int insert(String student) {
        Connection conn = getConn();
        int i = 0;
        String sql = "insert into students (Name,Sex,Age) values(?,?,?)";
        PreparedStatement pstmt;
        try {
            pstmt = (PreparedStatement) conn.prepareStatement(sql);
            pstmt.setString(1, student);
            i = pstmt.executeUpdate();
            pstmt.close();
        } catch (SQLException e) {
            e.printStackTrace();
        }
        return i;
    }

    /*查询数据*/
    private static Integer getAll() {
        Connection conn = getConn();
        String sql = "select * from students";
        PreparedStatement pstmt;
        try {
            pstmt = (PreparedStatement)conn.prepareStatement(sql);
            ResultSet rs = pstmt.executeQuery();
            while (rs.next()) {
                /*读取数据做业务处理*/
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        return null;
    }
}

可以看到，在使用 JDBC 时，我们首先要配置后再拿到 JDBC 连接，然后在增删改查的业务方法中拿到这个连接，并把我们的 SQL 语句交给 JDBC 连接发送到真实的 DB 上执行。

在实际的工作中，我们不会每次执行 SQL 语句时临时去建立连接，而是会借助数据库连接池，同时因为实际业务的复杂性，为了保证数据的一致性，我们还会引入事务操作，于是上面的代码就会变成：

package com.xhtest.tl.jdbc;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

/**
 * 类说明：使用连接池和事务的JDBC
 */
public class UsePoolTran {

    /*数据库连接池*/
    private static DBPool dbPool = new DBPool(10);

    /*使用事务*/
    public void business(){
        /*获取连接*/
        Connection conn = null;
        try {
            conn = dbPool.fetchConnection(1000);
            conn.setAutoCommit(false);/*开启事务*/

            insert("13号");
            System.out.println("其他业务工作");
            insert("14号");

            conn.commit();/*提交*/
        } catch (Exception e) {
            try {
                /*发生异常时，回滚*/
                if(null!=conn) conn.rollback();
            } catch (SQLException e1) {
                e1.printStackTrace();
            }
            e.printStackTrace();
        }finally {
            try {
                conn.close();
            } catch (SQLException e) {
                e.printStackTrace();
            }
        }
    }

    /*Insert数据，Update,Delete用法与之类似*/
    private static int insert(String student) {
        int i = 0;
        try {
            Connection conn = dbPool.fetchConnection(1000);
            String sql = "insert into students (Name,Sex,Age) values(?,?,?)";
            PreparedStatement pstmt;
            pstmt = (PreparedStatement) conn.prepareStatement(sql);
            pstmt.setString(1, student);
            i = pstmt.executeUpdate();
            pstmt.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return i;
    }

    /*查询数据*/
    private static Integer getAll() {
        try {
            Connection conn = dbPool.fetchConnection(1000);
            String sql = "select * from students";
            PreparedStatement pstmt;
            pstmt = (PreparedStatement)conn.prepareStatement(sql);
            ResultSet rs = pstmt.executeQuery();
            while (rs.next()) {
                /*读取数据做业务处理*/
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }
}

但是上面的代码包含什么样的问题呢？分析代码我们可以发现，执行业务方法 business 时，为了启用事务，我们从数据库连接池中拿了一个连接，但是在具体的 insert 方法和 getAll 方法中，在执行具体的 SQL 语句时，我们从数据库连接池中拿一个连接，这就说执行事务和执行 SQL 语句完全是不同的数据库连接，这会导致什么问题？事务失效了！！数据库执行事务时，事务的开启和提交、语句的执行等都是必须在一个连接中的。实际上，上面的代码要保证数据的一致性，就必须要启用分布式事务。

怎么解决这个问题呢？有一个解决思路是，把数据库连接作为方法的参数，在方法之间进行传递，比如下面这样：

package com.xhtest.tl.jdbc;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

/**
 * 类说明：正确使用事务的JDBC
 */
public class UsePoolTranOK {

    private static DBPool dbPool = new DBPool(10);

    /*Insert数据，Update,Delete用法与之类似*/
    private static int insert(String student,Connection conn) {
        int i = 0;
        try {
            String sql = "insert into students (Name,Sex,Age) values(?,?,?)";
            PreparedStatement pstmt;
            pstmt = (PreparedStatement) conn.prepareStatement(sql);
            pstmt.setString(1, student);
            i = pstmt.executeUpdate();
            pstmt.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return i;
    }

    /*查询数据*/
    private static Integer getAll(Connection conn) {
        try {
            String sql = "select * from students";
            PreparedStatement pstmt;
            pstmt = (PreparedStatement)conn.prepareStatement(sql);
            ResultSet rs = pstmt.executeQuery();
            while (rs.next()) {
                /*读取数据做业务处理*/
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }

    /*使用事务*/
    public void business(){
        /*获取连接*/
        Connection conn = null;
        try {
            conn = dbPool.fetchConnection(1000);
            conn.setAutoCommit(false);/*开启事务*/

            insert("13号",conn);
            System.out.println("其他业务工作");
            insert("14号",conn);

            conn.commit();/*提交*/
        } catch (Exception e) {
            try {
                if(null!=conn) conn.rollback();/*发生异常时，回滚*/
            } catch (SQLException e1) {
                e1.printStackTrace();
            }
            e.printStackTrace();
        }finally {
            try {
                conn.close();
            } catch (SQLException e) {
                e.printStackTrace();
            }
        }
    }
}

但是我们分析平时我们使用 SSM 的代码会发现，我们在编写数据访问相关代码的时候从来没有把数据库连接作为方法参数进行传递。这意味着，对 Spring来说，在帮我们进行事务托管的时候，会遇到同样的问题，那么 Spring 是如何解决这个问题的？

其实稍微分析下 Spring 的事务管理器的代码就能发现端倪，在org.springframework.jdbc.datasource.DataSourceTransactionManager#doBegin 中，我们会看到如下代码

			// Bind the connection holder to the thread.
			if (txObject.isNewConnectionHolder()) {
				TransactionSynchronizationManager.bindResource(obtainDataSource(), txObject.getConnectionHolder());
			}

	public static void bindResource(Object key, Object value) throws IllegalStateException {
		Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
		Assert.notNull(value, "Value must not be null");
		Map<Object, Object> map = resources.get();
		// set ThreadLocal Map if none found
		if (map == null) {
			map = new HashMap<>();
			resources.set(map);
		}

	private static final ThreadLocal<Map<Object, Object>> resources =
			new NamedThreadLocal<>("Transactional resources");

public class NamedThreadLocal<T> extends ThreadLocal<T> {

看来，Spring 是使用一个 ThreadLocal 来实现“绑定连接到线程”的。
现在我们可以对 ThreadLocal 下一个比较确切的定义了

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

此类提供线程局部变量。这些变量与普通对应变量的不同之处在于，访问一个变量的每个线程（通过其 get 或 set 方法）都有自己独立初始化的变量副本。ThreadLocal 实例通常是希望将状态与线程（例如，用户 ID 或事务 ID）相关联的类中的私有静态字段。

也就是说 ThreadLocal 为每个线程都提供了变量的副本，使得每个线程在某一时间访问到的并非同一个对象，这样就隔离了多个线程对数据的数据共享。

由此也可以看出 ThreadLocal 和 Synchonized 都用于解决多线程并发访问。可是 ThreadLocal 与 synchronized 有本质的差别。synchronized 是利用锁的机制，使变量或代码块在某一时该仅仅能被一个线程访问，ThreadLocal 则是副本机制。此时不论多少线程并发访问都是线程安全的。

ThreadLocal 的一大应用场景就是跨方法进行参数传递，比如 Web 容器中，每个完整的请求周期会由一个线程来处理。结合 ThreadLocal 再使用 Spring 里的IOC 和 AOP，就可以很好的解决我们上面的事务的问题。只要将一个数据库连接放入 ThreadLocal 中，当前线程执行时只要有使用数据库连接的地方就从ThreadLocal 获得就行了。

再比如，在微服务领域，链路跟踪中的 traceId 传递也是利用了 ThreadLocal。

ThreadLocal 的使用

ThreadLocal 类接口很:
1.设置当前线程的线程局部变量的值。

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

2.返回当前线程所对应的线程局部变量。

    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;
            }
        }
        return setInitialValue();
    }

3.将当前线程局部变量的值删除

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

4.返回该线程局部变量的初始值

/**
返回该线程局部变量的初始值，该方法是一个 protected 的方法，显然是为
了让子类覆盖而设计的。这个方法是一个延迟调用方法，在线程第 1 次调用 get()
或 set(Object)时才执行，并且仅执行 1 次。ThreadLocal 中的缺省实现直接返回一
个 null。
  */
    protected T initialValue() {
        return null;
    }

ThreadLocal解析

package com.xhtest.tl;

import java.util.HashMap;
import java.util.Map;

/**
 * 类说明：自己实现的ThreadLocal
 */
public class MyThreadLocal<T> {
    /*存放变量副本的map容器，以Thread为键，变量副本为value*/
    private Map<Thread,T> threadTMap = new HashMap<>();

    public synchronized T get(){
        return  threadTMap.get(Thread.currentThread());
    }

    public synchronized void set(T t){
        threadTMap.put(Thread.currentThread(),t);
    }

}

考虑到并发安全性，对数据的存取用synchronize关键字加锁，但是DougLee在《并发编程实战》中为我们做过性能测试
在这里插入图片描述
可以看到ThreadLocal的性能远超类似synchronize的锁实现ReentrantLock，比我们后面要学的AtomicInteger也要快很多，即使我们把Map的实现更换为Java中专为并发设计的ConcurrentHashMap也不太可能达到这么高的性能。

怎么样设计可以让ThreadLocal达到这么高的性能呢？最好的办法则是让变量副本跟随着线程本身，而不是将变量副本放在一个地方保存，这样就可以在存取时避开线程之间的竞争。

同时，因为每个线程所拥有的变量的副本数是不定的，有些线程可能有一个，有些线程可能有2个甚至更多，则线程内部存放变量副本需要一个容器，而且容器要支持快速存取，所以在每个线程内部都可以持有一个Map来支持多个变量副本，这个Map被称为ThreadLocalMap。

具体实现

在这里插入图片描述

上面先取到当前线程，然后调用getMap方法获取对应的ThreadLocalMap，ThreadLocalMap是一个声明在ThreadLocal的静态内部类，然后Thread类中有一个这样类型成员变量，也就是ThreadLocalMap实例化是在Thread内部，所以getMap是直接返回Thread的这个成员。

看下ThreadLocal的内部类ThreadLocalMap源码，这里其实是个标准的Map实现，内部有一个元素类型为Entry的数组，用以存放线程可能需要的多个副本变量。
在这里插入图片描述
可以看到有个Entry内部静态类，它继承了WeakReference，总之它记录了两个信息，一个是ThreadLocal<?>类型，一个是Object类型的值。getEntry方法则是获取某个ThreadLocal对应的值，set方法就是更新或赋值相应的ThreadLocal对应的值。
在这里插入图片描述
回顾我们的get方法，其实就是拿到每个线程独有的ThreadLocalMap
然后再用ThreadLocal的当前实例，拿到Map中的相应的Entry，然后就可以拿到相应的值返回出去。当然，如果Map为空，还会先进行map的创建，初始化等工作。

Hash冲突的解决

什么是Hash，就是把任意长度的输入（又叫做预映射， pre-image），通过散列算法，变换成固定长度的输出，该输出就是散列值，输入的微小变化会导致输出的巨大变化。所以Hash常用在消息摘要或签名上，常用hash消息摘要算法有：（1)MD4（2) MD5它对输入仍以512位分组，其输出是4个32位字的级联（3)SHA-1及其他。

Hash转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值。比如有10000个数放到100个桶里，不管怎么放，有个桶里数字个数一定是大于2的。

所以Hash简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。常用HASH函数：直接取余法、乘法取整法、平方取中法。 Java里的HashMap用的就是直接取余法。

我们已经知道Hash属于压缩映射，一定能会产生多个实际值映射为一个Hash值的情况，这就产生了冲突，常见处理Hash冲突方法：

开放定址法：

基本思想是，出现冲突后按照一定算法查找一个空位置存放，根据算法的不同又可以分为线性探测再散列、二次探测再散列、伪随机探测再散列。

线性探测再散列即依次向后查找，二次探测再散列，即依次向前后查找，增量为1、2、3的二次方，伪随机，顾名思义就是随机产生一个增量位移。

ThreadLocal里用的则是线性探测再散列
在这里插入图片描述

链地址法：

这种方法的基本思想是将所有哈希地址为i的元素构成一个称为同义词链的单链表，并将单链表的头指针存在哈希表的第i个单元中，因而查找、插入和删除主要在同义词链中进行。链地址法适用于经常进行插入和删除的情况。Java里的HashMap用的就是链地址法，为了避免hash 洪水攻击，1.8版本开始还引入了红黑树。

再哈希法：

这种方法是同时构造多个不同的哈希函数：Hi=RH1（key） i=1，2，…，k当哈希地址Hi=RH1（key）发生冲突时，再计算Hi=RH2（key）……，直到冲突不再产生。这种方法不易产生聚集，但增加了计算时间。

建立公共溢出区

这种方法的基本思想是：将哈希表分为基本表和溢出表两部分，凡是和基本表发生冲突的元素，一律填入溢出表。

内存泄漏分析

package com.xhtest.tl;

import cn.tulingxueyuan.tools.SleepTools;

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
 * @author 
 * 类说明：
 */
public class ThreadLocalMemoryLeak {
    private static final int TASK_LOOP_SIZE = 500;

    /*线程池*/
    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> threadLocalLV;

    public static void main(String[] args) throws InterruptedException {
        SleepTools.ms(4000);
        for (int i = 0; i < TASK_LOOP_SIZE; ++i) {
            poolExecutor.execute(new Runnable() {
                @Override
                public void run() {
                    SleepTools.ms(500);
//
//                    LocalVariable localVariable = new LocalVariable();
//
//
//                    ThreadLocalMemoryLeak oom = new ThreadLocalMemoryLeak();
//                    oom.threadLocalLV = new ThreadLocal<>();
//                    oom.threadLocalLV.set(new LocalVariable());
//
//                   oom.threadLocalLV.remove();

                    System.out.println("use local varaible");

                }
            });

            SleepTools.ms(100);
        }
        System.out.println("pool execute over");
    }

}

场景1，首先任务中不执行任何有意义的代码，当所有的任务提交执行完成后，可以看见，我们这个应用的内存占用基本上为25M左右
在这里插入图片描述
场景2，然后我们只简单的在每个任务中new出一个数组，执行完成后我们可以看见，内存占用基本和场景1同

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

执行完成后我们可以看见，内存占用变为了100多M
场景4，于是，我们加入一行代码，再执行，看看内存情况:
在这里插入图片描述
可以看见，内存占用基本和场景1同。
这就充分说明，场景3，当我们启用了ThreadLocal以后确实发生了内存泄漏。

分析

根据我们前面对ThreadLocal的分析，我们可以知道每个Thread 维护一个 ThreadLocalMap，这个映射表的 key 是 ThreadLocal实例本身，value 是真正需要存储的 Object，也就是说 ThreadLocal 本身并不存储值，它只是作为一个 key 来让线程从 ThreadLocalMap 获取 value。仔细观察ThreadLocalMap，这个map是使用 ThreadLocal 的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收。

因此使用了ThreadLocal后，引用链如图所示
在这里插入图片描述
图中的虚线表示弱引用。
这样，当把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方法。

从表面上看内存泄漏的根源在于使用了弱引用，但是另一个问题也同样值得思考：为什么使用弱引用而不是强引用？

下面我们分两种情况讨论：
1.key 使用强引用：对ThreadLocal对象实例的引用被置为null了，但是ThreadLocalMap还持有这个ThreadLocal对象实例的强引用，如果没有手动删除，ThreadLocal的对象实例不会被回收，导致Entry内存泄漏。

2.key 使用弱引用：对ThreadLocal对象实例的引用被被置为null了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal的对象实例也会被回收。value在下一次ThreadLocalMap调用set，get，remove都有机会被回收。

比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏，但是使用弱引用可以多一层保障。

因此，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key就会导致内存泄漏，而不是因为弱引用。

总结

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

错误使用ThreadLocal导致线程不安全

package com.xhtest.tl;

import cn.tulingxueyuan.tools.SleepTools;

import java.util.Random;

/**
 * @author 
 * 类说明：
 */
public class ThreadLocalUnsafe implements Runnable {

    //public static Number number = new Number(0);
    public static ThreadLocal<Number> value = new ThreadLocal<Number>(){
        @Override
        protected Number initialValue() {
            return new Number(0);
        }
    };

    @Override
    public void run() {
        Random r = new Random();
        Number number = value.get();
        //每个线程计数加随机数
        number.setNum(number.getNum()+r.nextInt(100));
      //将其存储到ThreadLocal中
        value.set(number);
        SleepTools.ms(2);
        //输出num值
        System.out.println(Thread.currentThread().getName()+"="+value.get().getNum());
    }

    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 + "]";
        }
    }

}

运行后的结果为
在这里插入图片描述
为什么每个线程都输出115？难道他们没有独自保存自己的Number副本吗？为什么其他线程还是能够修改这个值？仔细考察ThreadLocal和Thead的代码，我们发现ThreadLocalMap中保存的其实是对象的一个引用，这样的话，当有其他线程对这个引用指向的对象实例做修改时，其实也同时影响了所有的线程持有的对象引用所指向的同一个对象实例。这也就是为什么上面的程序为什么会输出一样的结果。
而上面的程序要正常的工作，应该的用法是让每个线程中的ThreadLocal都应该持有一个新的Number对象。

so1ucky

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
ThreadLocal

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

扫一扫