三、垃圾回收
1、如何判断对象可以回收( 标记阶段）
1.1 引用计数法
引用计数法：弊端：循环引用时，两个对象的计数都为1，导致两个对象都无法被释放
1.2 可达性分析算法
Java 虚拟机中的垃圾回收器采用可达性分析来探索所有存活的对象
扫描堆中的对象，看是否能够沿着 GC Root对象 为起点的引用链找到该对象，找不到，表示可以回收
哪些对象可以作为 GC Root ?
- 虚拟机栈（栈帧中的本地变量表）中引用的对象。
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI（即一般说的Native方法）引用的对象
1.3 四种引用
2、垃圾回收算法 （清除）
2.1 标记清除
定义：标记清除算法顾名思义，是指在虚拟机执行垃圾回收的过程中，先采用标记算法确定可回收对象，然后垃圾收集器根据标识清除相应的内容，给堆内存腾出相应的空间。
这里的腾出内存空间并不是将内存空间的字节清0，而是记录下这段内存的起始结束地址，下次分配内存的时候，会直接覆盖这段内存。
缺点：容易产生大量的内存碎片，可能无法满足大对象的内存分配，一旦导致无法分配对象，那就会导致jvm启动gc，一旦启动gc，我们的应用程序就会暂停，这就导致应用的响应速度变慢。
2.2 标记整理
标记-整理 会将不被GC Root引用的对象回收，清楚其占用的内存空间。然后整理剩余的对象，可以有效避免因内存碎片而导致的问题，但是因为整体需要消耗一定的时间，所以效率较低。
2.3 复制
将内存分为等大小的两个区域，FROM和TO（TO中为空）。先将被GC Root引用的对象从FROM放入TO中，再回收不被GC Root引用的对象。然后交换FROM和TO。这样也可以避免内存碎片的问题，但是会占用双倍的内存空间。
3、分代回收
对象首先分配在伊甸园区域。
新生代空间不足，触发Minor GC,伊甸园和From存活的对象使用Copy复制到TO中，存活的对象年龄加1并交换 from to
Minor GC 会引发Stop the world(在执行垃圾收集算法时，Java应用程序的其他所有线程都被挂起（除了垃圾收集帮助器之外）),之所以要暂停其他用户的线程，是因为在垃圾回收的过程中牵扯到对象的复制，即对象地址的改变，这种情况下，如果多个线程都在同时运行，就会造成一个混乱，对象都已经移动，其他线程再访问这个对象，根据原来的地址就找不到这个对象，所以才会引发STW。暂停其他用户线程，等垃圾回收成后，用户线程才能继续。
当对象寿命超过阈值时会晋升至老年代，最大寿命是15次（4bit）。
当老年代空间不足，会先尝试触发Minor GC,如果之后空间仍不足，会触发一次Full GC。FULL GC也会引起STW,只是老年代对应的STW时间更长。
3.1 回收过程
简而言之： 对象创建后在伊甸园区；新生代满了miner GC; 老年代满了full GC , 但是之前先miner GC
3.2 相关VM参数
3.3 GC分析
大对象处理策略
当遇到一个较大的对象时，就算新生代的伊甸园为空，也无法容纳该对象时，会将该对象直接晋升为老年代。
线程内存溢出
某个线程的内存溢出了而抛异常（out of memory），不会让其他的线程结束运行。这是因为当一个线程抛出OOM异常后，它所占据的内存资源会全部被释放掉，从而不会影响其他线程的运行，进程依然正常。
4、垃圾回收器
4.1 概念
并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上
吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )），也就是。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%
4.2 串行
（1）Serial 收集器
Serial收集器是最基本的、发展历史最悠久的收集器
特点：单线程、简单高效（与其他收集器的单线程相比），采用复制算法。对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）
（2）ParNew 收集器
ParNew收集器其实就是Serial收集器的多线程版本
特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。和Serial收集器一样存在Stop The World问题
（3）Serial Old 收集器
Serial Old是Serial收集器的老年代版本
特点：同样是单线程收集器，采用标记-整理算法
4.3 吞吐量优先
（1）Parallel Scavenge 收集器
与吞吐量关系密切，故也称为吞吐量优先收集器
特点：属于新生代收集器也是采用复制算法的收集器（用到了新生代的幸存区），又是并行的多线程收集器（与ParNew收集器类似）
该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）
GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。
Parallel Scavenge收集器使用两个参数控制吞吐量：
XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间
XX:GCRatio 直接设置吞吐量的大小
（2）Parallel Old 收集器
是Parallel Scavenge收集器的老年代版本
特点：多线程，采用标记-整理算法（老年代没有幸存区）
4.4 响应时间优先
（1）CMS 收集器
Concurrent Mark Sweep，一种以获取最短回收停顿时间为目标的老年代收集器
特点：基于标记-清除算法实现。并发收集、低停顿，但是会产生内存碎片
应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务
CMS收集器的运行过程分为下列4步：
- 初始标记：标记GC Roots能直接关联到的对象。速度很快但是仍存在Stop The World问题
- 并发标记：进行GC Roots Tracing 的过程，找出所有的存活对象且用户线程可并发执行
- 重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题
- 并发清除：对标记的对象进行清除回收
CMS收集器的内存回收过程是与用户线程一起并发执行的
（2）G1 回收器
4.4 G1垃圾回收
（1）G1垃圾回收阶段
初始标记为什么需要STW？
因为初始标记标记的是GC Root，而GC Root容易变动，比如栈帧中的本地变量表。所以需要STW。
重新标记为什么需要STW？
因为在重新标记之前是并发标记，在并发标记的期间会出现漏标和多标的对象，所以为了修正这部分对象，需要在重新标记期间STW。
（2）Young Collection
分代是按对象的生命周期划分，分区则是将堆空间划分连续几个不同小区间，每一个小区间独立回收，可以控制一次回收多少个小区间，方便控制 GC 产生的停顿时间
E：伊甸园 S：幸存区 O：老年代
会STW
（3）Young Collection+CM
CM：并发标记
在 Young GC 时会对 GC Root 进行初始标记
在老年代占用堆内存的比例达到阈值时，对进行并发标记（不会STW），阈值可以根据用户来进行设定
（4）Mixed Collection （G1独有的）
会对E S O 进行全面的回收：最终标记。拷贝存活。
-XX:MaxGCPauseMills:xxx 用于指定最长的停顿时间
问：为什么有的老年代被拷贝了，有的没拷贝？
因为指定了最大停顿时间，如果对所有老年代都进行回收，耗时可能过高。为了保证时间不超过设定的停顿时间，会回收最有价值的老年代（回收后，能够得到更多内存）
（5）Full Collection
G1在老年代内存不足时（老年代所占内存超过阈值）
如果垃圾产生速度慢于垃圾回收速度，不会触发Full GC，还是并发地进行清理
如果垃圾产生速度快于垃圾回收速度，便会触发Full GC
（6）Young Collection 跨代引用
（7）Remark
重新标记阶段
在垃圾回收时，收集器处理对象的过程中
黑色：已被处理，需要保留的 灰色：正在处理中的 白色：还未处理的
但是在并发标记过程中，有可能A被处理了以后未引用C，但该处理过程还未结束，在处理过程结束之前A引用了C，这时就会用到remark
过程如下
- 之前C未被引用，这时A引用了C，就会给C加一个写屏障，写屏障的指令会被执行，将C放入一个队列当中，并将C变为 处理中 状态
- 在并发标记阶段结束以后，重新标记阶段会STW，然后将放在该队列中的对象重新处理，发现有强引用引用它，就会处理它
（8）JDK 8U20 字符串去重
过程
- 将所有新分配的字符串（底层是char[]）放入一个队列
- 当新生代回收时，G1并发检查是否有重复的字符串
- 如果字符串的值一样，就让他们引用同一个字符串对象
- 注意，其与String.intern的区别：intern关注的是字符串对象。字符串去重关注的是char[]。在JVM内部，使用了不同的字符串标。
优点与缺点
- 节省了大量内存
- 新生代回收时间略微增加，导致略微多占用CPU
（9）JDK 8U40 并发标记类卸载
在并发标记阶段结束以后，就能知道哪些类不再被使用。如果一个类加载器的所有类都不在使用，则卸载它所加载的所有类
（10）JOK 8U60 回收巨型对象
- 一个对象大于region的一半时，就称为巨型对象
- G1不会对巨型对象进行拷贝
- 回收时被优先考虑
- G1会跟踪老年代所有incoming引用，如果老年代incoming引用为0的巨型对象就可以在新生代垃圾回收时处理掉
（11）JDK9 并发标记起始时间的调整
- 并发标记必须在堆空间占满前完成，否则退化为 FullGC
- JDK 9 之前需要使用 -XX:InitiatingHeapOccupancyPercent
- JDK 9 可以动态调整：-XX:InitiatingHeapOccupancyPercent 用来设置初始值；进行数据采样并动态调整；总会添加一个安全的空档空间。
（12）JDK9 更高效的回收
5、垃圾回收调休
5.1 调优领域
查看虚拟机参数命令
"F:\JAVA\JDK8.0\bin\java" -XX:+PrintFlagsFinal -version | findstr "GC"
可以根据参数去查询具体的信息
- 调优领域
- 内存
- 锁竞争
- CPU占用
- IO
- GC
5.2 确定目标
低延迟/高吞吐量？ 选择合适的GC
- CMS G1 ZGC
- ParallelGC
- Zing
5.3 最快的GC
（1）答案是不发生 GC
（2）查看 FullGC 前后的内存占用，考虑下面几个问题
- 数据是不是太多？
resultSet = statement.executeQuery("select * from 大表 limit n")
- 数据表示是否太臃肿？
对象图
对象大小 16 Integer 24 int 4
- 是否存在内存泄漏？
static Map map =
软弱
第三方缓存实现
5.4 新生代调优
（1）新生代的特点
- 所有的new操作分配内存都是非常廉价的，TLAB
- 死亡对象回收零代价
- 大部分对象用过即死（朝生夕死）
- MInor GC 所用时间远小于Full GC
（2）新生代内存越大越好么？
- 不是。
新生代内存太小：频繁触发Minor GC，会STW，会使得吞吐量下降
新生代内存太大：老年代内存占比有所降低，会更频繁地触发Full GC。而且触发Minor GC时，清理新生代所花费的时间会更长
- 合适的大小
新生代内存设置为内容纳[并发量*(请求-响应)]的数据为宜
幸存区需要能够保存 当前活跃对象+需要晋升的对象
晋升阈值配置得当，让长时间存活的对象尽快晋升
5.5 老年代调优
以 CMS 为例
CMS 的老年代内存越大越好
先尝试不做调优，如果没有 Full GC 那么已经...，否则先尝试调优新生代
观察发生 Full GC 时老年代内存占用，将老年代内存预设调大 1/4 ~ 1/3
-XX:CMSInitiatingOccupancyFraction=percent
5.6 案例
案例1 Full GC 和 Minor GC频繁
答案：先增大新生代内存，并且让生命周期的短的留在新生代，然后再看。
案例2 请求高峰期发生 Full GC，单次暂停时间特别长 （CMS），需要低延时
答案：查看哪一部分耗时长，GC日志哪一个部分耗时长（比如重新标记，CMS会扫描所有对象）。在重新标记之前，在新生代（Minor GC）做垃圾清除，那么重新标记的数量就少了。
案例3 老年代充裕情况下，发生 Full GC （CMS jdk1.7）
答案：JDK的版本查看。方法区，1.7 之前是永久代，可能不足；方法区：1.8之后是元空间，充足。
