详解Java内存泄露的示例代码

在定位JVM性能问题时可能会遇到内存泄露导致JVM OutOfMemory的情况,在使用Tomcat容器时如果设置了reloadable=”true”这个参数,在频繁热部署应用时也有可能会遇到内存溢出的情况。Tomcat的热部署原理是检测到WEB-INF/classes或者WEB-INF/lib目录下的文件发生了变更后会把应用先停止然后再启动,由于Tomcat默认给每个应用分配一个WebAppClassLoader,热替换的原理就是创建一个新的ClassLoader来加载类,由于JVM中一个类的唯一性由它的class文件和它的类加载器来决定,因此重新加载类可以达到热替换的目的。当热部署的次数比较多会导致JVM加载的类比较多,如果之前的类由于某种原因(比如内存泄露)没有及时卸载就可能导致永久代或者MetaSpace的OutOfMemory。这篇文章通过一个Demo来简要介绍下ThreadLocal和ClassLoader导致内存泄露最终OutOfMemory的场景。

类的卸载

在类使用完之后,满足下面的情形,会被卸载:

1.该类在堆中的所有实例都已被回收,即在堆中不存在该类的实例对象。

2.加载该类的classLoader已经被回收。

3.该类对应的Class对象没有任何地方可以被引用,通过反射访问不到该Class对象。

如果类满足卸载条件,JVM就在GC的时候,对类进行卸载,即在方法区清除类的信息。

场景介绍

上一篇文章我介绍了ThreadLocal的原理,每个线程有个ThreadLocalMap,如果线程的生命周期比较长可能会导致ThreadLocalMap里的Entry没法被回收,那ThreadLocal的那个对象就一直被线程持有强引用,由于实例对象会持有Class对象的引用,Class对象又会持有加载它的ClassLoader的引用,这样就会导致Class无法被卸载了,当加载的类足够多时就可能出现永久代或者MetaSpace的内存溢出,如果该类有大对象,比如有比较大的字节数组,会导致Java堆区的内存溢出。

源码介绍

这里定义了一个内部类Inner,Inner类有个静态的ThreadLocal对象,主要用于让线程持有Inner类的强引用导致Inner类无法被回收,定义了一个自定义的类加载器去加载Inner类,如下所示:

public class MemoryLeak {
  public static void main(String[] args) {
 //由于线程一直在运行,因此ThreadLocalMap里的Inner对象一直被Thread对象强引用
    new Thread(new Runnable() {
      @Override
      public void run() {
        while (true) {
   //每次都新建一个ClassLoader实例去加载Inner类
          CustomClassLoader classLoader = new CustomClassLoader
              ("load1", MemoryLeak.class.getClassLoader(), "com.ezlippi.MemoryLeak$Inner", "com.ezlippi.MemoryLeak$Inner$1");
          try {
            Class<?> innerClass = classLoader.loadClass("com.ezlippi.MemoryLeak$Inner");
            innerClass.newInstance();
   //帮助GC进行引用处理
            innerClass = null;
            classLoader = null;
            Thread.sleep(10);
          } catch (ClassNotFoundException | IllegalAccessException | InstantiationException | InterruptedException e) {
            e.printStackTrace();
          }
        }
      }
    }).start();
  }
 //为了更快达到堆区
  public static class Inner {
    private byte[] MB = new byte[1024 * 1024];
    static ThreadLocal<Inner> threadLocal = new ThreadLocal<Inner>() {
      @Override
      protected Inner initialValue() {
        return new Inner();
      }
    };
 //调用ThreadLocal.get()才会调用initialValue()初始化一个Inner对象
    static {
      threadLocal.get();
    }
    public Inner() {
    }
  }
 //源码省略
  private static class CustomClassLoader extends ClassLoader {}

堆区内存溢出

为了触发堆区内存溢出,我在Inner类里面设置了一个1MB的字节数组,同时要在静态块中调用threadLocal.get(),只有调用才会触发initialValue()来初始化一个Inner对象,不然只是创建了一个空的ThreadLocal对象,ThreadLocalMap里并没有数据。

JVM参数如下:

-Xms100m -Xmx100m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintClassHistogram -XX:+HeapDumpOnOutOfMemoryError

最后执行了814次后JVM堆区内存溢出了,如下所示:

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid11824.hprof ...
Heap dump file created [100661202 bytes in 1.501 secs]
Heap
 par new generation  total 30720K, used 30389K [0x00000000f9c00000, 0x00000000fbd50000, 0x00000000fbd50000)
 eden space 27328K, 99% used [0x00000000f9c00000, 0x00000000fb6ad450, 0x00000000fb6b0000)
 from space 3392K, 90% used [0x00000000fb6b0000, 0x00000000fb9b0030, 0x00000000fba00000)
 to  space 3392K,  0% used [0x00000000fba00000, 0x00000000fba00000, 0x00000000fbd50000)
 concurrent mark-sweep generation total 68288K, used 67600K [0x00000000fbd50000, 0x0000000100000000, 0x0000000100000000)
 Metaspace    used 3770K, capacity 5134K, committed 5248K, reserved 1056768K
 class space  used 474K, capacity 578K, committed 640K, reserved 1048576K
Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space
 at com.ezlippi.MemoryLeak$Inner.<clinit>(MemoryLeak.java:34)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
 at java.lang.reflect.Constructor.newInstance(Unknown Source)
 at java.lang.Class.newInstance(Unknown Source)
 at com.ezlippi.MemoryLeak$1.run(MemoryLeak.java:20)
 at java.lang.Thread.run(Unknown Source)

可以看到JVM已经没有内存来创建新的Inner对象,因为堆区存放了很多个1MB的字节数组,这里我把类的直方图打印出来了(下图是堆大小为1024M的场景),省略了一些无关紧要的类,可以看出字节数组占了855M的空间,创建了814个 com.ezlippi.MemoryLeak$CustomClassLoader 的实例,和字节数组的大小基本吻合:

 num   #instances     #bytes class name
----------------------------------------------
  1:     6203   855158648 [B
  2:     13527    1487984 [C
  3:      298     700560 [I
  4:     2247     228792 java.lang.Class
  5:     8232     197568 java.lang.String
  6:     3095     150024 [Ljava.lang.Object;
  7:     1649     134480 [Ljava.util.HashMap$Node;
 11:      813     65040 com.ezlippi.MemoryLeak$CustomClassLoader
 12:      820     53088 [Ljava.util.Hashtable$Entry;
 15:      817     39216 java.util.Hashtable
 16:      915     36600 java.lang.ref.SoftReference
 17:      543     34752 java.net.URL
 18:      697     33456 java.nio.HeapCharBuffer
 19:      817     32680 java.security.ProtectionDomain
 20:      785     31400 java.util.TreeMap$Entry
 21:      928     29696 java.util.Hashtable$Entry
 22:     1802     28832 java.util.HashSet
 23:      817     26144 java.security.CodeSource
 24:      814     26048 java.lang.ThreadLocal$ThreadLocalMap$Entry

Metaspace溢出

为了让Metaspace溢出,那就必须把MetaSpace的空间调小一点,要在堆溢出之前加载足够多的类,因此我调整了下JVM参数,并且把字节数组的大小调成了1KB,如下所示:

private byte[] KB = new byte[1024];
-Xms100m -Xmx100m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintClassHistogram -XX:MetaspaceSize=2m -XX:MaxMetaspaceSize=2m

从 GC日志可以看出在Meraspace达到GC阈值(也就是MaxMetaspaceSize配置的大小时)会触发一次FullGC:

java.lang.OutOfMemoryError: Metaspace
 <<no stack trace available>>
{Heap before GC invocations=20 (full 20):
 par new generation  total 30720K, used 0K [0x00000000f9c00000, 0x00000000fbd50000, 0x00000000fbd50000)
 eden space 27328K,  0% used [0x00000000f9c00000, 0x00000000f9c00000, 0x00000000fb6b0000)
 from space 3392K,  0% used [0x00000000fb6b0000, 0x00000000fb6b0000, 0x00000000fba00000)
 to  space 3392K,  0% used [0x00000000fba00000, 0x00000000fba00000, 0x00000000fbd50000)
 concurrent mark-sweep generation total 68288K, used 432K [0x00000000fbd50000, 0x0000000100000000, 0x0000000100000000)
 Metaspace    used 1806K, capacity 1988K, committed 2048K, reserved 1056768K
 class space  used 202K, capacity 384K, committed 384K, reserved 1048576K
[Full GC (Metadata GC Threshold) [CMS
Process finished with exit code 1

通过上面例子可以看出如果类加载器和ThreadLocal使用的不当确实会导致内存泄露的问题,完整的源码在github

(0)

相关推荐

  • Java中典型的内存泄露问题和解决方法

    Q:在Java中怎么可以产生内存泄露?A:Java中,造成内存泄露的原因有很多种.典型的例子是一个没有实现hasCode和equals方法的Key类在HashMap中保存的情况.最后会生成很多重复的对象.所有的内存泄露最后都会抛出OutOfMemoryError异常,下面通过一段简短的通过无限循环模拟内存泄露的例子说明一下. 复制代码 代码如下: import java.util.HashMap;import java.util.Map; public class MemoryLeak { pu

  • Java内存溢出和内存泄露

    虽然jvm可以通过GC自动回收无用的内存,但是代码不好的话仍然存在内存溢出的风险. 一.为什么要了解内存泄露和内存溢出? 1.内存泄露一般是代码设计存在缺陷导致的,通过了解内存泄露的场景,可以避免不必要的内存溢出和提高自己的代码编写水平: 2.通过了解内存溢出的几种常见情况,可以在出现内存溢出的时候快速的定位问题的位置,缩短解决故障的时间.  二.基本概念  理解这两个概念非常重要. 内存泄露:指程序中动态分配内存给一些临时对象,但是对象不会被GC所回收,它始终占用内存.即被分配的对象可达但已无

  • Java语言中的内存泄露代码详解

    Java的一个重要特性就是通过垃圾收集器(GC)自动管理内存的回收,而不需要程序员自己来释放内存.理论上Java中所有不会再被利用的对象所占用的内存,都可以被GC回收,但是Java也存在内存泄露,但它的表现与C++不同. JAVA中的内存管理 要了解Java中的内存泄露,首先就得知道Java中的内存是如何管理的. 在Java程序中,我们通常使用new为对象分配内存,而这些内存空间都在堆(Heap)上. 下面看一个示例: public class Simple { public static vo

  • 理解Java中的内存泄露及解决方法示例

    本文详细地介绍了Java内存管理的原理,以及内存泄露产生的原因,同时提供了一些列解决Java内存泄露的方案,希望对各位Java开发者有所帮助. Java内存管理机制 在C++ 语言中,如果需要动态分配一块内存,程序员需要负责这块内存的整个生命周期.从申请分配.到使用.再到最后的释放.这样的过程非常灵活,但是却十分繁琐,程序员很容易由于疏忽而忘记释放内存,从而导致内存的泄露. Java 语言对内存管理做了自己的优化,这就是垃圾回收机制. Java 的几乎所有内存对象都是在堆内存上分配(基本数据类型

  • 详细介绍Java内存泄露原因

    一.Java内存回收机制 不论哪种语言的内存分配方式,都需要返回所分配内存的真实地址,也就是返回一个指针到内存块的首地址.Java中对象是采用new或者反射的方法创建的,这些对象的创建都是在堆(Heap)中分配的,所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的.GC为了能够正确释放对象,会监控每个对象的运行状况,对他们的申请.引用.被引用.赋值等状况进行监控,Java会使用有向图的方法进行管理内存,实时监控对象是否可以达到,如果不可到达,则就将其回收,这样也可以消除引用循环的问题.在J

  • 实例详解Java中ThreadLocal内存泄露

    案例与分析 问题背景 在 Tomcat 中,下面的代码都在 webapp 内,会导致WebappClassLoader泄漏,无法被回收. public class MyCounter { private int count = 0; public void increment() { count++; } public int getCount() { return count; } } public class MyThreadLocal extends ThreadLocal<MyCount

  • 浅谈Java编程中的内存泄露情况

    必须先要了解的 1.c/c++是程序员自己管理内存,Java内存是由GC自动回收的. 我虽然不是很熟悉C++,不过这个应该没有犯常识性错误吧. 2.什么是内存泄露? 内存泄露是指系统中存在无法回收的内存,有时候会造成内存不足或系统崩溃. 在C/C++中分配了内存不释放的情况就是内存泄露. 3.Java存在内存泄露 我们必须先承认这个,才可以接着讨论.虽然Java存在内存泄露,但是基本上不用很关心它,特别是那些对代码本身就不讲究的就更不要去关心这个了. Java中的内存泄露当然是指:存在无用但是垃

  • 详解Java内存泄露的示例代码

    在定位JVM性能问题时可能会遇到内存泄露导致JVM OutOfMemory的情况,在使用Tomcat容器时如果设置了reloadable="true"这个参数,在频繁热部署应用时也有可能会遇到内存溢出的情况.Tomcat的热部署原理是检测到WEB-INF/classes或者WEB-INF/lib目录下的文件发生了变更后会把应用先停止然后再启动,由于Tomcat默认给每个应用分配一个WebAppClassLoader,热替换的原理就是创建一个新的ClassLoader来加载类,由于JVM

  • 详解Java内存溢出的几种情况

    JVM(Java虚拟机)是一个抽象的计算模型.就如同一台真实的机器,它有自己的指令集和执行引擎,可以在运行时操控内存区域.目的是为构建在其上运行的应用程序提供一个运行环境.JVM可以解读指令代码并与底层进行交互:包括操作系统平台和执行指令并管理资源的硬件体系结构. 1. 前言 JVM提供的内存管理机制和自动垃圾回收极大的解放了用户对于内存的管理,大部分情况下不会出现内存泄漏和内存溢出问题.但是基本不会出现并不等于不会出现,所以掌握Java内存模型原理和学会分析出现的内存溢出或内存泄漏,对于使用J

  • 详解JAVA 内存管理

    前一段时间粗略看了一下<深入Java虚拟机 第二版>,可能是因为工作才一年的原因吧,看着十分的吃力.毕竟如果具体到细节的话,Java虚拟机涉及的内容太多了.可能再过一两年去看会合适一些吧. 不过看了一遍<深入Java虚拟机>再来理解Java内存管理会好很多.接下来一起学习下Java内存管理吧. 请注意上图的这个: 我们再来复习下进程与线程吧: 进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位. 线程是进程的一个实体,是CPU调

  • 详解Android内存泄露及优化方案一

    目录 一.常见的内存泄露应用场景? 1.单例的不恰当使用 2.静态变量导致内存泄露 3.非静态内部类导致内存泄露 4.未取消注册或回调导致内存泄露 5.定时器Timer 和 TimerTask 导致内存泄露 6.集合中的对象未清理造成内存泄露 7.资源未关闭或释放导致内存泄露 8.动画造成内存泄露 9.WebView 造成内存泄露 总结 一.常见的内存泄露应用场景? 1.单例的不恰当使用 单例是我们开发中最常见和使用最频繁的设计模式之一,所以如果使用不当就会导致内存泄露.因为单例的静态特性使得它

  • 详解Android内存泄露及优化方案

    目录 一.常见的内存泄露应用场景? 1.单例的不恰当使用 2.静态变量导致内存泄露 3.非静态内部类导致内存泄露 4.未取消注册或回调导致内存泄露 5.定时器Timer 和 TimerTask 导致内存泄露 6.集合中的对象未清理造成内存泄露 7.资源未关闭或释放导致内存泄露 8.动画造成内存泄露 9.WebView 造成内存泄露 总结 一.常见的内存泄露应用场景? 1.单例的不恰当使用 单例是我们开发中最常见和使用最频繁的设计模式之一,所以如果使用不当就会导致内存泄露.因为单例的静态特性使得它

  • 详解java中的四种代码块

    在java中用{}括起来的称为代码块,代码块可分为以下四种: 一.简介 1.普通代码块: 类中方法的方法体 2.构造代码块: 构造块会在创建对象时被调用,每次创建时都会被调用,优先于类构造函数执行. 3.静态代码块: 用static{}包裹起来的代码片段,只会执行一次.静态代码块优先于构造块执行. 4.同步代码块: 使用synchronized(){}包裹起来的代码块,在多线程环境下,对共享数据的读写操作是需要互斥进行的,否则会导致数据的不一致性.同步代码块需要写在方法中. 二.静态代码块和构造

  • 详解java基于MyBatis使用示例

    MyBatis的前身叫iBatis,本是apache的一个开源项目, 2010年这个项目由apache software foundation 迁移到了google code,并且改名为MyBatis.MyBatis是支持普通SQL查询,存储过程和高级映射的优秀持久层框架.MyBatis消除了几乎所有的JDBC代码和参数的手工设置以及结果集的检索.MyBatis使用简单的XML或注解用于配置和原始映射,将接口和Java的POJOs(Plan Old Java Objects,普通的Java对象)

  • 图文详解java内存回收机制

    在Java中,它的内存管理包括两方面:内存分配(创建Java对象的时候)和内存回收,这两方面工作都是由JVM自动完成的,降低了Java程序员的学习难度,避免了像C/C++直接操作内存的危险.但是,也正因为内存管理完全由JVM负责,所以也使Java很多程序员不再关心内存分配,导致很多程序低效,耗内存.因此就有了Java程序员到最后应该去了解JVM,才能写出更高效,充分利用有限的内存的程序. 1.Java在内存中的状态  首先我们先写一个代码为例子: Person.java package test

  • 详解Java内存管理中的JVM垃圾回收

    一.概述 相比起C和C++的自己回收内存,JAVA要方便得多,因为JVM会为我们自动分配内存以及回收内存. 在之前的JVM 之内存管理 中,我们介绍了JVM内存管理的几个区域,其中程序计数器以及虚拟机栈是线程私有的,随线程而灭,故而它是不用考虑垃圾回收的,因为线程结束其内存空间即释放. 而JAVA堆和方法区则不一样,JAVA堆和方法区时存放的是对象的实例信息以及对象的其他信息,这部分是垃圾回收的主要地点. 二.JAVA堆垃圾回收 垃圾回收主要考虑的问题有两个:一个是效率问题,一个是空间碎片问题.

  • 详解Android内存优化策略

    目录 前言 一.内存优化策略 二.具体优化的点 1.避免内存泄漏 2.Bitmap等大对象的优化策略 (1) 优化Bitmap分辨率 (2) 优化单个像素点内存 (3) Bitmap的缓存策略 (4) drawable资源选择合适的drawable文件夹存放 (5) 其他大对象的优化 (6) 避免内存抖动 3.原生API回调释放内存 4.内存排查工具 (1)LeakCanary监测内存泄漏 (2)通过Proflier监控内存 (3)通过MAT工具排查内存泄漏 总结 前言 在开始之前需要先搞明白一

随机推荐