JVM思维导图-待整理版本

什么时候会初始化一个类？

线程执行了一个方法，就会对这个方法调用创建对应的一个栈帧

栈帧里就有这个方法的局部变量表 、操作数栈、动态链接、方法出口等

比如对象头，如果在64位的linux操作系统上，会占用16字节，<br>然后如果你的实例对象内部有个int类型的实例变量，他会占用4个字节，<br>如果是long类型的实例变量，会占用8个字节。<br>如果是数组、Map之类的，那么就会占用更多的内存了<br><br>优化: 补齐机制、指针压缩机制<br>

类在方法区，他在内存里，所以你必须给他初始化，赋值

好处就在于，每个层级的类加载器各司其职，而且不会重复加载一个类。

还有一些安全性的问题,比如只有 启动类加载器才能加载String类等受保护的资源.

一旦新生代快满了，那么垃圾回收的时候

[ 可达性分析 ] 算法来判定哪些对象是可以被回收的，哪些对象是不可以被回收的。

只要你的对象被方法的局部变量、类的静态变量给引用了，就不会回收他们。

强引用

弱引用

虚引用

有GC Roots引用的对象不能回收，没有GC Roots引用的对象可以回收，如果有GC Roots引用，但是如果是软引用或者弱引用的，也有可能被回收掉。

假设有一个对象要被垃圾回收了，那么假如这个对象重写了Object类中的finialize()方法<br>此时会先尝试调用一下他的finalize()方法，看是否把自己这个实例对象给了某个GC Roots变量，<br>比如说代码中就给了某个类的静态变量。<br>如果重新让某个GC Roots变量引用了自己，那么就不用被垃圾回收了。<br>

短期存活的，分配在Java堆内存之后，迅速使用完就会被垃圾回收

长期存活的，需要一直生存在Java堆内存里，让程序后续不停的去使用

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

假设每天100万个支付订单，那么一般用户交易行为都会发生在每天的高峰期，比如中午或者晚上。

假设每天高峰期大概是几个小时，用100万平均分配到几个小时里，那么大概是每秒100笔订单左右，咱们就以每秒100笔订单来计算一下好了

假设我们的支付系统部署了3台机器，每台机器实际上每秒大概处理30笔订单。

如果用户发起一次支付请求，那么支付需要在JVM中创建一个支付订单对象，填充进去数据，然后把这个支付订单写入数据<br><br>库，还可能会处理一些其他的事情咱们就假设一次支付请求的处理，包含一个支付订单的创建，大概需要1秒钟的时间

那么大体上你的脑子里可以出现的一个流动的模型，应该是每台机器一秒钟接收到30笔支付订单的请求，然后在JVM的新生代<br><br>里创建了30个支付订单的对象，做了写入数据库等处理

接着1秒之后，这30个支付订单就处理完毕，然后对这些支付订单对象的引用就回收了，这些订单在JVM的新生代里就是没人<br><br>引用的垃圾对象了。

接着再是下一秒来30个支付订单，重复这个步骤。

直接根据支付订单类中的实例变量的类型来计算就可以了。

比如说支付订单类如下所示，<br>你只要记住一个Integer类型的变量数据是4个字节，<br>Long类型的变量数据是8个字节，<br>还有别的类型的变量数据占据多少字节<br>

比如支付订单这种核心类，你就按20个实例变量来计算，然后一般大概一个对象也就在几百字节的样子

我们算他大一点好了，就算一个支付订单对象占据500字节的内存空间，不到1kb。

假设有3台机器，每秒钟处理30笔支付订单的请求，那么在这1秒内，大家都知道，肯定是有方法里的局部变量在<br>引用这些支付订单的

那么30个支付订单，大概占据的内存空间是30 * 500字节 = 15000字节，大概其实也就15kb而已。其实是非常非常小的。

每秒30个支付请求，创建30个支付订单对象，也就占据kb级别的内存空间而已

然后接着1秒过后，这30个对象就没有人引用了，就成了新生代里的垃圾了。

