调查一次内存泄漏

调查分析现场的一次内存泄漏

首先先了解jvm 内存模型划分

《深入理解Java虚拟机（第2版）》中的描述是下面这个样子的：

JVM的内存结构大概分为：

  • 堆（Heap）：线程共享。所有的对象实例以及数组都要在堆上分配。回收器主要管理的对象。
  • 方法区（Method Area）：线程共享。存储类信息、常量、静态变量、即时编译器编译后的代码。
  • 方法栈（JVM Stack）：线程私有。存储局部变量表、操作栈、动态链接、方法出口，对象指针。
  • 本地方法栈（Native Method Stack）：线程私有。为虚拟机使用到的Native 方法服务。如Java使用c或者c++编写的接口服务时，代码在此区运行。
  • 程序计数器（Program Counter Register）：线程私有。有些文章也翻译成PC寄存器（PC Register），同一个东西。它可以看作是当前线程所执行的字节码的行号指示器。指向下一条要执行的指令。

 

先看一张图，这张图能很清晰的说明JVM内存结构的布局和相应的控制参数：

（图片来源于网络）

堆

堆的作用是存放对象实例和数组。从结构上来分，可以分为新生代和老年代。而新生代又可以分为Eden 空间、From Survivor 空间（s0）、To Survivor 空间（s1）。 所有新生成的对象首先都是放在新生代的。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来的对象，和从前一个Survivor复制过来的对象，而复制到老年代的只有从第一个Survivor区过来的对象。而且，Survivor区总有一个是空的。

  • 控制参数：-Xms设置堆的最小空间大小 -Xmx设置堆的最大空间大小。-XX:NewSize设置新生代最小空间大小。-XX:MaxNewSize设置新生代最小空间大小。
  • 垃圾回收：此区域是垃圾回收的主要操作区域。
  • 异常情况：如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError 异常

方法区

方法区（Method Area）与Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java 堆区分开来。

很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9 等）来说是不存在永久代的概念的。在Java8中永生代彻底消失了。

  • 控制参数: -XX:PermSize 设置最小空间 -XX:MaxPermSize 设置最大空间。
  • 垃圾回收:对此区域会涉及但是很少进行垃圾回收。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意。
  • 异常情况:根据Java 虚拟机规范的规定， 当方法区无法满足内存分配需求时，将抛出OutOfMemoryError。

方法栈

每个线程会有一个私有的栈。每个线程中方法的调用又会在本栈中创建一个栈帧。在方法栈中会存放编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不等同于对象本身。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

  • 控制参数:-Xss控制每个线程栈的大小。
  • 异常情况:在Java 虚拟机规范中，对这个区域规定了两种异常状况：

- StackOverflowError： 异常线程请求的栈深度大于虚拟机所允许的深度时抛出；

- OutOfMemoryError 异常： 虚拟机栈可以动态扩展，当扩展时无法申请到足够的内存时会抛出。

本地方法栈

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其

区别不过是虚拟机栈为虚拟机执行Java 方法（也就是字节码）服务，而本地方法栈则

是为虚拟机使用到的Native 方法服务。

  • 控制参数:在Sun JDK中本地方法栈和方法栈是同一个，因此也可以用-Xss控制每个线程的大小。
  • 异常情况:与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError 和OutOfMemoryError

异常。

程序计数器

它的作用可以看做是当前线程所执行的字节码的行号指示器。

  • 异常情况:此内存区域是唯一一个在Java 虚拟机规范中没有规定任何OutOfMemoryError 情况的区域。

 

常见内存溢出错误

有了对内存结构清晰的认识，就可以帮助我们理解不同的OutOfMemoryErrors，下面列举一些比较常见的内存溢出错误，通过查看冒号“：”后面的提示信息，基本上就能断定是JVM运行时数据的哪个区域出现了问题。

Exception in thread “main”: java.lang.OutOfMemoryError: Java heap space

