对象被判定为垃圾的标准
没有被其他对象引用
判断对象是否为垃圾的算法
引用计数算法
通过判断对象的引用数量来决定是否可以被回收
每个对象实例都有一个引用计数器，被引用则+1，完成引用则-1
任何引用计数为0的对象可以被当做垃圾收集
优点：执行效率高，程序执行受影响较小
缺点：无法检测出循环引用的情况，导致内存泄漏
可达性分析算法
判断对象的引用链是否可达来决定对象是否可以被回收
可以作为GC Root 的对象
- 虚拟机栈中引用的对象(栈帧中的本地变量表)
- 方法区中的常量引用的对象
- 方法区中的类静态属性引用的对象
- 本地方法栈中JNI(Native方法)的引用对象
- 活跃线程的引用对象
垃圾回收算法
标记清除算法(Mark and Sweep)
标记：从根集合扫描，对存活的对象进行标记
清除：对堆内存从头到尾进行线性遍历，回收不可达对象内存。并且将原来标记为可达对象的标识清除掉，以便进行下一次垃圾回收。
复制算法(Copying)
- 分为对象面和空闲面
- 对象在对象面上创建
- 存活的对象被从对象面复制到空闲面
- 将对象面所有对象内存清除
标记-整理算法(Compacting)
标记: 从根集合进行扫描，对存活的对象进行标记
清除: 移动所有存活的对象，且按照内存地址依次排列，然后将末端内存地址以后的内存全部回收
分代收集算法(Generational Collector)
垃圾回收算法的组合拳
按照对象生命周期的不同划分区域以采用不同的垃圾回收算法
目的: 提高JVM的回收效率
GC的分类
- Minor GC(发生在年轻代中的垃圾收集动作，采用的是复制算法，年轻代几乎是所有Java对象出生的地方，年轻代是GC收集垃圾的频繁区域)
- Full GC(与老年代相关，由于对老年代的回收一般会伴随着年轻代的垃圾收集，因此被命名为Full GC)
- Full GC 比 Major GC慢, 但执行频率低
年轻代和老年代
年轻代：尽可能快速地收集掉那些生命周期短的对象，年轻代被划分为一个Eden区和两个Survivor区
老年代：存放生命周期较长的对象
年轻代垃圾回收的过程
假设每个对象的大小是一样的，Eden最多保存4个对象，Survivor最多保存3个对象。
图中数字代表对象的年龄，当对象的年龄达到某个值时(默认情况下15，可通过 -XX MaxTenuringThrehold来调整)，这些对象会成为老年代。对于一些较大的对象，Eden和Survivor都无法装下时也会进入老年代。
如何晋升到老年代
- 经历一定Minor次数依然存活的对象
- Survivor区中存放不下的对象
- 新生成的大对象(-XX:PretenuerSizeThreshold)
常用调优参数
- -XX:SurvivorRatio:Eden和Survivor的比值, 默认8:1
- -XX:NewRatio: 老年代和年轻代内存大小的比例, 默认2:1
- -XX:MaxTenuringThreshold: 对象从年轻代晋升到老年代经历过GC次数的最大阈值
触发Full GC的条件
老年代空间不足
- 永久代空间不足(针对jdk7及以前的版本, jdk8及以后的版本已经取消了永久代)
- CMS GC时出现promotion failed, concurrent mode failure
- Minor GC晋升到老年代的平均大小大于老年代的剩余空间
- 调用System.gc(),该方法只是提醒虚拟机回收对象, 回不回收还是由虚拟机决定
- 使用RMI来进行RPC或管理的JDK应用, 每小时执行1次Full GC
Stop-the-World
- JVM由于要执行GC而停止了应用程序的执行
- 任何一种GC算法中都会发生
- 多数GC优化通过减少Stop-the-world发生的时间来提高程序性能
Safepoint
- 分析过程中对象引用关系不会发生变化的点
- 产生Safepoint的地方: 方法调用; 循环跳转; 异常跳转等
- 安全点数量要适中
JVM的运行模式
- Server
- Client
Client启动速度较快，Server启动速度较慢，但是当运行稳定后，Server模式运行的程序要比Client快，这是因为Server模式启动的JVM采用的是重量级的虚拟机，对程序采用了更多的优化，Client模式启动的JVM采用的是轻量级的虚拟机
常见的垃圾收集器
年轻代常见的垃圾收集器
Serial收集器(-XX:+UseSerialGC, 复制算法)
单线程收集，进行垃圾收集时，必须暂停所有工程线程
简单高效，Client模式下默认的年轻代收集器
ParNew收集器(-XX:+UseParNewGC, 复制算法)
多线程收集，其余的行为、特点和Serial收集器一样
单核执行效率不如Serial，在多核执行才有优势
Parallel Scavenge收集器(-XX:+UseParallelGC, 复制算法)
多线程收集
比起关注用户线程停顿时间，更关注系统的吞吐量()
在多核下执行才有优势，Server模式下默认的年轻代收集器
老年代常见的垃圾收集器
Serial Old收集器(-XX:+UseSerialOldGC, 标记-整理算法)
单线程收集，进行垃圾收集时，必须暂停所有工作线程
简单高效，Client模式下默认的老年代收集器
Parallel Old收集器(-XX:+UseParallelOldGC, 标记-整理算法)
多线程，吞吐量优先
CMS收集器(-XX:+UseConcMarkSweepGC, 标记-清除算法)
- 初始标记: stop-the-world
- 并发标记: 并发追溯标记，程序不会停顿
- 并发预清理: 查找执行并发标记阶段从年轻代晋升到老年代的对象
- 重新标记: 暂停虚拟机，扫描CMS堆中的剩余对象
- 并发清理: 清理垃圾对象，程序不回停顿
- 并发重置: 重置CMS收集器的数据结构
即用于年轻代又用于老年代的垃圾收集器
G1收集器(-XX:+UseG1GC, 复制-标记整理算法)
并行和并发
分代收集
空间整合
可预测的停顿
将整个Java堆内存分成多个大小相等的Region
年轻代和老年代不再物理隔离
Java中的强引用，软引用，弱引用，虚引用
| 引用类型 | 垃圾回收时间 | 用途 | 生存时间 |
|---|---|---|---|
| 强引用 | 从来不会 | 对象的一般状态 | JVM停止运行时 |
| 软引用 | 在内存不足时 | 对象缓存 | 内存不足时终止 |
| 弱引用 | 在垃圾回收时 | 对象缓存 | gc运行后终止 |
| 虚引用 | Unknown | 标记、哨兵 | Unknown |
强引用
最普遍的引用：Object obj = new Onject()
抛出OutOfMemoryError终止程序也不会回收具有强引用的对象
通过将对象设置为null来弱化引用，使其被回收
软引用
对象处在有用但非必须的状态
只有当内存空间不足时，GC会回收该引用的对象的内存
可以用来实现高速缓存
String abc = new String("lizhenheng"); // 强引用
SoftReference<String> softReference = new SoftReference<String>(abc); // 软引用
弱引用
非必须的对象，比弱引用更弱一些
GC时会被回收
被回收的概率也不大，因为GC线程优先级比较低
适用于引用偶尔被使用且不影响垃圾收集的对象
String abc = new String("lizhenheng"); // 强引用
WeakReference<String> softReference = new WeakReference<String>(abc); // 弱引用
虚引用
不会决定对象的生命周期
任何时候都可能被垃圾收集器回收
跟踪对象被垃圾收集器回收的活动，起哨兵作用
必须和引用队列ReferenceQueue联合使用