下一秒请求过来，我们的系统持续的创建支付订单对象，不停在新生代里放入30个支付订单，然后新生代里的对象会持续的累积和增加。

直到有一刻，发现可能新生代里都有几十万个对象了，此时占据了几百MB的空间了，可能新生代空间就快满了

然后就会触发Minor GC，就把新生代里的垃圾对象都给回收掉了，腾出内存空间，然后继续来在内存里分配新的对象。

真实的支付系统线上运行，肯定每秒会创建大量其他的对象，但是我们结合这个访问压力以及核心对象的内存占据，<br>大致可以来估算一下整个支付系统每秒钟大致会占据多少内存空间<br>

其实如果你要估算的话，可以把之前的计算结果扩大10倍~20倍。<br>也就是说，每秒钟除了在内存里创建支付订单对象，还会创建其他数十种对象<br>

那么每秒钟创建出来的被栈内存的局部变量引用的对象大致占据的内存空间就在几百KB~1MB之间。

然后下一秒继续来新的请求创建大概1MB的对象放在新生代里，接着变成垃圾，再来下一秒

循环多次之后，新生代里垃圾太多，就会触发Minor GC回收掉这些垃圾。这就是一个完整系统的大致JVM层面的内存使用模型。

常见的机器配置是2核4G，或者是4核8G。

机器采用4核8G，然后-Xms和-Xmx设置为3G，给整个堆内存3G内存空间，-Xmn设置为2G，给新生代2G内存空间。

假设你的业务量如果更大，你可以考虑不只部署3台机器，可以横向扩展部署5台机器，或者10台机器，这样每台机器处理的请求更少，对JVM的压力更小。

内存不足,满足不了瞬时创建对象的需求, 导致 OOM

大促期间，瞬时访问量增加十倍

少数请求需要几十秒处理，导致老年代内存占用变大

老年代对象越来越多导致频繁垃圾回收

一般也不会特别的去预估和设置的，一般默认就是比如512KB到1MB

案例背景引入

特殊的电商大促场景

抗住大促的瞬时压力需要几台机器？

大促高峰期订单系统的内存使用模型估算

内存到底该如何分配？

新生代垃圾回收优化之一：Survivor空间够不够

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

多大的对象直接进入老年代？

别忘了指定垃圾回收器

什么时候对象会进入老年代？

大促期间多久会触发一次Full GC？

老年代GC的时候会发生“Concurrent Mode Failure”吗？

-Xms3072M <br>-Xmx3072M <br>-Xmn2048M <br>-Xss1M <br>-XX:PermSize=256M ===&gt; [ 替换 MetaspaceSize 元空间 ] <br>-XX:MaxPermSize=256M ===&gt; [ 替换 MaxMetaspaceSize 元空间 ] <br>-XX:SurvivorRatio=8 <br>-XX:MaxTenuringThreshold=5 <br>-XX:PretenureSizeThreshold=1M <br>-XX:+UseParNewGC <br>-XX:+UseConcMarkSweepGC <br>-XX:CMSInitiatingOccupancyFaction=92<br>-XX:+UseCMSCompactAtFullCollection<br>-XX:CMSFullGCsBeforeCompaction=0<br><br><br>

默认

Full GC优化的前提是Minor GC的优化，<br>Minor GC的优化的前提是合理分配内存空间，<br>合理分配内存空间的前提是对系统运行期间的内存使用模型进行预估<br>

核心点就是搞明白在晚上两三小时高峰期内，每秒钟会有多少请求，每个请求会连带产生多少对象，占用多少内存，每个请求要处理多长时间。

比如说晚上3小时高峰期内有总共60万活跃用户，平均每个用户大概会使用1小时左右来上课，那么每小时大概会有20万活跃用户同时在线学习。

这20万活跃用户因为需要进行大量的互动操作，所以大致可以认为是每分钟进行1次互动操作，一小时内会进行60次互动操作

