JVM的GC算法由CMS切换为G1

已于 2023-02-10 11:06:25 修改
阅读量1.3k 收藏 2
点赞数
分类专栏： Java基础 文章标签： jvm java
于 2022-11-23 15:53:12 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_38658642/article/details/128001832
版权

GC算法

-XX:+UseSerialGC

新生代和老年代都使用串行收集器

串行收集器使用单线程并且是独占式的垃圾回收

-XX:+UseParNewGC

新生代使用ParNew垃圾回收器，老年代使用串行收集器

ParNew是串行收集器的多线程版本，只工作在新生代（可以见名知义，ParNew:Paralle New,并行新生代）。可以考虑在CPU并发能力强的系统中使用ParNew，单CPU的话，性能不一定比串行收集器好。

-XX:+UseParallelGC

新生代使用ParallelGC回收器，老年代使用串行收集器

ParallelGC是工作在新生代的并行垃圾收集器，使用复制算法。只是它更关注系统的吞吐量，所以和ParNewGC的一个区别是有相关参数可以设置GC的停顿时间。

-XX:+UseParallelOldGC

新生代使用ParallelGC，老年代使用ParallelOldGC

ParallelOldGC是ParallelGC的老年代版本，只工作在老年代，使用标记压缩的回收算法，JDK1.6版本及之后支持

-XX:+UseConcMarkSweepGC

新生代使用ParNew，老年代使用CMS

CMS垃圾收集器更关注系统停顿时间，采用标记清除算法并且使用多线程并行回收。

CMS在GC失败时，老年代会使用串行收集器

-XX:+UseG1GC

使用G1回收器，同时作用于新生代和老年代

工作在新生代的垃圾收集器：SerialGC、ParNewGC、ParallelGC

工作在老年代的垃圾收集器：CMS、SerialGC、ParallelOldGC

G1同时在新生代和老年代工作。

查看当前jvm采用的GC算法

 

或查看gc日志

 

GC统计

1. cms简介

CMS(Concurrent Mark and Sweep 并发-标记-清除)，是一款基于并发、使用标记清除算法的垃圾回收算法，只针对老年代进行垃圾回收。CMS收集器工作时，尽可能让GC线程和用户线程并发执行，以达到降低STW时间的目的。

-XX:+UseConcMarkSweepGC

值得补充的是，下面介绍到的CMS GC是指老年代的GC，而Full GC指的是整个堆的GC事件，包括新生代、老年代、元空间等，两者有所区分

1.1 名词解释

可达性分析算法：用于判断对象是否存活，基本思想是通过一系列称为“GC Root”的对象作为起点（常见的GC Root有系统类加载器、栈中的对象、处于激活状态的线程等），基于对象引用关系，从GC Roots开始向下搜索，所走过的路径称为引用链，当一个对象到GC Root没有任何引用链相连，证明对象不再存活。

Stop The World：GC过程中分析对象引用关系时，为了保证分析结果的准确性，需要通过停顿所有Java执行线程，保证引用关系不再动态变化，该停顿事件称为Stop The World(STW)。

Safepoint：代码执行过程中的一些特殊位置，当线程执行到这些位置的时候，说明虚拟机当前的状态是安全的，如果有需要GC，线程可以在这个位置暂停。HotSpot采用主动中断的方式，让执行线程在运行期轮询是否需要暂停的标志，若需要则中断挂起。

1.2 老年代垃圾回收

CMS GC以获取最小停顿时间为目的，尽可能减少STW时间，可以分为7个阶段

1.3 CMS常见问题

最终标记阶段停顿时间过长问题：

CMS的GC停顿时间约80%都在最终标记阶段(Final Remark)，若该阶段停顿时间过长，常见原因是新生代对老年代的无效引用，在上一阶段的并发可取消预清理阶段中，执行阈值时间内未完成循环，来不及触发Young GC，清理这些无效引用

通过添加参数：-XX:+CMSScavengeBeforeRemark。在执行最终操作之前先触发Young GC，从而减少新生代对老年代的无效引用，降低最终标记阶段的停顿，但如果在上个阶段(并发可取消的预清理)已触发Young GC，也会重复触发Young GC

并发模式失败(concurrent mode failure) & 晋升失败(promotion failed)问题

