【十五】不要问我JVM ！—— OOM及性能优化案例与解决

小灰灰 2022-08-29 06:13 354阅读 0赞

> # 一、内存泄漏案例分析（一） #

public class Stack { 
        private Object[] elements;
        private int size = 0;
        private static final int DEFAULT_INITIAL_CAPACITY = 16;
    
        public Stack() { 
            elements = new Object[DEFAULT_INITIAL_CAPACITY];
        }
    
        // 入栈
        public void push(Object e) { 
            ensureCapacity();
            elements[size++] = e;
        }
    
        // 出栈
        public Object pop() { 
            if (size == 0)
                throw new EmptyStackException();
            return elements[--size];
        }
    
        // 扩容
        private void ensureCapacity() { 
            if (elements.length == size) { 
                elements = Arrays.copyOf(elements, 2 * size + 1);
            }
        }
    }

**分析**  
上述程序并没有明显的错误，但是这段程序有一个内存泄漏，随着GC活动的增加，或者内存占用的不断增加，程序性能的降低就会表现出来，严重时可导致内存泄漏，但是这种失败情况相对较少。

代码的主要问题在`pop`函数，下面通过这张图示展现:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70]  
当进行大量的`pop`操作时，由于引用未进行置空，gc是不会释放的，如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 1]  
**解决方法**  
将代码中的`pop()`方法变成如下方法：

public Object pop() { 
        if (size == 0) { 
            throw new EmptyStackException();
        }
        Object result = elements[--size];
        elements[size] = null;
        return result;
    }

> # 二、Tomcat堆溢出分析 #

Tomcat是最常用的Java Servlet容器之一，同时也可以当做单独的Web服务器使用。Tomcat本身使用Java实现，并运行于Java虚拟机之上。在大规模请求时，Tomcat有可能会因为无法承受压力而发生内存溢出错误。这里根据一个被压垮的Tomcat的堆快照文件，来分析Tomcat在崩溃时的内部情况。

**分析过程**  
图显示了Tomcat溢出时的总体信息，可以看到堆的大小为29.7MB。从统计饼图中得知，当前深堆最大的对象为StandardManager，它持有大约16.4MB的对象。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 2]  
一般来说，我们总是会对占用空间最大的对象特别感兴趣，如果可以查看StandardManager内部究竟引用了哪些对象，对于分析问题可能会起到很大的帮助。因此，在饼图中单击StandardManager所在区域，在弹出菜单中选择“with outgoing references”命令，这样将会列出被StandardManager引用的所有对象。如图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 3]  
图显示了被StandardManager引用的对象，其中特别显眼的就是sessions对象，它占用了约17MB空间。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 4]  
继续查找，打开sessions对象，查看被它引用的对象，如图所示。可以看到sessions对象为ConcurrentHashMap，其内部分为16个Segment。从深堆大小看，每个Segment都比较平均，大约为1MB,合计17MB。继续打开Segment,查看存储在sessions中的真实对象。如图所示，可以找到内部存放的为StandardSession对象。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 5]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 6]  
通过OQL命令，查找所有的StardardSession。可以看到当前堆中含有9941个session,并且每一个session的深堆为1592字节，合计约15MB，达到当前堆大小的50%。由此，可以知道，当前Tomcat发生内存溢出的原因，极可能是由于在短期内接收大量不同客户端的请求，从而创建大量session导致。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 7]  
为了获得更为精确的信息，可以查看每一个session的内部数据，在左侧的对象属性表中，可以看到所选中的session的最后访问时间和创建时间。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 8]  
通过OQL命令和MAT的排序功能，可以找到当前系统中最早创建的session和最后创建的session。再根据当前的session总数，可以计算每秒的平均压力为：9941/(1403324677648-1403324645728)\*1000=311次/秒。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 9]  
由此推断，在发生Tomcat堆溢出时，Tomcat在连续30秒的时间内，平均每秒接收了约311次不同客户端的请求，创建了合计9941个session。

> # 三、后台导出数据引发的OOM #

公司的后台系统，偶发性的引发OOM异常，堆内存溢出。