那么20万用户在1小时内会进行1200万次互动操作，平均到每秒钟大概是3000次左右的互动操作，这是一个很合理的数字。

那么每秒钟要承载3000并发请求，<br>根据经验来看，一般系统的核心服务需要部署5台4核8G的机器来抗住是差不多的，<br>每台机器每秒钟抗个600请求，这个压力可以接受，一般不会导致宕机的问题。<br>

那么每个请求会产生多少个对象呢？

接着我们来看看G1垃圾回收器的默认内存布局，之前说过我们采用的是4核8G的机器来部署系统，然后每台机器每秒会有600个请求会占用3MB左右的内存空间

那么假设我们对机器上的JVM，分配4G给堆内存，其中新生代默认初始占比为5%，最大占比为60%，每个Java线程的栈内存为1MB，<br>元数据区域（永久代）的内存为256M，此时JVM参数如下：<br>“-Xms4096M -Xmx4096M -Xss1M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseG1GC“<br>

“-XX:MaxGCPauseMills”，他的默认值是200毫秒

有一个问题，就是系统运行起来之后，会不停的在新生代的Eden区域内分配对象，按照之前的推算是每秒分配3MB的对象

“-XX:G1MaxNewSizePercent”参数限定了新生代最多就是占用堆内存60%的空间

他会根据你预设的gc停顿时间，给新生代分配一些Region，然后到一定程度就触发gc，<br>并且把gc时间控制在预设范围内，尽量避免一次性回收过多的Region导致gc停顿时间超出预期。<br>

对于G1而言，我们首先应该给整个JVM的堆区域足够的内存，比如我们在这里就给了JVM超过5G的内存，其中堆内存有4G的内存。

应该合理设置“-XX:MaxGCPauseMills”参数

老年代在堆内存里占比超过45%就会触发。

年轻代的对象进入老年代的几个条件

一旦老年代频繁达到占用堆内存45%的阈值，那么就会频繁触发mixed gc。

尽量避免对象过快进入老年代，尽量避免频繁触发mixed gc，就可以做到根本上优化mixed gc了

核心:&nbsp;“-XX:MaxGCPauseMills”

Minor GC : 无STW

无内存碎片

对内存的使用效率太低了

-XX:MaxTenuringThreshold”来设置，默认是15岁

假如说当前放对象的Survivor区域里，一批对象的总大小大于了这块Survivor区域的内存大小的50%，那么此时大<br><br>于等于这批对象年龄的对象，就可以直接进入老年代了

年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n以上的对象都放入老年代。

“-XX:PretenureSizeThreshold”，可以把他的值设置为字节数，比如“1048576”字节，就是1MB。

这个时候就必须得把这些对象直接转移到老年代去

发现老年代的可用内存已经小于了新生代的全部对象大小了，就会看一个“-XX:-HandlePromotionFailure”的参数是否设置了

如果有这个参数，那么就会继续尝试进行下一步判断。

下一步判断，就是看看老年代的内存大小，是否大于之前每一次Minor GC后进入老年代的对象的平均大小

此时就会直接触发一次“FullGC”，就是对老年代进行垃圾回收，尽量腾出来一些内存空间，然后再执行Minor GC。

要不然是在Minor GC之前，一通检查发现很可能Minor GC之后要进入老年代的对象太多了，老年代放不下，此时需要提前触发Full GC然后再带着进行Minor GC

要不然是在Minor GC之后，发现剩余对象太多放入老年代都放不下了

标记整理算法 ???

每条数据包含了平均20个字段，可以认为平均每条数据在1KB左右的大小。那么每次计算任务的1万条数据就对应了10MB的大小。

1.G堆内存 新生代是按照8:1:1的比例来分配Eden和两块Survivor的区域，那么大体上来说，Eden区就是<br>1.2GB，每块Survivor区域在100MB左右

每次执行一个计算任务，就会在Eden区里分配10MB左右的对象，那么一分钟大概对应100次计算任务

正在运行的任务对象会进入老年代.