并发模式失败：当CMS在执行回收时，新生代发生垃圾回收，同时老年代又没有足够的空间容纳晋升的对象时，CMS 垃圾回收就会退化成单线程的Full GC。所有的应用线程都会被暂停，老年代中所有的无效对象都被回收

晋升失败：当新生代发生垃圾回收，老年代有足够的空间可以容纳晋升的对象，但是由于空闲空间的碎片化，导致晋升失败，此时会触发单线程且带压缩动作的Full GC

内存碎片问题：

通常CMS的GC过程基于标记清除算法，不带压缩动作，导致越来越多的内存碎片需要压缩。

常见以下场景会触发内存碎片压缩：

  • 新生代Young GC出现新生代晋升担保失败(promotion failed)
  • 程序主动执行System.gc()

可通过参数CMSFullGCsBeforeCompaction的值，设置多少次Full GC触发一次压缩，默认值为0，代表每次进入Full GC都会触发压缩，带压缩动作的算法为上面提到的单线程Serial Old算法，暂停时间(STW)时间非常长，需要尽可能减少压缩时间。

模拟代码：

public static void main(String[] args) {
    List<byte[]> res = new ArrayList<>();
    byte[] array = null;
    while (true){
        int num=(int)(Math.random()*100-1);
        array = new byte[2 * 1024 * num];
        res.add(array);
        System.out.println(array.length);
    }
}

启动参数增加：参考：https://open.atatech.org/articles/249506

产生碎片可通过gc日志查看：

通过其中一段日志发现GC前：

剩余总空间 Total Free Space：82563*8/1024/1024=0.62MB,

最大连续空间 Max Chunk Size：230*8/1024=1.79KB

连续空间个数 Number of Blocks: 3349

碎片率 frag: 0.9683 = 96.83%

GC后：

剩余总空间 Total Free Space：84644*8/1024/1024=0.64MB,

最大连续空间 Max Chunk Size：254*8/1024=1.98KB

连续空间个数 Number of Blocks: 3356

碎片率 frag: 0.9943 = 99.43%

从第一次GC开始碎片率逐步升高，直到最后面的Number of Blocks等于1 ，碎片全部被清除，整个GC耗时2秒多。

GC统计数据变化：

发现到达一定时间后，老年代的GC次数在快速增加，GC耗时也在逐步增加, 直到最后的OutOfMemoryError

