ThreadLocal和内存泄漏

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ThreadLocal和内存泄漏相关的知识,希望对你有一定的参考价值。

在多个帖子中提到:ThreadLocal的不当使用会导致内存泄漏。我正在努力了解如何使用ThreadLocal进行内存泄漏。

我发现它的唯一情况如下:

Web服务器维护一个Threads池(例如,用于servlet)。如果没有删除ThreadLocal中的变量,那些线程可能会造成内存泄漏,因为线程没有死亡。

这种情况没有提到“Perm Space”内存泄漏。这是内存泄漏的唯一(主要)用例吗?

答案

ThreadLocal组合的PermGen穷举通常是由类加载器泄漏引起的。 一个例子: 想象一下具有工作线程池的应用服务器。 它们将保持活动直到应用程序服务器终止。 部署的Web应用程序在其中一个类中使用静态ThreadLocal,以便存储一些线程本地数据,即Web应用程序的另一个类的实例(让我们称之为SomeClass)。这是在工作线程内完成的(例如,此操作源自HTTP请求)。 重要: By definition,保持对ThreadLocal值的引用,直到“拥有”线程死亡或者ThreadLocal本身不再可达。 如果Web应用程序在关闭时无法清除对ThreadLocal的引用,则会发生错误: 因为工作线程通常永远不会消失并且对ThreadLocal的引用是静态的,所以ThreadLocal值仍然引用了SomeClass的实例,这是一个Web应用程序的类 - 即使Web应用程序已被停止! 因此,Web应用程序的类加载器无法进行垃圾回收,这意味着Web应用程序的所有类(以及所有静态数据)都会保持加载状态(这会影响PermGen内存池以及堆)。 Web应用程序的每次重新部署迭代都会增加permgen(和堆)的使用。 =>这是permgen泄漏 这种泄漏的一个流行的例子是log4j中的this bug(同时修复)。

另一答案

这个问题的公认答案以及Tomcat关于这个问题的“严重”日志都是误导性的。关键的话是:

根据定义,保持对ThreadLocal值的引用,直到“拥有”线程死亡或者ThreadLocal本身不再可访问为止。 [我的重点]。

在这种情况下,对ThreadLocal的唯一引用位于类的静态final字段中,该类现在已成为GC的目标,以及来自工作线程的引用。但是,从工作线程到ThreadLocal的引用是WeakReferences

但是,ThreadLocal的值不是弱引用。因此,如果您在ThreadLocal的值中引用了应用程序类,那么这些将保留对ClassLoader的引用并阻止GC。但是,如果你的ThreadLocal值只是整数或字符串或其他一些基本对象类型(例如,上面的标准集合),那么应该没有问题(它们只会阻止引导/系统类加载器的GC,这是永远不会发生)。

完成后明确清理ThreadLocal仍然是一个好习惯,但是在the cited log4j bug的情况下,天空肯定没有下降(从报告中可以看出,值是一个空的Hashtable)。

这是一些要演示的代码。首先,我们创建一个基本的自定义类加载器实现,没有父项在完成时打印到System.out:

import java.net.*;

public class CustomClassLoader extends URLClassLoader {

    public CustomClassLoader(URL... urls) {
        super(urls, null);
    }

    @Override
    protected void finalize() {
        System.out.println("*** CustomClassLoader finalized!");
    }
}

然后我们定义一个驱动程序应用程序,它创建这个类加载器的新实例,使用它来加载一个带有ThreadLocal的类,然后删除对类加载器的引用,允许它进行GC。首先,在ThreadLocal值是对自定义类加载器加载的类的引用的情况下:

import java.net.*;

public class Main {

    public static void main(String...args) throws Exception {
        loadFoo();
        while (true) { 
            System.gc();
            Thread.sleep(1000);
        }
    }

    private static void loadFoo() throws Exception {
        CustomClassLoader cl = new CustomClassLoader(new URL("file:/tmp/"));
        Class<?> clazz = cl.loadClass("Main$Foo");
        clazz.newInstance();
        cl = null;
    }


    public static class Foo {
        private static final ThreadLocal<Foo> tl = new ThreadLocal<Foo>();

        public Foo() {
            tl.set(this);
            System.out.println("ClassLoader: " + this.getClass().getClassLoader());
        }
    }
}

当我们运行它时,我们可以看到CustomClassLoader确实没有被垃圾收集(因为主线程中的本地线程具有对我们的自定义类加载器加载的Foo实例的引用):

$ java Main
ClassLoader: CustomClassLoader@7a6d084b

但是,当我们更改ThreadLocal而不是包含对简单Integer而不是Foo实例的引用时:

public static class Foo {
    private static final ThreadLocal<Integer> tl = new ThreadLocal<Integer>();