Serial和Serial Old垃圾回收器：分别用来回收新生代和老年代的垃圾对象

ParNew和CMS垃圾回收器：

G1垃圾回收器

Serial垃圾回收器就是用一个线程进行垃圾回收，然后此时暂停系统工作线程，所以一般我们在服务器程序中很<br><br>少用这种方式。

ParNew 他针对服务器一般都是多核CPU做了优化，他是支持多线程个垃圾回收的，可以大<br><br>幅度提升回收的性能，缩短回收的时间

CMS垃圾回收器，专门负责老年代的垃圾回收

假设1分钟100个计算任务，每个计算任务是10秒钟，在60秒到来的那一刻，只有50-60秒开始执行的<br><br>计算任务是没有执行完毕的，占比1/6,100 / 6 = 16.66 。 所以可以大致估算还有20个计算任务还在计算中。

ParNew垃圾回收器如果一旦在合适的时机执行Minor GC的时候，就会把系统程序的工作线程全部停掉，<br>禁止程序继续运行创建新的对象，然后自己就用多个垃圾回收线程去进行垃圾回收，回收的机制和算法就跟之前说的是一样的<br>

-XX:+UseParNewGC

ParNew垃圾回收器默认情况下的线程数量

"标记清理" 算法

垃圾回收线程和系统工作线程尽量同时执行的模式来处理的。

CMS在执行一次垃圾回收的过程一共分为4个阶段：

对CMS的垃圾回收机制进行性能分析

第一是 新生代空间不足, Minor GC 前 . 老年代可用内存小于新生代全部对象的大小，如果没开启空间担保参数，会直接触发Full GC，所以一般空间担保参数都会打开

第二是 新生代空间不足, Minor GC 前 . 老年代可用内存小于历次新生代GC后进入老年代的平均对象大小，此时会提前Full GC；

第三是新生代Minor GC后的存活对象大于Survivor，那么就会进入老年代，此时老年代内存不足。

第四 大对象直接进入老年代

第五&nbsp;CMSInitiatingOccupancyFraction

机器CPU负载过高

频繁FULL GC报警

系统无法处理请求或者处理过慢

系统承载高并发请求或者处理数据量过大,导致Young GC频繁, <br>而且每次Young GC过后存活对象过多,内存分配不合理.Survivor区域过小,导致对象频繁进入老年代,频繁触发FULL GC<br>

系统一次性加载过多的数据进内存,产生很多大对象,导致频繁有大对象进入老年代,导致FULL GC

发生内存泄漏,莫名创建大量对象,始终无法回收,一直占用老年代内存, 导致FULL GC

jstat 发现内存使用并不多,频繁触发GC

新生代执行速度其实很快，因为直接从GC Roots出发就追踪哪些对象是活的就行了，新生代存活对象是很少的，这个速度是极快的，<br><br>不需要追踪多少对象。

然后直接把存活对象放入Survivor中，就一次性直接回收Eden和之前使用的Survivor了。

在并发标记阶段，他需要去追踪所有存活对象，老年代存活对象很多，这个过程就会很慢；

其次并发清理阶段，他不是一次性回收一大片内存，而是找到零零散散在各个地方的垃圾对象，速度也很慢；

最后完事儿了，还得执行一次内存碎片整理，把大量的存活对象给挪在一起，空出来连续内存空间，这个过程还得“Stop theWorld”，那就更慢了。

万一并发清理期间，剩余内存空间不足以存放要进入老年代的对象了，引发了“Concurrent Mode Failure”问题，那更是麻烦，还得<br><br>立马用“Serial Old”垃圾回收器，“Stop the World”之后慢慢重新来一遍回收的过程，这更是耗时了。

因为反射的对象会创建软引用

如果这个参数设置为0的话,会导致metaspace可能会被迅速填满,造成Full GC

在新生代的Eden区域满了之后就会触发，采用复制算法来回收新生代的垃圾