@cpe-172-100-1-50 ~ % jstat -gcutil 45198 5000
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00  21.97   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  28.24   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  35.14   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  40.90   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  48.25   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  54.10   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  62.69   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  68.61   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  73.84   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  81.41   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  87.55   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  95.41   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00 100.00   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00 100.00   7.05  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  15.10  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  21.03  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  29.59  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  34.66  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  42.52  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  48.89  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  57.65  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  64.09  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  70.07  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  77.49  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  86.10  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  92.71  31.54  62.24  60.70      1    0.047     0    0.000    0.047
  0.00 100.00  97.78  31.54  62.24  60.70      1    0.047     0    0.000    0.047
 99.99   0.00   8.06  60.00  62.25  60.70      2    0.096     3    0.009    0.105
 99.99   0.00  14.84  60.00  62.25  60.70      2    0.096     4    0.013    0.109
 99.99   0.00  21.59  60.00  62.25  60.70      2    0.096     5    0.014    0.110
 99.99   0.00  28.31  60.00  62.25  60.70      2    0.096     7    0.019    0.116
 99.99   0.00  33.43  60.00  62.25  60.70      2    0.096     9    0.024    0.120
 99.99   0.00  41.96  60.00  62.25  60.70      2    0.096    10    0.029    0.125
 99.99   0.00  49.28  60.00  62.25  60.70      2    0.096    11    0.030    0.126
 99.99   0.00  55.25  60.00  62.25  60.70      2    0.096    13    0.037    0.133
 99.99   0.00  62.93  60.00  62.25  60.70      2    0.096    14    0.038    0.134
 99.99   0.00  70.33  60.00  62.25  60.70      2    0.096    15    0.039    0.135
 99.99   0.00  77.26  60.00  62.25  60.70      2    0.096    17    0.045    0.141
 99.99   0.00  82.49  60.00  62.25  60.70      2    0.096    18    0.048    0.144
 99.99   0.00  88.85  60.00  62.25  60.70      2    0.096    19    0.049    0.145
 99.99   0.00  97.21  60.00  62.25  60.70      2    0.096    21    0.055    0.151
  0.00  99.99   2.11  60.00  62.25  60.70      3    0.133    24    0.062    0.195
  0.00  99.99   8.22  60.00  62.25  60.70      3    0.133    25    0.063    0.196
  0.00  99.99  16.60  60.00  62.25  60.70      3    0.133    27    0.068    0.201
  0.00  99.99  22.65  60.00  62.25  60.70      3    0.133    29    0.074    0.207
  0.00  99.99  27.97  60.00  62.25  60.70      3    0.133    30    0.079    0.212
  0.00  99.99  34.85  60.00  62.25  60.70      3    0.133    31    0.080    0.213
  0.00  99.99  41.21  60.00  62.25  60.70      3    0.133    33    0.087    0.220
  0.00  99.99  49.15  60.00  62.25  60.70      3    0.133    34    0.092    0.225
  0.00  99.99  54.81  60.00  62.25  60.70      3    0.133    35    0.093    0.227
  0.00  99.99  61.89  60.00  62.25  60.70      3    0.133    37    0.100    0.233
  0.00  99.99  67.94  60.00  62.25  60.70      3    0.133    39    0.105    0.238
  0.00  99.99  75.76  60.00  62.25  60.70      3    0.133    40    0.109    0.242
  0.00  99.99  81.64  60.00  62.25  60.70      3    0.133    41    0.110    0.243
  0.00  99.99  87.37  60.00  62.25  60.70      3    0.133    43    0.114    0.247
  0.00  99.99  95.22  60.00  62.25  60.70      3    0.133    44    0.117    0.250
 99.99   0.00   2.16  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00   9.63  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  16.49  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  24.43  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  31.96  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  38.85  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  45.43  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  53.06  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  58.61  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  65.95  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  72.51  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  79.70  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  87.10  60.00  62.25  60.70      4    0.184    46    0.120    0.303
 99.99   0.00  92.81  60.00  62.25  60.70      4    0.184    46    0.120    0.303
  0.00  99.98   2.02  60.00  62.25  60.70      5    0.230    48    0.121    0.351
  0.00  99.98   8.40  60.00  62.25  60.70      5    0.230    48    0.121    0.351
  0.00  99.98  13.40  60.00  62.25  60.70      5    0.230    48    0.121    0.351
  0.00  99.98  20.16  60.00  62.25  60.70      5    0.230    48    0.121    0.351
  0.00  99.98  27.80  60.00  62.25  60.70      5    0.230    48    0.121    0.351
  0.00  99.98  33.37  60.00  62.25  60.70      5    0.230    48    0.121    0.351
 

2. G1简介

G1(Garbage-First）是一款面向服务器的垃圾收集器，支持新生代和老年代空间的垃圾收集，主要针对配备多核处理器及大容量内存的机器，G1最主要的设计目标是: 实现可预期及可配置的STW停顿时间

2.1 G1堆空间划分

Region

为实现大内存空间的低停顿时间的回收，将划分为多个大小相等的Region。每个小堆区都可能是 Eden区，Survivor区或者Old区，但是在同一时刻只能属于某个代。

在逻辑上, 所有的Eden区和Survivor区合起来就是新生代，所有的Old区合起来就是老年代，且新生代和老年代各自的内存Region区域由G1自动控制，不断变动

巨型对象

当对象大小超过Region的一半，则认为是巨型对象(Humongous Object)，直接被分配到老年代的巨型对象区(Humongous regions)，这些巨型区域是一个连续的区域集，每一个Region中最多有一个巨型对象，巨型对象可以占多个Region。

G1把堆内存划分成一个个Region的意义在于：

每次GC不必都去处理整个堆空间，而是每次只处理一部分Region，实现大容量内存的GC

通过计算每个Region的回收价值，包括回收所需时间、可回收空间，在有限时间内尽可能回收更多的内存，把垃圾回收造成的停顿时间控制在预期配置的时间范围内，这也是G1名称的由来: garbage-first

2.2 G1工作模式

针对新生代和老年代，G1提供2种GC模式，Young GC和Mixed GC，两种会导致Stop The World

1、Young GC 当新生代的空间不足时，G1触发Young GC回收新生代空间 Young GC主要是对Eden区进行GC，它在Eden空间耗尽时触发，基于分代回收思想和复制算法，每次Young GC都会选定所有新生代的Region，同时计算下次Young GC所需的Eden区和Survivor区的空间，动态调整新生代所占Region个数来控制Young GC开销。

2、Mixed GC 当老年代空间达到阈值会触发Mixed GC，选定所有老年代里的Region，根据全局并发标记统计得出收集收益高的若干老年代 Region。在用户指定的开销目标范围内，尽可能选择收益高的老年代Region进行GC，通过选择哪些老年代Region和选择多少Region来控制Mixed GC开销。

2.3 G1注意点

Full GC问题

G1的正常处理流程中没有Full GC，只有在垃圾回收处理不过来(或者主动触发)时才会出现， G1的Full GC就是单线程执行的Serial old gc，会导致非常长的STW，是调优的重点，需要尽量避免Full GC，常见原因如下：

1) 程序主动执行System.gc()

