提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
文章目录
前言
本文总结自黑马程序员JVM完整教程 Java 虚拟机(JVM)垃圾回收篇。
1. 如何判断对象可以回收
1.1 引用计数法
给对象添加一个引用计数器,每当有一个地方引用它时,计数器值就加1;当引用失效时,计数器值就减1;任何时刻计数器为0的对象就是不可能再被使用的。
主流的 Java 虚拟机里面没有选用引用计数算法来管理内存,其中最主要的原因是它很难解决对象之间相互循环引用问题。
1.2 可达性分析法
- Java 虚拟机中的垃圾回收器采用可达性分析来探索所有存活的对象
- 扫描堆中的对象,看是否能够沿着GC Root 对象为起点的引用链找到该对象,找不到,表示可以回收
- 哪些对象可以作为 GC Root ?
- 虚拟机栈(栈帧中的本地变量表)中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中 JNI(即一般说的 Native 方法)引用的对象
1.3 四种引用
- 强引用(StrongReference)
只有所有 GC Roots 对象都不通过【强引用】引用该对象,该对象才能被垃圾回收 - 软引用(SoftReference)
仅有弱引用引用该对象时,在垃圾回收后,内存仍不足时会再次出发垃圾回收,回收软引用对象
可以配合引用队列来释放软引用自身 - 弱引用(WeakReference)
仅有弱引用引用该对象时,在垃圾回收时,在垃圾回收时,无论内存是否充足,都会回收弱引用对象
可以配合引用队列来释放弱引用自身 - 虚引用(PhantomReference)
必须配合引用队列使用,主要配合 ByteBuffer 使用,被引用对象回收时,会将虚引用入队,由 Reference Handler 线程调用虚引用相关方法释放直接内存 - 终结器引用(FinalReference)
无需手动编码,但其内部配合引用队列使用,在垃圾回收时,终结器引用入队(被引用对象暂时没有被回收),再由 Finalizer 线程通过终结器引用找到引用对象并调用它的 finalize 方法,第二次 GC 时才能回收被引用对象
2. 垃圾回收算法
2.1 标记清除
2.2 标记整理
2.3 复制
3. 分代垃圾回收
- 对象首先分配在伊甸园区域
- 新生代空间不足时,触发 minor gc,伊甸园和 from 存活的对象使用 copy 复制到to中,存活的对象年龄加1并且交换 from to(复制)
- minor gc 会引发 stop the world ,暂停其它用户的线程,等垃圾回收结束,用户线程才会恢复运行
- 当对象寿命超过阈值时,会晋升老年代,最大寿命15(4bit)
- 当老年代空间不足,会先尝试触发 minor gc,如果之后空间仍不足,那么触发 full gc,STW的时间更长(标记-清除 或 标记-整理)
3.1 相关 VM 参数
4. 垃圾回收器
4.1 串行
- 串行
- 堆内存较小,适合个人电脑
4.2 吞吐量优先
- 多线程
- 堆内存较大,多核 CPU
- 让单位时间内,STW 的时间最短 0.2 0.2 = 0.4
4.3 响应时间优先
- 多线程
- 堆内存较大,多核 CPU
- 尽可能让单次 STW 的时间最短 0.1 0.1 0.1 0.1 0.1 = 0.5
4.4 G1
定义:Garbage First
- 2004 论文发布
- 2009 JDK 6u14 体验
- 2012 JDK 7u4 官方支持
- 2017 JDK 9默认
适用场景 - 同时注重吞吐量(Throughput)和低延迟(Low latency),默认的暂停目标是200ms
- 超大堆内存,会将堆划分为多个大小相等的 Region
- 整体上是标记+整理算法,两个区域之间是复制算法
相关JVM参数
-XX:+UseG1GC
-XX:G1HeapRegionSize=size
-XX:MaxGCPauseMillis=time
(1)G1垃圾回收阶段
(2)Young Collection
(3)Young Collection+CM
(4)Mixed Collection
(5)Full GC
- SerialGC
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足发生的垃圾回收- full gc
- ParallelGC
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足发生的垃圾回收- full gc
- CMS
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足
- G1
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足
(6) Young Collection 跨代引用
(7)Remark
(8) JDK 8u20 字符串去重
- 优点:节省大量内存
- 缺点:忽略多占用了 cpu 时间,新生代回收时间略微增加
-XX:+UseStringDeduplication
String s1 = new String("hello");// char[]{'h','e','l','l','o'}
String s2 = new String("hello");// char[]{'h','e','l','l','o'}
- 将所以新分配的字符串放入一个队列
- 当新生代回收时,G1并发检查是否有字符串重复
- 如果它们值一样,让它们引用同一个char[]
- 注意,与String.intern()不一样
- String.intern()关注的是字符串对象
- 而字符串去重关注的是char[]
- 在 JVM 内部,使用了不同的字符串表
(9) JDK 8u40 并发标记类卸载
所有对象都经过并发标记后,就能知道哪些类不再被使用,当一个类加载器的所有类都不再使用,则卸载它所加载的所有类
-XX:+ClassUnloadingWithConcurrentMark 默认启用
(10) JDK 8u60 回收巨型对象
- 一个对象大于 region 的一半时,称之为巨型对象
- G1 不会对巨型对象进行拷贝
- 回收时被优先考虑
- G1 会跟踪老年代所有 incoming 引用,这样老年代 incoming 引用为0的巨型对象就可以在新生代垃圾回收时处理掉
(11)JDK 9并发标记起始时间的调整 - 并发标记必须在对空间占满前完成,否则退化为 FullGC
- JDK 9 之前需要使用-XX:InitiatingHeapOccupancyPercent
- JDK 9可以动态调整
- -XX:InitiatingHeapOccupancyPercent 用来设置初始值
- 进行数据采样并动态调整
- 总会添加一个安全的空档空间
(12)JDK 9 更高效的回收
- 250+增强
- 180+bug修复
5. 垃圾回收调优
5.1 调优领域
- 内存
- 锁竞争
- cpu占用
- io
5.2 确定目标
- 【低延迟】还是【高吞吐量】,选择合适的回收器
- CMS,G1,ZGC
- ParallelGC
- Zing
5.3 最快的GC是不发生GC
-
查看 FullGC 前后的内存占用,考虑下面几个问题
- 数据是不是太多?
- 数据表示是否太臃肿?
- 是否存在内存泄漏
5.4 新生代调优
- 新生代的特点
- 所有的 new 操作的内存分配非常廉价
- TLAB thread-local allocation buffer
- 所有的 new 操作的内存分配非常廉价
- 死亡对象的回收代价是零
- 大部分对象用过即死
- Minor GC 的时间远远低于 Full GC
- 新生代大小最优设置:新生代能容纳所有【并发量*(请求-响应)】的数据
- 幸存区大到能保留【当前活跃对象+需要晋升对象】
- 晋升阈值配置得当,让长时间存活对象尽快晋升
-XX:MaxTenuringThreshold=threshold
-XX:+PrintTenuringDistribution
5.5 老年代调优
以CMS为例
- CMS 的老年代内存越大越好
- 先尝试不做调优,如果没有 Full GC 那么已经…,否则先尝试调优新生代
- 观察发生 Full GC 时老年代内存占用,将老年代内存预设调大1/4~1/3
- -XX:CMSInitiatingOccupancyFraction=percent
5.6 案例
Full GC 和 Minor GC频繁
请求高峰期发生 Full GC,单次暂停时间特别长(CMS)
老年代充裕情况下,发生 Full GC(CMS jdk1.7)