（1）发生Young GC之前进行检查，如果“老年代可用的连续内存空间” &lt; “新生代历次Young GC后升入老年代的对象<br><br>总和的平均大小”，说明本次Young GC后可能升入老年代的对象大小，可能超过了老年代当前可用内存空间<br><br>此时必须先触发一次Old GC给老年代腾出更多的空间，然后再执行Young GC

（2）执行Young GC之后有一批对象需要放入老年代，此时老年代就是没有足够的内存空间存放这些对象了，此时必<br><br>须立即触发一次Old GC

（3）老年代内存使用率超过了92%，也要直接触发Old GC，当然这个比例是可以通过参数调整的

三个条件你概括成一句话，就是老年代空间也不够了，没法放入更多对象了，这个时候务必执行Old<br>GC对老年代进行垃圾回收

&nbsp; (4) Metaspace 空间占满

Old GC执行的时候一般都会带上一次Young GC

在上述几种条件达到的时候，他触发的实际上就是Full GC，这个Full GC会包含Young GC、Old GC和永久代的GC<br>说触发Full GC的时候，可能就会去回收年轻代、老年代和永久代三个区域的垃圾对象<br>

在上述几种条件达到的时候，他触发的实际上就是Full GC，这个Full GC会包含Young GC、Old GC和永久代的GC<br>说触发Full GC的时候，可能就会去回收年轻代、老年代和永久代三个区域的垃圾对象<br>

CMSParallelRemarkEnabled

CMSScavengeBeforeRemark

1.Metaspace 空间

2. 虚拟机栈内存

3.堆内存空间

-server<br>-Xms4096M <br>-Xmx4096M <br>-Xmn3072M <br>-Xss1M <br>-XX:PermSize=256M ===&gt; [ 替换 MetaspaceSize 元空间 ] <br>-XX:MaxPermSize=256M ===&gt; [ 替换 MaxMetaspaceSize 元空间 ] <br>-XX:+UseParNewGC <br>-XX:+UseConcMarkSweepGC<br>-XX: CMSInitiatingOccupancyFraction =92<br>-XX:UseCMSInitiatingOccupancyOnly<br>-XX:+UseCMSCompactAtFullCollection<br>-XX:CMSFullGCsBeforeCompaction=0<br>-XX:+CMSParallelInitialMarkEnabled<br>-XX:+CMSScavengeBeforeRemark<br>-XX:+CMSParallelRemarkEnabled<br>-XX:+PrintHeapAtGC<br>-XX:DisableExplicitGC<br>-XX:PringGCDetails<br>-Xloggc:gc.log<br>-XX:+HeapDumpOnOutOfMemoryError <br>-XX:HeapDumpPath=/app/logs/log_hprof/gc.hprof <br><br>----------下面的参数看情况----------<br>-XX:SurvivorRatio=8 <br>-XX:MaxTenuringThreshold=5 <br>-XX:PretenureSizeThreshold=1M <br><br>-XX:LargePageSizeInBytes=128m <br>-XX:+UseFastAccessorMethods&nbsp;<br>-XX:MaxDirectMemorySize=40M<br>

java -XX:+PrintFlagsFinal -version | grep UseFastAccessorMethods<br>

禁止手动回收GC&nbsp;

DirectByteBuffer 使用的时候垃圾回收会出问题,可以会导致OOM&nbsp; : Direct buffer memory

希望G1在垃圾回收的时候，可以保证，在1小时内由G1垃圾回收导致的“Stop the World”时间，<br>也就是系统停顿的时间，不能超过1分钟

其实我们对内存合理分配，优化一些参数，就是为<br>了尽可能减少Minor GC和Full GC，尽量减少GC带来的系统停顿，避免影响系统处理请求。

直接可以给G1指定，在一个时间内，垃圾回收导致的系统停顿时间不能超过多久，G1全权给你负责，保证达到这个目标

相当于我们就可以直接控制垃圾回收对系统性能的影响了

