JVM实战高手

加载

连接

初始化

启动类加载器

扩展类加载器

应用类加载器

自定义类加载器

对于一个加载类的具体请求，首先要委派给自己的父类加载器去加载（直到传导给顶层的类加载器），如果父类加载器无法完成加载请求时子类加载器才会尝试加载，这就叫“双亲委派”

作用：
防止重复加载同一个“.class”

线程共享：堆空间、元数据区

线程私有：Java虚拟机栈、程序计数器、本地方法栈

https://blog.csdn.net/qq_43332570/article/details/113365866

对象在内存中的分布

-Xms4096M -Xmx4096M -Xmn3072M -Xss1M  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M 
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
-XX:CMSInitiatingOccupancyFaction=92 
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSScavengeBeforeRemark 
-XX:+DisableExplicitGC -XX:+PrintGCDetails -Xloggc:gc.log 
-XX:+HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=/usr/local/app/oom

JVM参数配置说明：
首先是各个内存区域的大小分配，这个是需要你精心调优的
其次是两种垃圾回收器的指定
接着是常规性的CMS垃圾回收参数，可以帮助优化偶尔发生的Full GC性能
然后就是要打印出GC日志，分析每次GC的具体情况
最后就是在OOM的时候需要自动dump内存快照

CMS垃圾回收器参数

2核4G机器
有点紧凑

4核8G机器

可达性分析法

Java引用类型

频繁垃圾回收问题

标记-清除算法
(最基础的收集算法)

标记-复制算法
(新生代)

标记-整理算法
(老年代)

垃圾回收算法应用

JDK 8中的垃圾收集器

Serial与Serial Old垃圾收集器

Parallel Scavenger与Parallel Old垃圾收集器

ParNew和CMS垃圾收集器

G1垃圾收集器

新生代对象进入老年代的4钟常见条件

老年代空间分配担保规则

老年代触发垃圾回收的时机

1. 将写好的“.java”代码打包编译成“.class”字节码文件
   
2. 使用诸如“java -jar”之类的命令来负责运行，使用“java”命令会启动一个JVM进程
   
3. 在JVM启动时或者类运行时，通过类加载器把“.class”字节码文件加载到JVM内存中
   
4. JVM基于字节码执行引擎，执行加载到内存中的那些类
   

1. 在编译时对字节码加密，或者做混淆处理
也有第三方公司做的商业级字节码文件加密

2. 然后在类加载时，采用自定义的类加载器解密文件即可

当你使用到某个类时，如“StringUtils”，此时就会从“.class”字节码文件中加载对应的类到JVM内存中

加载

连接

初始化

使用

卸载

启动类加载器

扩展类加载器

应用类加载器

自定义类加载器

什么意思呢？

作用：
防止重复加载同一个“.class”

双亲委派模型图示

拓展阅读：
JVM的双亲委派机制

思路：
1. Tomcat自定义了很多类加载器；
2. Tomcat打破了双亲委派机制，
    每个WebApp负责加载自己对应Web应用的class文件，
    不会传导给上层类加载器去加载

Tomcat类加载机制

栈空间（线程私有）
随着线程的创建而创建，随着线程的结束而死亡

堆空间（所有线程共享）

直接内存

堆外内存

一个对象对内存空间的占用，大致分为两块：
1. 一个是对象自己本身的一些信息
2. 一个是对象的实例变量作为数据占用的空间

1. 当方法里的代码执行完毕，那么方法就执行完毕了，
那么此时就会把方法对应的栈帧从当前线程的Java虚拟机栈里出栈

2. 一旦方法的栈帧出栈，那么那个栈帧里的局部变量也就没有了

没有任何方法的局部变量在引用某个实例对象，但是他还占着内存资源，那么我们应该怎么处理呢？

JVM的垃圾回收机制

方法区中的类会被回收，满足以下条件就可以被回收：
首先该类的所有实例对象都已经从Java堆内存中被回收；
其次加载这个类的ClassLoader已经被回收；
最后，对该类的Class对象没有任何引用

实例变量得在你创建类的实例对象时才会初始化

类的初始化阶段，仅仅是初始化类而已，跟对象无关，
用new关键字才会构造一个对象出来

其实栈帧出栈后，里面的局部变量直接就从内存中清理掉了。
另外，JVM中的垃圾回收针对的是新生代、老年代、方法区（永久代），不会针对方法的栈帧

大部分对象都是存活周期极短的

只有少数对象是长期存活在堆内存的

JVM将Java堆内存划分为了两个区域

为什么需要这么区分呢？

在JDK8之前的版本中，称其为永久代（方法区）

