JVM

分析一下有谁在引用他，然后一层层往上去判断，看是否有GC Roots

示例1

示例2

一个变量引用一个对象

此时垃圾回收绝对不会去回收这个对象

public static SoftReference<ReplicaManager> replicaManager = new SoftReference<ReplicaManager>(new ReplicaManager);

正常情况下不会回收软引用对象

如果垃圾回收后发现内存空间还是不够存放新的对象，还是会被回收

和没引用类似

垃圾回收会被回收掉

Eden区占80%内存空间，Servivor各占10%

确保90%的内存被使用到

（1）刚开始对象分配在Eden区内

（2）如果过Eden区快满了，此时就会触发垃圾回收

（3）将Eden区中的存活对象一次性转移到一块空着的Survivor区

（4）清空Eden区

（5）新对象再次分配到Eden区

（6）再次Minor GC，将Eden区和上一次Minor GC存活对象的Survivor区内的存活对象转移到另外一块Survivor区去。

（1）Minor GC之后，剩余的存活对象的大小，小于Surivor区的大小，那么存活独享进入Survivor区域

（2）Minor GC过后，剩余的存活对象的大小大于Survivor区域的大小，但是小于老年代可用内存大小的，此时直接进入老年代即可

（3）Minor GC之后，剩余的存活独享大于Survivor区域的大小，也大于老年代可用内存的大小，发生“Handle Promotion Failure”的情况，这个时候就会触发一次“Full GC”

老年代可用的连续空间 < 新生代历次YoungGC后升入老年代的对象总和的平均大小

4核8G，JVM内存4G，新生代和老年代分配1.5G

每次Minor GC之后，后会直接进入老年代

加入这个选项，就会使用ParNew垃圾回收器

-XX:ParalleGCThreads

代码片段

初始标记

并发标记

重新标记

并发清理

CMS并发清理时，只回收了之前标记好的垃圾对象，但是因为这个阶段系统一直运行，部分对象可能进入老年代，然后没人引用变成垃圾对象。这种垃圾对象是“浮动垃圾”，这些对象是不会本次回收的

为了保证CMS垃圾回收期间，能让其他对象进入老年代，所以会预留空间。设置老年代占用多少比例的时候触发CMS垃圾回收

如果CMS垃圾回收期间，要放入老年代的对象大于可用空间，发生Concurrent Mode Failure.

设置在Full GC之后要再次进行Stop the World，停止工作线程，然后进行碎片整理，将存活对象移动到一起。

执行一定次数Full GC之后再执行一次内存碎片整理工作，默认0，即每次Full GC都会进行一次内存整理

一般4核8G会给JVM4G，其他留给操作系统

1s 300 订单60MB，1.5G新生代大概需要25s就会占满，然后进行Minor GC

能回收掉99%的对象，除了最近1s的订单，大概剩余100MB

-XX:SurViVorRatio默认值8，Survivor是150M的内存，所以20s就会MinorGC，然后存活对象放入S1，下次Minor GC，存活对象还是100MB放入S2

问题：因为每次新生代垃圾回收在100MB左右，可能会突破150MB，会导致对象进入老年代。同时因为100MB大于Survivor区空间的50%，也可能导致对象进入老年代。

问题：新生代对象躲过多少次垃圾回收后进入老年代

问题：多大的对象直接进入老年代

指定垃圾回收器

-Xms3072M -Xmx3072 -Xmn2048M -Xss1M -XX:permSize=256M -XX:MaxPermSize=256M -XX:Survivor=8 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M

（1）-XX:MaxTenuringThreshold=5 躲过5次MinorGC

（2）超过1MB的大对象，直接进入老年代

（3）Minor GC之后存活的对象超过200MB，或者是超过Survivor的50%，会有部分对象进入老年代

（1）没有打开 “-XX:HandlePromotionFailure”选项，结果老年代可用内存最多1G，新生代对象总大小最大1.8G，此时Minor GC前检查，发现老年代可用内存小于新生代总对象大小，导致每次Minor GC之前都Full GC（1.6后已经废弃）

（2）每次Minor GC之前，检查老年代可用内存空间小于历次Minor GC后升入老年代的平均对象大小

（3）某次Minor GC后要升入老年代的对象有几百M，但是老年代的可用空间不足了

（4）设置了“-XX:CMSInitiatingOccupancyFaction”参数，假设设定值为92%，前面条件都没满足，然后触发了此条件，就会Full GC

