Java快速定位排查OOM，OOM区域：堆内存、元空间、本地方法栈、虚拟机栈、直接内存。

1、什么是OOM？java.lang.OutOfMemoryError，即内存溢出。2、哪些内存区域会发生OOM？五个区域会发生OOM：直接内存、元空间、本地方法栈、虚拟机栈、元空间。JVM运行时数据区五个区域中，除了程序计数器不会发生OOM，其他区域都有可能。除了元空间、本地方法栈、虚拟机栈、堆外，还有一块区域大家容易忽略，即直接内存。(紫色)区域线程共有、发生GC；(绿色)线程私有，内存很小，

Be_insighted

6065人浏览 · 2022-01-16 11:35:14

Be_insighted · 2022-01-16 11:35:14 发布

Java8内存模型

Throwable下面的Error

SOFE之StackOverflowError

OOM之Java heap space

OOM之GC overhead linit exceeded

OOM之Direct buffer memory

OMM之unabe to create new native thread故障演示

OOM之unable to create new native thread上限调整

OOM之Metaspace

笔记：

0、堆内存配置过小时会怎样？

如JVM参数设置：

-Xms10 -Xmx10 -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m

启动代码则报：

Error occurred during initialization of VM
Too small initial heap

1、什么是OOM？

java.lang.OutOfMemoryError，即内存溢出。

2、哪些内存区域会发生OOM？

五个区域会发生OOM：堆内存、元空间、本地方法栈、虚拟机栈、直接内存。

JVM运行时数据区五个区域中，除了程序计数器不会发生OOM，其他区域都有可能。

除了元空间、本地方法栈、虚拟机栈、堆外，还有一块区域大家容易忽略，即直接内存。

(紫色)区域线程共有、发生GC；

(绿色)线程私有，内存很小，几乎不需要GC

程序计数器不会OOM，记录了方法之间的条用和执行情况。存储了指向下一条指令的地址，它是当前线程所执行的字节码的行号指示器。

3、为什么会出现OOM?

业务正常运行起来就需要比较大的内存，而给JVM设置的内存过小。具体表现就是程序跑不起来，或者跑一会就挂了。
GC回收内存的速度赶不上程序运行消耗内存的速度。出现这种情况一般就是往list、map中填充大量数据，内存紧张时JVM拆东墙补西墙补不过来了。如：一次性查询了大量数据，或者纪录条数不多，但某些字段存储的信息占用空间较大！
存在内存泄漏情况，久而久之也会造成OOM。哪些情况会造成内存泄漏呢？比如打开文件不释放、创建网络连接不关闭、不再使用的对象未断开引用关系、使用静态变量持有大对象引用。

4、JVM会挂么，挂的原因有哪些？

OOM会导致JVM挂掉。

本地方法栈和虚拟机栈如果出问题，项目未上线前都会出现，通常深度调用所致！

Windows操作系统：JVM挂了是由于OOM所致！

Linux操作系统：内核保护机制(为了保证系统在可用内存较少的情况下依旧能够运行)，会杀死需要大内存的进程或者线程

线上环境JVM挂了，首先排除是不是被Linux杀死了，怎么看呢？通过命令[sudo egrep -i -r 'Out Of' /var/log]查看，如果是，关闭一些服务，或者把一些服务移走，腾出点内存。

如果不是Linux系统主动杀死JVN，这时候就可以确定是OOM导致的，那具体是哪个OOM导致的呢？看有没有生成dump文件。如果生成了，要么是堆OOM，要么是元空间OOM；如果没生成，直接可以确定是直接内存导致的OOM。

进一步排查，是堆OOM还是元空间OOM。这时候需要把dump文件从服务器上下载下来，用visualvm分、MAT、JProfiler分析。

如果发现发生OOM的位置是创建对象，调用构造方法之类的代码，那一定是堆OOM。<init>就是构造方法的字节码格式。

如果发现发生OOM的位置是类加载器那些方法，那一定是元空间OOM。

服务应当配置GC相关参数

调优参数务必加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=dump文件位置，发生OOM让JVM自动dump出内存，方便后续分析问题解决问题。
堆内存不要设置的特别大，因为你设置的特别大，发生OOM时生成的dump文件就特别大，不好分析。
主动dump内存会引发STW，请择时操作。如通过arthas提供的命令heapdump主动dump出JVM的内存，这个操作会引发FGC，关键是STW，操作时请选择好时机。

直接内存溢出(OutOfNemoryError: Direct buffer memory)

        元空间的本质和永久代类似，都是对JvM规范中方法区的实现。不过元空间与永久代之间最大的区别在于:
        元空间并不在虚拟机中，而是使用本地内存。
        因此，默认情况下，元空间的大小仅受本地内存限制。