在JDK8以后，该区域叫“Metaspace”，即元空间

默认触发条件

新生代内存空间的垃圾回收，称之为“Minor GC”，
有的时候也叫“Young GC”

10多次垃圾回收之后，还没被回收掉，
那么它将被转移到Java堆内存的老年代中去

这个次数是可以通过参数配置的

答案是肯定的，也需要被垃圾回收

新生代垃圾回收之后，因为存活对象太多，导致大量对象直接进入老年代

特别大的超大对象直接不经过新生代就进入老年代

动态对象年龄判断机制

空间担保机制

-Xms：Java堆内存的大小

-Xmx：Java堆内存的最大大小

-Xmn：Java堆内存中的新生代大小，扣除新生代剩下的就是老年代的内存大小了

-XX:PermSize：永久代大小
-XX:MaxPermSize：永久代最大大小

-XX:MetaspaceSize：元空间大小
-XX:MaxMetaspaceSize：元空间最大大小

-Xss：每个线程的栈内存大小

java -Xms512M -Xmx512M -Xmn256M -Xss1M -XX:PermSize=128M -XX:MaxPermSize=128M -jar App.jar

Tomcat是在bin目录下的catalina.sh中加入JVM参数

Spring Boot可以在启动的时候加上JVM参数

系统的压力到底集中在哪里呢？

系统每秒钟需要处理多少笔支付订单?

每个支付订单处理要耗时多久？

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

每秒发起的支付请求需要占用多少内存？

前面的估算只是针对一个核心业务流程来分析的
其实真实系统运行中，肯定还会创建其他的对象，
可以根据实际情况将计算结果扩大10～20倍

2核4G机器
有点紧凑

4核8G机器

在系统高峰期，可能会出现系统请求处理缓慢，
然后导致新生代中积压了很多对象，回收缓慢，频繁触发 Young GC，多次 Young GC后对象被转移到老年代，
一旦老年代的对象越来越多，造成频繁触发老年代垃圾回收，极大的影响系统性能。

一般设置几百MB

一般默认就是比如512KB到1MB

栈内存什么时候会发生内存溢出

哪些对象可以回收，哪些对象不能回收呢？

可达性分析法

强引用

软引用
SoftReference

弱引用
WeakReference

虚引用
PhantomReference

把新生代划分为两块区域，使用其中一块区域存放对象，
当该区域快满发生垃圾回收时，将存活的对象复制到未使用的区域，
然后对之前的区域进行全部回收

这种方式内存空间使用率低，需要进行分区优化

分成一个Eden区，两个Survivor区，
默认比例为8:1:1

优点：内存空间利用率高，避免出现内存碎片

在进行Young GC前，首先会检查老年代最大可用连续空间是否大于新生代所有对象的总空间
（空间担保机制）

工作流程：
刚开始对象都分配在Eden区，如果Eden区快满了，触发Young GC，
此时会把Eden区存活的对象复制到空的Survivor0区，
接着清空Eden区，然后继续分配对象到Eden区，如果Eden区快满了，再次触发YoungGC，
此时会把Eden区和Survivor0区的存活对象，复制到Survivor1区，并清空Eden区和Survivor0区
就这样一直循环使用这三块区域

整个垃圾回收的过程中全程会进入Stop the Wold状态，也就是暂停系统工作线程

万一垃圾回收过后，存活下来的对象在另外一块Survivor区域中放不下咋整？

万一我们突然分配了一个超级大的对象，新生代找不到连续内存空间来存放，此时咋整？

到底一个存活对象要在新生代里这么来回倒腾多少次之后才会被转移都老年代去？

对象年龄

动态对象年龄判断

大对象直接进入老年代

Young GC后存活对象大于Survivor区内存空间，
部分对象进入Survivor区，其余存活对象就直接进入老年代

Young GC前，
检查老年代最大可用连续空间
是否大于
新生代所有对象的总空间

总而言之

Young GC前，检查老年代最大可用连续空间小于新生代所有对象的总空间，
并且没有开启空间担保机制，此时要直接触发Full GC
(但是一般情况下默认打开空间担保机制)

Young GC前，检查发现很可能Young GC之后要进入老年代的对象太多了（历次晋升老年代的平均值 > 老年代可用空间），
老年代可能放不下，此时需要提前触发Full GC，然后再进行Young GC（不满足空间担保规则）

Young GC后，发现剩余对象太多老年代放不下（空间担保失败）

到底什么时候会尝试触发Minor GC？

触发Young GC之前会如何检查老年代大小，涉及哪几个步骤和条件？

