标签：lang java OOM 故障 GC 内存 JVM OutOfMemoryError Metaspace

# 前提概要 > **对于JVM服务而言出现了OOM(Out Of Memory)问题，并且对其进行相关的解决是作为一个Java技术栈人员必备的实战能力。在此总结了一些相对通用的方案，希望能帮助到大家**。 # 分析原因 > **某Java服务出现了OOM，最常见的原因为：** 1. **有可能是内存分配确实过小，而正常业务使用了大量内存（正常现象）** 2. **某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽（内存泄漏、代码问题）** 3. **某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接（线程不断创建、代码问题）** # 排查方案 ## 确认是不是内存本身就分配过小 > 方法：**jmap -heap pid**  如上图，可以查看新生代，老生代堆内存的分配大小以及使用情况，看是否本身分配过小。 ## 找到最耗内存的对象 方法：**jmap -histo:live 10765 | more**  如上图，输入命令后，会以表格的形式显示存活对象的信息，并按照所占内存大小排序： - **实例数** - **所占内存大小** - **类名** > **是不是很直观？对于实例数较多，占用内存大小较多的实例/类，相关的代码就要针对性review了。** 上图中占内存最多的对象是**RingBufferLogEvent**，共占用内存**18M**，属于正常使用范围。 如果发现某类对象占用内存很大（例如几个G），很可能是类对象创建太多，且一直未释放。例如： - **申请完资源后，未调用close()或dispose()释放资源** - **消费者消费速度慢（或停止消费了），而生产者不断往队列中投递任务，导致队列中任务累积过多** > **线上执行该命令会强制执行一次fullgc。另外还可以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 JVM中常见的两个错误 - StackoverFlowError ：栈溢出 - OutOfMemoryError: java heap space：堆溢出 除此之外，还有以下的错误 ```` java.lang.StackOverflowError java.lang.OutOfMemoryError：java heap space java.lang.OutOfMemoryError：GC overhead limit exceeeded java.lang.OutOfMemoryError：Direct buffer memory java.lang.OutOfMemoryError：unable to create new native thread java.lang.OutOfMemoryError：Metaspace ```` > **OutOfMemoryError和StackOverflowError是属于Error，不是Exception** ### StackoverFlowError > **堆栈溢出，我们有最简单的一个递归调用，就会造成堆栈溢出，也就是深度的方法调用栈一般是512K，不断的深度调用，直到栈被撑破** ```` public class StackOverflowErrorDemo { public static void main(String[] args) { stackOverflowError(); } /** * 栈一般是512K，不断的深度调用，直到栈被撑破 * Exception in thread "main" java.lang.StackOverflowError */ private static void stackOverflowError() { stackOverflowError(); } } ```` #### 运行结果 ```` Exception in thread "main" java.lang.StackOverflowError at com.moxi.interview.study.oom.StackOverflowErrorDemo.stackOverflowError(StackOverflowErrorDemo.java:17) ```` ### OutOfMemoryError：java heap space 创建了很多对象，导致堆空间不够存储 ```java public class JavaHeapSpaceDemo { public static void main(String[] args) { // 堆空间的大小 -Xms10m -Xmx10m // 创建一个 80M的字节数组 byte [] bytes = new byte[80 * 1024 * 1024]; } } ``` 我们创建一个80M的数组，会直接出现Java heap space ```` Exception in thread "main" java.lang.OutOfMemoryError: Java heap space ```` ### GC overhead limit exceeded > **GC回收时间过长时会抛出OutOfMemoryError，过长的定义是，超过了98%的时间用来做GC，并且回收了不到2%的堆内存**  为了更快的达到效果，我们首先需要设置JVM启动参数 ```` -Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m ```` 异常出现的步骤就是，我们不断的像list中插入String对象，直到启动GC回收 ```java public class GCOverheadLimitDemo { public static void main(String[] args) { int i = 0; List list = new ArrayList<>(); try { while(true) { //1.6时intern()方法发现字符串常量池(存储永久代)没有就复制,物理拷贝 //1.7时intern()方法发现字符串常量池(存储堆)没有就在保存地址值映射实际堆内存对象 list.add(String.valueOf(++i).intern()); } } catch (Exception e) { System.out.println("***************i:" + i); e.printStackTrace(); throw e; } finally { } } } ``` #### 运行结果 ```` [Full GC (Ergonomics) [PSYoungGen: 2047K->2047K(2560K)] [ParOldGen: 7106K->7106K(7168K)] 9154K->9154K(9728K), [Metaspace: 3504K->3504K(1056768K)], 0.0311093 secs] [Times: user=0.13 sys=0.00, real=0.03 secs] [Full GC (Ergonomics) [PSYoungGen: 2047K->0K(2560K)] [ParOldGen: 7136K->667K(7168K)] 9184K->667K(9728K), [Metaspace: 3540K->3540K(1056768K)], 0.0058093 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] Heap PSYoungGen total 2560K, used 114K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000) eden space 2048K, 5% used [0x00000000ffd00000,0x00000000ffd1c878,0x00000000fff00000) from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000) to space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000) ParOldGen total 7168K, used 667K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000) object space 7168K, 9% used [0x00000000ff600000,0x00000000ff6a6ff8,0x00000000ffd00000) Metaspace used 3605K, capacity 4540K, committed 4864K, reserved 1056768K class space used 399K, capacity 428K, committed 512K, reserved 1048576K Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at java.lang.Integer.toString(Integer.java:403) at java.lang.String.valueOf(String.java:3099) at com.moxi.interview.study.oom.GCOverheadLimitDemo.main(GCOverheadLimitDemo.java:18) ```` > **我们能够看到 多次Full GC，并没有清理出空间，在多次执行GC操作后，就抛出异常 GC overhead limit** ### Direct buffer memory > **Netty + NIO：这是由于NIO引起的** 1. **NIO程序的时候经常会使用ByteBuffer来读取或写入数据，这是一种基于通道(Channel)与缓冲区(Buffer)的I/O方式，它可以使用Native函数库直接分配堆外内存** 2. **然后通过一个存储在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的空间 ByteBuffer bb = ByteBuffer.allocateDirect(6 * 1024 * 1024); 这个时候，运行就会出现问题了 配置的maxDirectMemory：5.0MB ```` [GC (System.gc()) [PSYoungGen: 2030K->488K(2560K)] 2030K->796K(9728K), 0.0008326 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC (System.gc()) [PSYoungGen: 488K->0K(2560K)] [ParOldGen: 308K->712K(7168K)] 796K->712K(9728K), [Metaspace: 3512K->3512K(1056768K)], 0.0052052 secs] [Times: user=0.09 sys=0.00, real=0.00 secs] Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:693) at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) at com.moxi.interview.study.oom.DIrectBufferMemoryDemo.main(DIrectBufferMemoryDemo.java:19) ```` ### unable to create new native thread > **不能够创建更多的新的线程了，也就是说创建线程的上限达到了** 在高并发场景的时候，会应用到 > 高并发请求服务器时，经常会出现如下异常**java.lang.OutOfMemoryError:unable to create new native thread**，准确说该 **native thread** 异常与对应的平台有关 #### 导致原因： > **应用创建了太多线程，一个应用进程创建多个线程，超过系统承载极限** > 服务器并不允许你的应用程序创建这么多线程，Linux系统默认运行单个进程可以创建的线程为1024个，如果应用创建超过这个数量，就会报 **java.lang.OutOfMemoryError:unable to create new native thread** #### 解决方法 - 想办法降低你应用程序创建线程的数量，分析应用是否真的需要创建这么多线程，如果不是，改代码将线程数降到最低 - 对于有的应用，确实需要创建很多线程，**远超过linux系统默认1024个线程限制**，可以通过修改linux服务器配置，扩大linux默认限制 ```java public class UnableCreateNewThreadDemo { public static void main(String[] args) { for (int i = 0; ; i++) { System.out.println("************** i = " + i); new Thread(() -> { try { TimeUnit.SECONDS.sleep(Integer.MAX_VALUE); } catch (InterruptedException e) { e.printStackTrace(); } }, String.valueOf(i)).start(); } } } ``` 这个时候，就会出现下列的错误，线程数大概在 900多个 ```` Exception in thread "main" java.lang.OutOfMemoryError: unable to cerate new native thread ```` ##### 如何查看线程数 ```` ulimit -u ```` ### Metaspace > **元空间内存不足，Matespace元空间应用的是本地内存** **-XX:MetaspaceSize 的初始化大小为20M** #### 元空间是什么 > **元空间就是我们的方法区，存放的是类模板，类信息，常量池等** Metaspace是方法区HotSpot中的实现，它与持久代最大的区别在于：Metaspace并不在虚拟内存中，而是使用本地内存，也即在java8中，**class metadata（the virtual machines internal presentation of Java class），被存储在叫做Metaspace的native memory** > **永久代（java8后背元空间Metaspace取代了）存放了以下信息：** - 虚拟机加载的类信息 - 常量池 - 静态变量 - 即时编译后的代码 模拟Metaspace空间溢出，我们不断生成类 往元空间里灌输，类占据的空间总会超过Metaspace指定的空间大小 代码 在模拟异常生成时候，因为初始化的元空间为20M，因此我们使用JVM参数调整元空间的大小，为了更好的效果 ```` -XX:MetaspaceSize=8m -XX:MaxMetaspaceSize=8m ```` ### 代码如下： ```java public class MetaspaceOutOfMemoryDemo { // 静态类 static class OOMTest { } public static void main(final String[] args) { // 模拟计数多少次以后发生异常 int i =0; try { while (true) { i++; // 使用Spring的动态字节码技术 Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(OOMTest.class); enhancer.setUseCache(false); enhancer.setCallback(new MethodInterceptor() { @Override public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable { return methodProxy.invokeSuper(o, args); } }); } } catch (Exception e) { 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的最大大小 与永久代很大的不同就是，如果不指定大小的话，随着更多类的创建，虚拟机会耗尽所有可用的系统内存**。

标签：lang,java,OOM,故障,GC,内存,JVM,OutOfMemoryError,Metaspace
来源： https://blog.51cto.com/alex4dream/2927257

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。