原因：对象不能被分配到堆内存中。

Exception in thread “main”: java.lang.OutOfMemoryError: PermGen space

原因：类或者方法不能被加载到老年代。它可能出现在一个程序加载很多类的时候，比如引用了很多第三方的库。

Exception in thread “main”: java.lang.OutOfMemoryError: Requested array size exceeds VM limit

原因：创建的数组大于堆内存的空间。

Exception in thread “main”: java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?

原因：分配本地分配失败。JNI、本地库或者Java虚拟机都会从本地堆中分配内存空间。

Exception in thread “main”: java.lang.OutOfMemoryError: <reason> <stack trace>（Native method）

原因：同样是本地方法内存分配失败，只不过是JNI或者本地方法或者Java虚拟机发现。

 

现场问题分析

言归正传，回到主题，现场在部署应用之后，在运行过程中突然出现OOM，java.lang.OutOfMemoryError: GC overhead limit exceeded

超出了GC开销限制。科普了一下，这个是JDK6新添的错误类型。是发生在GC占用大量时间为释放很小空间的时候发生的，是一种保护机制。一般是因为堆太小，导致异常的原因：没有足够的内存。 

Sun 官方对此的定义：超过98%的时间用来做GC并且回收了不到2%的堆内存时会抛出此异常。那为什么都发生gc了，还有难以释放的内存呢？

需要现场获取dump文件在eclipse memory analyzer上继续进行分析

jmap -dump:format=b,file=/home/admin/logs/heap.hprof 进程
当然也可以加上如下jvm参数，可以在发生oom时自动生成dump文件
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/home/jvmlogs/

经过现场发来的dump文件发现，eclipse memory analyzer自动帮我们发现了可疑的泄漏点（我的方式，thread_overview->JAVA Basics->dominator tree）

 

 

 

thread-pool-35 keeps local variables with total size 1,216,555,792 (88.31%) bytes.

thread-pool-35线程 这个char[]对象占据了总大小的88.31%，总共是

1,216,555,792字节，换算成mb就是1160mb
查看details和查看其线程栈发现


 

经过分析，原因是在页面点击文件上传时，由于Mybatis 批量插入了庞大的数据量，导致内存使用增加，才会出现这个问题引发的内存溢出

参考网上的一案例

由于①mybatis的DAO接口我是传List，而mybatis的foreach底层代码是arrays的，②所以需要把List转arrays，然后遍历Arrays，③用StringBuilder拼接SQL的。

        问题出现在②③步！因生成的arrays对象和StringBuilder对象是在堆内存中的，而堆内存的对象GC回收机制是：只有JVM的使用内存达到最大内存时的一定阀值，才会执行GC回收！

        如果当本身JVM已经使用了占有了JVM的最大内存的90%,那么②③步的生成的对象占有内存+本身已占有的内存如果超出JVM的最大内存，而JVM又来不及执行GC时就会导致JVM内存溢出，当前线程挂掉！

解决办法：

1，提醒应用方优化代码，从根本解决问题。（重要）

2，JVM给出这样一个参数：-XX:-UseGCOverheadLimit  禁用这个检查，其实这个参数解决不了内存问题，只是把错误的信息延后，替换成 java.lang.OutOfMemoryError: Java heap space。

3，增大堆内存 -Xms -Xmx -XX:MaxNewSize -XX:MaxPermSize  


学习链接

MAT常见泄漏Problem Suspect解析方案

https://blog.csdn.net/cui130/article/details/89916495

Mybatis 批量插入引发的血案

https://blog.csdn.net/bobozai86/article/details/84560641
https://blog.csdn.net/syy_c_j/article/details/52151402



问题分析2：
现场一个应用，部署后一直卡着，卡非常久之后发生了oom，分析dump文件发现，在加载lib下的jar包时发生了死循环

 

 

 

 

 

posted on 2021-04-23 15:33  sina-p  阅读(226)  评论(0)    收藏  举报

导航