1、因为是偶发性的，所以第一次简单的认为就是堆内存不足导致，所以单方面的加大了堆内存从4G调整到8G。  
2、但是问题依然没有解决，只能从堆内存信息下手，通过开启了-XX:+HeapDumpOnOutOfMemoryError 参数 获得堆内存的dump文件。  
3、VisualVM 对 堆dump文件进行分析，通过VisualVM查看到占用内存最大的对象是String对象，本来想跟踪着String对象找到其引用的地方，但dump文件太大，跟踪进去的时候总是卡死，而String对象占用比较多也比较正常，最开始也没有认定就是这里的问题，于是就从线程信息里面找突破点。  
4、通过线程进行分析，先找到了几个正在运行的业务线程，然后逐一跟进业务线程看了下代码，发现有个引起我注意的方法，导出订单信息。  
5、因为订单信息导出这个方法可能会有几万的数据量，首先要从数据库里面查询出来订单信息，然后把订单信息生成excel，这个过程会产生大量的String对象。  
6、为了验证自己的猜想，于是准备登录后台去测试下，结果在测试的过程中发现到处订单的按钮前端居然没有做点击后按钮置灰交互事件，结果按钮可以一直点，因为导出订单数据本来就非常慢，使用的人员可能发现点击后很久后页面都没反应，结果就一直点，结果就大量的请求进入到后台，堆内存产生了大量的订单对象和EXCEL对象，而且方法执行非常慢，导致这一段时间内这些对象都无法被回收，所以最终导致内存溢出。  
7、知道了问题就容易解决了，最终没有调整任何JVM参数，只是在前端的导出订单按钮上加上了置灰状态，等后端响应之后按钮才可以进行点击，然后减少了查询订单信息的非必要字段来减少生成对象的体积，然后问题就解决了。

> # 四、CPU经常100% 问题定位 #

CPU高一定是某个程序长期占用了CPU资源。  
1、所以先需要找出那个进行占用CPU高。

top  列出系统各个进程的资源占用情况。

2、然后根据找到对应进行里哪个线程占用CPU高。

top -Hp 进程ID   列出对应进程里面的线程占用资源情况

3、找到对应线程ID后，再打印出对应线程的堆栈信息

printf "%x\n"  PID    把线程ID转换为16进制。
    jstack PID 打印出进程的所有线程信息，从打印出来的线程信息中找到上一步转换为16进制的线程ID对应的线程信息。

4、最后根据线程的堆栈信息定位到具体业务方法,从代码逻辑中找到问题所在。

查看是否有线程长时间的watting 或blocked
    如果线程长期处于watting状态下， 关注watting on xxxxxx，说明线程在等待这把锁，然后根据锁的地址找到持有锁的线程。

> # 五、内存飚高问题定位 #

内存飚高如果是发生在java进程上，一般是因为创建了大量对象所导致，持续飚高说明垃圾回收跟不上对象创建的速度，或者内存泄露导致对象无法回收。  
1、先观察垃圾回收的情况

jstat -gc PID 1000 查看GC次数，时间等信息，每隔一秒打印一次。
    jmap -histo PID | head -20   查看堆内存占用空间最大的前20个对象类型,可初步查看是哪个对象占用了内存。

如果每次GC次数频繁，而且每次回收的内存空间也正常，那说明是因为对象创建速度快导致内存一直占用很高；如果每次回收的内存非常少，那么很可能是因为内存泄露导致内存一直无法被回收。  
2、导出堆内存文件快照

jmap -dump:live,format=b,file=/home/myheapdump.hprof PID  dump堆内存信息到文件。

3、使用visualVM对dump文件进行离线分析,找到占用内存高的对象，再找到创建该对象的业务代码位置，从代码和业务场景中定位具体问题。

> # 六、数据分析平台系统频繁 Full GC #

平台主要对用户在 App 中行为进行定时分析统计，并支持报表导出，使用 CMS GC 算法。  
数据分析师在使用中发现系统页面打开经常卡顿，通过 jstat 命令发现系统每次 Young GC 后大约有 10% 的存活对象进入老年代。  
原来是因为 Survivor 区空间设置过小，每次 Young GC 后存活对象在 Survivor 区域放不下，提前进入老年代。  
通过调大 Survivor 区，使得 Survivor 区可以容纳 Young GC 后存活对象，对象在 Survivor 区经历多次 Young GC 达到年龄阈值才进入老年代。  
调整之后每次 Young GC 后进入老年代的存活对象稳定运行时仅几百 Kb，Full GC 频率大大降低。

> # 七、业务对接网关 OOM #

网关主要消费 Kafka 数据，进行数据处理计算然后转发到另外的 Kafka 队列，系统运行几个小时候出现 OOM，重启系统几个小时之后又 OOM。  
通过 jmap 导出堆内存，在 eclipse MAT 工具分析才找出原因：代码中将某个业务 Kafka 的 topic 数据进行日志异步打印，该业务数据量较大，大量对象堆积在内存中等待被打印，导致 OOM。、

> # 八、鉴权系统频繁长时间 Full GC #

