import java.util.Scanner; import java.util.concurrent.ArrayBlockingQueue; /** public static void main(String[] args) throws Exception { for (int i = 0; i < worker; i++) { System.out.println("End"); private static void alloc(int n) { |
a.测试代码执行命令,堆内存18g,使用不同的GC算法
重要参数说明:
-Xms18g -Xmx18g:
-XX:+PrintGC 打印GC日志
-XX:+PrintGCTimeStamps 打印GC发送的时间
-XX:+PrintGCApplicationStoppedTime 打印应用由于GC而产生的停顿时间
-XX:+UseG1GC 指定G1垃圾回收
-XX:+UseConcMarkSweepGC 指定CMS垃圾回收
java -Xms18g -Xmx18g -XX:+UseConcMarkSweepGC -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -Xloggc:cmsgc.log Mem
java -Xms18g -Xmx18g -XX:+UseG1GC -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -Xloggc:g1gc.log Mem
b.GC情况查看命令,间隔10秒,观察30次
jstat -gcutil pid 10000 30
CPU:Intel(R) Xeon(R) CPU E5-2609 v4 @ 1.70GHz
内存:24G
硬盘:500G
操作系统:centos
jdk:1.8.0_121-b13
堆内存:限制18G
变量:垃圾回收算法(CMS和G1)
使用UseConcMarkSweepGC的GC情况
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT |
使用G1的GC情况
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT |
使用CMS的应用暂停时间(选取部分)
491.172: [Full GC (Allocation Failure) 18350819K->17302210K(18806272K), 2.7447486 secs] |
使用G1的应用暂停时间(选取部分)
9.938: [GC pause (G1 Humongous Allocation) (young) (initial-mark) 16G->16G(18G), 0.0074400 secs] |
CMS |
G1 |
|
YGC(年轻代GC次数) |
290 |
1850 |
YGCT(年轻代GC的时间) |
39.229 |
8.033s |
FGC(FullGC的次数) |
121 |
286 |
FGCT(FullGC的总时间) |
223.913s |
32.271s |
GCT(GC的总时间) |
263.142s |
40.304s |
最大应用暂停时间 |
2.869s |
0.196s |
CMS垃圾回收产生的FullGC次数是121,FullGC总的时间是223.913s,平均每次FullGC的时间是1.85s,总的GC时间是263.142s
G1垃圾回收产生的FullGC次数是286,FullGC总的时间是32.271s,平均每次FullGC的时间是0.11s,总的GC时间是40.304s
显然在实验中,G1总的GC时间短,FullGC的次数是CMS的2.36倍,CMS应用暂停时间达到最大2.869s,G1最大应用暂停时间0.196s,也跟官方给FGC的最大暂停时间(200ms)接近G1算法已经称为Java8之后的默认算法,本身的需要调整的参数很少,性能&易用性方面都比CMS好。大内存的情况下,同等条件,G1算法比CMS更适合
https://www.oracle.com/cn/technical-resources/articles/java/g1gc.html
https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
The first focus of G1 is to provide a solution for users running applications that require large heaps with limited GC latency. This means heap sizes of around 6GB or larger, and stable and predictable pause time below 0.5 seconds.
Applications running today with either the CMS or the ParallelOldGC garbage collector would benefit switching to G1 if the application has one or more of the following traits.
– Full GC durations are too long or too frequent.
– The rate of object allocation rate or promotion varies significantly.
– Undesired long garbage collection or compaction pauses (longer than 0.5 to 1 second)
Note: If you are using CMS or ParallelOldGC and your application is not experiencing long garbage collection pauses, it is fine to stay with your current collector. Changing to the G1 collector is not a requirement for using the latest JDK.
以下是对oracle官方描述的翻译
G1的推荐用例
G1的首要重点是为运行需要大量GC延迟的应用程序的用户提供一个解决方案。这意味着堆大小约为6GB或更大,并且稳定且可预测的暂停时间低于0.5秒。
如果应用程序具有以下一个或多个特性,那么使用CMS或ParallelOldGC垃圾收集器运行的应用程序将有利于切换到G1。
• Full GC 持续时间太长或太频繁
• 对象分配频率高或者提升变化明显
• 不期望GC久、压缩停顿 (超过 0.5 to 1 秒)
注意:如果您使用的是CMS或parallelloldgc,并且您的应用程序没有遇到长时间的垃圾收集暂停,那么可以使用当前收集器。使用最新的JDK不需要更改为G1收集器。
本文作者:安全狗
本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/158874.html