参数设置：-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectNemorySize=5m
故障现象:
Exception in thread "main" java.Lang.OutOfNemoryError: Direct buffer memory
导致原因:
        写NIO程序经常使用ByteBuffer来读取或者写入数据，这是一种基于通道(Channel)与缓冲区(Buffer)的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避兔了在Java堆和Native堆中来回复制数据。
        ByteBuffer.allocate(capability)方式是分配JVM堆内存，属于GC管辖范围，由于需要拷贝，所以速度相对较慢。
        ByteBuffer .allocteDirect(capability)方式是分配OS本地内存，不属于GC管辖范围，由于不需要内存拷贝所以速度相对较快。
        但如果不断分配本地内存，堆内存很少使用，那么JVM就不需要执行6C，DirectByteBuffer对象们就不会被回收，这时候堆内存充足，但本地内存可能已经使用光了，再次尝试分配本地内存就会出现OutOfMemoryError，那程序就直接崩溃了。

public class DirectMemoryOutOfTest {
    private static final int _1MB = 1024 * 1024;

    public static void main(String[] args) throws IllegalAccessException {
        List<ByteBuffer> list = new ArrayList<ByteBuffer>();

        while (true) {
            ByteBuffer buffer = ByteBuffer.allocateDirect(_1MB);

            list.add(buffer);
        }
    }
}

Connected to the target VM, address: '127.0.0.1:11385', transport: 'socket'
[GC (Allocation Failure) [PSYoungGen: 2048K->488K(2560K)] 2048K->863K(9728K), 0.0013739 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
默认配置的maxDirectMemory: 5.0MB
[GC (System.gc()) [PSYoungGen: 951K->504K(2560K)] 1326K->983K(9728K), 0.0016879 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 504K->0K(2560K)] [ParOldGen: 479K->855K(7168K)] 983K->855K(9728K), [Metaspace: 3230K->3230K(1056768K)], 0.0155668 secs] [Times: user=0.06 sys=0.00, real=0.02 secs] 
Exception in thread "main" Disconnected from the target VM, address: '127.0.0.1:11385', transport: 'socket'
Heap
 PSYoungGen      total 2560K, used 81K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 2048K, 3% used [0x00000000ffd00000,0x00000000ffd145e0,0x00000000fff00000)
java.lang.OutOfMemoryError: Direct buffer memory
  from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
	at java.nio.Bits.reserveMemory(Bits.java:658)
  to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
 ParOldGen       total 7168K, used 855K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
  object space 7168K, 11% used [0x00000000ff600000,0x00000000ff6d5fe0,0x00000000ffd00000)
	at com.example.demo.jvm.DirectMemorySizeTest.main(DirectMemorySizeTest.java:19)
 Metaspace       used 3262K, capacity 4568K, committed 4864K, reserved 1056768K
  class space    used 346K, capacity 392K, committed 512K, reserved 1048576K

Process finished with exit code 1

GC overhead limit exceeded

JVM参数配置演示 -Xms10m -Xmx10m -XX:+PrintGcDetails -XX:MaxDirectNemorysize=5m
GC回收时间过长时会抛OutofMemroyError。过长的定义是，超过98%的时间用来做cc并且回收了不到2%的堆内存,连续多次GC都只回收了不到2%的极端情况下才会抛出。假如不抛出 GC overhead limit 错误会发生什么情况呢?那就是GC清理的这么点内存很快会再次填满，迫使GC再次执行．这样就形成恶性循环,
CPU使用率一直是100%,而GC却没有任何成果

/**
 * 模拟GC效果不明显的场景
 * -Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
 *
 */
public class GCOverheadTest {

    public static void main(String[] args) {
        List<String> lists = new ArrayList<>();
        int i = 0;
        while (true){
            // Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
            lists.add(String.valueOf(++i).intern());
        }
    }
}

[GC (Allocation Failure) [PSYoungGen: 2048K->488K(2560K)] 2048K->852K(9728K), 0.0025921 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2536K->488K(2560K)] 2900K->2336K(9728K), 0.0051902 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2536K->496K(2560K)] 4384K->4214K(9728K), 0.0057323 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 2544K->496K(2560K)] 6262K->6271K(9728K), 0.0061699 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[Full GC (Ergonomics) [PSYoungGen: 496K->0K(2560K)] [ParOldGen: 5775K->5788K(7168K)] 6271K->5788K(9728K), [Metaspace: 3182K->3182K(1056768K)], 0.1037437 secs] [Times: user=0.17 sys=0.00, real=0.10 secs] 
[Full GC (Ergonomics) [PSYoungGen: 2048K->1023K(2560K)] [ParOldGen: 5788K->6285K(7168K)] 7836K->7309K(9728K), [Metaspace: 3182K->3182K(1056768K)], 0.0933461 secs] [Times: user=0.14 sys=0.00, real=0.09 secs] 
[Full GC (Ergonomics) [PSYoungGen: 2048K->2047K(2560K)] [ParOldGen: 6285K->6285K(7168K)] 8333K->8332K(9728K), [Metaspace: 3182K->3182K(1056768K)], 0.0546351 secs] [Times: user=0.11 sys=0.00, real=0.06 secs]