网站建设基本情况老房改造 装修公司

1. 背景

java8中默认使用parallel scavenge + parallel old的组合。当然我们也可使用parnew + cms或g1的方案。
在实际应用过程中，如果ygc和fgc都比较少，如ygc一天几次或者一小时几次，其实我们都不用关心垃圾回收器的选型。因为垃圾回收器的改变带来的性能提升几乎可以忽略。
然而，在大流量高并发场景下，如果一分钟出现1次或者多次ygc的话，那么我们评估使用场景，选择合适的垃圾回收器就显得更有价值。
另外，其实在实际应用过程中很少会出现fgc的情况，即使大流量的服务，基本都是在执行ygc，有时候可能几天才会出现一次fgc甚至很久都不出现。而且，线上活跃的应用一般都会持续迭代，可能3/5天上线一次，每次服务发布，之前积压的内存就清理了，几乎不会触发fgc。

2. 对比

接下来我们对比一下上述三种搭配的适用场景：

2.1 parallel scavenge+ parallel old

启动参数：-XX:+UseParallelGC（新生代）和 -XX:+UseParallelOldGC（老年代），一般默认，不用手动配置。

特点：

多线程并行回收新生代（Parallel Scavenge）和老年代（Parallel Old）。
默认以最大化吞吐量（应用运行时间占比）为目标。
适合多核服务器环境，但对延迟敏感的应用可能不友好。

适用场景：后台计算密集型任务（如批处理），不追求低延迟。

实战示例：8C16G机器

-Xms8192m
-Xmx8192m
-XX:MaxMetaspaceSize=512m
-XX:MetaspaceSize=512m
-XX:MaxDirectMemorySize=1024m
-XX:ConcGCThreads=4
-XX:ParallelGCThreads=8
-Xmn4096m
-XX:CICompilerCount=3
-XX:+UnlockExperimentalVMOptions
-XX:+ParallelRefProcEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/export/Logs/xxx/gc.log
-XX:GCLogFileSize=1024M
-XX:+HeapDumpAfterFullGC
-XX:HeapDumpPath=/export/Logs/xxx/fgcdump.log

2.2 parnew + cms

启动参数：-XX:+UseConcMarkSweepGC，需要手动配置，同时还需要其他参数，后文列出。

特点：

老年代使用并发标记清除算法，尽量减少停顿时间。
新生代默认使用ParNew回收器（多线程）。
通过并发标记减少STW时间，但存在内存碎片问题。
注意：Java 8中仍可用，但在后续版本（Java 9+）被标记为废弃（Deprecated），最终在Java 14中被移除。

适用场景：对延迟敏感的中大型应用（如Web服务）。
搭配参数：

参数	含义	示例
-XX:ParallelGCThreads	并行GC线程的数量（ncpu <= 8 : ParallelGCThreads = ncpus，ncpu > 8 : 8 + (ncpus - 8) ( 5/8 )）	-XX:ParallelGCThreads=8
-XX:+UseParNewGC	年轻代使用ParNew	-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC	老年代使用CMS	-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled	JVM会在CMS的并发标记阶段（Concurrent Marking Phase）触发类卸载，释放不再使用的类元数据占用的内存	-XX:+CMSClassUnloadingEnabled
-XX:+UseCMSInitiatingOccupancyOnly	只用设定的回收阈值，如果不指定，JVM仅在第一次使用设定值，后续则自动调整	-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction	老年代允许的最大使用率，达到则触发old gc	-XX:CMSInitiatingOccupancyFraction=75
-XX:+CMSParallelRemarkEnabled	在CMS GC前启动一次ygc，目的在于减少old gen对ygc gen的引用，降低remark时的开销，一般CMS的GC耗时 80%都在remark阶段	-XX:+CMSParallelRemarkEnabled
-XX:CICompilerCount	热点编译器线程数（2 + int(max(0, cpu_core_num - 2) * 0.25)最低2核，超出2核的部分拿出25%来热点编译）	-XX:CICompilerCount=3
-XX:ConcGCThreads	CMS下是(ParallelGCThreads + 3) / 4 向下取整， G1下是ParallelGCThreads / 4	-XX:ConcGCThreads=4

实战示例：8C16G机器

-Xms8192m
-Xmx8192m
-XX:MaxMetaspaceSize=512m
-XX:MetaspaceSize=512m
-XX:MaxDirectMemorySize=1024m
-XX:ConcGCThreads=4
-XX:ParallelGCThreads=8
-Xmn4096m
-XX:CICompilerCount=3
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+UnlockExperimentalVMOptions
-XX:+CMSClassUnloadingEnabled
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75
-XX:+ExplicitGCInvokesConcurrent
-XX:+ParallelRefProcEnabled
-XX:+CMSParallelRemarkEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/export/Logs/xxx/gc.log
-XX:GCLogFileSize=1024M
-XX:+HeapDumpAfterFullGC
-XX:HeapDumpPath=/export/Logs/xxx/fgcdump.log

2.3 g1

启动参数：-XX:+UseG1GC，需要手动配置，同时还需要其他参数，后文列出。

特点：

将堆划分为多个区域（Region），优先回收垃圾最多的区域。
可预测的停顿时间模型，支持大堆（数十GB到上百GB）。
混合了标记-整理和复制算法，减少内存碎片。
注意：Java 7u4引入，Java 9+成为默认回收器。

适用场景：需要平衡吞吐量和延迟的大型应用（如企业级服务）。
搭配参数（cms体系中描述过的这里不再赘述，见示例）：

参数	含义	示例
-XX:+UseG1GC	使用G1垃圾回收器	-XX:+UseParNewGC
-XX:MaxGCPauseMillis	设置 G1 的暂停时间目标。这会告诉 G1 试图将 GC 暂停时间控制在指定的毫秒数内	-XX:MaxGCPauseMillis=50
-XX:G1HeapRegionSize	设置 G1 的堆区域大小。堆被划分为多个区域（Region），G1 GC 在这些区域上进行垃圾收集。设置合适的区域大小可以帮助提高垃圾回收效率。（）	-XX:G1HeapRegionSize=16m

实战示例：8C16G机器

-Xms8192m
-Xmx8192m
-XX:MaxMetaspaceSize=512m
-XX:MetaspaceSize=512m
-XX:MaxDirectMemorySize=1024m
-Xmn4096m
-XX:ConcGCThreads=2
-XX:ParallelGCThreads=8
-XX:CICompilerCount=3
-XX:+UseG1GC
-XX:MaxGCPauseMillis=50
-XX:+UnlockExperimentalVMOptions
-XX:+ParallelRefProcEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/export/Logs/xxx/gc.log
-XX:GCLogFileSize=1024M
-XX:+HeapDumpAfterFullGC
-XX:HeapDumpPath=/export/Logs/xxx/fgcdump.log

3. 总结

后台计算密集型任务（如批处理），不追求低延迟。场景下使用默认配置，即parallel scavenge + parallel old。对延迟敏感的中大型应用（如Web服务）使用parnew + cms。需要平衡吞吐量和延迟的大型应用（如企业级服务）使用g1。
C端高并发应用优先考虑parnew + cms 或 g1，但具体的选型还需根据实际场景评估，如果很难评估的情况下，可以同分组内A B两台机器，上线后观察分析gc日志以及在流量高峰期的cpu表现。