JVM垃圾回收
目录java
JVM垃圾回收
定义
程序的运行必然须要申请内存资源，无效的对象资源若是不及时处理就会一直占有内存 资源，最终将致使内存溢出，因此对内存资源的管理是很是重要了。
C/C++语言的垃圾回收 在C/C++语言中，没有自动垃圾回收机制，是经过new关键字申请内存资源，经过delete 关键字释放内存资源。 若是，程序员在某些位置没有写delete进行释放，那么申请的对象将一直占用内存资源， 最终可能会致使内存泄露。
Java语言的垃圾回收 为了让程序员更专一于代码的实现，而不用过多的考虑内存释放的问题，因此，在Java语 言中，有了自动的垃圾回收机制，也就是咱们熟悉的GC（Garbage Collection）。 有了垃圾回收机制后，程序员只须要关心内存的申请便可，内存的释放由系统自动识别 完成。 换句话说，自动的垃圾回收的算法就会变得很是重要了，若是由于算法的不合理，致使 内存资源一直没有释放，一样也可能会致使内存泄露的。git
JVM 垃圾回收的过程
对象在Eden Space建立，当Eden Space满了的时候，gc就把全部在Eden Space中的对象扫描一次，把全部有效的对象复制到第一个Survivor Space，同时把无效的对象所占用的空间释放。当Eden Space再次变满了的时候，就启动移动程序把Eden Space中有效的对象复制到第二个Survivor Space，同时，也将第一个Survivor Space中的有效对象复制到第二个Survivor Space。若是填充到第二个Survivor Space中的有效对象被第一个Survivor Space或Eden Space中的对象引用，那么这些对象就是长期存在的，此时这些对象将被复制到Permanent Generation。若垃圾收集器依据这种小幅度的调整收集不能腾出足够的空间，就会运行Full GC，此时JVM GC中止全部在堆中运行的线程并执行清除动做。程序员
垃圾回收算法
自动化的管理内存资源，垃圾回收机制必需要有一套算法来进行计算，哪些是有效的对 象，哪些是无效的对象，对于无效的对象就要进行回收处理。 常见的垃圾回收算法有：引用计数法、标记清除法、标记压缩法、复制算法、分代算法 等。github
引用计数法
假设有一个对象A，任何一个对象对A的引用，那么对象A的引用计数器+1，当引用失败 时，对象A的引用计数器就-1，若是对象A的计数器的值为0，就说明对象A没有引用了， 能够被回收web
算法分析
- 优势：
-- 实时性较高，无需等到内存不够的时候，才开始回收，运行时根据对象的计数器是否
为0，就能够直接回收。
-- 在垃圾回收过程当中，应用无需挂起。若是申请内存时，内存不足，则马上报
outofmember 错误。
-- 区域性，更新对象的计数器时，只是影响到该对象，不会扫描其余的所有对象。 - 缺点：
-- 每次对象被引用时，都须要去更新计数器，有一点时间开销。
-- 浪费CPU资源，即便内存够用，仍然在运行时进行计数器的统计。
-- 没法解决循环引用问题。（最大的缺点）
引用计数法的循环引用问题
以下所示，即便a和b都为null，可是因为a和b存在循环引用，这样a和b永远都不会被回收算法
class TestA{
public TestB b;
}
class TestB{
public TestA a;
}
public class Main{
public static void main(String[] args){
A a = new A();
B b = new B();
a.b=b;
b.a=a;
a = null;
b = null;
}
}
标记清除法
标记清除算法主要就是为了解决引用计数法没法解决的循环引用问题。标记清除法将垃圾回收分为2个阶段，分别是标记和清除。
-- 标记：从根节点开始标记引用的对象。
-- 清除：未被标记引用的对象就是垃圾对象，能够被清理服务器
- 标记
当开始执行标记清楚垃圾回收时，JVM会中止应用程序的运行并开启GC线程，注意这里JVM 在GC前会通知应用程序中止运行，由于若是不中止运行则不能准确的标记线程。而后开始根据搜索算法搜索全部对象并做标记。
照根搜索算法，全部从root对象可达的对象就被标记为了存活的对象，此 时已经完成了第一阶段标记。接下来，就要执行第二阶段清除并发
- 清除
根据标记的结果，没有被标记的对象将会回收清除掉，而被标记的对象将会留下，而且会将标 记位从新归0。
接下来，唤醒中止的程序线程，让程序继续运行oracle
算法分析
优势
标记清除算法解决了引用计数算法中的循环引用的问题，没有从root节点引 用的对象都会被回收dom缺点
-- 效率较低，标记和清除两个动做都须要遍历全部的对象，而且在GC时，须要中止应 用程序，对于交互性要求比较高的应用而言这个体验是很是差的。
-- 碎片化，经过标记清除算法清理出来的内存，碎片化较为严重，由于被回收的对象可能存在于 内存的各个角落，因此清理出来的内存是不连贯的。
标记清除改进算法-压缩标记算法
标记清楚法，有个很明显的肯定就是清楚后的内存碎片化严重，而标记压缩算法是在标记清除算法的基础之上，作了优化改进的算法。和标记清除算法一 样，也是从根节点开始，对对象的引用进行标记，在清理阶段，并非简单的清理未标 记的对象，而是将存活的对象压缩到内存的一端，而后清理边界之外的垃圾，从而解决 了碎片化的问题。
算法分析
- 优势
解决了碎片化问题 - 缺点
清理过程当中增长了移动内存的步骤，效率相对较低
复制算法
复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块，在垃圾回收 时，将正在使用的对象复制到另外一个内存空间中，而后将该内存空间清空，交换两个内存的角色，完成垃圾的回收。 若是内存中的垃圾对象较多，须要复制的对象就较少，这种状况下适合使用该方式而且 效率比较高，反之，则不适合
在JVM年轻代内存空间使用的就是复制算法
JVM年轻代内存空间的复制算法过程
- 在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor 区“To”是空的。
- 紧接着进行GC，Eden区中全部存活的对象都会被复制到“To”，而在“From”区中，仍 存活的对象会根据他们的年龄值来决定去向。年龄达到必定值(年龄阈值，能够经过XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对 象会被复制到“To”区域。
- 通过此次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他 们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前 的“To”。无论怎样，都会保证名为To的Survivor区域是空的。
- GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满以后，会将全部对象 移动到年老代中。
算法分析
- 优势： 在垃圾对象多的状况下，效率较高 清理后，内存无碎片
- 缺点：
-- 在垃圾对象少的状况下，不适用，如：老年代内存
-- 内存使用率较低，分配的2块内存空间，在同一个时刻，只能使用一半，内存使用率较低
JVM 回收策略--分代算法
前面说了4种回收算法，每一种算法都有优缺点，在实际的JVM垃圾回收中，就采用了分代算法来处理实际的垃圾回收，即根据JVM的内存分区采起不一样的垃圾回收算法。
年轻代：
年轻代存放的是新建立的对象，内存空间相对小垃圾回收频繁，大多数对象存在时间短朝生夕死，因此采用的是复制算法，来做垃圾回收年老代：
年老代存放的是JVM认为生命周期比较长的对象，即经在年轻代通过垃圾回收仍然存在的对象会被放入年老代，同时年老代的内存空间也相对更大，GC没有年轻代频繁。年老代主要采用标记清楚法或压缩标记法来避免内存碎片。
垃圾收集器
前面说了垃圾回收的算法，但还须要有具体的实现，在jvm中，实现了多种垃圾收集器，包括：串行垃圾收集器、并行垃圾收集器、CMS(并发)垃圾收集器、G1垃圾收集器，
串行垃圾收集器 DefNew
使用单线程进行垃圾回收，垃圾回收时，只有一个线程在工做， 而且java应用中的全部线程都要暂停，等待垃圾回收的完成。这种现象称之为 STW（Stop-The-World）。 对于交互性较强的应用而言，这种垃圾收集器是不可以接受的。 通常在Javaweb应用中是不会采用该收集器的。
package JavaCore.JVM.GC;
import java.util.ArrayList;
import java.util.List;
import java.util.Properties;
import java.util.Random;
/*******************************************************************************
* @Copyright (C), 2018-2019,github:Swagger-Ranger
* @FileName: TestGC
* @Author: liufei32@outlook.com
* @Date: 2019/4/11 15:08
* @Description: 测试串行GC，查看GC过程
* @Aha-eureka: IDEA配置运行参数VM options：-XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m
* -XX:+UseSerialGC 使用串行垃圾回收
* -XX:+PrintGCDetails 打印垃圾回收信息
* -Xms16m -Xmx16m 设置VM启动内存大小和最大内存大小
*
*
* [0.009s][warning][gc] -XX:+PrintGCDetails is deprecated. Will use -Xlog:gc* instead.
* [0.022s][info ][gc] Using Serial
* [0.022s][info ][gc,heap,coops] Heap address: 0x00000000ff000000, size: 16 MB, Compressed Oops mode: 32-bit
* [0.308s][info ][gc,start ] GC(0) Pause Young (Allocation Failure) <---- Pause Young (Allocation Failure) 开始年轻代GC，不包括年老代，GC缘由Allocation Failure内存分配失败，即内存耗光，自己设置16M，年轻代分配的确定就更小
* [0.316s][info ][gc,heap ] GC(0) DefNew: 4416K->512K(4928K) <---- DefNew：开始串行回收，4416k开始回收时占用内存，512k回收后占用内存，4928k总共内存
* [0.316s][info ][gc,heap ] GC(0) Tenured: 0K->2100K(10944K) <---- 能够看出回收前占用0，回收后占用2100k，有年轻代的对象被放入了年老代
* [0.316s][info ][gc,metaspace ] GC(0) Metaspace: 6580K->6580K(1056768K) <---- 在这个GC过程当中没有动方法区中的对象
* [0.316s][info ][gc ] GC(0) Pause Young (Allocation Failure) 4M->2M(15M) 8.220ms
* [0.317s][info ][gc,cpu ] GC(0) User=0.02s Sys=0.00s Real=0.01s
* [0.340s][info ][gc,start ] GC(1) Pause Young (Allocation Failure)
* [0.349s][info ][gc,heap ] GC(1) DefNew: 4928K->512K(4928K)
* [0.349s][info ][gc,heap ] GC(1) Tenured: 2100K->5016K(10944K)
* [0.349s][info ][gc,metaspace ] GC(1) Metaspace: 6580K->6580K(1056768K)
* [0.349s][info ][gc ] GC(1) Pause Young (Allocation Failure) 6M->5M(15M) 8.863ms
* [0.349s][info ][gc,cpu ] GC(1) User=0.02s Sys=0.00s Real=0.01s
* [0.454s][info ][gc,start ] GC(2) Pause Young (Allocation Failure)
* [0.460s][info ][gc,heap ] GC(2) DefNew: 4928K->512K(4928K)
* [0.460s][info ][gc,heap ] GC(2) Tenured: 5016K->7894K(10944K)
* [0.460s][info ][gc,metaspace ] GC(2) Metaspace: 6580K->6580K(1056768K)
* [0.460s][info ][gc ] GC(2) Pause Young (Allocation Failure) 9M->8M(15M) 6.236ms
* [0.460s][info ][gc,cpu ] GC(2) User=0.02s Sys=0.00s Real=0.01s
* ......
* [0.904s][info ][gc,cpu ] GC(7) User=0.00s Sys=0.00s Real=0.00s
* [1.057s][info ][gc,start ] GC(8) Pause Young (Allocation Failure)
* [1.057s][info ][gc,start ] GC(9) Pause Full (Allocation Failure) <----Pause Full (Allocation Failure) 内存分配失败，全部内存空间开始所有GC,即包括老年代
* [1.057s][info ][gc,phases,start] GC(9) Phase 1: Mark live objects <----能够看出采用了压缩标记法，先标记存活的对象
* [1.061s][info ][gc,phases ] GC(9) Phase 1: Mark live objects 3.279ms
* [1.061s][info ][gc,phases,start] GC(9) Phase 2: Compute new object addresses <----计算内存大小
* [1.064s][info ][gc,phases ] GC(9) Phase 2: Compute new object addresses 3.114ms
* [1.064s][info ][gc,phases,start] GC(9) Phase 3: Adjust pointers <----调整内存引用
* [1.066s][info ][gc,phases ] GC(9) Phase 3: Adjust pointers 2.074ms
* [1.066s][info ][gc,phases,start] GC(9) Phase 4: Move objects <----移动对象
* [1.067s][info ][gc,phases ] GC(9) Phase 4: Move objects 0.777ms
* [1.067s][info ][gc ] GC(9) Pause Full (Allocation Failure) 13M->3M(15M) 9.637ms
* [1.067s][info ][gc,heap ] GC(8) DefNew: 4928K->0K(4928K)
* [1.067s][info ][gc,heap ] GC(8) Tenured: 8674K->3340K(10944K)
* ......
* [2.327s][info ][gc ] GC(16) Pause Young (Allocation Failure) 8M->6M(15M) 3.350ms
* [2.327s][info ][gc,cpu ] GC(16) User=0.00s Sys=0.00s Real=0.00s
* [2.537s][info ][gc,start ] GC(17) Pause Young (Allocation Failure)
* [2.547s][info ][gc,heap ] GC(17) DefNew: 4928K->511K(4928K)
* [2.547s][info ][gc,heap ] GC(17) Tenured: 6636K->8563K(10944K)
* [2.547s][info ][gc,metaspace ] GC(17) Metaspace: 7493K->7493K(1056768K) <-------注意：Metaspace方法区的内存空间几乎一致没变，由于其存放的是类的结果，不是对象，且其空间在JDK1.8以后也不在VM内存中而是在服务器内存中，其内存大小是能够动态变化的
* ......
*******************************************************************************/
public class TestGC {
public static void main( String[] args ) {
serialGC();
}
public static void serialGC() {
List<Object> list = new ArrayList<>();
while (true) {
int sleep = new Random().nextInt(100);
if (System.currentTimeMillis() % 2 == 0) {
list.clear();
} else {
for (int i = 0; i < 10000; i++) {
Properties properties = new Properties();
properties.put("key_" + i, "value_" + System.currentTimeMillis() + i);
list.add(properties);
}
}
try {
Thread.sleep(sleep);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
并行垃圾回收器
ParNew
ParNew垃圾收集器是工做在年轻代上的，只是将串行的垃圾收集器改成了并，而,老年代使用的依然是串行 收集器。
-XX:+UseParNewGC 参数设置年轻代使用ParNew回收器
注意在不一样的JVM中，可能会有不一样的垃圾回收器，全部有些参数可能在你的JVM中就没法使用
ParallelGC
- -XX:+UseParallelGC 年轻代使用ParallelGC垃圾回收器，老年代使用串行回收器。
- -XX:+UseParallelOldGC 年轻代使用ParallelGC垃圾回收器，老年代使用ParallelOldGC垃圾回收器。
- -XX:MaxGCPauseMillis 设置最大的垃圾收集时的停顿时间，单位为毫秒 须要注意的时，ParallelGC为了达到设置的停顿时间，可能会调整堆大小或其余 的参数，若是堆的大小设置的较小，就会致使GC工做变得很频繁，反而可能会 影响到性能。 该参数使用需谨慎。
- -XX:GCTimeRatio 设置垃圾回收时间占程序运行时间的百分比，公式为1/(1+n)。 它的值为0~100之间的数字，默认值为99，也就是垃圾回收时间不能超过1%
-XX:UseAdaptiveSizePolicy 自适应GC模式，垃圾回收器将自动调全年轻代、老年代等参数，达到吞吐量、 堆大小、停顿时间之间的平衡。 通常用于，手动调整参数比较困难的场景，让收集器自动进行调整。
‐XX:+UseParallelGC ‐XX:+UseParallelOldGC ‐XX:MaxGCPauseMillis=100 ‐ XX:+PrintGCDetails ‐Xms16m ‐Xmx16m
CMS垃圾回收
CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器， 该回收器是针对老年代垃圾回收的，经过参数-XX:+UseConcMarkSweepGC进行设置
执行过程：
-- 初始化标记(CMS-initial-mark) ,标记root，会致使stw；
-- 并发标记(CMS-concurrent-mark)，与用户线程同时运行；
-- 预清理（CMS-concurrent-preclean），与用户线程同时运行；
-- 从新标记(CMS-remark) ，会致使stw；
-- 并发清除(CMS-concurrent-sweep)，与用户线程同时运行；
-- 调整堆大小，设置CMS在清理以后进行内存压缩，目的是清理内存中的碎片；
-- 并发重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行；
启动参数：
-XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xms16m -Xmx16m
package JavaCore.JVM.GC;
/*******************************************************************************
* @Copyright (C), 2018-2019,github:Swagger-Ranger
* @FileName: TestGC
* @Author: liufei32@outlook.com
* @Date: 2019/4/11 15:08
* @Description: 测试CMS GC，查看GC过程
* @Aha-eureka: IDEA配置运行参数VM options：-XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xms16m -Xmx16m
*
* CMS将在JDK1.9以后移除，使用-Xlog:gc*来代替
*Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
* [0.009s][warning][gc] -XX:+PrintGCDetails is deprecated. Will use -Xlog:gc* instead.
*
*[0.518s][info ][gc,cpu ] GC(7) User=0.03s Sys=0.00s Real=0.01s
* [0.518s][info ][gc,start ] GC(8) Pause Initial Mark <----初始标记
* [0.519s][info ][gc ] GC(8) Pause Initial Mark 7M->7M(15M) 0.409ms
* [0.519s][info ][gc,cpu ] GC(8) User=0.00s Sys=0.00s Real=0.00s
* [0.519s][info ][gc ] GC(8) Concurrent Mark <---- 并发标记
* [0.528s][info ][gc ] GC(8) Concurrent Mark 8.778ms
* [0.528s][info ][gc,cpu ] GC(8) User=0.00s Sys=0.00s Real=0.01s
* [0.528s][info ][gc ] GC(8) Concurrent Preclean <----预处理
* [0.528s][info ][gc ] GC(8) Concurrent Preclean 0.072ms
* [0.528s][info ][gc,cpu ] GC(8) User=0.00s Sys=0.00s Real=0.00s
* [0.528s][info ][gc,start ] GC(8) Pause Remark <----从新标记
* [0.530s][info ][gc ] GC(8) Pause Remark 8M->8M(15M) 1.609ms
* [0.530s][info ][gc,cpu ] GC(8) User=0.02s Sys=0.00s Real=0.00s
* [0.530s][info ][gc ] GC(8) Concurrent Sweep <----并发清除
* [0.533s][info ][gc ] GC(8) Concurrent Sweep 3.021ms
* [0.533s][info ][gc,cpu ] GC(8) User=0.00s Sys=0.00s Real=0.00s
* [0.533s][info ][gc ] GC(8) Concurrent Reset <----重置
* [0.533s][info ][gc ] GC(8) Concurrent Reset 0.038ms
* [0.533s][info ][gc,cpu ] GC(8) User=0.00s Sys=0.00s Real=0.00s
* [0.533s][info ][gc,heap ] GC(8) Old: 7016K->7016K(10944K)
* [0.599s][info ][gc,start ] GC(9) Pause Young (Allocation Failure)
*******************************************************************************/
public class TestGC_CMS {
public static void main( String[] args ) {
TestGC.serialGC();
}
}
G1垃圾收集器
G1垃圾收集器是在jdk1.7中正式使用的全新的垃圾收集器，oracle官方计划在jdk9中将 G1变成默认的垃圾收集器，以替代CMS。
G1的设计原则就是简化JVM性能调优，开发人员只须要简单的三步便可完成调优：
- 第一步，开启G1垃圾收集器
- 第二步，设置堆的最大内存
- 第三步，设置最大的停顿时间
G1中提供了三种模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不一样的条件 下被触发
G1特色
G1垃圾收集器相对比其余收集器而言，最大的区别在于它取消了年轻代、老年代的物理 划分，取而代之的是将堆划分为若干个区域（Region），这些区域中包含了有逻辑上的 年轻代、老年代区域。 这样作的好处就是，咱们不再用单独的空间对每一个代进行设置了，不用担忧每一个代内 存是否足够。
G1中的E,S,O均可以和以前的内存物理分区对应，但新增了一个Humongous区即矩形对象区：若是一个对象占用的空间超过了分区容量50%以上就是巨型对象。
为何要单独划分H区
在G1垃圾收集器中，垃圾收集的方式是将存活的对象直接拷贝到老年代或者S区，以前的那个占用内存空间就空出来，这样就完成了清理工做。这是一种更加简单有效的垃圾收集方式，但假设有独享占用了分区容量的50%那这个对象就没法按照上面的那种直接拷贝的方法来回收内存。同时以前在处理大对象时的方法默认直接会被分配在老年代，可是若是它是一个短时间存在的巨型对象，就会对垃圾收集器形成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。若是 一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续 的H区，有时候不得不启动Full GC。
YoungGC
再次温习下，在G1GC中是取消了物理上的内存年轻代、年老代的划分而是将堆内存划分为若干个区域，在这些若干的区域里采用了逻辑上的年轻代和年老代的划分也就是说每一块的物理内存区域在逻辑上是年轻代、年老代或是属于E,S仍是O区是能够变化的。
Young GC主要是对Eden区进行GC，它在Eden空间耗尽时会被触发，具体的过程：
-- 在YoungGC，是会STW（Stop-The-World)的，即应用中止等待GC完成
-- Eden空间的数据移动到Survivor空间中，若是Survivor空间不够，Eden空间的部分 数据会直接晋升到年老代空间。 逻辑上的分区是能够变的，即内存实际并无改变而是直接在逻辑上变动分区
-- Survivor区的数据移动到新的Survivor区中，也有部分数据晋升到老年代空间中。 最终Eden空间的数据为空，GC中止工做，应用线程继续执行
Remembered Set（已记忆集合）
在垃圾回收时，咱们确认哪些对象能够被垃圾回收，去标记须要回收的对象以释放内存都是从root对象开始，但有个重要的问题一直没有讨论就是哪些对象是root对象。
在GC年轻代的对象时，咱们如何找到年轻代中对象的根对象呢？ 根对象多是在年轻代中，也能够在老年代中，那么老年代中的全部对象都是根么？ 若是全量扫描老年代，那么这样扫描下来会耗费大量的时间。 因而，G1引进了RSet的概念。它的全称是Remembered Set，其做用是跟踪指向某个堆 内的对象引用。
每一个Region初始化时，会初始化一个RSet，该集合用来记录并跟踪其它Region指向该 Region中对象的引用，每一个Region默认按照512Kb划分红多个Card，因此RSet须要记录 的东西就是 xx Region的 xx Card。这样在确认回收对象时就只须要去遍历Rset集合就能够了而不用去扫描每一个对象。
MixedGC
当愈来愈多的对象晋升到老年代old region时，为了不堆内存被耗尽，虚拟机会触发一 个混合的垃圾收集器，即Mixed GC，该算法并非一个Old GC，除了回收整个Young Region，还会回收一部分的Old Region，这里须要注意：是一部分老年代，而不是所有 老年代，能够选择哪些old region进行收集，从而能够对垃圾回收的耗时时间进行控制。 也要注意的是Mixed GC 并非 Full GC。 MixedGC何时触发？ 由参数 -XX:InitiatingHeapOccupancyPercent=n 决定。默 认：45%，该参数的意思是：当老年代大小占整个堆大小百分比达到该阀值时触发。
GC步骤：
-
- 全局并发标记（global concurrent marking）
-- 初始标记（initial mark，STW） 标记从根节点直接可达的对象，这个阶段会执行一次年轻代GC，会产生全局停 顿。
-- 根区域扫描（root region scan） G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。 该阶段与应用程序（非 STW）同时运行，而且只有完成该阶段后，才能开始下 一次 STW 年轻代垃圾回收。
-- 并发标记（Concurrent Marking） G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行， 能够被 STW 年轻代垃圾回收中断。
-- 从新标记（Remark，STW） 该阶段是 STW 回收，由于程序在运行，针对上一次的标记进行修正。
-- 清除垃圾（Cleanup，STW） 清点和重置标记状态，该阶段会STW，这个阶段并不会实际上去作垃圾的收集， 等待evacuation阶段来回收。
- 全局并发标记（global concurrent marking）
-
- 拷贝存活对象（evacuation）
-- Evacuation阶段是全暂停的。该阶段把一部分Region里的活对象拷贝到另外一部分Region 中，从而实现垃圾的回收清理
- 拷贝存活对象（evacuation）
G1收集器参数
-XX:+UseG1GC 使用 G1 垃圾收集器
-XX:MaxGCPauseMillis 设置指望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到），默认 值是 200 毫秒。
-XX:G1HeapRegionSize=n 设置的 G1 区域的大小。值是 2 的幂，范围是 1 MB 到 32 MB 之间。目标是根 据最小的 Java 堆大小划分出约 2048 个区域。 默认是堆内存的1/2000。
-XX:ParallelGCThreads=n 设置 STW 工做线程数的值。将 n 的值设置为逻辑处理器的数量。n 的值与逻辑 处理器的数量相同，最多为 8。
-XX:ConcGCThreads=n设置并行标记的线程数。将 n 设置为并行垃圾回收线程数 (ParallelGCThreads) 的 1/4 左右。
-XX:InitiatingHeapOccupancyPercent=n 设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。
G1收集器优化建议
- 年轻代大小
-- 避免使用 -Xmn 选项或 -XX:NewRatio 等其余相关选项显式设置年轻代大小。 固定年轻代的大小会覆盖暂停时间目标。 - 暂停时间目标不要太过严苛
-- G1 GC 的吞吐量目标是 90% 的应用程序时间和 10%的垃圾回收时间。
-- 评估 G1 GC 的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示您愿意 承受更多的垃圾回收开销，而这会直接影响到吞吐量
可视化GC分析工具
前面经过-XX:+PrintGCDetails能够对GC日志进行打印，咱们就能够在控制台查看，这样 虽然能够查看GC的信息，可是并不直观，能够借助于第三方的GC日志分析工具进行查看。
使用工具：
GC Easy是一款在线的可视化工具，易用、功能强大。
地址：
http://gceasy.io/
使用方法
在运行JVM前设置参数，并将JVM GC日志输出到log文件，而后将文件上传到gceasy.io在线分析工具中
GC配置参数
‐XX:+PrintGC 输出GC日志 ‐XX:+PrintGCDetails 输出GC的详细日志 ‐XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式） ‐XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013‐05‐ 04T21:53:59.234+0800） ‐XX:+PrintHeapAtGC 在进行GC的先后打印出堆的信息 ‐Xloggc:../logs/gc.log 日志文件的输出路径
VM options:----具体的参数不一样的Jdk版本可能有区别
-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xmx256m -XX:+PrintGCDetails - XX:+PrintGCTimeStamps ‐-X:+PrintGCDateStamps -X:+PrintHeapAtGC -Xloggc:D://Swagger-Ranger//test//gc.log
解析后就能够看到，好比：
https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTkvMDQvMTEvLS1nYy5sb2ctLTE2LTE0LTM5&channel=WEB
其中对应的配置为-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xmx256m -XX:+PrintGCDetails -Xloggc:D://Swagger-Ranger//gc.log
本博客为Swagger-Ranger的笔记分享，文章会持续更新 文中源码地址： https://github.com/Swagger-Ranger 欢迎交流指正，若有侵权请联系做者确认删除： liufei32@outlook.com
- 1. jvm垃圾回收
- 2. JVM垃圾回收
- 3. 【Jvm】垃圾回收
- 4. Jvm垃圾回收
- 5. jvm - 垃圾回收
- 6. JVM 垃圾回收
- 7. JVM-垃圾回收
- 8. JVM--垃圾回收
- 9. jvm 垃圾回收
- 10. JVM（二）JVM垃圾回收
- 更多相关文章...
- • Lua 垃圾回收 - Lua 教程
- • Redis的超时命令和垃圾回收策略 - Redis教程
- • 算法总结-回溯法
- • Java Agent入门实战（三）-JVM Attach原理与使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. jvm垃圾回收
- 2. JVM垃圾回收
- 3. 【Jvm】垃圾回收
- 4. Jvm垃圾回收
- 5. jvm - 垃圾回收
- 6. JVM 垃圾回收
- 7. JVM-垃圾回收
- 8. JVM--垃圾回收
- 9. jvm 垃圾回收
- 10. JVM（二）JVM垃圾回收