系统对外提供各种账号鉴权服务，使用时发现系统经常服务不可用，通过 Zabbix 的监控平台监控发现系统频繁发生长时间 Full GC，且触发时老年代的堆内存通常并没有占满，发现原来是业务代码中调用了 System.gc()。

> \#九、 单个缓存数据过大导致的系统CPU飚高  
> 1、系统发布后发现CPU一直飚高到600%，发现这个问题后首先要做的是定位到是哪个应用占用CPU高，通过top 找到了对应的一个java应用占用CPU资源600%。  
> 2、如果是应用的CPU飚高，那么基本上可以定位可能是锁资源竞争，或者是频繁GC造成的。  
> 3、所以准备首先从GC的情况排查，如果GC正常的话再从线程的角度排查，首先使用jstat -gc PID 指令打印出GC的信息，结果得到得到的GC 统计信息有明显的异常，应用在运行了才几分钟的情况下GC的时间就占用了482秒，那么问这很明显就是频繁GC导致的CPU飚高。  
> 4、定位到了是GC的问题，那么下一步就是找到频繁GC的原因了，所以可以从两方面定位了，可能是哪个地方频繁创建对象，或者就是有内存泄露导致内存回收不掉。  
> 5、根据这个思路决定把堆内存信息dump下来看一下，使用jmap -dump 指令把堆内存信息dump下来（堆内存空间大的慎用这个指令否则容易导致会影响应用，因为我们的堆内存空间才2G所以也就没考虑这个问题了）。  
> 6、把堆内存信息dump下来后，就使用visualVM进行离线分析了，首先从占用内存最多的对象中查找，结果排名第三看到一个业务VO占用堆内存约10%的空间，很明显这个对象是有问题的。  
> 7、通过业务对象找到了对应的业务代码，通过代码的分析找到了一个可疑之处，这个业务对象是查看新闻资讯信息生成的对象，由于想提升查询的效率，所以把新闻资讯保存到了redis缓存里面，每次调用资讯接口都是从缓存里面获取。  
> 8、把新闻保存到redis缓存里面这个方式是没有问题的，有问题的是新闻的50000多条数据都是保存在一个key里面，这样就导致每次调用查询新闻接口都会从redis里面把50000多条数据都拿出来，再做筛选分页拿出10条返回给前端。50000多条数据也就意味着会产生50000多个对象，每个对象280个字节左右，50000个对象就有13.3M，这就意味着只要查看一次新闻信息就会产生至少13.3M的对象，那么并发请求量只要到10，那么每秒钟都会产生133M的对象，而这种大对象会被直接分配到老年代，这样的话一个2G大小的老年代内存，只需要几秒就会塞满，从而触发GC。  
> 9、知道了问题所在后那么就容易解决了，问题是因为单个缓存过大造成的，那么只需要把缓存减小就行了，这里只需要把缓存以页的粒度进行缓存就行了，每个key缓存10条作为返回给前端1页的数据，这样的话每次查询新闻信息只会从缓存拿出10条数据，就避免了此问题的 产生。
> 
> # 十、网站流量浏览量暴增后，网站反应页面响很慢 #

1、问题推测：在测试环境测速度比较快，但是一到生产就变慢，所以推测可能是因为垃圾收集导致的业务线程停顿。  
2、定位：为了确认推测的正确性，在线上通过jstat -gc 指令 看到JVM进行GC 次数频率非常高，GC所占用的时间非常长，所以基本推断就是因为GC频率非常高，所以导致业务线程经常停顿，从而造成网页反应很慢。  
3、解决方案：因为网页访问量很高，所以对象创建速度非常快，导致堆内存容易填满从而频繁GC，所以这里问题在于新生代内存太小，所以这里可以增加JVM内存就行了，所以初步从原来的2G内存增加到16G内存。  
4、第二个问题：增加内存后的确平常的请求比较快了，但是又出现了另外一个问题，就是不定期的会间断性的卡顿，而且单次卡顿的时间要比之前要长很多。  
5、问题推测：练习到是之前的优化加大了内存，所以推测可能是因为内存加大了，从而导致单次GC的时间变长从而导致间接性的卡顿。  
6、定位：还是通过jstat -gc 指令 查看到 的确FGC次数并不是很高，但是花费在FGC上的时间是非常高的,根据GC日志 查看到单次FGC的时间有达到几十秒的。  
7、解决方案： 因为JVM默认使用的是PS+PO的组合，PS+PO垃圾标记和收集阶段都是STW，所以内存加大了之后，需要进行垃圾回收的时间就变长了，所以这里要想避免单次GC时间过长，所以需要更换并发类的收集器，因为当前的JDK版本为1.7，所以最后选择CMS垃圾收集器，根据之前垃圾收集情况设置了一个预期的停顿的时间，上线后网站再也没有了卡顿问题。