假设1h后，老年代有900MB的对象，此时剩余可用100MB，此时触发Full GC。如果系统程序还在不停的创建对象，导致200MB进入老年代，此时触发Concurrent Mode Failure。导致系统进入Stop the World，CMS切换为Serial Old

因为概率极小，暂时不考虑。

因为Full GC的频率并不高，所以保持默认每次FUll GC之后后执行一次内存碎片

（1）G1垃圾回收器可以同时回收新生代和老年代的对象

（2）将Java堆内存拆分为多个大小相等的Region

（3）逻辑上有新生代和老年代

（4）可以设置一个垃圾回收的预期停顿时间

G1会追踪每个Region里的回收价值

G1是可以设定目标GC停顿时间的，也就是G1执行GC时最多可以让系统停顿多长时间。

（1）达到一定年龄

（2）动态年龄判定规则，Minor GC后存活对象超过Survivor的50%

G1提供了专门的Region来存放大对象，而不是让大对象进入老年代的Region中。如果对象太多大，会横跨多个Region来存放

判定规则

在G1里，新生代和老年代的eRegion是不停的变化的，一次垃圾回收后，就有很多Region都空了，此时这些不属于新生代了，可以用来存放大对象。

回收时机

当老年代占据了堆内存的45%的Region的时候，此时就会尝试触发一个新生代 + 老年代一起回收的混合回收阶段

例如：堆内存2048个Region，如果老年代占据了近1000个Region时，就会触发混合回收

（1）触发一个“初始标记”的操作，这个过程需要进入Stop the World，仅仅只是标记一下GC Roots直接能引用的对象，速度很快

（2）并发标记阶段，会允许系统程序运行，同时进行GC Roots追踪，从GC Roots开始追踪所有的存活对象。耗时，因为要追踪所有存活对象

（3）最终标记阶段，进入Stop the World，系统程序禁止运行，会根据并发标记阶段记录的那些对象修改，最终标记一下有哪些存活对象那个，那些垃圾对象。

（4）混合回收阶段，会计算老年代中每个Region中的存活对象数量，存活对象的占比，还有执行垃圾回收的预期性能和效率，将GC导致的停顿时间控制在我们指定的范围内

一次混合回收的过程中，最后一个阶段执行几次混合回收，默认8次。先停止系统，混合回收一些，再恢复系统运行，接着再禁止系统运行，混合回收，反复8次。

假设一次混合回收预期要回收掉一共160Region，那么此时第一次混合回收，会回收掉一些Region，比如20个Region，然后系统恢复一会，再混合回收。

反复回收的意义

默认值5%

混合回收的时候，对Region回收都是基于复制算法进行的，都是要把回收回收的Region里存活的对选哪个放入其他Region，然后这个Region中的垃圾对象全部清理掉。这样的话回收过程中就会不断空出来新的Region，一旦达到了堆内存的5%，此时就会立即停止混合回收。

G1整体是基于复制算法进行Region垃圾回收的，不存在垃圾碎片问题

默认值85%

确定要回收的Region时候，必须是存活对象低于85%的RegionCIA可以进行回收

减少拷贝成本

（1）一个百万级注册用户的在线教育平台，注册用户几百万，日活用户规模大概在几十万

（2）业务流程：浏览 -> 报课

（3）高频行为：上课

（4）高峰期：晚上八九点、周末。几十万的日活基本上都在这个时间

（5）高频功能：大量的游戏互动环节，会承载用户高频率、大量的互动点击

活跃数：假设3h有60w活跃用户，平均每个用户会使用1h左右来上课，大概1h有20w活跃用户同时学习

互动数：假设每分钟互动一次，一小时60次互动，那么20w用户在1h内会进行1200w次互动操作，平均每秒大概3000次左右互动。

服务器配置：一般系统的核心服务需要部署5台4核8G的机器来抗住

请求产生的对象：一次互动请求大致会连带创建几个对象，占据几kb，假设为5KB，那么1秒600次就会占用3MB左右内存

内存分配

此时堆内存4GB，Region = 4GB / 2048，每个Region大小是2MB，新生代占5%就是1000个Regoin，200MB空间

GC停顿时间

触发新生代GC的时机

（1）应该给整个JVM的堆区域足够的内存

（2）合理设置-XX:MaxGCPauseMills，避免频繁GC和挺短过长

老年代在堆内存占比45%就会触发

尽量避免对象过快的进入老年代，避免触发mixed GC

