JVM 垃圾回收机制、垃圾收集器、调优参数
目录
-
-
- 概述
- 标记对象是否为垃圾的算法
-
- 引用计数算法
- 可达性分析算法
- 引用类型
- 垃圾回收算法
-
- 标记-清除算法 Mark-Sweep
- 标记-整理算法 Mark- Compact
- 复制算法 Coping
- 分代收集算法
- 堆外内存（直接内存）的回收
- 垃圾收集器
-
- JVM的2种运行模式
- 新生代常见的3种收集器
-
- Serial收集器
- ParNew收集器
- Parallel Scavenge收集器
- 老年代常见的3种收集器
-
- Serial Old
- Parallel Old（默认）
- CMS收集器
- 整堆收集器 G1
- 垃圾收集器总结、选择建议
- 常用的JVM调优参数
-
- jvm通用调优参数
- 基于分代收集算法实现的GC的通用调优参数
- 主流收集器各自的调优参数
-
概述
C++的内存回收很麻烦，不回收可能会造成内存泄漏，Java中由GC完成内存回收，不用手动回收内存。
程序计数器占据的内存较小，没有必要进行垃圾回收；虚拟机栈、本地方法栈在进行出栈操作后，会自动回收栈帧使用的内存空间，无需gc进行垃圾回收。
垃圾收集主要针对堆和方法区进行，其中方法区存放的对象十分稳定，存活率极高，通常只在类卸载、常量不被使用的情况下才会产生垃圾。在方法区上进行垃圾回收性价比不高。堆内存占用非常大，对象多，是垃圾回收的重点区域。
类的卸载条件很多，需要满足以下三个条件
- 该类所有的实例都已经被回收
- 加载该类的类加载器已经被回收
- 该类对应的 Class 对象没有在任何地方被引用
即使满足了这3个条件也不一定会被卸载。
标记对象是否为垃圾的算法
对象被判定为垃圾的标准：没有被其它对象引用
引用计数算法
堆中每个对象都对应一个引用计数器，当一个变量引用此对象时，计数器+1；当引用此对象的变量生命周期结束或者被赋新值时，计数器-1；计数器为0时该对象成为垃圾，等待gc回收。
优点：简单、高效
缺点：需要存储每个对象对应的引用计数器，有额外的内存开销；没有处理循环引用问题，存在循环引用时，计数器永不为0，可能导致内存泄漏。
eg. a对象中引用了b对象，b对象中引用了a对象，即存在循环引用，使用引用计数法时，这2个对象的计数器永不为0，永远不会被回收。
即使把这2个变量都置为null，只是引用变成了null，堆中的这2个对象不变，依然持有彼此的引用，它们的计数器也不会为0。
因为引用计数法没有解决循环引用问题，所有主流垃圾收集器都不采用引用计数算法，而采用可达性分析算法。
可达性分析算法
又叫做根搜索算法，使用不同的GC Root，从GC Root开始寻找引用链上的对象，没在任何一条引用链中的对象标记为垃圾。
相比于引用计数法，可达性分析算法同样具备简单、高效的优点，且没有存在循环引用时不能被gc回收的问题。
可以作为GC Root的对象
- java虚拟机栈中的局部变量表中引用的对象
- 本地方法栈中 JNI 引用的对象
- 方法区中类的静态成员、常量引用的对象
- 被同步锁synchronized持有的对象
使用可达性分析算法进行分析时，整个分析过程必须在一个一致的堆内存快照中进行，否则不能保证分析结果的正确性，这也是进行gc时必须stop the world的一个重要原因。
即使是以系统最短停顿时间为目标的CMS收集器，枚举GC Root时也是要停顿的。
对象的finalize机制
根类Object提供了一个finalize()方法，默认是空实现，可以被子类重写。
finalize()类似 C++ 的析构函数，可以用于关闭外部资源，但此方法运行代价很高、不确定性大，无法保证各个对象的调用顺序，最好不要使用，关闭资源可以用 try-finally代替。
当一个对象可被回收时，如果需要执行该对象的 finalize() 方法，那么就有可能在该方法中让对象重新被引用，从而实现自救。自救只能进行一次，如果回收的对象之前调用了 finalize() 方法自救，后面回收时不会再调用该方法。
一个没被任何其它对象引用的对象，只是暂时不被使用，并不一定就是垃圾，可能该类重写了finalize()方法，在finalize()方法中复活、重新使用当前对象。
堆中对象可能的三种状态
- 可触及的：在GC Root的引用链上
- 可复活的：不在GC Root的引用链上，但可能调用finalize()方法进行复活
- 不可触及的：调用了对象的finalize()方法，但该方法中并没有复活当前对象
可达性分析算法至少要经过2次标记，才会把对象标记为垃圾
- 第一次使用GC Root的引用链进行筛选，将不在GC Root的引用链上的对象标记为可复活的
- 第二次对可复活的对象进行筛选
如果对象所属的类没有重写finalize()方法，或者之前已经执行过finalize()方法但没有复活对象，则直接标记为不可触及的；
如果对象所属的类重写了finalize()方法，且之前没有执行过finalize()方法，则把对象放入finalize队列中，
由jvm创建的一个低优先级的finalizer线程处理队列中对象，调用对象的finalize()方法，如果没有复活，则把对象标记为不可触及的。
状态为不可触及的对象才会成为垃圾，等待被gc回收。
引用类型
无论引用计数算法，还是可达性分析算法，判定对象是否可被回收都与对象的引用类型有关。java 提供了四种引用类型。
1、 Strong Reference 强引用
被强引用关联的对象不会被gc回收，一般都是以强引用方式进行关联。
与其它引用类型的区别：强引用禁止引用目标被垃圾收集器收集，而其他引用不禁止。
//eg.使用new来创建强引用，变量user强引用new出来的对象
User user = new User();
2、Soft Reference 软引用
被软引用关联的对象只有在内存不够的情况下才会被回收。
可以使用 SoftReference 类来创建软引用。
User user = new User();
SoftReference<User> sf = new SoftReference<>(user);
//置空对象，使对象只被软引用关联
user = null;
3、Weak Reference 弱引用
被弱引用关联的对象在下次进行垃圾收集时一定会被回收，即只能存活到下一次垃圾回收发生之前。
可以使用 WeakReference 类来创建弱引用。
User user = new User();
WeakReference<User> wf = new WeakReference<>(user);
user = null;
4、Phantom Reference 虚引用
又称为幽灵引用、幻影引用，虚引用不会对关联对象的生存时间造成影响，设置虚引用的目的是在关联对象（目标对象）被回收时可以收到系统通知。
可以使用 PhantomReference类来创建虚引用。
User user = new User();
PhantomReference<User> pf = new PhantomReference<>(user, null);
user = null;
垃圾回收算法
标记-清除算法 Mark-Sweep
- 标记需要回收的对象
- 清除要回收的对象
清除并不是置空，只是把要清除的对象的地址保存在空闲地址列表中，后续分配内存时可以使用这些内存，再次分配时才覆盖原有内容。
缺点：容易产生内存碎片，可能导致后续给大对象分配内存空间时没有足够大的连续内存，从而提前触发下一次gc。
标记-整理算法 Mark- Compact
- 标记需要回收的对象
- 将所有存活的对象压缩（Compact）到内存的一端，然后直接清理掉边界以外的部分。
不会产生内存碎片，但效率要低于复制算法。
复制算法 Coping
将内存划分为2块，每次只使用一块，进行垃圾回收时将存活的对象复制到未使用的一块上，清理掉之前使用的那一块。
不会产生内存碎片，适合对象存活率低的场景，常用于新生代的垃圾回收。
新生代对象存活率低，一般使用复制算法；老年代对象存活率高，一般使用标记-整理算法。
分代收集算法
根据对象存活周期（年龄代）将堆内存划分为几块，不同块使用合适的收集算法。
把堆划分为2大块
- 新生代（Young Gen）：包括Eden区、2个Survivor区，默认大小比例8:1:1
- 老年代（Old Gen）：老年代内存空间比新生代大得多
新生代使用复制算法，老年代使用标记-清除或标记-整理算法。
对象|内存 分配策略
- 对象主要分配在新生代的 Eden 区上
- 如果启用了本地线程分配缓冲TLAB，则优先分配到线程各自的分配缓冲区中
- 少数情况下会直接分配在老年代中，比如大对象
垃圾回收方式
- 新生代使用复制算法进行垃圾回收，回收时把Eden区、Survivor from区中存活的对象复制到Survivor to中，然后清理掉Eden区、Survivor from区。Survivor from、to是相对的，不是固定的某一块内存空间。
- 老年代使用标记-清除或标记-整理算法进行垃圾回收，不同的垃圾收集器，老年代使用的垃圾回收算法可能不同。
gc分类
- Minor GC：新生代 GC，回收新生代。新生代对象存活时间很短，回收率极高，Minor GC 非常频繁，回收执行速度也很快。
- Full GC：又叫做Major GC，主要回收老年代，但通常伴随着Minor GC，所以可以看做老年代、新生代都在回收，收集整个堆。老年代内存大、对象多，对象存活时间长，相比于Minor GC，Full GC执行次数较少、回收速度慢。
minor gc的触发条件
- Eden区空间不足
full gc的触发条件
- 老年代空间不足
- 调用System.gc()。虽然只是建议进行Full GC，但一般都会进行
- 新生代空间不足时使用老年代的内存空间进行分配担保（Handle Promotion），分配担保失败时会触发full gc
分配担保：新生代对象存活率偏高，Survivor to中放不下时，会使用老年代的空间进行分配担保，即把Survivor to中放不下的对象直接放到老年代中。
full gc时间花销大，造成的停顿时间较长，看到jvm频繁进行full gc时要引起注意，应该进行优化。
对象如何晋升到老年代
- 经历指定的Minor GC次数仍然存活，默认15次
- 新生代空间不足时使用老年代的内存空间进行分配担保，Survivor to中放不下的对象直接放到老年代中
- 大对象直接在老年代进行分配
堆外内存（直接内存）的回收
DirectByteBuffer对象本身是直接分配在老年代的，对象本身可在Full GC时被回收，但DirectByteBuffer申请使用的是直接内存，所引用的直接内存不在gc回收范围内，不会被gc回收。
jdk提供了一种机制：可以给堆中的对象注册一个钩子函数(其实就是实现 Runnable的一个子接口)，当堆中的对象被GC回收的时候，会回调run()方法。
Unsafe类提供了大量的native方法，可以在run()方法中调用Unsafe类的freeMemory()方法，释放DirectByteBuffer对象引用的直接内存。
垃圾收集器
stop the word：jvm进行垃圾回收时会暂停应用程序的执行（暂停所有用户线程），gc完成才会继续执行应用程序，主流垃圾收集器或多或少都存在这各个情况。
safepoint：安全点，标记阶段对象引用关系不会发生变化的点，比如方法调用、循环跳转处。
JVM的2种运行模式
- client模式：使用轻量级虚拟机，适合对性能要求不高的项目，常用于桌面程序。桌面程序内存占用小，一般就几十兆、两三百兆。
- server模式：使用重量级虚拟机，启动慢，但做了更多的优化，稳定运行后性能更高，适合对性能要求高的项目，常用于java web项目。
使用java -version可以查看jvm的种类、运行模式，HotSpot默认使用server模式。
新生代常见的3种收集器
Serial收集器
- 使用单线程进行垃圾回收
- 使用复制算法
- 性能低，常用于桌面程序，是HotSpot虚拟机client模式下默认的新生代垃圾收集器
ParNew收集器
- 使用多线程进行垃圾回收，相当于Serial的多线程版本
- 使用复制算法
- 是web应用主流使用的新生代垃圾收集器，一个重要原因是ParNew是能与CMS搭配使用少数新生代收集器之一
Par是Parallel的缩写
#使用ParNew收集器，+是启用，-是取消
-XX:+UseParNewGC
#可以指定进行垃圾回收的线程数，默认为cpu核心数
-XX:ParallelGCThreads=8
Parallel Scavenge收集器
- 使用多线程进行垃圾回收
- 使用复制算法
- 吞吐量优先
- 是HotSpot虚拟机在server模式下默认的新生代垃圾收集器
与其它收集器不同，其它收集器关注缩短系统停顿时间，而 Parallel Scavenge关注吞吐量
吞吐量 = 运行用户代码的时间 / (运行用户代码的时间 + 垃圾收集时间）
高吞吐量可以高效利用cpu执行程序代码，适合在不需要太多交互的应用中使用。
Parallel Scavenge可以使用gc自适应调节：jvm根据当前运行状况，动态调整设置最适合的gc停顿时间、吞吐量
#启用gc自适应调节
-XX:UseAdaptiveSizePolicy
#也可以使用以下方式进行手动设置，但一般不手动设置
#设置gc最大暂停时间，在这个时间范围内，至少进行一次gc
-XX:MaxGCPauseMillis=600000
#设置吞吐量，默认99，即吞吐量为99%
-XX:GCTimeRatio=99
老年代常见的3种收集器
Serial Old
- 和Serial 一样使用单线程进行垃圾回收
- 使用标记整理算法
- 用于老年代的垃圾回收，是HotSpot虚拟机 Client模式下默认的老年代垃圾回收器
Parallel Old（默认）
- 使用多线程进行垃圾回收
- 使用标记整理算法
- 吞吐量优先
- 是HotSpot虚拟机在server模式下默认的老年代收集器
#取消默认的Parallel Old收集器
-XX:-UseParallelOldGC
CMS收集器
- 使用标记-清除算法
- 关注系统停顿时间，以系统最短停顿时间为目标，适合与用户交互多的程序。
- 是server模式下主流的老年代垃圾收集器
cms进行垃圾回收的主要步骤
- 初始标记 ：标记作为GC Root的对象（stop the world）
- 并发标记：根据可达性分析算法找出所有的引用链
- 重新标记：修正并发标记期间因用户程序导致的标记变动（stop the world）
- 并发清除：回收标记对象
只在初始标记、重新标记阶段出现stop the world，其它回收阶段可以和用户线程并发执行，回收垃圾引起的系统停顿时间几乎可以忽略不计。
web服务端重视响应速度，希望gc引起的系统停顿时间尽可能短，以带给用户更好的体验，cms正好符合web应用的需求，是java web应用老年代主流使用的垃圾收集器。
说明
和其它收集器不同，cms在垃圾收集阶（并发清除）段还需要运行应用，需要预留足够的内存空间供应用使用，所以cms不能像其它收集器一样等到老年代快满了才进行垃圾回收。
如果cms预留的内存空间不能满足应用运行的需要，jvm会临时使用Serial Old代替cms收集老年代，引起的停顿时间较长。
cms的优缺点
- 优点：并发收集，系统停顿时间短
- 缺点：本次回收时不能清除并发标记阶段新产生的垃圾；进行并发清除时还要运行应用（运行应用时还需要使用一些线程来并发清除垃圾），对cpu很敏感；使用标记-清除算法，会产生大量的内存碎片。
#启用CMS收集器，CMS是ConcMarkSweep的缩写
-XX:+UseConcMarkSweepGC
整堆收集器 G1
- G1收集器将整个堆划分为多个大小相等的独立区域（Region），可以对整个堆进行垃圾回收
- 使用标记-整理算法，不会产生内存碎片
- 和CMS一样都关注于缩短系统停顿时间，但G1的系统停顿时间是可预测的
- 回收价值大
G1 会跟踪各个 Region 里面垃圾的回收价值，记录回收所获得的空间、所花费的时间，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。
这也是 Garbage- Firsti 名称的由来、以及可预测的原因，这种方式保证了 G1 在有限时间内获取尽可能高的回收价值。‘
g1进行垃圾回收的主要步骤
- 初始标记（Initial Marking) ：标记作为GC Root的对象
- 并发标记（Concurrent Marking）：根据可达性分析算法找出各个Region所有的引用链
- 最终标记（Final Marking) ：修正并发标记期间因用户程序导致的标记变动
- 筛选回收（Live Data Counting and Evacuation)：回收各个Regin中Remembered Set 之外的部分
垃圾收集器总结、选择建议
| 名称 | 收集年代 | 使用的垃圾回收算法 | gc线程 | 关注点 | 地位 |
|---|---|---|---|---|---|
| Serial收集器 | 新生代 | 复制算法 | 单线程 | client模式下默认的新生代收集器 | |
| ParNew收集器 | 新生代 | 复制算法 | 多线程 | 新生代主流使用的收集器 | |
| Parallel Scavenge收集器 | 新生代 | 复制算法 | 多线程 | 关注吞吐量 | server模式下默认的新生代收集器 |
| Serial Old收集器 | 老年代 | 标记整理算法 | 单线程 | client模式下默认的老年代收集器 | |
| Parallel Old收集器 | 老年代 | 标记整理算法 | 多线程 | 关注吞吐量 | server模式下默认的老年代收集器 |
| CMS收集器 | 老年代 | 标记清除算法 | 单线程、多线程混合 | 关注缩短系统停顿时间 | 老年代主流使用的收集器 |
| G1收集器 | 所有年代 | 标记整理算法 | 单线程、多线程混合 | 关注缩短系统停顿时间、高价值回收 | 优秀，但低版本jdk中包含的G1版本尚不成熟 |
java web应用的收集器选择
- jdk9及之后版本的jdk：默认收集器是G1，也推荐使用G1
- jdk8及之前版本的jdk：包含的G1版本尚不成熟，推荐使用ParNew收集新生代，使用CMS收集老年代
常用的JVM调优参数
jvm内存不是越大越好，内存太小会频繁GC，内存太大触发GC时停顿时间会较长。根据压测结果不断调整jvm内存大小，合适就好，并非越大越好。
优化指标
- 吞吐量=非GC停顿时间/系统运行总时间，一般要将吞吐量优化到95%甚至98%以上，即GC停顿时间控制在系统运行总时间的2%或5%以内。
- 尽量减少Full GC次数，将单次Full GC造成停顿时间控制在1s以内。
jvm通用调优参数
#启动应用的时候可以设置jvm参数，单位直接用 k、m、g
#在IDEA中同样可以设置jvm参数，参数之间都是用空格分隔
java -Xms512m -Xmx512m -jar xxx.jar
#控制台打印gc信息
-verbose:gc -XX:+PrintGCDetails
#一般将初始堆内存、最大堆内存设置为一样的，防止堆扩容时引起内存抖动、影响程序运行的稳定性
-Xms10g #初始堆内存，默认为物理内存的1/64
-Xmx10g #最大堆内存，默认为物理内存的1/4
-Xss256k #每个线程 java虚拟机栈的大小
-XX:MetaspaceSize=1g #元空间的初始内存
#-XX:MaxMetaspaceSize #元空间的最大内存，默认不限制。jdk的元空间直接使用本地内存，不占用堆内存，不用指定元空间的最大内存。
基于分代收集算法实现的GC的通用调优参数
主流的垃圾回收算法是分代收集算法，以下的jvm调优参数也是针对分代收集算法的
-Xmn512m #新生代大小
-Xx:NewRatio=3 #老年代、新生代的大小比例，默认3
-Xx:SurvivorRatio=8 #Eden区与一个Servivor区的大小比例，默认8。2个servivor区的大小比例默认1:1
-XX:MaxTenuringThreshold=15 #新生代对象晋升到老年代需经历的Minor GC次数，默认15
-XX:PretenureSizeThreshold=3145728 #大对象阈值，单位字节，体积超过这个值就认为是大对象，直接在老年代分配空间
主流收集器各自的调优参数
#ParNew
-XX:+UseParNewGC #启用ParNew收集器
-XX:ParallelGCThreads=n #ParNew回收垃圾使用的线程数。默认为cpu核心数，但使用docker部署应用时，可能取的是物理机的cpu核数，而非分配给容器的cpu核数，最好手动指定，避免踩坑
#CMS
-XX:+UseConcMarkSweepGC #启用CMS收集器，CMS是ConcMarkSweep的缩写
-XX:ParallelCMSThreads=n #CMS回收垃圾使用的线程数，和ParNew的一样，在docker下容易踩坑，应该手动配置
-XX:+UseCMSCompactAtFullCollection #在FullGC后压缩整理内存碎片
-XX:CMSFullGCBeforeCompaction=4 #每隔4次FullGC才整理压缩一次内存碎片
-XX:UseCMSInitiatingOccupancyOnly #使用内存占用阈值触发GC
-XX:CMSInitiatingOccupancyFraction=70 #（老年代）内存占用达到70%就触发GC
#G1
-XX:+UseG1GC #启用G1收集器
-XX:MaxGCPauseMillis=n #GC最大停顿时间，G1会尽可能满足这个参数
-XX:G1HeapReginSize=n #每个Regin的大小
这些jvm调优参数并非1次就确定下来，需要不断调整参数，反复测试查看GC日志，比较效果以找到合适的值。