> # 五、一个线程OOM了，其它线程还能运行吗？SOF呢？ #

Java 的OOM分很多类型：

*  堆溢出（“java.lang.OutOfMemoryError: Java heap space”）
 *  永久代溢出（“java.lang.OutOfMemoryError:Permgen space”）
 *  不能创建线程（“java.lang.OutOfMemoryError:Unable to create new native thread”）
 *  若虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出 OutOfMemoryError异常

发生 SOF的：

*  虚拟机栈/本地方法栈溢出

OOM在《Java虚拟机规范》里，除程序计数器，虚拟机内存的其他几个运行时区域都可能发生OOM。

## 堆溢出 OOM ##

Java堆用于储存对象实例，只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免GC机制清除这些对象，则随对象数量增加，总容量触及最大堆的容量限制后就会产生内存溢出异常。

JVM启动参数设置：

-Xms5m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError

`-XX:+HeapDumpOnOutOfMemoryError`可以让虚拟机在出现内存溢出异常的时候Dump出当前的内存堆转储快照。

public class HeapOOM { 
        public static void main(String[] args) throws InterruptedException { 
            TimeUnit.SECONDS.sleep(5);
    
            new Thread(()-> { 
               List<byte[]> list = new ArrayList<>();
               while(true){ 
                   ConsoleUtil.print(Thread.currentThread() + "==");
                   byte[] b = new byte[1024 * 1024];
                   list.add(b);
                   try { 
                       Thread.sleep(1000);
                   } catch (InterruptedException e) { 
                       e.printStackTrace();
                   }
               }
            }, "t1").start();
    
            new Thread(()-> { 
                while(true){ 
                    ConsoleUtil.print(Thread.currentThread() + "==");
                    try { 
                        Thread.sleep(1000);
                    } catch (InterruptedException e) { 
                        e.printStackTrace();
                    }
                }
            }, "t2").start();
        }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 10]  
从打印结果来看，t1 线程OOM后，t2线程照样运行！  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 11]  
从VisualVM的堆内存曲线看，堆的使用大小，突然抖动！说明当一个线程抛OOM后，它所占据的内存资源会全部被释放掉，而不会影响其他线程的正常运行！

所以，**一个线程溢出后，进程里的其他线程还能照常运行。**

发生OOM的线程一般情况下会死亡，也就是会被终结掉，该线程持有的对象占用的heap都会被gc了，释放内存。因为发生OOM之前要进行gc，就算其他线程能够正常工作，也会因为频繁gc产生较大的影响。

## 虚拟机栈/本地方法栈溢出 ##

由于HotSpot JVM并不区分虚拟机栈和本地方法栈（合二为一），因此HotSpot的`-Xoss`参数（设置本地方法栈的大小）虽然存在，但无任何效果，栈容量只能由`-Xss`参数设定。

关于虚拟机栈和本地方法栈，《Java虚拟机规范》描述如下异常：

*  若线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常
 *  若虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出 OutOfMemoryError异常

《Java虚拟机规范》明确允许JVM实现自行选择是否支持栈的动态扩展，而HotSpot虚拟机的选择是不支持扩展，所以除非在创建线程申请内存时就因无法获得足够内存而出现OOM，否则在线程运行时是不会因为扩展而导致内存溢出的，只会因为栈容量无法容纳新的栈帧而导致StackOverflowError。

**如何验证呢？**

先在单线程操作，尝试下面两种行为是否能让HotSpot OOM。

### （1）使用-Xss减少栈内存容量 ###

JVM启动参数设置：

-Xss160k

public class StackSOF01 { 
        private int stackLength = 1;
    
        public void stackLeak() { 
            System.out.println("stackLength:" + stackLength);
            stackLength++;
            stackLeak();
        }
    
        public static void main(String[] args) { 
            StackSOF01 stackSOF01 = new StackSOF01();
         
                stackSOF01.stackLeak();
    
        }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 12]

### （2）定义大量局部变量，增大此方法帧中本地变量表的长度，看会不会OOM ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 13]  
![在这里插入图片描述][8eb700cdf6264a87b214d7f8a82d78a2.png]  
所以无论是由于栈帧太或虚拟机栈容量太小，当新的栈帧内存无法分配时， `HotSpot` 都抛`SOF`。可若在允许动态扩展栈容量大小的虚拟机上，相同代码则会导致不同情况。