2) 全局并发标记期间老年代空间被填满（并发模式失败）

3) Mixed GC期间老年代空间被填满（晋升失败）

4) Young GC时Survivor空间和老年代没有足够空间容纳存活对象

类似CMS，常见的解决是：

1) 增大-XX:ConcGCThreads=n 选项增加并发标记线程的数量，或者STW期间并行线程的数量：-XX:ParallelGCThreads=n

2) 减小-XX:InitiatingHeapOccupancyPercent 提前启动标记周期

3) 增大预留内存 -XX:G1ReservePercent=n ，默认值是10，代表使用10%的堆内存为预留内存，当Survivor区域没有足够空间容纳新晋升对象时会尝试使用预留内存

巨型对象分配

巨型对象区中的每个Region中包含一个巨型对象，剩余空间不再利用，导致空间碎片化，当G1没有合适空间分配巨型对象时，G1会启动串行Full GC来释放空间。可以通过增加 -XX:G1HeapRegionSize来增大Region大小，这样一来，相当一部分的巨型对象就不再是巨型对象了，而是采用普通的分配方式

不要设置Young区的大小

原因是为了尽量满足目标停顿时间，逻辑上的Young区会进行动态调整。如果设置了大小，则会覆盖掉并且会禁用掉对停顿时间的控制。

平均响应时间设置

使用应用的平均响应时间作为参考来设置MaxGCPauseMillis，JVM会尽量去满足该条件，可能是90%的请求或者更多的响应时间在这之内， 但是并不代表是所有的请求都能满足，平均响应时间设置过小会导致频繁GC。

GC统计数据变化：

相对于CMS算法而言，虽然最后都出现了OutOfMemoryError，但是：

1、G1的整体Full GC 次数和时间具有显著降低。
2、并且相对于CMS算法来说，采用G1算法时，模拟程序运行循环次数要更多，大约在40300次左右。

cpe-172-100-1-50 ~ % jstat -gcutil 78717 500
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00  15.38   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  15.38   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  15.38   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  15.38   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  15.38   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00   0.00  23.08   0.00  17.71  19.94      0    0.000     0    0.000    0.000
  0.00 100.00  50.91  52.64  62.24  60.70     17    0.429     0    0.000    0.429
  0.00 100.00  43.65  98.34  62.24  60.70     26    0.891     0    0.000    0.891
  0.00   0.00   0.00 100.00  62.24  60.70     29    0.945     1    0.000    0.945
  0.00   0.00   0.00 100.00  62.24  60.70     29    0.945     1    0.000    0.945
  0.00   0.00   0.00 100.00  62.24  60.70     29    0.945     1    0.000    0.945

