中国建设建筑教育网站,合肥响应式网站开发,企业信用信息查询公示系统网址,WordPress中文替换布目录
1.概述
2.堆溢出、内存泄定位及解决办法
2.1.示例代码
2.2.抓堆快照
2.3.分析堆快照 1.概述
常见的几种JVM内存溢出的场景如下#xff1a; Java堆溢出#xff1a; 错误信息: java.lang.OutOfMemoryError: Java heap space 原因#xff1a;Java对象实例在运行时持…目录
1.概述
2.堆溢出、内存泄定位及解决办法
2.1.示例代码
2.2.抓堆快照
2.3.分析堆快照 1.概述
常见的几种JVM内存溢出的场景如下 Java堆溢出 错误信息: java.lang.OutOfMemoryError: Java heap space 原因Java对象实例在运行时持续创建但不再使用的对象没有及时被垃圾回收器回收导致堆内存耗尽。 解决方案增加堆内存大小(-Xms和-Xmx参数)优化对象生命周期管理减少不必要的大对象或者长时间存在的临时对象。 永久代/元空间溢出取决于Java版本 在Java 8及以前版本中永久代存储类信息、常量池、静态变量等数据若空间不足会抛出java.lang.OutOfMemoryError: PermGen space错误。 在Java 8之后永久代已被元空间取代元空间直接使用本地操作系统内存可能出现java.lang.OutOfMemoryError: Metaspace。 解决方案增大永久代或元空间的大小检查代码是否有大量动态加载类或者反射操作生成过多类信息的情况。 栈空间溢出 错误信息: java.lang.StackOverflowError 原因递归调用过深或线程栈帧过大导致线程栈空间耗尽。 解决方案调整栈的大小(-Xss参数)改进算法避免深度递归合理控制线程数量或每个线程栈的大小。
首先栈溢出定位很简单直接异常栈就会告诉去调整代码逻辑即可。这里着重要聊一下的是元空间溢出和堆溢出。
元空间溢出
JDK1.8及其以后版本元空间替代了永久代其主要用于存储类的元数据信息包括类的结构信息如字段、方法、接口、常量池等、运行时常量池、方法字节码、静态变量等。也就是说类被加载了其相关信息就会存在元空间中。
此处也许有些读者会有疑问
类是要在被用到的时候才会加载也就是一般我们new对象的时候对应的类才会被加载那么存在元空间在堆之前被撑爆的情况吗
答
当然是存在的只要你的元空间比你的堆小或者频繁用Class.forName()、ClassLoader.loadClass()等反射的手法来加载类但是不new对象也能把元空间撑爆了。
元空间溢出其实是比较难遇见的但是定位方法其实不难直接代码全局搜Class.forName之类的语法基本就能定位元凶。
接下来本文要讲的重点是生产中最容易遇见的一种JVM内存溢出——堆溢出以及比堆溢出藏得更深的隐形杀手——内存泄漏这两者如何定位以及解决。
2.堆溢出、内存泄定位及解决办法
2.1.示例代码
直接的堆溢出从异常栈信息里是能看出哪里造成的OOM很容易定位 难定位的是哪种怕的是内存泄漏也就是堆还没有撑爆但是就是在要爆不爆之间徘徊造成频繁的GC由于GC的时候是要”Stop The World“会暂停所有JAVA线程的工作这自然会浪费CPU资源外界的感知就是”变慢了“。这里我们详细的来聊一聊如何定位内存泄漏的问题。
测试代码
//定义一个类该类中一旦调用一个方法就会持续让List持有一个个1024KB大小的内存空间但是又不会直接撑爆heap
import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.util.ArrayList;
public class MyUser {private Byte[] bytes;
ArrayListbyte[] list new ArrayList();
public static final int OBJECT_SIZE 1024 * 1024; // 每个对象占用1MB空间public static final double HEAP_UTILIZATION_RATIO 0.8; // 目标堆利用率
public MyUser(){}
public void callTest(){try {MemoryMXBean memoryMxBean ManagementFactory.getMemoryMXBean();long maxMemory Runtime.getRuntime().maxMemory();
while (true) {// 检查当前堆内存使用情况如果已超过目标利用率则退出循环long currentHeapUsage memoryMxBean.getHeapMemoryUsage().getUsed();if ((double) currentHeapUsage / maxMemory HEAP_UTILIZATION_RATIO) {System.out.println(当前堆内存使用率达到目标利用率程序即将退出...);break;}
// 创建一个大对象byte[] largeObject new byte[OBJECT_SIZE];// 将大对象添加到列表中list.add(largeObject);
// 添加一个延时模拟其他操作便于观察Thread.sleep(100); // 等待100毫秒
// 可以在此处添加额外的日志输出或监控代码用于记录GC信息和内存状态}
// 清理资源防止后续分析时误判list.clear();} catch (InterruptedException e) {throw new RuntimeException(e);}}
}
//用junit开始测试
Test
public void test02() throws Exception{MyUser myUser new MyUser();myUser.callTest();
2.2.抓堆快照
运行上面的示例代码打开jvisualVM开始监控程序可以看到
垃圾回收是有在进行的而且频率不低但是堆的大小一直在扩被占用率一直在攀升说明并没有被回收掉存在严重的内存泄露。 这时候就需要把堆的dump抓下来看看了。右上角有抓heap dump的选项。
2.3.分析堆快照
通过MAT看看了看看到底是有哪些东西占着内存一直没被回收掉。
MAT是eclipse旗下的一款heap的分析工具可以用来专门分析heap dump。下载地址
Eclipse Memory Analyzer | projects.eclipse.org
MAT和JDK有版本适配关系千万别下错了作者用的JDK下载的1.8.1版本 还要注意下载的安装包和操作系统之间也是有严格的适配关系的作者第一次就下成了x86而不是x86_64确定好自己的操作系统平台下对应的 用MAT打开抓下来的heap dump 工具会分析显示除怀疑内存泄漏的地方
其实从饼状图上已经可以看出端倪饼状图显示了可能存在内存泄漏的对象和该对象持有的内存的对比这个对象自身占的内存大小只有浅灰色的一小条但是其持有的内存居然达到了300多MB很明显的内存泄漏的情况。 我们初步断定了存在内存泄漏接下来当然是要定位具体位置然后才好解决它。
展开详细信息可以看到怀疑是Main线程上的一个MyUser类型里面的一个类型为ArrayList名叫list的成员变量造成了内存泄漏 接下来去看这里的代码逻辑就行了。
