JVM深入

JDK8默认par收集器
垃圾收集器：
1.serial：单线程的收集器（复制算法）

2.serial Old：serial老年代版本（标记整理算法）

为什么会是单线程？
Java刚开始的时候是用于嵌入式设备编写，如单片机，且CPU当时也只有单核，没有考虑到多线程的情况。

3.parNew：serial多线程版本，还是会STW，有停顿时间 此收集器关注：停顿时间

停顿时间吞吐量 = 业务代码的时间/(业务代码的时间+垃圾收集的时间) = 99%
4.Parallel Scavenge：复制算法 并行 此收集器关注：吞吐量
5. Parallel Old：多线程+标记整理算法 Parallel Scavenge的老年代版本
6. 并发类的收集器CMS 标记清除 缺点：产生空间碎片 优点：并发

什么是并发？什么是并行？
并发：单位时间内，能承受多少用户，能完成多少业务。关注最终执行状态。
并行：如上图，多个垃圾收集器并行执行。关注执行过程。

如上图，
初始标记，找Gcroot，依赖产生变化后，
重新标记实际为增量标记，标记出并发标记后产生的垃圾对象，最好再去清理，用时较短。

面试细节：为什么初始标记为单线程？ 重新标记为多线程？
初始标记很快，没有必要额外开线程去进行标记，有可能开线程的开销比标记的开销更大。
并发标记，要缩短停顿时间
重新标记，因为并发标记时已经创建了线程，直接用就行，开销小
7. G1（Garbage-First）增量回收算法 ：CMS停顿时间变得更短 短到开发者可以自己定义 解决我们空间碎片的问题
JDK1.8推荐使用 JDK1.9默认使用
例：如回收一次垃圾200s，用户设置150s，那将如何实现？
标记垃圾优先级，按垃圾优先级进行GC（偷工减料）

8.Region 逻辑上存在Eden和Old 可以相互转换
9.zgc JDK11 z->zero 且必须在liunx64位下使用 停顿时间控制在10ms以内

垃圾收集器分类，见图

JVM参数
标准参数：不会随着我们JDK的版本变化而变化

非标准参数：随着我们的JDK的版本变化而变化

-X
-XX
Boolean
XX[+/-] + value -XX+UseG1GC
name -value -XX：initiaHeapSize -100M -XX：MaxHeapSize=100M

设置参数的场景

1. 开发工具里面
2. 运行Java类里
3. 中间件 配置文件
4. 实时去改 jinfo