    public Foo() {
        tl.set(42);
        System.out.println("ClassLoader: " + this.getClass().getClassLoader());
    }
}

然后我们看到自定义类加载器现在被垃圾收集(因为主线程上的本地线程只引用了系统类加载器加载的整数):

$ java Main
ClassLoader: CustomClassLoader@e76cbf7
*** CustomClassLoader finalized!

(Hashtable也是如此)。所以在log4j的情况下,他们没有内存泄漏或任何类型的错误。他们已经清除了Hashtable,这足以确保类加载器的GC。 IMO,这个bug出现在Tomcat中,它会在关闭所有未明确的.stove()d的ThreadLocals时不加选择地记录这些“SEVERE”错误,无论它们是否拥有对应用程序类的强引用。似乎至少有一些开发人员正在投入时间和精力来“修复”幻想内存泄漏事件。

另一答案

线程本地没有任何内在错误:它们不会导致内存泄漏。他们并不慢。它们比非线程本地对应物更本地化(即,它们具有更好的信息隐藏属性)。当然,它们可能被滥用,但大多数其他编程工具也是如此......

请参阅Joshua Bloch撰写的link

另一答案

以前的帖子解释了问题,但没有提供任何解决方案。我发现没有办法“清除”ThreadLocal。在我处理请求的容器环境中,我最终在每个请求结束时调用了.remove()。我意识到使用容器管理的事务可能会有问题。

另一答案

在代码下面,for迭代中的实例t不能是GC。这可能是ThreadLocal & Memory Leak的一个例子

public class MemoryLeak {

    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < 100000; i++) {
                    TestClass t = new TestClass(i);
                    t.printId();
                    t = null;
                }
            }
        }).start();
    }


    static class TestClass{
        private int id;
        private int[] arr;
        private ThreadLocal<TestClass> threadLocal;
        TestClass(int id){
            this.id = id;
            arr = new int[1000000];
            threadLocal = new ThreadLocal<>();
            threadLocal.set(this);
        }

        public void printId(){
            System.out.println(threadLocal.get().id);
        }
    }
}
另一答案

这是ThreadLocal的替代方案,它没有内存泄漏问题:

class BetterThreadLocal<A> {
  Map<Thread, A> map = Collections.synchronizedMap(new WeakHashMap());

  A get() {
    ret map.get(Thread.currentThread());
  }

  void set(A a) {
    if (a == null)
      map.remove(Thread.currentThread());
    else
      map.put(Thread.currentThread(), a);
  }
}

注意:存在新的内存泄漏情况,但这种情况极不可能,可以通过遵循简单的指导原则来避免。该场景是对BetterThreadLocal中的Thread对象的强引用。

我永远不会保持对线程的强引用,因为你总是希望在它的工作完成时允许线程进行GC ...所以你去:一个无内存漏洞的ThreadLocal。

有人应该对此进行基准测试我希望它与Java的ThreadLocal一样快(两者都基本上做了一个弱的哈希映射查找,只有一个查找线程,另一个查找ThreadLocal)。

Sample program in JavaX.

最后一点:我的系统(JavaX)也跟踪所有WeakHashMaps并定期清理它们,因此最后一个不太可能的漏洞被插入(长期存在的WeakHashMaps,从未被查询,但仍然有陈旧的条目)。

另一答案

当ThreadLocal始终存在时,会导致内存泄漏。如果ThreadLocal对象可能是GC,则不会导致内存泄漏。因为ThreadLocalMap中的条目扩展了WeakReference,所以在ThreadLocal对象为GC之后,该条目将是GC。

下面的代码创建了很多ThreadLocal,它永远不会发生内存泄漏,而main的主线始终是活的。

// -XX:+PrintGCDetails -Xms100m -Xmx100m 
public class Test {

    public static long total = 1000000000;
    public static void main(String[] args) {
        for(long i = 0; i < total; i++) {
            // give GC some time
            if(i % 10000 == 0) {
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
            ThreadLocal<Element> tl = new ThreadLocal<>();
            tl.set(new Element(i));
        }
    }
}

class Element {
    private long v;
    public Element(long v) {
        this.v = v;
    }
    public void finalize() {
        System.out.println(v);
    }
}

以上是关于ThreadLocal和内存泄漏的主要内容,如果未能解决你的问题,请参考以下文章

ThreadLocal源码分析理解弱引用和内存泄漏

ThreadLocal 和内存泄漏

ThreadLocal和内存泄漏

ThreadLocal源码分析理解弱引用和内存泄漏

javaThreadLocal 内存泄漏 代码演示 实例演示

漫聊 ThreadLocal (内存泄漏,弱引用)