个人中心
gpt4 book ai didi

实例详解Java中ThreadLocal内存泄露

转载 作者：qq735679552 更新时间：2022-09-29 22:32:09 24 4
gpt4 key购买 nike

CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章实例详解Java中ThreadLocal内存泄露由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

案例与分析 。

问题背景 。

在 Tomcat 中，下面的代码都在 webapp 内，会导致WebappClassLoader泄漏，无法被回收.

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class MyCounter {
     private int count = 0 ;
 
     public void increment() {
         count++;
     }
 
     public int getCount() {
         return count;
     }
}
 
public class MyThreadLocal extends ThreadLocal<MyCounter> {
}
 
public class LeakingServlet extends HttpServlet {
     private static MyThreadLocal myThreadLocal = new MyThreadLocal();
 
     protected void doGet(HttpServletRequest request,
             HttpServletResponse response) throws ServletException, IOException {
 
         MyCounter counter = myThreadLocal.get();
         if (counter == null ) {
             counter = new MyCounter();
             myThreadLocal.set(counter);
         }
 
         response.getWriter().println(
                 "The current thread served this servlet " + counter.getCount()
                         + " times" );
         counter.increment();
     }
}

上面的代码中，只要LeakingServlet被调用过一次，且执行它的线程没有停止，就会导致WebappClassLoader泄漏。每次你 reload 一下应用，就会多一份WebappClassLoader实例，最后导致 PermGen OutOfMemoryException.

解决问题 。

现在我们来思考一下：为什么上面的ThreadLocal子类会导致内存泄漏?

WebappClassLoader 。

首先，我们要搞清楚WebappClassLoader是什么鬼?

对于运行在 Java EE容器中的 Web 应用来说，类加载器的实现方式与一般的 Java 应用有所不同。不同的 Web 容器的实现方式也会有所不同。以 Apache Tomcat 来说，每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全.

也就是说WebappClassLoader是 Tomcat 加载 webapp 的自定义类加载器，每个 webapp 的类加载器都是不一样的，这是为了隔离不同应用加载的类.

那么WebappClassLoader的特性跟内存泄漏有什么关系呢？目前还看不出来，但是它的一个很重要的特点值得我们注意：每个 webapp 都会自己的WebappClassLoader，这跟 Java 核心的类加载器不一样.

我们知道：导致WebappClassLoader泄漏必然是因为它被别的对象强引用了，那么我们可以尝试画出它们的引用关系图。等等！类加载器的作用到底是啥？为什么会被强引用?

类的生命周期与类加载器 。

要解决上面的问题，我们得去研究一下类的生命周期和类加载器的关系.

跟我们这个案例相关的主要是类的卸载:

在类使用完之后，如果满足下面的情况，类就会被卸载:

      1、该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例.

      2、加载该类的ClassLoader已经被回收.

      3、该类对应的java.lang.Class对象没有任何地方被引用，没有在任何地方通过反射访问该类的方法.

如果以上三个条件全部满足，JVM 就会在方法区垃圾回收的时候对类进行卸载，类的卸载过程其实就是在方法区中清空类信息，Java 类的整个生命周期就结束了.

由Java虚拟机自带的类加载器所加载的类，在虚拟机的生命周期中，始终不会被卸载。Java虚拟机自带的类加载器包括根类加载器、扩展类加载器和系统类加载器。Java虚拟机本身会始终引用这些类加载器，而这些类加载器则会始终引用它们所加载的类的Class对象，因此这些Class对象始终是可触及的.

由用户自定义的类加载器加载的类是可以被卸载的.

注意上面这句话，WebappClassLoader如果泄漏了，意味着它加载的类都无法被卸载，这就解释了为什么上面的代码会导致 PermGen OutOfMemoryException.

关键点看下面这幅图 。

实例详解Java中ThreadLocal内存泄露

我们可以发现：类加载器对象跟它加载的 Class 对象是双向关联的。这意味着，Class 对象可能就是强引用WebappClassLoader，导致它泄漏的元凶.

引用关系图 。

理解类加载器与类的生命周期的关系之后，我们可以开始画引用关系图了。（图中的LeakingServlet.class与myThreadLocal引用画的不严谨，主要是想表达myThreadLocal是类变量的意思） 。

实例详解Java中ThreadLocal内存泄露

下面，我们根据上面的图来分析WebappClassLoader泄漏的原因.

      1、LeakingServlet持有static的MyThreadLocal，导致myThreadLocal的生命周期跟LeakingServlet类的生命周期一样长。意味着myThreadLocal不会被回收，弱引用形同虚设，所以当前线程无法通过ThreadLocalMap的防护措施清除counter的强引用.

      2、强引用链：thread -> threadLocalMap -> counter -> MyCounter.class -> WebappClassLocader，导致WebappClassLoader泄漏.

总结 。

内存泄漏是很难发现的问题，往往由于多方面原因造成。ThreadLocal由于它与线程绑定的生命周期成为了内存泄漏的常客，稍有不慎就酿成大祸。本文只是对一个特定案例的分析，若能以此举一反三，那便是极好的。希望本文对大家能有所帮助.

最后此篇关于实例详解Java中ThreadLocal内存泄露的文章就讲到这里了,如果你想了解更多关于实例详解Java中ThreadLocal内存泄露的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。

24 4 0
文章推荐： 快手女生社会头像黑白伤感 青春如此珍贵应当好好浪费
文章推荐： 浅谈java实现背包算法(0-1背包问题)
文章推荐： 快手头像女生背影伤感一点的 我理智也很冷漠连话都不想说
文章推荐： JAXB命名空间及前缀_动力节点Java学院整理
qq735679552
个人简介

我是一名优秀的程序员,十分优秀！

滴滴打车优惠券免费领取
滴滴打车优惠券
全站热门文章
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com