GC-详解

引用计数：解决不了互相引用的问题
GC Roots可达性分析
GC Roots对象：jvm栈，native栈，static ，常量(这个点不要太纠结，比如字符串常量本身就是root)
强，软（oom之前回收），弱（下一次gc回收），虚（唯一作用就是gc时能收到系统通知）
若对象只被弱引用，下一次gc回收，导致弱引用指向null
若重写finalize方法，且以前没有调用它，则可调用finalize方法，可完成一次对象的自救
回收方法区：
回收常量（如"abc"）
回收类/类卸载（无实例，ClassLoader被回收了，Class对象不被引用）
算法：标记-清除（内存碎片）
复制（可用内存小了，hotspot新生代：8:1:1,将eden和survivor的存活对象复制到另一块survivor，内存不够，担保入老年代）
标记-整理：存活对象一端移动
分代收集：新生代复制，老年代标记-清除或标记-整理

GC Roots可达性分析中（找出所有需回收/存活对象），引用关系不能变化，必须停顿执行线程（ stop the world），线程不是在哪里都可以停顿的，必须进入safepoint（方法调用，循环末尾，异常点去test是否gc要求暂停） saferegion（线程进入后引用关系不再改变（如sleep或blocked，或者只要引用关系不改变就好），gc不管在saferegion的线程（不要求线程中断），线程离开saferegion检查gc roots枚举是否完成），即有些线程本来就是blocked，防止这样的线程离开saferegion

垃圾收集里的并行（多个gc线程），并发（多个gc线程且用户线程也可以运行，只有cms）
Serial：单线程，stw，简单高效
ParNew：Serial的多线程版本，单cpu选Serial（减少线程切换开销），多cpuParNew
Parallel Scavenge：关注吞吐量（总垃圾回收时间短，适合后台运算），其他的一般关注停顿时间（用户体验）-XX:GCTimeRatio(控制gc总时间占比) -XX:MaxGCPauseMillis（控制单次gc时间）
-XX:+UseAdaptiveSizePolicy,可不用指定-Xmn,-XX:SurvivorRatio等，jvm自适应调节这些参数，省事。
Serial Old：标记-整理 Serial的老年版
Parallel Old：标记-整理 Parallel Scavenge 的老年版（关注吞吐量 Parallel Scavenge+ Parallel Old 绝佳）
CMS：停顿时间很短，标记（初始，并发，重新）-清除
初始标记：时间短，stw，标记GC Roots能直接关联对象
并发标记：gc roots枚举，用户线程可执行，时间长点
重新标记：由于之前用户线程执行导致的引用关系变化，修正一下，也比较短，stw
并发清除：用户线程可执行，时间长点， 会产生新的垃圾，要预留部分内存供程序使用（不能等到老年代满了再触发gc，参数决定老年代到达多少触发gc），这时候预留少了，concurrent mode failure，使用serial old （备用）重新进行gc
内存碎片，需要几次gc后做一个碎片合并整理。
G1：工作在两代，关注吞吐量和停顿时间，用户自定义停顿时间，适合大堆，将堆划为region，每个region可以是eden，survivor，old
整体上是标记+整理算法，两个区域之间是复制算法，跨region的引用需记忆集
初始标记+并发标记+重新标记+筛选回收(回收价值-回收可获得空间和成本-时间对region排序，根据用户期望的停顿时间)
ZGC也可了解下
跨代引用：我回收新生代，会不会有老年代指向新生代(极少)，我在新生代进行gc roots枚举+记忆集(old指向young的指针，卡表是记忆集的一种实现)

full/major gc：比较慢，一般出现都伴有一次minor gc
对象优先在eden分配，内存不够，minor gc，minor gc后survivor放不下，担保入老年代
大对象直接老年代（-XX:PretenureSizeThreshold）
长期存活直接老年代（-XX:MaxTenuringThreshold）
同年对象大小超过survivor一半，大于等于此年对象进入老年代，年指分代年龄
担保入老年代老年代也可能放不下？minor gc前做判断
1 老年代最大连续空间 > 新生代对象总大小, 可minor gc
2 可冒险(HandlePromotionFailure) 且 老年代最大连续空间 > 历次晋升平均大小 ，可minor gc
3 其它，直接 full gc