JVM知识点整理
JVM
- 回收哪个区域？
-
-
- 关联面试题：fullgc会回收方法区（元空间）吗?
-
- 怎么判断对象可以被回收了
-
- 关联面试题：哪些对象可以作为 GC Root （两栈两方法）
- JVM GC什么时候执行？
- 分代回收机制
-
- 思考：假如eden区80m,老年代200m,一个对象90m?
- 各区域触发垃圾回收的类型与解释
-
- 新生代
-
- 新生代GC收集（类比倒水）
- 老年代（为什么老年代的回收耗时，比新生代更长呢）
- 跨代引用的问题
- 方法区
- 回收算法讲解
-
- 标记 - 清除算法
- 标记 - 复制算法
- 标记 - 整理算法
- 常用的垃圾回收器
-
- Serial/Serial Old
- ParNew( 负责收集新生代区域)
- Parallel Scavenge
- Parallel Old
- CMS
-
- CMS 负责收集老年代区域，它采用**标记-清除**算法。
- G1
-
- 运行步骤
- 三色标记（解决或降低用户线程的停顿）
-
-
- 原理流程
- 最终标记和重新标记解决了什么？
-
- 漏标
- 多标
- 读屏障、写屏障
- CMS通过写屏障卡表解决
- G1写屏障rset解决
-
回收哪个区域？
JVM GC只回收堆区和方法区内的基本类型数据和对象。
栈区的数据（仅指基本类型数据），在超出作用域后会自动出栈释放掉，所以其不在JVM GC的管理范围内。
关联面试题：fullgc会回收方法区（元空间）吗?
1.常量对象不再任何地方被引用的时候，这个常量可以被回收
2.无用类（堆中不存在该类的任何实例对象,加载该类的类加载器已经被回收,Class对象不在任何地方被引用）
怎么判断对象可以被回收了
对象不可达
GC Roots 作为起始节点，从这些节点开始，根据引用关系向下搜索，搜索过程的就是一条引用链，没有在这个链条上面的对象，也就是根节点通过引用链不可达到这个对象时，就认为这个对象是可以被回收的。
关联面试题：哪些对象可以作为 GC Root （两栈两方法）
- 虚拟机栈中引用的对象
- 本地方法栈中 JNI引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
public class StaticObj {
public static Object obj = new Object();
//...
}
public class ConstObj {
public static final String STR = "hello";
//...
}
JVM GC什么时候执行？
- 老年代空间不足
- 方法区空间不足
- Eden区和s区不足
- 手动触发gc
分代回收机制
弱分代假说：绝大多数对象都是朝生夕死的。
强分代假说：熬过越多次的垃圾回收的对象，就越难消亡
思考：假如eden区80m,老年代200m,一个对象90m?
老年代的担保机制，如果一个对象大于设定的值那么直接丢到老年代中。
除此之外，当存活的对象超过Survivor空间大小时，这些存活的对象会忽略年龄，直接进入老年代里。
各区域触发垃圾回收的类型与解释
- Minor GC：只回收新生代区域。
- Major GC：只回收老年代区域。只有CMS实现了MajorGC，所以在老年代里，触发GC，除了CMS和G1之外的其他收集器，大多数触发的其实是 Full GC
- Full GC：回收整个堆区和方法区
- Mixed GC：回收整个新生代和部分老年代。G1收集器实现了这个类型。
新生代
默认情况下，新生代（Young generation）、老年代（Old generation）所占空间比例为 1 : 2 。
包含1个伊甸园空间（Eden）， 2个幸存者空间（Fron Survivor、To Survivor）
Eden : Fron : To = 8 : 1 : 1
适合使用标记-复制算法
新生代GC收集（类比倒水）
新创建的对象，是保存在伊甸园空间的（Eden）。那些经历多次GC依然存活的对象会经由幸存者空间（Survivor）转存到老年代空间（Old generation）
老年代（为什么老年代的回收耗时，比新生代更长呢）
1、老年代内存占比更大，所以理论上回收的时间也更长
2、老年代使用的是标记-整理算法，清理完成内存后，还得把存活的对象重新排序整理成连续的空间，成本更高
跨代引用的问题
卡表（Card Table）
每一个卡页，可能会包含N个存在跨区域引用的对象，只要存在跨区域引用的对象，这个卡页就会被标识为1。当GC发生的时候，就不需要扫描整个区域了，只需要把这些被标识为1的卡页加入对应区域的 GC Roots 里一起扫描即可。
方法区
之前引用的面试题已经说明过，这边再重新说明一次
1.常量对象不再任何地方被引用的时候，这个常量可以被回收
2.无用类（堆中不存在该类的任何实例对象,加载该类的类加载器已经被回收,Class对象不在任何地方被引用）
回收算法讲解
标记 - 清除算法
标记出所有存活的对象，再扫描整个空间中未被标记的对象直接回收。
标记 - 复制算法
把内存分成两块大小相同的空间（1 : 1），每次只使用其中一块，当使用中的这块内存用完了，就把存活的对象移动到另一块内存中，再把使用过的这块内存空间一次性清理掉。(依照eden区、survivor区思考)
缺点：这个做法虽然效率极高，但也浪费了一半的内存空间。
标记 - 整理算法
和标记-清除算法一样，先标记，但清除之前，会先进行整理，把所有存活的对象往内存空间的左边移动，然后清理掉存活对象边界以外的内存，即完成了清除的操作。
常用的垃圾回收器
Serial/Serial Old
一个单线程工作的收集器。在进行垃圾回收的时候，需要暂停所有的用户线程，直到回收结束。
ParNew( 负责收集新生代区域)
ParNew 就是 在Serial 收集器的基础之上，实现了它的多线程版本。
Parallel Scavenge
和 ParNew 很相似，都是新生代的收集器，支持多线程并行回收，也同样是使用标记-复制来作为回收算法。
区别：实现一个可控制吞吐量的垃圾收集器。
Parallel Old
Parallel Old 是 Parallel Scavenge 的老年代版本
CMS
CMS 负责收集老年代区域，它采用标记-清除算法。
- 初始标记
STW,GC Root直接关联的对象 - 并发标记
并发标记从GC Roots直接关联的对象开始，遍历整个引用链，这个阶段耗时较长，但用户线程可以和GC线程一起并发执行。 - 重新标记
STW,重新标记就是修正用户线程继续运行，导致的变动的那一部分对象 - 并发清理
缺陷：
1.内存碎片。由于使用了 标记-清理 算法，回收结束后会产生大量不连续的内存空间，也就是内存碎片。
2.GC进行时会降低吞吐量。
3.浮动垃圾。CMS有两个阶段是可以用户线程和GC线程并发执行的，用户线程的继续执行自然会伴随垃圾的不断产生，这些就是浮动垃圾。这些垃圾只能等下次触发GC的时候才能清除了
G1
G1 收集器的设计理念是：实现一个停顿时间可控的低延迟垃圾收集器。
G1 依然遵循分代回收的设计理论，但它对堆（Java Heap）内存进行了重新布局，不再是简单的按照新生代、老年代分成两个固定大小的区域了，而是把堆区划分成很多个大小相同的区域（Region），新、老年代也不再固定在某个区域了，每一个Region都可以根据运行情况的需要，扮演Eden、Survivor、老年代区域、或者Humongous区域。
运行步骤
1.初始标记
只标记 GC Roots 能直接关联的对象
2.并发标记
从根节点（GC Root）开始，顺着引用链遍历整个堆，找出存活的对象。这个步骤耗时较长，但用户线程可以和GC线程并发执行。
3.最终标记
处理并发标记阶段，用户线程继续运行产生的引用变动，这个阶段需要暂停用户线程，支持并行处理。
4.筛选回收
计算出各个Region的回收价值和成本，再根据用户期望的停顿时间来决定要回收多少个Region。
回收使用的是复制算法，把需要回收的这些Region里存活的对象，复制到空闲的Region中，然后清理掉旧Region全部空间。
三色标记（解决或降低用户线程的停顿）
原理流程
初始标记
并发标记
此时黑色对象就是存活的对象，白色对象就是已消亡可回收的对象。
最终标记和重新标记解决了什么？
漏标
D此时所有引用已经扫描过，但是此时D->G,但是对于GC线程来说，是不知道这个引用的，就会产生漏标。
多标
D->E 引用断开，E、F、G不可达。
读屏障、写屏障
在读写前后，将变动节点记录下来（对象 G） 给记录下来。（可以想象成AOP）
CMS通过写屏障卡表解决
卡表是一个与Java堆大小相同的数组，每个元素记录着相应内存区域是否被修改。当用户线程修改了某个被标记的对象的指针时，就会由卡表中相应的条目被设置为“dirty”。垃圾收集器会检查卡表中所有“dirty”条目所对应的内存区域。
G1写屏障rset解决
Remembered Set（RSet），它是一种专门针对并发标记整理算法的优化，它能够更方便和高效地记录所有引用了老年代对象的新生代对象，避免了传统卡表方式在处理跨代引用时需要全局扫描卡表的缺点。
当某个Region的对象被修改时，处理这个Region的线程需要扫描该Region的RSet，找到其他Region中指向该Region的对象，