刚开始的时候，默认新生代对堆内存的占比是5%，也就是占据200MB左右的内存，<br>对应大概是100个Region，这个是可以通过“-XX:G1NewSizePercent”来设置新生代初始占比的，其实维持这个默认值即可<br>

因为在系统运行中，JVM其实会不停的给新生代增加更多的Region，但是最多新生代的占比不会超过60%，<br>可以通过“-XX:G1MaxNewSizePercent”。<br>

而且一旦Region进行了垃圾回收，此时新生代的Region数量还会减少，这些其实都是动态的。

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

接着会进入“并发标记”的阶段，这个阶段会允许系统程序的运行，同时进行GC Roots追踪，从GC Roots开始追踪所有的存活对象

这个并发标记阶段还是很耗时的，因为要追踪全部的存活对象。

但是这个阶段是可以跟系统程序并发运行的，所以对系统程序的影响不太大。

而且JVM会对并发标记阶段对对象做出的一些修改记录起来，比如说哪个对象被新建了，哪个对象失去了引用。

这个阶段会进入“Stop the World”，系统程序是禁止运行的，<br>但是会根据并发标记 阶段记录的那些对象修改，最终标记一下有哪些存活对象，有哪些是垃圾对象<br>

最后一个阶段，就是“混合回收“阶段，这个阶段会计算老年代中每个Region中的存活对象数量，存活对象的占比，还有执行垃圾回收的预期性能和效率。

接着会停止系统程序，然后全力以赴尽快进行垃圾回收，此时会选择部分Region进行回收，因为必须让垃圾回收的停顿时间控制在我们指定的范围内。

比如说老年代此时有1000个Region都满了，但是因为根据预定目标，本次垃圾回收可能只能停顿200毫秒，那么通过之前的计算得知，<br>可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region，把GC导致的停顿时间控制在我们指定的范围内<br>

其实老年代对堆内存占比达到45%的时候，触发的是“混合回收

一般在老年代的Region占据了堆内存的Region的45%之后，会触发一个混合回收的过程，也就是Mixed GC

在这里最后一个环节，其实就是执行混合回收，从新生代和老年代里都回收一些Region。

但是最后一个阶段混合回收的时候，其实会停止所有程序运行，所以说G1是允许执行多次混合回收

比如先停止工作，执行一次混合回收回收掉 一些Region，接着恢复系统运行，然后再次停止系统运行，再执行一次混合回收回收掉一些Region。

有一些参数可以控制这个，比如“-XX:G1MixedGCCountTarget”参数，就是在一次混合回收的过程中，最后一个阶段执行几次混合回收，默认值是8次

意味着最后一个阶段，先停止系统运行，混合回收一些Region，再恢复系统运行，接着再次禁止系统运行，混合回收一些Region，反复8次

假设一次混合回收预期要回收掉一共有160个Region，那么此时第一次混合回收，会回收掉一些Region，比如就是 20个Region(年轻代10个,老年代10个)。<br>接着恢复系统运行一会儿，然后再执行一次“混合回收”(年轻代10个,老年代10个)<br>如此反复执行8次混合回收阶段之后 ，不就把预订的160个Region都回收掉了？而且还把系统停顿时间控制在指定范围内。<br><br>

那么为什么要反复回收多次呢？

“-XX:G1HeapWastePercent”，默认值是5%

在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他<br>Region，然后这个Region中的垃圾对象全部清理掉

这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会 立即停止混合回收，意味着本次混合回收就结束了。

而且从这里也能看出来G1整体是基于复制算法进行Region垃圾回收的，不会出现内存碎片的问题，不需要像CMS那样标记-清理之后，再进行内存碎片的整理。

默认值是85%

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

否则要是一个Region的存活对象多余85%，你还回收他干什么？这个时候要把85%的对象都拷贝到别的Region，这个成本是很高的。

1. 内存使用率高,导致频繁full gc, gc带来的STW影响业务

2.内存使用率过多.导致JVM发生OOM

3.内存使用率过高,也许有的时候,导致这个进程因为申请内存不足,直接被操作系统把这个进程杀掉了