如果系统部署在大内存的机器上，例如32核64G的机器，此时分配给系统的有几十个G，新生代Eden可能有30~40G的内存。此时如果系统负载非常高，每秒几万的访问请求。可能导致Eden区的几十G内存频繁塞满触发垃圾回收。每次垃圾回收需要几秒。

（1）一次Minor GC之后发现Survivor区域的几个年龄的对象加起来超过了Survivor区域的50%.

（2）年龄1 + 年龄2 + 年龄3 > 50%，那么年龄3以上的对象会进入老年代

（1）无论是CMS垃圾回收器还是G1垃圾回收器。因为都要经历几个阶段（初始标记、并发标记、重新标记、并发清理、碎片整理）

（2）一般老年代gc是新生代gc的10倍以上，每次停顿时间几秒钟

（1）第一行代码一运行，在JVM的Eden区放入一个1MB的对象，同时在main线程的虚拟机栈中会压入一个main()方法的栈帧，main()栈帧内部有一个array1变量，这个变量指向堆内存Eden区的那个1MB的数组

（2）第二行代码运行，在堆内存创建第二个数组，并且让局部变量指向第二个数组，然后第一个数组没人引用了，成为垃圾对象

（3）第三行代码这行代码在堆内存的Eden区内创建了第三个数据，让array1指向了第三个数据，前面两个数组变成了垃圾对象

（4）第四行代码，array1 = null，让这个变量都不指向，前面三个数组全部变成垃圾对象。

（5）第五行代码,byte[] array2 = new byte[2*1024*1024]。此时分配一个2MB大小的数组，尝试放入Eden区

由于Eden总共就4MB的大小，前面是哪个数组占用了3MB，所以第五行代码会触发Young GC

解析

GC执行过程

par new generation total 4608K,used 2601K

eden... from... to ....

concurrent..

Metaspace

代码段1

代码段2

（1）分配3个2MB的数组，然后最后让array1变量指向第三个2MB数组

（2）创建一个128K的数组，但是让他指向了null。Eden默认存在一定大小的位置对象

（3）接着执行array3的代码，想要分配一个2MB的数组，会触发Young GC

（1）ParNew:8148K -> 662K(9216K)

（2） 

（3） 

（4） 

Young GC过后存活对象放不下Survivor区域，部分对象会进入老年代，部分对象停留在Survivor中

直接分配了一个4MB的大对象，由于参数设定大对象为3MB，所以直接进入老年代。接着不对对象进行引用

连续分配4个数组，3个2MB，1个128KB，全部进入Eden

（1）此时执行这行代码，Eden已经放不下了，所以触发了Young GC

（2）大对象，直接放入老年代中，但是老年已经有了一个4M数组，放不下3个2MB + 1个128KB

Eden原来有8140的对象，但是无法回收，因为都被引用了

（1）执行了CMS垃圾回收器的Full GC（老年代Old GC + Young GC  + 元数据GC）

（2）在CMS Full GC之前已经触发了Young GC，此时执行了Old GC

（3）CMS流程

（1）jstat -gc PID ms（间隔时间）

（2）jstat -gccapacity PID

（3）jstat -gcnew PID

（4）jstat -gcnewcapacity PID

（5）jstat -gcoldcapacity PID

（6）jstat -gcold PID

（7）jstat -gcmetacapacity PID

（1）获取每秒钟在年轻代的Eden区分配多少对象

（2）Young GC的触发频率和每次耗时

（3）Young GC后有多少对象是存活和进入老年代的

（4）Full GC的触发时机和耗时

会打印堆内存相关的一些参数设置以及当前堆内存里的一些基本各个区域的情况

将当前目录生成一个dump.hrpof文件，生成一个内存快照供后续分析

打开了一个服务，然后可以通过7000端口访问

-XX:MetaspaceSize=512m

-XX:MaxMetaspaceSize=512m

（1）这个类的类加载器先要被回收

（2）类的所有对象实例都要被回收等

（1）系统的Metaspace区域过小

（2）cglib等动态生成的一些类，代码中没有控制好，导致类过多，造成内存溢出

 

（1）定义一个类代表汽车，有一个run方法，标识启动汽车，让汽车行驶

（2）通过Enhancer动态生成类，给Enhancer一个父类Car，然后在调用run方法时，先被MethodInterceptor拦截，判断如果是run方法，先做安全检查

（3）安全检查后，通过methodProxy.invokeSuper(o, objects)调用父类Car的run方法

（4）类似于如下代码

 JVM配置