若测试时不限于单线程，而是不断新建线程，在HotSpot上也会产生OOM。但这样产生OOM和栈空间是否足够不存在直接的关系，主要取决于操作系统本身内存使用状态。甚至说这种情况下，给每个线程的栈分配的内存越大，反而越容易产生OOM。

不难理解，os分配给每个进程的内存有限制，比如32位Windows的单个进程最大内存限制为2G。HotSpot提供参数可以控制Java堆和方法区这两部分的内存的最大值，那剩余的内存即为2G（os限制）减去最大堆容量，再减去最大方法区容量，由于程序计数器消耗内存很小，可忽略，若把直接内存和虚拟机进程本身耗费的内存也去掉，剩下的内存就由虚拟机栈和本地方法栈来分配了。因此为每个线程分配到的栈内存越大，可以建立的线程数量越少，建立线程时就越容易把剩下的内存耗尽。

出现SOF时，会有明确错误堆栈可供分析，相对容易定位问题。如果使用HotSpot虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的）到达1000~2000没有问题，对于正常的方法调用（包括不能做尾递归优化的递归调用），这个深度应该完全够用。但如果是建立过多线程导致的内存溢出，在不能减少线程数量或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量换取更多的线程。这种通过“减少内存”手段解决内存溢出的方式，如果没有这方面处理经验，一般比较难以想到。也是由于这种问题较为隐蔽，从 JDK 7起，以上提示信息中“unable to create native thread”后面，虚拟机会特别注明原因可能是“possibly”。

## 方法区和运行时常量池溢出 ##

运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放到一起。

HotSpot从JDK 7开始逐步“去永久代”，在JDK 8中完全使用元空间代替永久代。那么方法区使用“永久代”还是“元空间”来实现，对程序有何影响呢？

在JDK6或之前HotSpot虚拟机，常量池都是分配在永久代，限制永久代的大小，即可间接限制其中常量池的容量：  
![在这里插入图片描述][f3d3228002bf4bfea3967fdf4cb3af35.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 14]

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space 
      at java.lang.String.intern(Native Method) 
      at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java: 18)

可见，运行时常量池溢出时，在OutOfMemoryError异常后面跟随的提示信息是“PermGen space”，说明运行时常量池的确是属于方法区（即JDK 6的HotSpot虚拟机中的永久代）的 一部分。

而使用JDK 7或更高版本的JDK来运行这段程序并不会得到相同的结果，无论是在JDK 7中继续使 用-XX：MaxPermSize参数或者在JDK 8及以上版本使用-XX：MaxMeta-spaceSize参数把方法区容量同样限制在6MB，也都不会重现JDK 6中的溢出异常，循环将一直进行下去，永不停歇。这种变化是因为自JDK 7起，原本存放在永久代的字符串常量池被移至Java堆，所以在JDK 7及以上版 本，限制方法区的容量对该测试用例来说是毫无意义。

JDK8及以后：可以使用

-XX:MetaspaceSize=10M
    -XX:MaxMetaspaceSize=10M

设置元空间初始大小以及最大可分配大小。

> 1.如果不指定元空间的大小，默认情况下，元空间最大的大小是系统内存的大小，元空间一直扩大，虚拟机可能会消耗完所有的可用系统内存。  
> 2.如果元空间内存不够用，就会报OOM。  
> 3.默认情况下，对应一个64位的服务端JVM来说，其默认的`-XX:MetaspaceSize`值为21MB，这就是初始的高水位线，一旦元空间的大小触及这个高水位线，就会触发Full GC并会卸载没有用的类，然后高水位线的值将会被重置。  
> 4.从第3点可以知道，如果初始化的高水位线设置过低，会频繁的触发Full GC，高水位线会被多次调整。所以为了避免频繁GC以及调整高水位线，建议将`-XX:MetaspaceSize`设置为较高的值，而`-XX:MaxMetaspaceSize`不进行设置。

## 本机直接内存溢出 ##

直接内存（Direct Memory）的容量大小可通过-XX:MaxDirectMemorySize指定，若不指定，则默认与Java堆最大值（-Xmx）一致。

这里越过DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配。  
Unsafe类的getUnsafe()指定只有引导类加载器才会返回实例，体现了设计者希望只有虚拟机标准类库里面的类才能使用Unsafe，JDK10时才将Unsafe的部分功能通过VarHandle开放给外部。

因为虽然使用DirectByteBuffer分配内存也会抛OOM，但它抛异常时并未真正向os申请分配内存，而是通过计算得知内存无法分配，就在代码里手动抛了OOM，真正申请分配内存的方法是Unsafe::allocateMemory()  
![在这里插入图片描述][12f6018fe4fd4f0c863f65fb3299d204.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 15]  
![在这里插入图片描述][d2a22d33e55d4fed88e12fb22469ddab.png]  
由直接内存导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见有什么明显异常，若发现内存溢出之后产生的Dump文件很小，而程序中又直接或间接使用了 DirectMemory（比如使用NIO），则该考虑直接内存了。

