快速定位Java 内存OOM的问题
Java服务出现了OOM(OutOfMemory)问题，总结了一些相对通用的方案，希望能帮助到Java技术栈的同学。
某Java服务（假设PID=10765）出现了OOM，最常见的原因为：
有可能是内存分配确实过小，而正常业务使用了大量内存
某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽
某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接
画外音：无非“本身资源不够”“申请资源太多”“资源耗尽”几个原因。
更具体的，可以使用以下工具逐一排查。
一、确认是不是内存本身就分配过小
方法：jmap-heap10765
如上图，可以查看新生代，老生代堆内存的分配大小以及使用情况，看是否本身分配过小。
二、找到最耗内存的对象
方法：jmap-histo:live10765|more
如上图，输入命令后，会以表格的形式显示存活对象的信息，并按照所占内存大小排序：
实例数
所占内存大小
类名
是不是很直观？对于实例数较多，占用内存大小较多的实例/类，相关的代码就要针对性review了。
上图中占内存最多的对象是RingBufferLogEvent，共占用内存18M，属于正常使用范围。
如果发现某类对象占用内存很大（例如几个G），很可能是类对象创建太多，且一直未释放。例如：
申请完资源后，未调用close()或dispose()释放资源
消费者消费速度慢（或停止消费了），而生产者不断往队列中投递任务，导致队列中任务累积过多
画外音：线上执行该命令会强制执行一次fgc。另外还可以dump内存进行分析。
三、确认是否是资源耗尽
工具：
pstree
netstat
查看进程创建的线程数，以及网络连接数，如果资源耗尽，也可能出现OOM。
这里介绍另一种方法，通过
/proc/${PID}/fd
/proc/${PID}/task
可以分别查看句柄详情和线程数。
例如，某一台线上服务器的sshd进程PID是9339，查看
ll/proc/9339/fd
ll/proc/9339/task
如上图，sshd共占用了四个句柄
0->标准输入
1->标准输出
2->标准错误输出
3->socket（容易想到是监听端口）
sshd只有一个主线程PID为9339，并没有多线程。
所以，只要
ll/proc/${PID}/fd|wc-l
ll/proc/${PID}/task|wc-l（效果等同pstree-p|wc-l）
就能知道进程打开的句柄数和线程数。
补充：Java内存溢出OOM
Java内存溢出OOM
经典错误
JVM中常见的两个错误
StackoverFlowError：栈溢出
OutofMemoryError:javaheapspace：堆溢出
除此之外，还有以下的错误
java.lang.StackOverflowError java.lang.OutOfMemoryError：javaheapspace java.lang.OutOfMemoryError：GCoverheadlimitexceeeded java.lang.OutOfMemoryError：Directbuffermemory java.lang.OutOfMemoryError：unabletocreatenewnativethread java.lang.OutOfMemoryError：Metaspace
架构
OutOfMemoryError和StackOverflowError是属于Error，不是Exception
StackoverFlowError
堆栈溢出，我们有最简单的一个递归调用，就会造成堆栈溢出，也就是深度的方法调用
栈一般是512K，不断的深度调用，直到栈被撑破
publicclassStackOverflowErrorDemo{
publicstaticvoidmain(String[]args){
stackOverflowError();
}
/**
*栈一般是512K，不断的深度调用，直到栈被撑破
*Exceptioninthread"main"java.lang.StackOverflowError
*/
privatestaticvoidstackOverflowError(){
stackOverflowError();
}
}
运行结果
Exceptioninthread"main"java.lang.StackOverflowError atcom.moxi.interview.study.oom.StackOverflowErrorDemo.stackOverflowError(StackOverflowErrorDemo.java:17)
OutOfMemoryError
javaheapspace
创建了很多对象，导致堆空间不够存储
/**
*Java堆内存不足
*/
publicclassJavaHeapSpaceDemo{
publicstaticvoidmain(String[]args){
//堆空间的大小-Xms10m-Xmx10m
//创建一个80M的字节数组
byte[]bytes=newbyte[80*1024*1024];
}
}
我们创建一个80M的数组，会直接出现Javaheapspace
Exceptioninthread"main"java.lang.OutOfMemoryError:Javaheapspace
GCoverheadlimitexceeded
GC回收时间过长时会抛出OutOfMemoryError，过长的定义是，超过了98%的时间用来做GC，并且回收了不到2%的堆内存
连续多次GC都只回收了不到2%的极端情况下，才会抛出。假设不抛出GCoverheadlimit错误会造成什么情况呢？
那就是GC清理的这点内存很快会再次被填满，迫使GC再次执行，这样就形成了恶性循环，CPU的使用率一直都是100%，而GC却没有任何成果。
代码演示：
为了更快的达到效果，我们首先需要设置JVM启动参数
-Xms10m-Xmx10m-XX:+PrintGCDetails-XX:MaxDirectMemorySize=5m
这个异常出现的步骤就是，我们不断的像list中插入String对象，直到启动GC回收
/**
*GC回收超时
*JVM参数配置:-Xms10m-Xmx10m-XX:+PrintGCDetails
*/
publicclassGCOverheadLimitDemo{
publicstaticvoidmain(String[]args){
inti=0;
Listlist=newArrayList<>();
try{
while(true){
//1.6时intern()方法发现字符串常量池(存储永久代)没有就复制,物理拷贝
//1.7时intern()方法发现字符串常量池(存储堆)没有就在保存地址值映射实际堆内存对象
list.add(String.valueOf(++i).intern());
}
}catch(Exceptione){
System.out.println("***************i:"+i);
e.printStackTrace();
throwe;
}finally{
}
}
}
运行结果
[FullGC(Ergonomics)[PSYoungGen:2047K->2047K(2560K)][ParOldGen:7106K->7106K(7168K)]9154K->9154K(9728K),[Metaspace:3504K->3504K(1056768K)],0.0311093secs][Times:user=0.13sys=0.00,real=0.03secs] [FullGC(Ergonomics)[PSYoungGen:2047K->0K(2560K)][ParOldGen:7136K->667K(7168K)]9184K->667K(9728K),[Metaspace:3540K->3540K(1056768K)],0.0058093secs][Times:user=0.00sys=0.00,real=0.01secs] Heap PSYoungGentotal2560K,used114K[0x00000000ffd00000,0x0000000100000000,0x0000000100000000) edenspace2048K,5%used[0x00000000ffd00000,0x00000000ffd1c878,0x00000000fff00000) fromspace512K,0%used[0x00000000fff80000,0x00000000fff80000,0x0000000100000000) tospace512K,0%used[0x00000000fff00000,0x00000000fff00000,0x00000000fff80000) ParOldGentotal7168K,used667K[0x00000000ff600000,0x00000000ffd00000,0x00000000ffd00000) objectspace7168K,9%used[0x00000000ff600000,0x00000000ff6a6ff8,0x00000000ffd00000) Metaspaceused3605K,capacity4540K,committed4864K,reserved1056768K classspaceused399K,capacity428K,committed512K,reserved1048576K Exceptioninthread"main"java.lang.OutOfMemoryError:GCoverheadlimitexceeded atjava.lang.Integer.toString(Integer.java:403) atjava.lang.String.valueOf(String.java:3099) atcom.moxi.interview.study.oom.GCOverheadLimitDemo.main(GCOverheadLimitDemo.java:18)
我们能够看到多次FullGC，并没有清理出空间，在多次执行GC操作后，就抛出异常GCoverheadlimit
Directbuffermemory
Netty+NIO：这是由于NIO引起的
写NIO程序的时候经常会使用ByteBuffer来读取或写入数据，这是一种基于通道(Channel)与缓冲区(Buffer)的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
ByteBuffer.allocate(capability)：第一种方式是分配JVM堆内存，属于GC管辖范围，由于需要拷贝所以速度相对较慢
ByteBuffer.allocteDirect(capability)：第二种方式是分配OS本地内存，不属于GC管辖范围，由于不需要内存的拷贝，所以速度相对较快
但如果不断分配本地内存，堆内存很少使用，那么JVM就不需要执行GC，DirectByteBuffer对象就不会被回收，这时候堆内存充足，但本地内存可能已经使用光了，再次尝试分配本地内存就会出现OutOfMemoryError，那么程序就崩溃了。
一句话说：本地内存不足，但是堆内存充足的时候，就会出现这个问题
我们使用-XX:MaxDirectMemorySize=5m配置能使用的堆外物理内存为5M
-Xms20m-Xmx20m-XX:+PrintGCDetails-XX:MaxDirectMemorySize=5m
然后我们申请一个6M的空间
//只设置了5M的物理内存使用，但是却分配6M的空间 ByteBufferbb=ByteBuffer.allocateDirect(6*1024*1024);
这个时候，运行就会出现问题了
配置的maxDirectMemory：5.0MB
[GC(System.gc())[PSYoungGen:2030K->488K(2560K)]2030K->796K(9728K),0.0008326secs][Times:user=0.00sys=0.00,real=0.00secs] [FullGC(System.gc())[PSYoungGen:488K->0K(2560K)][ParOldGen:308K->712K(7168K)]796K->712K(9728K),[Metaspace:3512K->3512K(1056768K)],0.0052052secs][Times:user=0.09sys=0.00,real=0.00secs] Exceptioninthread"main"java.lang.OutOfMemoryError:Directbuffermemory atjava.nio.Bits.reserveMemory(Bits.java:693) atjava.nio.DirectByteBuffer.(DirectByteBuffer.java:123) atjava.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) atcom.moxi.interview.study.oom.DIrectBufferMemoryDemo.main(DIrectBufferMemoryDemo.java:19)
unabletocreatenewnativethread
不能够创建更多的新的线程了，也就是说创建线程的上限达到了
在高并发场景的时候，会应用到
高并发请求服务器时，经常会出现如下异常java.lang.OutOfMemoryError:unabletocreatenewnativethread，准确说该nativethread异常与对应的平台有关
导致原因：
应用创建了太多线程，一个应用进程创建多个线程，超过系统承载极限
服务器并不允许你的应用程序创建这么多线程，linux系统默认运行单个进程可以创建的线程为1024个，如果应用创建超过这个数量，就会报java.lang.OutOfMemoryError:unabletocreatenewnativethread
解决方法：
想办法降低你应用程序创建线程的数量，分析应用是否真的需要创建这么多线程，如果不是，改代码将线程数降到最低
对于有的应用，确实需要创建很多线程，远超过linux系统默认1024个线程限制，可以通过修改linux服务器配置，扩大linux默认限制
/**
*无法创建更多的线程
*/
publicclassUnableCreateNewThreadDemo{
publicstaticvoidmain(String[]args){
for(inti=0;;i++){
System.out.println("**************i="+i);
newThread(()->{
try{
TimeUnit.SECONDS.sleep(Integer.MAX_VALUE);
}catch(InterruptedExceptione){
e.printStackTrace();
}
},String.valueOf(i)).start();
}
}
}
这个时候，就会出现下列的错误，线程数大概在900多个
Exceptioninthread"main"java.lang.OutOfMemoryError:unabletoceratenewnativethread
如何查看线程数
ulimit-u
Metaspace
元空间内存不足，Matespace元空间应用的是本地内存
-XX:MetaspaceSize的初始化大小为20M
元空间是什么
元空间就是我们的方法区，存放的是类模板，类信息，常量池等
Metaspace是方法区HotSpot中的实现，它与持久代最大的区别在于：Metaspace并不在虚拟内存中，而是使用本地内存，也即在java8中，classmetadata（thevirtualmachinesinternalpresentationofJavaclass），被存储在叫做Matespace的nativememory
永久代（java8后背元空间Metaspace取代了）存放了以下信息：
虚拟机加载的类信息
常量池
静态变量
即时编译后的代码
模拟Metaspace空间溢出，我们不断生成类往元空间里灌输，类占据的空间总会超过Metaspace指定的空间大小
代码
在模拟异常生成时候，因为初始化的元空间为20M，因此我们使用JVM参数调整元空间的大小，为了更好的效果
-XX:MetaspaceSize=8m-XX:MaxMetaspaceSize=8m
代码如下：
/**
*元空间溢出
*
*/
publicclassMetaspaceOutOfMemoryDemo{
//静态类
staticclassOOMTest{
}
publicstaticvoidmain(finalString[]args){
//模拟计数多少次以后发生异常
inti=0;
try{
while(true){
i++;
//使用Spring的动态字节码技术
Enhancerenhancer=newEnhancer();
enhancer.setSuperclass(OOMTest.class);
enhancer.setUseCache(false);
enhancer.setCallback(newMethodInterceptor(){
@Override
publicObjectintercept(Objecto,Methodmethod,Object[]objects,MethodProxymethodProxy)throwsThrowable{
returnmethodProxy.invokeSuper(o,args);
}
});
}
}catch(Exceptione){
System.out.println("发生异常的次数:"+i);
e.printStackTrace();
}finally{
}
}
}
会出现以下错误：
发生异常的次数:201
java.lang.OutOfMemoryError:Metaspace
注意
在JDK1.7之前:永久代是方法区的实现，存放了运行时常量池、字符串常量池和静态变量等。
在JDK1.7:永久代是方法区的实现，将字符串常量池和静态变量等移出至堆内存。运行时常量池等剩下的还再永久代(方法区)
在JDK1.8及以后:永久代被元空间替代，相当于元空间实现方法区，此时字符串常量池和静态变量还在堆，运行时常量池还在方法区(元空间)，元空间使用的是直接内存。
-XX:MetaspaceSize=N//设置Metaspace的初始（和最小大小）-XX:MaxMetaspaceSize=N//设置Metaspace的最大大小与永久代很大的不同就是，如果不指定大小的话，随着更多类的创建，虚拟机会耗尽所有可用的系统内存。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持毛票票。如有错误或未考虑完全的地方，望不吝赐教。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。