什么时候在Young GC之前就会提前触发一次Full GC？

Full GC的算法是什么？

Young GC过后可能对应哪几种情况？

哪些情况下Young GC后的对象会进入老年代？

G1收集器既可以收集年轻代的内存空间，也可以收集老年代的内存空间。
——《深入剖析Java虚拟机》（基础卷）

OpenJDK 8默认使用Parallel Scavenger与Parallel Old垃圾收集器

Serial收集器

Serial Old收集器

使用“-XX:+UseSerialGC”参数开启

ParNew收集器

CMS收集器

统一收集新生代和老年代

JDK9后默认的垃圾回收器

没有Full GC是有可能的，除非你做到几乎没什么对象进入老年代，那就自然不会触发Full GC

参见第三周答疑第一个

多线程垃圾回收器
能够充分利用服务器多核CPU的优势

使用“-XX:UseParNewGC”参数项

跟CPU核数一样
一般不用手动调节

使用“-XX:ParallelGCThreads”参数，也可以设置线程的数量

先将垃圾对象都标记出来，
然后一次性把垃圾对象回收掉

问题：会造成大量的垃圾碎片

初始标记

并发标记

重新标记

并发清理

并发回收垃圾导致的CPU资源紧张

Concurrent Mode Failure问题

内存碎片问题

触发老年代空间担保规则（三种情况），见第三部分 第三节

内存使用率超过92%，也需要直接触发Full GC
可以通过“-XX:CMSInitiatingOccupancyFaction”参数设置

单日上亿请求的电商系统
部署3台4核8G的机器

ParNew垃圾回收器的核心参数

结合系统运行模型，合理设置“-XX:MaxTenuringThreshold”，让长期存活的对象，尽快进入老年代

每秒占用多少内存？

多长时间触发一次Young GC？

一般Young GC后有多少存活对象，Survivor区能放的下吗？

会不会频繁因为Survivor区放不下导致对象进入老年代？

会不会因动态年龄判断规则进入老年代？

对象超过临界年龄

小概率情况下，存活对象超过Survivor区的50%

大对象

Young GC前，检查“老年代可用内存空间” < “历次Young GC后进入老年代的平均对象大小”

某次Young GC后存活对象太多，但是老年代可用内存空间不足

“-XX:CMSInitiatingOccupancyFaction”参数设置
老年代空间使用超过92%

Full GC优化的前提是Young GC的优化

Young GC的优化的前提是合理分配内存空间

合理分配内存空间的前提是对系统运行期间的内存使用模型进行预估

Stop the World

最大特点

如何做到对垃圾回收导致的系统停顿可控的？

Region可能属于新生代也可能属于老年代

G1是如何工作的？

对象什么时候进入新生代的Region？

什么时候触发Region GC？

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

什么时候触发老年代的Region GC？

到底有多少个Region呢？
每个Region的大小是多大呢？

新生代占比

新生代里还是有Eden和Survivor的划分的

可以通过“-XX:SurvivorRatio=8”参数来设置Eden区和Survivor区的比例

随着对象不停的在新生代里分配，属于新生代的Region会不断增加，
Eden和Survivor对应的Region也会不断增加。

触发新生代GC

复制算法来进行垃圾回收，并且系统进入“STW”状态

目标GC停顿时间

判断对象年龄

动态年龄判定规则

存活对象在Survivor区中放不下

G1提供了专门的Region来存放大对象

判断条件：对象是否超过了一个Region的50%

大对象如果太大，可能会横跨多个Region来存放

G1垃圾回收器会根据系统运行情况，动态的把Region分配给新生代（Eden区、Survivor区）、老年代、和大对象，
新生代和老年代都有各自的最大占比，当新生代的Eden区满的时候，触发新生代垃圾回收

新生代采用复制算法进行垃圾回收，但是不能超过预设的GC停顿时间，
所以G1需要清楚每个Region的回收效率

对象进入老年代

老年代占据了堆内存45%的Region时，触发混合垃圾回收

初始标记

并发标记

最终标记

筛选回收
（混合回收）

“-XX:G1MixedGCCountTarget”参数

“-XX:G1HeapWastePercent”参数

“-XX:G1MixedGCLiveThresholdPercent”参数

如果使用G1垃圾回收的时候，应该值得优化的是什么地方？

什么时候可能会导致G1频繁的触发Mixed混合垃圾回收？

如何尽量减少Mixed GC的频率？

部署：4核8G的机器

每秒600个请求

堆内存4G，新生代默认初始占比5%，最大占比60%，
每个Java线程的栈内存为1M，元数据区（永久代）内存256M