## 总结： ##

*  \*\*堆溢出：\*\*一个线程溢出后，进程里的其他线程还能照常运行。
 *  **虚拟机栈/本地方法栈溢出**：（1）单线程时，虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出 OOM，若线程请求的栈深度大于虚拟机所允许的最大深度，将抛出SOF。但是对于HotSpot都抛SOF。（2）多线程时，产生OOM和栈空间是否足够不存在直接的关系，主要取决于操作系统本身内存使用状态。给每个线程的栈分配的内存越大，反而越容易产生OOM。线程越多越容易OOM。
 *  **方法区和运行时常量池溢出**：JDK8后，永久代完全废弃，而使用元空间作为其替代者。在默认设置下，前面列举的那些正常的动态创建新类型的测试用例已经很难再迫使虚拟机产生方法区OOM。
 *  **本机直接内存溢出**：因为虽然使用DirectByteBuffer分配内存也会抛OOM，但它抛异常时并未真正向os申请分配内存，而是通过计算得知内存无法分配，就在代码里手动抛了OOM，真正申请分配内存的方法是Unsafe::allocateMemory()，所以其他线程还可以活动。

# 补充一：浅堆、深堆、保留集 #

**浅堆**（Shallow Heap）是指一个对象所消耗的内存。

在32位系统中，一个对象引用会占据4个字节，一个int类型会占据4个字节，long型变量会占据8个字节，每个对象头需要占用8个字节。根据堆快照格式不同，对象的大小可能会同8字节进行对齐。

以String为例：2个int值共占8字节，对象引用占用4字节，对象头8字节，合计20字节，向8字节对齐，故占24字节。这24字节为String对象的浅堆大小。它与String的value实际取值无关，无论字符串长度如何，浅堆大小始终是24字节。

**保留集**（Retained Set）  
对象A的保留集指当对象A被垃圾回收后，可以被释放的所有的对象集合（包括对象A本身），即对象A的保留集可以被认为是只能通过对象A被直接或间接访问到的所有对象的集合。通俗地说，就是指仅被对象A所持有的对象的集合。

**深堆**（Retained Heap）  
深堆是指对象的保留集中所有的对象的浅堆大小之和。  
注意：浅堆指对象本身占用的内存，不包括其内部引用对象的大小。一个对象的深堆指只能通过该对象访问到的（直接或间接）所有对象的浅堆之和，即对象被回收后，可以释放的真实空间。

`深堆大小` = `当前对象的浅堆大小` \+ `对象中所包含对象的深堆大小`

# 补充二：内存泄漏 #

**何为内存泄露（Memory Leak）**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 16]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 17]  
可达性分析算法来判断对象是否是不再使用的对象，本质都是判断一个对象是否还被引用。

严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。

但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也以叫做宽泛意义上的“内存泄漏”  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 18]  
对象X引用对象Y，X的生命周期比Y的生命周期长；

那么当Y生命周期结束的时候，X依然引用着Y,这时候，垃圾回收期是不会回收对象Y的；

如果对象X还引用着生命周期比较短的A、B、C,对象A又引用着对象a、b、c,这样就可能造成大量无用的对象不能被回收，进而占据了内存资源，造成内存泄漏，直到内存溢出。

**内存泄漏与内存溢出的关系**  
内存泄漏（Memory Leak）：申请了内存用完了不释放，比如一共有1024M的内存，分配了512M的内存一直不回收，那么可以用的内存只有512M了，仿佛泄露掉了一部分。

内存溢出（Out of Memory）：申请内存时，没有足够的内存可以使用；

可见，内存泄漏和内存溢出的关系：内存泄漏的增多，最终会导致内存溢出。

**泄漏的分类**

*  经常发生：发生内存泄露的代码会被多次执行，每次执行，泄露一块内存；
 *  偶然发生：在某些特定情况下才会发生
 *  一次性：发生内存泄露的方法只会执行一次；
 *  隐式泄漏：一直占着内存不释放，直到执行结束；严格的说这个不算内存泄漏，因为最终释放掉了，但是如果执行时间特别长，也可能会导致内存耗尽。

**内存泄漏的8种情况**  
静态集合类  
静态集合类，如HashMap、LinkedList等等。如果这些容器为静态的，那么它们的生命周期与JVM程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。

public class MemoryLeak { 
        static List<Object> list = new ArrayList<>();
    
