什么是垃圾
- 没有任何引用指向的对象就是垃圾(循环引用时,没有其他引用指向也是垃圾)
如何查找垃圾
- 引用计数器: 每增加一个引用指向时+1,删除一个引用指向时-1,引用计数为0时为垃圾(无法解决循环引用)
- 根可达算法(java 使用): 能被根对象(GC roots) 的访问到的就不是垃圾
java 根对象包括 (活动线程相关的各种引用。类的静态变量的引用。JNI 引用)
- Java 线程中，当前所有正在被调用的方法的引用类型参数、局部变量、临时值等。也就是与我们栈帧相关的各种引用。
- 所有当前被加载的 Java 类。
- Java 类的引用类型静态变量。
- 运行时常量池里的引用类型常量（String 或 Class 类型）。
- JVM 内部数据结构的一些引用，比如 sun.jvm.hotspot.memory.Universe 类。
- 用于同步的监控对象，比如调用了对象的 wait() 方法。
- JNI handles，包括 global handles 和 local handles。
基础的垃圾清除算法
Mark-Sweep(标记清除)
找到垃圾后直接删除
- 优点: 算法简单,执行效率快
- 缺点: 内存碎片化
Copying(拷贝)
将非垃圾对象复制到另一片空间,然后清空本空间
- 优点: 算法简单,执行效率快,不会碎片化
- 缺点: 浪费内存,有一块内存始终不能被利用到
Mark-Compact(标记压缩)
标记清除后会进行一次压缩(整理非垃圾对象,移动到一起)
- 优点: 不浪费空间,不会碎片化
- 缺点: 效率偏低
堆逻辑分区
- s0 -s1 之间复制年龄超过限制时,进入old区(不同垃圾回收器 默认值不一样)
- 通过参数: -XX:MaxTenuringThreshOld 配置 不超过15
堆逻辑分区
java对象生命周期对应储存位置
- 局部小对象可以存储在栈中(C struct 结构体)
- 大对象 默认是50M 可以通过参数配置 -XX:PretenureSizeThreshold
- TLAB 线程本地缓存区(避免线程间内存竞争,不需要锁),也在伊甸园区
- AGE 超过年龄限制
对象存储位置
现有的垃圾回收器
- 六种分代模型(老年代 和 新生代 各有其算法)
- G1: 逻辑分代,物理不分代
- ZGC: 逻辑物理均不分代
- Shenandoah: 与 ZGC 是竞争关系,算法相差不大
- Epsilon : jdk 11, 测试用,在特殊场景不需要垃圾回收器时使用(只管分配,不管回收)
现有的垃圾回收器
Serial 和 Serial Old
单线程标记处理
Serial
Parallel Scavenge 和 Parallel Old (java 8默认垃圾回收器)
多线程标记处理
Parallel
ParNew和CMS (ParNew 是 Parallel Scavenge 为了兼容CMS改造的)
- 多线程并发标记处理
- 初始标记STW时间极短, 重新标记时STW时间可能会非常长
- 会产生漏标(浮动垃圾)
- 会产生错标(标记时没引用,标记后又引用了),
- 三色标记算法修正错标,(写屏障,跟踪引用变更),
- 并发标记时,多个线程之间有可能产生隐形的错标问题(类似于线程安全问题)
- CMS 过程中,如果空间不够,会使用Serial Old 来清理(单线程)
CMS
G1
使用快照纠正错标
ZGC
使用颜色指针纠正错标
JVM 调优
常见设置
- -Xms -Xmx 一致,防止抖动(扩容和GC时)
- -XX:+HeapDumpOnOutOfMemoryError (oom后打印堆内存)
- -XX:ErrorFile JVM自身故障时输出的文件
常用工具
- jconsole
- jvisualvm
- arthas (阿里开源工具)
常用命令
- top -hp 查看线程占用资源信息
- jps -l 查找所有java进程
- jinfo [pid] 查看java进程 具体信息,启动命令等
- jstat -gc [pid] 查看java进程 GC信息
- jstack [pid] 查看java进程 所有线程及状态
- jmap [pid] 查看java进程 所有对象信息 (非常影响性能)
- jad [class path] 反编译输出源代码
- arthas->dashboard 查看仪表盘(中控台)
- arthas-> Thread [dashboard Thread ID] 查看 堆栈
常见场景
CPU暴增
- 使用 arthas dashboard | top -hp 定位到目标线程
- 如果是业务线程,排查业务线程代码
- 如果是GC线程,查看GC日志
死锁
- 使用 arthas thread -b 观察死锁
- 使用 jstack 关键线程情况
- jconsole 等
JVM进程静悄悄的退出
- JVM自身OOM导致 查看 Heap Dump on oom
- JVM自身故障 配置 -XX:ErrorFile,包括: crash线程信息,锁信息,native code cache,编译事件,GC相关记录等等
- 被Linux OOM killer 杀死, 日志位于/var/log/messages
- 硬件或内核问题 dmesg | grep java