代码设置，加入计数器

第273次时，Metaspace内存溢出

 

（1）0.531: [GC (Allocation Failure) 0.532: [ParNew: 67712K->2271K(76160K), 0.0018929 secs] 67712K->2271K(245504K), 0.0021394 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

（2）0.819: [Full GC (Metadata GC Threshold) 0.819: [CMS: 0K->2705K(169344K), 0.0254210 secs] 20962K->2705K(245504K), [Metaspace: 9402K->9402K(1058816K)], 0.0255527 secs] [Times: user=0.00 sys=0.02, real=0.03 secs]

（3）0.845: [Full GC (Last ditch collection) 0.845: [CMS: 2705K->1657K(169344K), 0.0118531 secs] 2705K->1657K(245632K), [Metaspace: 9402K->9402K(1058816K)], 0.0119546 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

（4）

控制台日志

（1） 实例最多的就是AppClassLoader，是CGLib之类的东西在动态生成类的时候搞出来的

（2）有一大堆自己的Demo1中动态生成出来的Car$EnhancerByCGLIB

每次方法调用的栈帧都是要占用内存的。虚拟机栈大小是固定的，比如1M，每次这个线程调用一个方法，都会将本次方法调用的栈帧压入虚拟机栈，这个栈帧是有方法的局部变量的，也是会占用内存的

如果不停的让线程调用方法，不停的往栈放入栈帧，此时就会消耗完线程栈内存，最终导致内存溢出的情况

 

 

 

 

（1） 控制台异常

（2）只要把所有的异常都写入了本地日志文件，那么可以去日志里定位一下异常信息，然后根据异常进行解决

（1）系统承载高并发请求，因为请求量过大，导致大量对象都是存活的，所以要继续放入新的对象是在是不行了。

（2）系统有内存泄漏问题，莫名其妙弄了很多对象，结果对象都是存活的，没有及时取消对他们的引用，导致GC无法回收

 

 

 

 

 显示是堆内存溢出

（1）分析下方信息

（2）Details

（3）查找是怎么创建出来的 See stacktrace

比如创建订单，1分钟超过一定数量报警，避免刷单

在OOM的时候自动dump内存快照出来

将dump内存快照放到指定地方

JVM内存里每天会频繁的创建和销毁100万个订单

（1） 一般用户交易都会发生在每天的高峰期，比如中午或者晚上

（2）100万平均分配到几个小时中，大概每秒100笔订单

（3）支付系统部署三台机器，每台机器实际上每秒大概处理30笔订单

（1）用户发起一次请求，支付需要在JVM中创建一个支付订单对象，填充进去数据，然后写入数据库，还会处理一些其他事情，估计为1s

（2）每台机器1s接收30笔支付订单的请求，在JVM的新生代里创建了30个支付订单的对象，等待写库等处理

每个支付订单大概需要多大的内存空间

（3）1s后，30个支付订单处理完毕，订单对象引用被回收

（4）重复以上动作

（1）不停在新生代放入30个支付订单，然后新生代里的互相会持续的积累和增加

完整的支付系统内存占用预估

（2）一段时间后，可能有几十万对象了，占据几百MB，新生代空间快满了

（3）触发Minor GC

（1）减少频繁的MinorGC

（2）设定：使用4核8G的机器来部署支付系统

（3）1M/S 差不多近半个小时才会让新生代Minor GC

环境

GC

（1）一个平台，有数十万甚至上百万的商家在平台上做生意，使用这个平台系统会产生大量的数据，然后基于这些数据需要为商家提供一些数据报表。BI（Business Intelligence）商业智能

（2）对这些经营数据依托各种大数据计算平台，比如Hadoop、Spark、Flink等技术进行海量数据的计算，计算出各种数据报表

（3）将计算好的各种数据分析表放入一些存储中，比如说MySQL、Elastcisearch、HBase

（4）基于MySQL、HBase、Elasticsearch中存储的数据报表，基于Java开发一个BI系统，基于各种条件对存储好的数据进行复杂的筛选和分析。

（1）4核8G的服务器

（2）新生代分配1.5G左右，Eden区大约1G左右的空间

（1）当使用系统的商家越来越多时，达到几万时，前端页面自动每隔几秒就发送一个请求到后台刷新一下数据，假设同意时间有几千个商家

（2）基本上BI系统部署的每台机器每秒的请求会达到几百个，我们假设是500个请求

（3）每个请求会加载出来一张报表需要的大量数据，同时还需要对这些数据进行内存中的现场计算加工

（4）根据测算，每个请求需要加载出来100kb数据进行计算，每秒500个请求就需要50M

Young GC

（1）后期随着商家越来越多，并发压力增加，高峰期有10w每秒的并发压力，如果单纯依靠集群可能需要上百台机器。

（2）此时会选择提升机器配置。将部署的机器全面提升到16核32G的高配置机器上去。每台机器可以抗每秒几千请求，此时只需要二三十机器就可以了

（3）此时新生代至少分配到20G的大内存，Eden区会占据16G以上

（4）每秒大概会加载内存中几百MB的数据，大概几十秒，就会填满Eden

（5）Young GC。大内存下速度会很慢，此时导致系统卡顿几百毫秒或者1秒。导致很多请求积压，影响前端请求超时

对GC设置一个预期的GC停顿时间，比如100ms，让G1保障每个Young GC的时候最多停顿100ms，避免影响中断用户的使用

JVM参数

示例程序

GC日志

（1）数据计算系统，日处理数据量在上亿的规模

（2）不停的从MySQL数据库以及其他数据源里提取大量的数据加载到自己的JVM内存里来进行计算处理

（3）每分钟大概需要执行500次数据提取和计算的任务

（4）分布式运行的系统。所以生产环境部署了多台机器，每台机器大概每分钟负责执行100次数据提取和计算的任务

（5）每次会提取1w左右的数据到内存进行计算，平均每次计算大概花费10s

（6）每台机器4核8G，JVM4G，新生代和老年代分别1.5G

Young GC

Full GC

系统问题

解决方案

分析

解决方案

JVM参数

示例代码

GC日志

JVM优化

新GC日志分析

（1）每秒几十万QPS（Query Per Second，每秒钟的查询数量）的社交APP

（2）因为这个社交APP的日用用户涨的很快，所以导致他的高峰期QPS很快就飙升到了10w，导致这个系统在高峰期的时候，年轻代的Eden区会迅速的填满，并且频繁触发Young GC

（3）YoungGC的时候，实际上有很多请求是没处理完毕的，因为每秒请求量太多了。导致有很多对象是需要存活下来的，但是Survivor区却放不下。导致大量对象快速进入老年代

（4）老年代频繁触发GC

核心优化点：增加机器，经理让每台机器承载更少的并发请求，减轻压力；同时给年轻代的Survivor区域更大的内存空间，让每次Young GC后的存活兑现停留在Survivor中，别进入老年代。

关键参数

在5次Full GC的过程中，每一次Full GC之后都会产生大量的内存碎片，提高了Full GC的频率

优化方案

（1）一个垂直电商App，专门做某个细分领域的。

（2）百万注册量，日活几十万，日APP的整体请求量小几千万级别，高峰期QPS每秒几百。

（3）高峰期Full GC每小时会发生好几次。Full GC一般正常情况下，都是以天为单位发生的，比如每天一次，或者是几天一次

作用：基本保证JVM性能别太差

参数设置

-XX:+CMSParallellnitialMarkEnabled

-XX:+CMSScavengeBeforeRemark

设置了一个奇怪的JVM参数，导致线上频率的Full GC报警

 

（1）这频繁的Full GC，实际上是JDK1.8以后的Metadata元空间数据区导致的，元空间一般是放一些加载到JVM里去的类。

（2）查看Metaspace内存占用情况

（1）在系统运行过程中，不停的有新的类被加载到Metaspace区域里，然后不停的把Metaspace区域占满，接着触发一次Full GC回收掉Metaspace区域中的部分类。整个过程循环

（2）判断什么类不停的被加载

（3）日志

（4）频繁加载奇怪类的原因

（5）解决方案

JVM性能表现如下

综合分析

JVM参数

（1）每分钟发生3次Young GC，说明平均20s就会让Eden区满，也就是差生300多MB独享，平均每秒产生15~20MB的对象

（2）每小时2次Full GC，所以每30分钟触发一次Full GC，根据-XX:CMSInitiatingOccupancyFraction=68设置，应该在老年代有600多MB时触发一次Full GC，所以系统运行30分钟就导致老年代有600多MB的对象触发了Full GC。

（3）一次Young GC耗时50毫秒

（4）一次Full GC耗时300多毫秒

（1）使用jstat观察JVM实际运行的情况，通过观察，每次Young GC过后升入老年代的对象很少。

（2）观察到现象，不知道为什么，突然有几百MB对象会占据在老年代。分析后是大对象

（1）定位系统的大对象

（2）优化

每秒都在执行Full GC，每次都耗时几百毫秒

JVM各个内存区域的使用了基本上没有什么问题，年轻代增长的不快，老年代才占用了10%，永久代也只使用了20%

每次执行都会指挥JVM去尝试执行一次Full GC，连带年轻代、老年代、永久代都进行回收。

禁止显示执行GC，不准通过代码触发GC

需要给所有用户发短信、邮件、APP push消息，吸引用户登录APP来参与，数据库、缓存和机器的资源都是足够的，但是CPU使用率飙升，导致系统几乎陷入卡死的状态。

线上系统的机器CPU负载过高的两个常见的场景

（1）使用排除法进行排查

（2）排查频繁Full GC的问题

（3）导出一份内存快照

（4）使用MAT工具进行分析

进过排查，发现是系统做了一个JVM本地的缓存，将很多数据都加载到内存里去缓存起来，然后提供查询服务的时候走本地内存，但是由于没有限制本地环境的大小，也没有使用LRU算法淘汰内存的数据，到时数据越来越多，造成内存泄漏

使用类似EHCache之类放的缓存框架，可以固定缓存多少个对象，同时定期淘汰删除掉一些不怎么样访问的环境，便于新数据进入缓存

线上系统进行一次版本升级，结果升级后系统对应的前端页面无法访问了。通过监控报警平台，发现线上系统所在机器的CPU负载非常高，持续走高，导致机器宕机

通过监控和jstat分析，发现Full GC非常频繁，基本上两分钟一次Full GC，而且每次Full GC都非常耗时，长达10s

（1）这个系统主要是用来进行大量数据处理后然后提供数据给用户看的，所以当时给JVM的堆分配了20G的内存，10G给年轻代，10G给老年代

（2）由于年轻代过大，Eden大概1分钟左右会被塞满，然后触发一次Young GC，而且Young GC过后直接有几个GB的对象直接进入老年代

（3）说明系统运行的时候产生了大量的对象，而且处理的极慢，在1分钟过后Young GC以后还有很多对象存活，导致直接进入老年代

（4）平均两分钟就会触发一次Full GC，而且由于老年代内存量很大，所以GC时间长达10s

（1）由于每次Young GC后有几个G的大量对象存活，所以这明显是代码层面的问题了，必须要去优化代码，避免代码层面加载过多的数据到内存里去处理。

（2）通过MAT定位代码

（3）分析String.split()为什么造成内存泄漏

（4）代码优化

代码

jps查询PID

导出内存快照

MAt分析内存快照

（1）一个非常复杂的PB级数据计算系统。需要不停的从数据存储中加载大量的数据到内存里来进行复杂的计算 。每次少则几十万条，多则上百万条数据，内存负载压力非常大。

（2）在系统将数据计算完之后，需要将计算好的数据推送给另外一个系统，两个系统之间的数据推送和交互使用Kafka实现。

（3）考虑到数据计算系统要推送计算结果到Kafka去，必须设计一个针对Kafka的故障高可用机制

在Kafka故障时，将一次计算的数据留存在内存里，不停的重试，知道Kafka恢复才可以。导致内存数据越来越多，每次Eden塞满之后，大量存活队形进入老年代且无法回收，造成内存溢出。

背景

问题

背景

问题

解决方案

每秒仅有100+请求的系统却频繁的因为OOM而崩溃

（1）发现了系统OOM，查看对应的日志

（2）使用MAT对内存快照进行分析

（3）通过系统监控发现每秒请求不是400，是100，所以不可能是Tocmat的400个线程都处于工作状态，那就只能是一个请求需要处理4s导致的，在4s里会瞬间有400个请求同时在处理

（4）为什么Tocmat工作线程在处理一个请求的时候会创建2个10MB的数组

每秒100个请求，每个请求处理4s，导致4s内有400个请求被400个线程处理，每个线程根据配置创建2个数组，每个数组10MB，占满了8G

（5）为什么一个请求需要4s

降低超时时间

tomcat工作流程

Tomcat底层原理

原理图

（1）溢出类型是什么（堆内存溢出、栈内存溢出、Metaspace内存溢出）

（2）哪个线程运行代码的时候内存溢出了

-XX:+HeapDumpOnOutOfMenmoryError

使用Jetty作为Web服务器的时候，在某个非常罕见的场景下发生的一次堆外内存溢出的场景

（1）收到线上的一个报警：某台机器部署的一个服务突然之间不可以访问了。然后登录机器看日志，发现如下信息

（2）通过日志发现有OOM异常，但是是Direct buffer memory区域，而且下面还有一大堆的jetty相关的方法调用栈

（1）这次OOM是Jetty这个Web服务器在使用堆外内存的时候导致的

（2）如果创建了很多DirectByteBuffer对象，占用了大量的堆外内存，而且没有GC线程来回收，就会发生内存溢出

（3）创建大量DirectByteBuffer的可能性

（4）使用jstat等工具观察线上系统的实际运行情况，同时根据日志看一下请求的处理耗时，综合性的分析

本次问题有两个

（1）合理分配内存，给年轻代更多的内存，让Survivor有更多的空间

（2）开放-XX:+DisableExplicitGC，使System.gc()生效

Direct buffer memory

jetty

解决OOM问题的底层技术修为的建议

堆外内存是如何申请和释放的

Java NIO的处理

发生在微服务架构下的一次RPC调用过程中的OOM。

一般线上系统OOM，都不是简单的由自己编写的代码导致，可能是因为系统使用的某个开源技术的内核代码有一定的故障和缺陷，此时要解决OOM问题，就必须深入到开源技术的源码中去分析。

早期的系统，在进行服务间的PRC通信时，采用的是基于Thrift框架自己封装出来的一个RPC框架。

平时服务A通过RPC框架去调用服务B，但是有一天，负责服务A的工程师更新了一些代码，然后将服务A重新上线，服务A没有任何问题，但是服务B宕机了

（1）登录到服务B的机器查看服务B的日志，发现了OOM异常：java.lang.OutOfMemoryError Java heap space。堆内存溢出

（2）尝试重启，发现很快fuwuB又宕机了，而且还是因为OOM。但是服务B是没有动过得，只是改过服务A的代码。

（3）查找内存溢出的故障发生点

（4）分析内存快照，找到占用内存最大的对象

（5）分析源代码找出原因

（1）将RPC框架中那个数组的默认值从4GB调整到4MB，一般请求都不会超过4MB

（2）同步服务A和服务B的Request类保持一致

服务A发送请求的时候，会对传输过来的对象进行序列化。类似Reqeust的对象变成一个byte[]数组

服务B会根据我们自定义的序列化协议（Protobuf）对发送过来的数组进行反序列化，接着把请求数据读取到一个byte[]缓存中去，然后调用业务逻辑代码处理请求，最后请求处理完毕，清理byte[]缓存。

流程图

RPC框架要进行对象传输，就必须要让服务A和服务B都知道有这么一个对象。

系统在使用mybatis写SQL语句的时候，在某些情况下允许不加where条件就可以执行，结果导致一下子查询出来上百万条数据引发了系统的OOM

（1）收到反馈说线上一个系统崩溃不可用了，此时立即登录到线上机器去查看日志，日志中发现了OOM的异常：java.lang.OutOFMemoryError, java heap space。堆内存溢出

（2）把自动导出的内存快照拷贝到自己电脑，用MAT进行分析

（1）检查内存中到底是什么对象太多了

（2）深入查看占用内存过多的对象

（3）定位到代码，哪些代码创建了这些对象

通过上述步骤，立马定位到了是系统中的一个业务方法，在执行查询操作的时候，因为没有带上where条件，导致查询出来过多数据，造成OOM

修改SQL语句，带上where条件

如果系统触发OOM是由于Tomcat、Jetty、RPC框架之类的底层技术，那么MAT的用处并没有那么大，最多是使用MAT查找占用过多的对象，然后结合异常日志调用栈和MAT中的对象引用情况，初步定位是底层技术中心哪部分代码导致的内存溢出。真正解决问题，需要仔细研究Tocmat、Jetty、RPC框架之类技术的底层源码，结合线上系统的负载情况、访问压力以及GC情况，以及底层技术的源码细节，真正分析清楚发生OOM的原因，才能解决。

如果是自己的系统代码问题导致的，值需要依托MAT层层分析，定位到代码的问题所在，就可以进行解决了

一个每天10亿数据量的日志清洗系统，他主要是从Kafka中不停地消费各种日志数据，然后对日志的格式进行清洗，比如设计到用户敏感的字段（姓名、手机号、身份证号码）进行脱敏处理，然后将清洗后的数据交付给其他的系统去使用

（1）发现日志清洗系统发生了OOM的异常，查看日志发现是java.lang.OutOfMemoryError: java heap space的问题，堆内存溢出

（2）发现XXXCalss.process()方法反复出现，导致了堆内存溢出的问题，初步判定是出现大量的递归

内存快照分析

分析JVM的GC日志

分析JVM运行时的内存使用模型

（1）增加堆内存

（2）改写代码

（1）先通过OOM的排查方法去分析，发现因为内存调小导致

（2）然后用GC日志和jstat分析，明显发现是内存不够用

（3）优化JVM参数和代码即可

（1）一个非常正常的线上服务，采用Web系统部署在Tomcat中的方式来启动

（2）收到反馈，服务不稳定，经常出现访问服务的接口的时候假死问题。相当于服务不可用。但是是一段时间内无法访问这个服务的接口，果断时间又可以了

（1）使用top命令检查机器资源使用

（2）分析内存使用这么高下可能出现的情况

（3）排查高内存对象

（4）结论：代码中没有限制的创建了大量的自定义类加载器，去重复加载了大量的数据，导致内存耗尽，进程被杀掉

修改代码，避免重复创建几千个自定义类加载器，避免重复加载大量的数据到内存

处理可以加载类之外，还可以用来加载一些其他的资源，比如外部配置文件

一个线上的数据同步系统，专门负责从另外一个系统去同步数据，另外一个系统会不停的发布自己的数据到Kafka中，然后这个系统专门从Kafka里去消费数据，接着保存到自己的数据库中去

时不时报内存溢出的错误，重启一段时间后又会再次出现，随着系统处理的数据量越来越多，频率越来越高

（1）每次重启后在一段时间之后OOM，所以内存是不断的上涨的。一般高到JVM内存溢出，通常两种情况

（2）分析了当时的系统，负载并不高，所以应该是随着时间推移，某种对象越来越多，赖在内存，无法回收掉，导致内存溢出

（3）使用jstat分析

（4）使用MAT查找大对象

将内存队列改为一个定长的阻塞队列，比如1024个元素，然后每次消费出来的数据，一条一条的吸入，而不是直接将list作为一个元素

发生OOM时

优化后

（1）Eden和2个Survivor，默认比例8:1:1

（2）写好的系统会不停的运行，运行的时候不停的在年轻代的Eden区域中创建对象

（3）一般创建对象都是咋一个钟方法里执行，一旦方法运行完毕，方法局部变量引用搞得对象会成为Eden的垃圾对象，可以被回收

（4）随着Eden不断创建对象，被塞满，触发一次Young GC，Young GC采用复制算法，从GC Roots（方法的局部变量、类的静态变量）开始追踪，标记出来存活的对象，然后把存活对象放入第一个Survivor区域，然后直接回收掉Eden区的全部垃圾对象，垃圾回收过程中，系统进入Stop the World（系统代码停止运行，不允许创建新的对象）

（5）Young GC执行完毕，系统恢复工作，继续在Eden区创建对象，如果下次Eden塞满，再次触发Young GC，Eden + s0的存活对象放入s1

（6）Young GC垃圾回收器很多，常用的是ParNew，基于多线程并发执行垃圾回收

对象进入老年代的时机

老年代如何触发GC

Full GC触发的条件

频繁Full GC的问题

（1）估算一下系统每隔核心接口每秒多少次请求，每次请求会创建多少个对象，每个对象多大，每秒会使用多少内存空间

（2）估算多久会发生一次Young GC，会有多少对象存活，会有多少对象升入老年代，以及老年代对象增长的速率，多久会触发Full GC

原则：尽可能让每次Young GC后存活对象远远小于Survivor区域，避免对象频繁进入老年代触发Full GC

使用jstat等工具观察JVM的运行内存模型

针对结果，尽可能优化JVM的内存分配，尽量避免对象频繁进入老年代，尽量让系统仅有Young GC

使用Zabbix、Open-Falcon之类的工具来监控，频繁Full GC就报警。或者使用jstat，每天定时检查

一旦发现频繁Full GC就进行优化，优化思路：通过jstat分析处理系统的JVM运行指标，找到Full GC的核心问题，然后优化JVM参数，尽量让对象别进入老年代，减少Full GC的频率

第一种：合理分配内存，调大Survivor

第二种、第三种：利用MAT工具分析，找出来哪些对象占用内存过多，然后通过一些对象的引用和线程执行堆栈的分析，找到代码，进行代码优化

第四种、第五种，对应的进行优化