        public void oomTest() { 
            // 局部变量
            Object obj = new Object();
            list.add(obj);
        }
    }

单例模式  
单例模式和静态集合导致内存泄露的原因类似，因为单例的静态特性，它的生命周期和JVM的生命周期一样长，所以如果单例对象如果持有外部对象的引用，那么这个外部对象也不会被回收，那么就会造成内存泄漏。

内部类持有外部类  
内部类持有外部类，如果一个外部类的实例对象的方法返回了一个内部类的实例对象。

这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄漏。

各种连接，如数据库连接、网络连接和IO连接等

在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用close方法来释放与数据库的连接。只有连接被关闭后，垃圾回收器才会回收对应的对象。

否则，如果在访问数据库的过程中，对Connection、Statement或ResultSet不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

public class MemoryLeak { 
        public static void main(String[] args) { 
            Connection conn = null;
            try { 
                Class.forName("com.mysql.jdbc.Driver");
                conn = DriverManager.getConnection("url", "", "");
                Statement stmt = conn.createStatement();
                ResultSet rs = stmt.executeQuery("......");
            } catch (ClassNotFoundException | SQLException e) { 
                e.printStackTrace();
            } finally { 
                // 1. 关闭结果集Statement
                // 2. 关闭声明的对象ResultSet
                // 3. 关闭连接Connection
            }
        }
    }

变量不合理的作用域  
一个变量的定义的作用范围大于其使用范围，如果没有及时地把对象设置为null，很有可能导致内存泄漏的发生。

public class UsingRandom { 
        private String msg;
    
        public void receiveMsg() { 
            // 从网络中接受数据保存到msg中
            readFromNet();
            // 将msg保存到数据库中
            saveDB();
        }
    }

如上面这个伪代码，通过readFromNet方法把接受的消息保存在变量msg中，然后调用saveDB方法把msg的内容保存到数据库中，此时msg已经就没用了，由于msg的生命周期与对象的生命周期相同，此时msg还不能回收，因此造成了内存泄漏。

实际上这个msg变量可以放在receiveMsg方法内部，当方法使用完，那么msg的生命周期也就结束，此时就可以回收了。还有一种方法，在使用完msg后，把msg设置为null，这样垃圾回收器也会回收msg的内存空间。

改变哈希值  
改变哈希值，当一个对象被存储进HashSet集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了。

否则，对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄漏。这也是 String 为什么被设置成了不可变类型，我们可以放心地把 String 存入 HashSet,或者把String当做HashMap的key值；

当我们想把自己定义的类保存到散列表的时候，需要保证对象的hashCode不可变。

public class ChangeHashCode { 
        public static void main(String[] args) { 
            HashSet<Person> set = new HashSet<>();
            Person p1 = new Person(1001, "AA");
            Person p2 = new Person(1002, "BB");
    
            set.add(p1);
            set.add(p2);
    
            // 导致了内存的泄漏
            p1.name = "CC";
            // 删除失败
            set.remove(p1);
    
            // [Person{id=1002, name='BB'}, Person{id=1001, name='CC'}]
            System.out.println(set);
    
            set.add(new Person(1001, "CC"));
            // [Person{id=1002, name='BB'}, Person{id=1001, name='CC'}, Person{id=1001, name='CC'}]
            System.out.println(set);
    
            set.add(new Person(1001, "AA"));
            // [Person{id=1002, name='BB'}, Person{id=1001, name='CC'}, Person{id=1001, name='CC'}, Person{id=1001, name='AA'}]
            System.out.println(set);
        }
    }
    
    @Data
    class Person { 
        int id;
        String name;
    
        @Override
        public boolean equals(Object o) { 
            if (this == o) return true;
            if (!(o instanceof Person)) return false;
    
            Person person = (Person) o;
    
            if (id != person.id) return false;
            return name != null ? name.equals(person.name) : person.name == null;
        }
    
        @Override
        public int hashCode() { 
            int result = id;
            result = 31 * result + (name != null ? name.hashCode() : 0);
            return result;
        }
    
        @Override
        public String toString() { 
            return "Person{" +
                    "id=" + id +
                    ", name='" + name + '\'' +
                    '}';
        }
    }

缓存泄漏  
内存泄漏的另一个常见来源是缓存，一旦你把对象引用放入到缓存中，就很容易遗忘。比如：之前项目在一次上线的时候，应用启动奇慢直到夯死，就是因为代码中会加载一个表中的数据到缓存（内存中，测试环境只有几百条数据，但是生产环境有几百万的数据。