JVM参数：
-Xms4096M -Xmx4096M 
-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M
-Xss1M
-XX:+UseG1GC

GC停顿时间设置

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

G1垃圾回收器到底在什么场景下适用呢？

1. 存放系统中创建出来的对象
2. 通常分为新生代和老年代，系统中创建的对象优先放在新生代
3. 新生代快塞满时，垃圾回收器会清理新生代的垃圾对象，也就是那些没有GC Roots引用的对象

1. 通过复制算法进行回收
2. 新生代进行垃圾回收时，会停止系统程序的运行，进入“STW”状态
3. 只允许后台垃圾回收器的多个垃圾回收线程工作，执行垃圾回收

垃圾回收期间停止系统程序的运行，这个叫做“Stop the World”

影响有多大

什么情况下影响比较大

老年代GC比较耗时

对象进入老年代的条件

专门针对新生代的GC

所谓老年代GC，称之为“Old GC”更合适一些
在之前的分析中，我们把老年代的GC称之为Full GC，其实也是可以的，
只不过是字面意思的不同说法

对于Full GC，更合适的说法是它是针对新生代、老年代、永久代的全体内存空间的垃圾回收，
所以就是对JVM进行的一次整体垃圾回收

一般很少使用，容易与“Old GC”、“Full GC”概念混淆

Mixed GC是G1中特有的概念，其实说白了，主要就是说在G1中，
一旦老年代占据堆内存的45%了，就要触发 Mixed GC，
此时对年轻代和老年代都会进行回收。

一般就是在新生代Eden区域满了以后就会触发

Old GC触发时机

Full GC触发时机

假如存放类信息、常量池的永久代满了之后，就会触发一次Full GC，
永久代中的垃圾一般是很少的，因为里面存放的都是一些类，还有常量池之类的东西，
这些东西通常来说是不需要回收的

此时可以尝试调整新生代的内存比例，
保证每次Young GC后存活对象可以放入到Survivor区域

更换高配置的机器

-XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 
-XX:NewSize=5242880 -XX:MaxNewSize=5242880
-XX:SurvivorRatio=8 
-XX:PretenureSizeThreshold=10485760 
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

说明：
“-XX:InitialHeapSize”和“-XX:MaxHeapSize”就是初始堆大小和最大堆大小
“-XX:NewSize”和“-XX:MaxNewSize”是初始新生代大小和最大新生代大小
“-XX:PretenureSizeThreshold=10485760”指定了大对象阈值是10MB
新生代使用ParNew垃圾回收器，老年代使用CMS垃圾回收器
GC日志的打印（打印详细的GC日志、每次GC发生的时间、日志输出到文件）

public class Demo1 {
    public static void main(String[] args) {
        byte[] arr1 = new byte[1024 * 1024];
        arr1 = new byte[1024 * 1024];
        arr1 = new byte[1024 * 1024];
        arr1 = null;

        byte[] arr2 = new byte[2 * 1024 * 1024];
    }
}

CommandLine flags: -XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 ……
这一行就是此处运行程序采取的JVM参数

0.218: [GC (Allocation Failure) 0.219: [ParNew: 4096K->512K(4608K), 0.0042920 secs] 4096K->1411K(9728K), 0.0053582 secs] 
[Times: user=0.00 sys=0.00, real=0.01 secs]

为啥会发生一次GC呢？

此处GC是什么时候发生的呢？

使用哪种垃圾回收器进行的垃圾回收

Java堆的内存情况

本次GC消耗的时间

JVM退出的时候打印出来的当前堆内存的使用情况

par new generation   total 4608K, used 2183K
  eden space 4096K,  52% used
  from space 512K,   8% used
  to   space 512K,   0% used

concurrent mark-sweep generation total 5120K, used 1407K

Metaspace       used 3516K, capacity 4500K, committed 4864K, reserved 1056768K
  class space    used 389K, capacity 392K, committed 512K, reserved 1048576K

JDK 1.8以后的Metaspace和Classspace区域分别存放的是什么内容

GC日志中这里的used、capacity、committed、reserved几个字段，都表示什么含义？

JVM参数示范

示例代码

GC日志

总结

JVM参数示范

示例代码

GC日志

模拟场景：新生代存活对象太多，老年代放不下，触发CMS的Full GC

JVM参数示范

示例代码

GC日志，及过程描述

模拟另外几种老年代GC的场景

JVM内的Eden、Survivor、老年代的内存使用情况

Young GC和Full gC的执行次数以及耗时

jstat -gc [服务进程的PID]