GC日志解读

 // 每次回收以花括号开始和结尾
 // invocations = 1 表示第一次回收
{Heap before GC invocations=2 (full 0):
 garbage-first heap   total 262144K, used 61176K [0x00000006c0000000, 0x00000006c0100800, 0x00000007c0000000)
  region size 1024K, 28 young (28672K), 2 survivors (2048K)
 Metaspace       used 3017K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 310K, capacity 386K, committed 512K, reserved 1048576K
// 表示 young GC 原因是：疏散停顿
2022-11-24T15:11:17.869-0800: 0.287: [GC pause (G1 Evacuation Pause) (young), 0.0099652 secs]
	// 并行回收耗时和 8个线程回收
   [Parallel Time: 7.3 ms, GC Workers: 8]
       // 疏散线程耗时
      [GC Worker Start (ms): Min: 287.4, Avg: 287.5, Max: 287.7, Diff: 0.3]
      [Ext Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.4]
      [Update RS (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.7]
         [Processed Buffers: Min: 0, Avg: 1.2, Max: 3, Diff: 3, Sum: 10]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 6.7, Avg: 6.8, Max: 6.9, Diff: 0.1, Sum: 54.5]
      [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.8]
         [Termination Attempts: Min: 1, Avg: 1.9, Max: 3, Diff: 2, Sum: 15]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [GC Worker Total (ms): Min: 6.9, Avg: 7.1, Max: 7.2, Diff: 0.4, Sum: 56.6]
      [GC Worker End (ms): Min: 294.5, Avg: 294.6, Max: 294.6, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.1 ms]
   [Other: 2.6 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 2.4 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.1 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.0 ms]
	// eden survivors heap等内存大小变化
   [Eden: 26.0M(26.0M)->0.0B(33.0M) Survivors: 2048.0K->4096.0K Heap: 59.7M(256.0M)->60.4M(256.0M)]
Heap after GC invocations=3 (full 0):
 garbage-first heap   total 262144K, used 61840K [0x00000006c0000000, 0x00000006c0100800, 0x00000007c0000000)
  region size 1024K, 4 young (4096K), 4 survivors (4096K)
 Metaspace       used 3017K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 310K, capacity 386K, committed 512K, reserved 1048576K
}
  // 回收结束标志，各阶段耗时
 [Times: user=0.00 sys=0.02, real=0.01 secs]

内存等参数配置

官方文档：Garbage-First (G1) Garbage Collector

堆内存设定

-XX:InitialHeapSize 作为最小Java堆大小

-XX:MaxHeapSize为最大Java堆大小；

-XX:MinHeapFreeRatio为最小可用内存百分比；

-XX:MaxHeapFreeRatio确定调整大小后的最大可用内存百分比。

默认值：

官方建议参数配置：

官方文档建议从其他GC转移到G1时，要先要删除所有影响GC的配置，仅使用-Xmx和-Xms设置暂停时间和整体堆大小，尤其CMS算法转为G1时（不然可能会导致其他设置没有效果，甚至降低了吞吐量和满足暂停时间目标的可能性）

Garbage-First Garbage Collector Tuning

避免使用Xmn; 暂停时间调整-XX:MaxGCPauseMillis=200

 https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html

总结：

1、仅通过-Xms和-Xmx设置堆内存大小

2、不要手动设置-Xmn新生代大小

G1收集器在运行过程中，会自己调整新生代和老年代的大小。其实是通过adapt代的大小来调整对象晋升的速

度和年龄，从而达到为收集器设置的暂停时间目标，如果手动设置了大小就意味着放弃了G1的自动调优。

3、GC最大暂停时间设置：-XX:MaxGCPauseMillis=200

一般情况下这个值设置到100ms或者200ms都是可以的(不同情况下会不一样)，但如果设置成50ms就不太合

理。暂停时间设置的太短，就会导致出现G1跟不上垃圾产生的速度。最终退化成Full GC。所以对这个参数的

调优是一个持续的过程，逐步调整到最佳状态。暂停时间只是一个目标，并不能总是得到满足。

4、适当增大堆内存大小