对于这个问题，可以使用`WeakHashMap`代表缓存，此种Map的特点是，当除了自身有对key的引用外，此key没有被其他对象引用那么此map会自动丢弃此值。

public class MapTest { 
        static Map<String, String> wMap = new WeakHashMap<>();
        static Map<String, String> map = new HashMap<>();
    
        public static void main(String[] args) { 
            init();
            testWeakHashMap();
            testHashMap();
        }
    
        public static void init() { 
            String ref1 = new String("obejct1");
            String ref2 = new String("obejct2");
            String ref3 = new String("obejct3");
            String ref4 = new String("obejct4");
            wMap.put(ref1, "cacheObject1");
            wMap.put(ref2, "cacheObject2");
            map.put(ref3, "cacheObject3");
            map.put(ref4, "cacheObject4");
            System.out.println("String引用ref1，ref2，ref3，ref4 消失");
    
        }
    
        public static void testWeakHashMap() { 
            System.out.println("WeakHashMap GC之前");
            System.out.println(wMap);
            try { 
                System.gc();
                TimeUnit.SECONDS.sleep(5);
            } catch (InterruptedException e) { 
                e.printStackTrace();
            }
            System.out.println("WeakHashMap GC之后");
            System.out.println(wMap);
        }
    
        public static void testHashMap() { 
            System.out.println("HashMap GC之前");
            System.out.println(map);
            try { 
                System.gc();
                TimeUnit.SECONDS.sleep(5);
            } catch (InterruptedException e) { 
                e.printStackTrace();
            }
            System.out.println("HashMap GC之后");
            System.out.println(map);
        }
    }

String引用ref1，ref2，ref3，ref4 消失
    WeakHashMap GC之前
    { obejct2=cacheObject2, obejct1=cacheObject1}
    WeakHashMap GC之后
    { }
    HashMap GC之前
    { obejct4=cacheObject4, obejct3=cacheObject3}
    HashMap GC之后
    { obejct4=cacheObject4, obejct3=cacheObject3}

上面代码演示WeakHashMap如何自动释放缓存对象，当init函数执行完成后，局部变量符串引用ref1，ref2，ref3，ref4都会消失，此时只有静态map中保存中对字符串对象的引用，可以看到，调用gc之后，HashMap的没有被回收，而WeakHashMap里面的缓存被回收了。

监听器和回调  
内存泄漏另一个常见来源是监听器和其他回调，如果客户端在你实现的API中注册回调，却没有显示的取消，那么就会积聚。

需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存成为WeakHashMap中的键。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70]: /images/20220829/00c80420680948bfb1ff82c0b3b4d5bf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 1]: /images/20220829/6da306750e2543d0947abc97169be52a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 2]: /images/20220829/85c5ce25bef9477b958f8c0b11d3fd21.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 3]: /images/20220829/acfabe5fe89142f38a3d5b897a346a6b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 4]: /images/20220829/6c2996f992814471a581049342ae15c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 5]: /images/20220829/4319a22326be474197e27ed4300e56a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 6]: /images/20220829/58d33128e17548a88c29ce92a4d367fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 7]: /images/20220829/2876a8a325924f20983b199593fc79b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 8]: /images/20220829/0e841792554a489b961021280c62c25a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 9]: /images/20220829/801f3d92f43942fbb773257c3f24e677.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 10]: /images/20220829/1b5e99471e1a4e809d994447d40955fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 11]: /images/20220829/9e23548e89bc4d46a218ead5ed23e8b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 12]: /images/20220829/0c6879369d2246a0b25d231e7c7ba1e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 13]: /images/20220829/77991812edaa4277aaea5b69b0b1b0cb.png
[8eb700cdf6264a87b214d7f8a82d78a2.png]: /images/20220829/840c062976aa4c139ab2a75d6ae38b8f.png
[f3d3228002bf4bfea3967fdf4cb3af35.png]: /images/20220829/1aea3f91f17d4ed4aa1dbcdc7d36c5e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 14]: /images/20220829/49bb813aba1b4992a6ca67afa874e946.png
[12f6018fe4fd4f0c863f65fb3299d204.png]: /images/20220829/c86ade68f58a4050a1aceeaa71368cf3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 15]: /images/20220829/efe3a6d6336c49d0b2da7e3fb4a6196b.png
[d2a22d33e55d4fed88e12fb22469ddab.png]: /images/20220829/fe29c017a71d43db9bc1728b4d32cd32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 16]: /images/20220829/e77f074558544ea3a93ed471d0123980.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 17]: /images/20220829/203db134cd2e462d84fe8990a85fb8f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 18]: /images/20220829/b9d359cbd4b64a4bbbf478c92c066adc.png