jstat -gccapacity [服务进程的PID]：堆内存分析

jstat -gcnew [服务进程的PID]：年轻代GC分析，这里的TT和MTT可以看到对象在年轻代存活的年龄和存活的最大年龄

jstat -gcnewcapacity [服务进程的PID]：年轻代内存分析

jstat -gcold [服务进程的PID]：老年代GC分析

jstat -gcoldcapacity [服务进程的PID]：老年代内存分析

jstat -gcmetacapacity [服务进程的PID]：元数据区内存分析

新生代对象增长的速率

Young GC的触发频率及每次耗时

每次Young GC后有多少对象是存活 / 进入老年代

老年代对象增长的速率

Full GC的触发频率及每次耗时

JConsole

VisualVM

开源的监控系统

查看堆内存中各个区域的情况

查看系统运行时的对象分布

生成堆内存快照

jhat  -port 7000 dump.hprof

上面的命令会启动一个jhat服务，默认HTTP端口号：7000

使用jstat、jmap、jhat等工具去看看线上系统的JVM运行是否正常，有没有频繁Full GC的问题

常见的有Zabbix、OpenFalcon、Ganglia

-XX:NewSize=104857600 -XX:MaxNewSize=104857600 
-XX:InitialHeapSize=209715200 -XX:MaxHeapSize=209715200 
-XX:SurvivorRatio=8  
-XX:MaxTenuringThreshold=15 
-XX:PretenureSizeThreshold=3145728 
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

说明：
堆内存200M
新生代100M（Eden区80M，每个Survivor区10M），老年代100M

// 模拟系统按照每秒钟100个请求，每个请求加载300KB数据的方式不停的运行
public class Demo5 {
    public static void main(String[] args) throws Exception {
        Thread.sleep(30000);
        while (true) {
            loadData();
        }
    }
    private static void loadData() throws Exception {
        byte[] data = null;
        for (int i = 0; i < 100; i++) {
            data = new byte[300 * 1024];
        }
        Thread.sleep(1000);
    }
}

jps：查看当前所有Java进程的PID
jstat -gc [服务进程的PID] 1000 1000：查看JVM的内存和GC情况

JVM运行状态分析

-XX:NewSize=104857600 -XX:MaxNewSize=104857600 
-XX:InitialHeapSize=209715200 -XX:MaxHeapSize=209715200 
-XX:SurvivorRatio=8  
-XX:MaxTenuringThreshold=15 
-XX:PretenureSizeThreshold=20971520 
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

说明：
堆内存200M
新生代100M（Eden区80M，每个Survivor区10M），老年代100M
大对象阈值20MB

public class Demo6 {
    public static void main(String[] args) throws Exception {
        Thread.sleep(30000);
        while (true) {
            loadData();
        }
    }
   private static void loadData() throws Exception {
        // 分配4个10MB的数组，但是都立马成为垃圾
        byte[] data = null;
        for (int i = 0; i < 4; i++) {
            data = new byte[10 * 1024 * 1024];
        }
        data = null;

        // data1和data2两个10MB的数组是被变量引用必须存活的
        byte[] data1 = new byte[10 * 1024 * 1024];
        byte[] data2 = new byte[10 * 1024 * 1024];
        
        // 此时Eden区已经占用了六七十MB空间了

        // data3变量依次指向了两个10MB的数组
        byte[] data3 = new byte[10 * 1024 * 1024];
        data3 = new byte[10 * 1024 * 1024];
        Thread.sleep(1000);
    }
}

JVM运行状态分析

最大的问题是什么

解决方案，
例如：

jstack [服务进程ID]：分析该进程下各个线程当前的堆栈状态

top -Hp [服务进程ID]：查看该进程下各个线程的CPU使用情况

机器CPU负载过高

频繁Full GC报警

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

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

系统一次性加载过多数据进内存，搞出来很多大对象，
导致频繁有大对象进入老年代，必然频繁触发Full GC

系统发生了内存泄漏，莫名其妙创建大量的对象，始终无法回收，
一直占用在老年代里，必然频繁触发Full GC

Metaspace（永久代）因为加载类过多触发Full GC

Metaspace溢出的原因

避免方法

触发场景：方法递归调用

一般引发堆内存溢出的原因，
1. 系统负载过高
2. 有内存泄漏问题

Caused by: java.lang.OutOfMemoryError: Metaspace。

java.lang.StackOverflowError

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

监控平台，比如：Zabbix、Open-Falcon

比较成熟的系统监控体系

-XX:+HeapDumpOnOutOfMemoryError  
-XX:HeapDumpPath=/usr/local/app/oom