你的小祖宗饿了
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
常见的 GC 算法（Parallel/CMS/G1）
KimmKing的技术博客
09-22 2060
学习了 GC 算法的相关概念之后，我们将介绍在 JVM 中这些算法的具体实现。首先要记住的是，大多数 JVM 都需要使用两种不同的 GC 算法——一种用来清理年轻代，另一种用来清理老年代。 我们可以选择 JVM 内置的各种算法。如果不通过参数明确指定垃圾收集算法，则会使用相应 JDK 版本的默认实现。本章会详细介绍各种算法的实现原理。 串行 GC（Serial GC） 串行 GC 对年轻代使用 m...
老年代 CMS gc回收算法 对hbase的影响
weixin_34192816的博客
04-02 200
老年代 CMS gc回收算法 对hbase的影响***** 参考链接： 深入研究java gc https://blog.51cto.com/12445535/2372976CMS失败模式（CMS Failure Mode）1、上文提到在正常的情况下CMS整个流程的暂停时间都是很短的，一般也就在10ms～100ms左右。2、然而这与线上的情况并不相符，线上集群在读写压力很大的情况下，经常会出现长...
java_opts gc回收器_java CMS垃圾回收升级G1回收器实践
weixin_34294809的博客
02-13 606
一、什么是G1G1(Garbadge First Collector)作为一款JVM最新的垃圾收集器，可以解决CMS中Concurrent Mode Failed问题，尽量缩短处理超大堆的停顿，在G1进行垃圾回收的时候完成内存压缩，降低内存碎片的生成。G1在堆内存比较大的时候表现出比较高吞吐量和短暂的停顿时间，而且已成为Java 9的默认收集器。未来替代CMS只是时间的问题。二、CMS与G1对比C...
GC：CMS与G1的区别
最新发布
zzznodoit的博客
06-17 411
使用范围：CMS针对老年代，G1覆盖老年代与新生代停顿时间：CMS以最小的停顿时间为目标，G1是提供可预测的停顿时间模型，运行用户指定最大停顿时间。内存碎片：CMS是标记-清除算法，G1是标记-整理算法垃圾回收过程所以，如果你想要低停顿、高吞吐的选CMS，如果你想对停顿时间可控选G1。JDK 1.9之后默认的GC都是G1.
用了很多年的 CMS 垃圾收集器，终于换成了 G1，真香！！
emprere的博客
06-04 189
上一篇：深夜看了张一鸣的微博，让我越想越后怕作者：Eric Fu链接：https://ericfu.me/g1-garbage-collector/在过去很长一段时间内，HotSpot J...
从CMS到G1
李昂的博客
07-04 458
在JDK14中CMS已经不再支持CMS了。 像青春的逝去般的垃圾回收器也迎来了他的换代。 我们不能龟缩不前，JDK8已经开始展示出颓态。5G的到来以及高端硬件的降价，用户的需求都在告诉我们。要么改变，要么被淘汰。 本文主要讲解G1回收器和他对比CMS的优劣。其实在JDK11后 8G以上内存99%的场景下 G1都比CMS表现更为优秀。 G1内存模型对比CMS和之前的垃圾收集器有了很大的改变。这无疑是惊艳的。 从上图可以看出G1把堆内存划分为若干个区域（Regi...
JVM GC算法 CMS 详解
liyanling的博客
07-31 1638
前言 CMS，全称Concurrent Low Pause Collector，是jdk1.4后期版本开始引入的新gc算法，在jdk5和jdk6中得到了进一步改进，它的主要适合场景是对响应时间的重要性需求 大于对吞吐量的要求，能够承受垃圾回收线程和应用线程共享处理器资源，并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收，也就是年老代的回收，目...
Java进阶指南：GC 算法2.3CMS GC/ G1 GC
小虾米的博客
03-08 343
本系列主要针对想进一步进阶Java的开发者，本文介绍CMS GC与G1 GC
JVM 调优理论知识：垃圾回收。常见垃圾回收器、GC算法。PC、PN、CMS、PO、G1、ZGC，JVM GC算法
dandanforgetlove的专栏
05-13 3640
熟悉GC常用算法，熟悉常见垃圾收集器，具有实际JVM调优实战经验 garbage 什么是garbage？没有被引用的对象都是垃圾 garbage how to find a garbage 如何找到垃圾 1.reference count 引用计数 rc 不能解决的问题： 循环引用。例如 A引用B，B引用C，C引用A. 2.root searching 根可达算法。 线程栈变量、静态变量、常量池、JNI指针 GC algorithms 1. Mark-Sweep ( 标记清...
JVM 的GC回收算法----G1
jerry_player的博客
03-04 3987
JVM内存垃圾回收目前有多种算法，每种算法都有自己的特点和使用场景，本文主要介绍一下G1（Garbage-First）算法.G1是一款面向服务端应用的垃圾回收器，是SUN公司在JDK1.7中提出来的，初衷是替换JDK1.5中的CMS垃圾回收算法。G1之前的所有收集器都是对整个新生代或老年代进行垃圾回收，而G1不是这样：G1是将整个堆空间分成许多个大小不等的独立区域（Region）,大约有2...
JVM调优，GC算法汇总
11-28
- **新生代GC算法选择**：串行GC或ParNew（并行GC的新生代版本）常用于新生代，而CMS或G1可能更适合老年代。 - **元空间**：JDK 8以后，类元数据存储在元空间而非永久代，需要合理设置元空间大小以避免溢出。 - **...
jvm gc 算法分析
weixin_43400718的博客
07-04 198
测试代码 /* 演示GC日志生成与解读 */ public class GCLogAnalysis { // 随机数; 记得这里可以设置随机数种子; private static Random random = new Random(); public static void main(String[] args) { // 当前毫秒时间戳 long startMillis = System.currentTimeMillis(); /
垃圾收集器CMS换G1
杜引强
01-12 374
原则上G1会计算执行GC的时间，并且极力减少花在GC上的时间（包括ygc,mixgc）,如果可能，会通过不断扩展堆空间来满足对象分配、转移的需要。G1的首要目标是为需要大量内存的系统提供一个保证GC低延迟的解决方案，也就是说堆内存最低在6GB及以上,稳定和可预测的暂停时间小于0.5秒。（2）G1在必要时也不能够增加或者缩小年轻代的空间. 因为大小是固定的,所以对更改大小无能为力；# 混合回收整理出来的空闲空间占heap的10时，结果老年代的回收，默认5。（1）Full GC 次数太频繁或者消耗时间太长；
JVM GC G1垃圾回收器配置
年少青山的博客
02-23 2982
JVM GC G1垃圾回收器配置
深入理解Java虚拟机（内存模型、类加载、垃圾回收、触发初始化、垃圾断定） JVM minor GC、FULL GC,G1、CMS、UseParallelGC
Be_insighted的博客
08-17 856
深入理解Java虚拟机 本文针对JDK 1.8，仅作抛转引玉，因水平有限，文章或许有不足之处，望您不吝指出！ 什么是JVM？ Java虚拟机(Java Virtual Machine)是运行Java字节码的虚拟机！对于不同的操作系统有特定的实现，相同的字节码(*.class 文件)，它都会给出相同的结果。 *.class 文件 <—— javac 编译源文件 一次编译，随处运行 字节码 + (不同系统的)虚拟机是实现“一次编译，随处运行”的关键； Java基本类型 byte、
JVM 经典垃圾收集器 —— CMS 收集器和 G1 收集器
低吟不作语的博客
12-26 922
本文部分摘自《深入理解 Java 虚拟机第三版》 概述 CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。由于大部分 Java 应用主要集中在互联网网站以及基于浏览器的 B/S 系统的服务端，这类应用通常会较为关注服务的响应速度，希望系统的停顿时间尽可能少，CMS 收集器就非常符合这类应用的需求 步骤 从名字可以知道，CMS 收集器是基于标记 - 清除算法实现的，它的运作过程分为四个步骤： 初始标记（CMS initial mark） 仅仅只..
jvm(gc调优)
Cyx12321的博客
06-13 817
从性能的角度看，通常关注三个方面（latency）和大多数情况下调优会侧重于其中一个或者两个方面的目标，很少有情况可以兼顾三个不同的角度。当然，除了上面通常的三个方面，也可能需要考虑其他 GC 相关的场景，例如，也可能与不合理的 GC 相关参数有关；或者，，GC 也会是个考虑的方面。
JVM性能调整 - GC调整策略
qiruiduni的专栏
09-17 1207
(鉴于GC的复杂性，请务必先读本系列中的前几篇 Blog, 否则将会云里雾里！) 调整目标   随着 Java 的演化，当初 C vs. Java 大战渐趋缓和：     Java:     老兄！ malloc / free 就是一名艺术？     C:         好钢用到刀刃上，总感觉 GC 忙个不停一直占着资源在清理“垃圾”     … 梦幻 GC 应该是这样子
[Inside HotSpot] UseParallelGC和UseParallelOldGC的区别
weixin_30872671的博客
05-25 1045
JVM的很多参数命名很有迷惑性，-XX:+UseParallel，-XX:+UseParallelOldGC，-XX:+UseParNewGC，-XX:+UseConcMarkSweepGC咋一看容易混淆，而且JDK升个级某个GC就可能不见了，为了详细了解这些参数的区别，先来看看到底都有哪些类型的GC： // hotspot\share\gc\shared\gc_globals.hpp prod...
SUN、HP JVM GC算法实战：并行、并发与G1
本文主要探讨了Java虚拟机（JVM）中的几种常见垃圾收集（GC）...选择合适的GC算法取决于应用的具体需求，包括对性能、停顿时间和内存管理的要求。理解这些算法的工作原理和参数调整是优化Java应用程序性能的关键步骤。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值