G1垃圾回收器
目录
G1是什么
Garbage-First收集器，是一款面向服务端应用的收集器，应用在多处理器和大容量内存环境中，实现了高吞吐量的同时尽可能满足垃圾收集暂停时间的要求。具有以下特征：
- 像CMS收集器一样，能与应用程序并发执行
- 整理空闲空间更快
- 需要更多时间来预测GC停顿时间
- 不希望牺牲大量的吞吐量性能
- 不需要更大的Java Heap
- Eden、Survivor和Tenured等内存区域不再是连续了，而是变成一个个大小一样的region，每个region从1M到32M不等。一个region有可能属于Eden，Survivor或者Tenured内存区域
G1收集器设计的目标是取代CMS收集器，它同CMS相比，在以下方面表现的更出色
- 是一个整理内存过程的垃圾收集器，不会产生很多内存碎片。
- G1的停顿时间更可控，G1在停顿时间上添加了预测机制，用户可指定期望停顿时间
G1从JDK1.9开始变成了默认的垃圾收集器，替换掉了CMS，它是一款面向服务端应用的收集器，主要应用再多CPU和大内存服务器下，极大减少垃圾收集的停顿时间，全面提升服务器性能。
G1的原理
Region区域化垃圾收集器，化整为零，打破了原来新生区和老年区的壁垒，避免了全内存扫描，只需要安装区域来进行扫描即可
核心思想是将整个堆内存区域分成大小相同的子区域Region，在JVM启动时会自动设置子区域大小。
在堆的使用上，G1并不要求对象的存储一定是物理上连续的，只要逻辑上连续即可。每个没去也不会固定地为某个代服务，可以按需在年轻代和老年代之间切换。启动时可通过参数-XX:G1HeapRegionSize=n指定分区大小(1MB-32MB)，默认将堆分为2048个分区，即能够支持的最大内存为64GB
区域化的垃圾回收
区域中存的有可能是伊甸园区、幸存者区、老年代区或者一个Humongous区域，用来存储一个占用分区容量50%以上的对象，这些对象默认直接分配在老年代，如果他是短期存在的巨型对象就会对垃圾收集器造成负面影响，为了解决此问题，G1使用“H”区专门存储巨型对象，当没有连续的H区不得不启动Full GC
回收步骤
针对Eden区进行收集，Eden区耗尽后会被触发，主要是小区域收集 + 形成连续的内存块，避免内碎片
- Eden区的数据移动到Survivor区，假如出现Survivor区空间不够，Eden区数据会晋升到Old区
- Survivor区的数据移动到新的Survivor区，部分数据晋升到Old区
- 最后Eden区收拾干净了，GC结束，用户的应用程序继续执行
回收前
回收后
回收过程
- 初始标记：只标记GC Roots能直接关联到的对象
- 并发标记：进行GC Roots Tracing（链路扫描）的过程
- 最终标记：修正并发标记期间，因为程序运行导致标记发生变化的那一部分对象
- 筛选回收：根据时间来进行价值最大化回收
参数配置
开发人员仅仅需要申明以下参数即可
三步归纳：-XX:+UseG1GC -Xmx32G -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=n：最大GC停顿时间单位毫秒，这是个软目标，JVM尽可能停顿小于这个时间
G1和CMS比较
- G1不会产生内存碎片
- 是可以精准控制停顿。该收集器是把整个堆（新生代、老年代）划分成多个固定大小的区域，每次根据允许停顿的时间去收集垃圾最多的区域。
SpringBoot结合JVMGC
启动微服务时候，就可以带上JVM和GC的参数
- IDEA开发完微服务工程
- maven进行clean package
- 要求微服务启动的时候，同时配置我们的JVM/GC的调优参数
- 我们就可以根据具体的业务配置我们启动的JVM参数
例如：
java -Xms1024m -Xmx1024 -XX:UseG1GC -jar xxx.jar