java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > Java ThreadLocal内存泄漏

浅谈Java中ThreadLocal引发的内存泄漏

作者：Mr Tang

本文主要介绍了浅谈Java中ThreadLocal引发的内存泄漏，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧

预备知识（引用）

Object o = new Object();

这个o，我们可以称之为对象引用，而new Object()我们可以称之为在内存中产生了一个对象实例。

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

内存泄漏的现象

/**
 * 类说明：ThreadLocal造成的内存泄漏演示
 */
public class ThreadLocalOOM {
    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大小的数组*/
    }
    final static ThreadLocal<LocalVariable> localVariable
            = new ThreadLocal<>();
    public static void main(String[] args) throws InterruptedException {
        Object o = new Object();
        /*5*5=25*/
        for (int i = 0; i < TASK_LOOP_SIZE; ++i) {
            poolExecutor.execute(new Runnable() {
                public void run() {
                    //localVariable.set(new LocalVariable());
                    new LocalVariable();
                    System.out.println("use local varaible");
                    //localVariable.remove();
                }
            });
            Thread.sleep(100);
        }
        System.out.println("pool execute over");
    }
}

首先只简单的在每个任务中new出一个数组

 可以看到内存的实际使用控制在25M左右：因为每个任务中会不断new出一个5M的数组，5*5=25M，这是很合理的。

当我们启用了ThreadLocal以后

内存占用最高升至150M，一般情况下稳定在90M左右，那么加入一个ThreadLocal后，内存的占用真的会这么多？

于是，我们加入一行代码：

 再执行，看看内存情况:

可以看见最高峰的内存占用也在25M左右，完全和我们不加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()方法，清除数据。

​ 其实考察ThreadLocal的实现，我们可以看见，无论是get()、set()在某些时候，调用了expungeStaleEntry方法用来清除Entry中Key为null的Value，但是这是不及时的，也不是每次都会执行的，所以一些情况下还是会发生内存泄露。只有remove()方法中显式调用了expungeStaleEntry方法。

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

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

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

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

为什么ThreadLocalMap的key要设置为弱引用？

在 ThreadLocalMap 中的set和get方法中，会对 key为null进行判断，如果key为null会把value也置为null。
这样就算忘记调用remove方法，对应的value在下次调用get、set、remove方法中的任意一个都会被清除，从而避免内存泄漏（相当于多了一层保障，但是如果后续一直不调用这些方法，依然存在内存泄漏的风险，所以最好是及时remove）。

总结

​ JVM利用设置ThreadLocalMap的Key为弱引用，来避免内存泄露。

JVM利用调用remove、get、set方法的时候，回收弱引用。

当ThreadLocal存储很多Key为null的Entry的时候，而不再去调用remove、get、set方法，那么将导致内存泄漏。

使用线程池+ ThreadLocal 时要小心，因为这种情况下，线程是一直在不断的重复运行的，从而也就造成了value可能造成累积的情况。

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

/**
 * 非安全的ThreadLocal 演示
 */
public class ThreadLocalUnsafe implements Runnable {
    public static ThreadLocal<Number> numberThreadLocal = new ThreadLocal<Number>();
    /**
     * 使用threadLocal的静态变量
     */
    public static Number number = new Number(0);
    public void run() {
        //每个线程计数加一
        number.setNum(number.getNum() + 1);
        //将其存储到ThreadLocal中
        numberThreadLocal.set(number);
        //延时2ms
        try {
            Thread.sleep(10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        //输出num值
        System.out.println("内存地址："+numberThreadLocal.get() + "，" + Thread.currentThread().getName() + "=" + numberThreadLocal.get().getNum());
    }
    public static void main(String[] args) {
        for (int i = 0; i < 5; i++) {
            new Thread(new ThreadLocalUnsafe()).start();
        }
    }
    /**
     * 一个私有的类 Number
     */
    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;
        }
    }
}

 输出：

内存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-2=5
内存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-0=5
内存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-4=5
内存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-1=5
内存地址：com.test.thread.ThreadLocalUnsafe$Number@5658172e，Thread-3=5

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

而上面的程序要正常的工作，应该去掉number的static 修饰，让每个ThreadLoalMap中使用不同的number对象进行操作。

总结：ThreadLocal只保证线程隔离，不保证线程安全。

到此这篇关于浅谈Java中ThreadLocal引发的内存泄漏的文章就介绍到这了,更多相关Java ThreadLocal内存泄漏内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文