-XX:+ParallelGC 和 -XX:+ParallelOldGC 有什么区别？

最新推荐文章于 2024-03-27 20:13:50 发布
原创 最新推荐文章于 2024-03-27 20:13:50 发布 · 1.2k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

博客介绍了HotSpot VM的垃圾回收选项，包括-XX:+UseParallelGC用于年轻代并行垃圾回收（1.4.1引入），-XX:+UseParallelOldGC用于全量并行垃圾回收（5.0 update 6引入），启用该选项会自动设置-XX:+UseParallelGC。

Take a look at the HotSpot VM Options:

-XX:+UseParallelGC = Use parallel garbage collection for scavenges. (Introduced in 1.4.1).

-XX:+UseParallelOldGC = Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.)

where Scavenges = Young generation GC.（其中 Scavenges = 年轻代 GC。）

JVM之垃圾收集器：Parallel与Parallel Old垃圾回收器
xylitolz的博客
04-06 805
文章目录简介设置Reference 简介 Parallel Scavenge Parallel Old 简介 和ParNew收集器不同，Parallel Scavenge收集器的目标是达到一个可控制的吞吐量(Throughput)，它也被称为吞吐量优先的垃圾收集器自适应调节策略也是Parallel Scavenge与ParNew一个重要区别 Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel Old收集器，用来替代老年代的Serial Old收集器
Java-Parallel GC介绍
Linux,Java,SpringBoot,Python,Lua略知一点
12-05 8331
JVM 垃圾收集器发展历史 JDK1.8中使用jmap -heap pid上面会出现Parallel GC jmap -heap 18378 Attaching to process ID 18378, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.261-b12 using thread-local object allocation. Parallel GC w
GC参数
天空之城
04-12 818
1.串行收集器： 1，最古老，最稳定 2，效率高 3，可能会产生较长的停顿       -XX:+UseSerialGC          --新生代，年老代使用串行回收             --新生代复制算法             --年老代标记-压缩     应用程序线程可能有多个，一旦回收开始，这些线程全部暂停，由GC线程接替运行，在串行回收器中,gc线程只有一个，
Linux环境多线程报错Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded原因解决以及分析
养歌的博客
12-23 1万+
今天线上的项目停止服务，导致用户登录不上，上次也导致了服务停止，没有把重心放在上面，今天又出现了这个问题才一直在找问题，查看日志定位到发生问题的地方，发现出现了java.lang.OutOfMemoryError: GC overhead limit exceeded错误。 那么这种原因是怎么来的？ 这个oracle官方已经给出了这个错误产生的原因和解决方法： 翻译过来的意思是： 线程名称中的异常：java。lang.OutOfMemoryError:超出GC开销限制 原因：详细消息“超出 GC 开销限制
Parallel GC
weixin_39035120的博客
07-01 617
英文原文地址：https://plumbr.io/handbook/garbage-collection-algorithms-implementations#parallel-gc This combination of Garbage Collectors usesmark-copyin the Young Generation andmark-sweep-compactin the Old Generation. Both Young and Old collections trigger ...
简介JVM的Parallel Scavenge及Parallel Old垃圾收集器
Etyero的博客
06-05 1万+
Parallel Scavenge: 是与ParNew类似，都是用于年轻代回收的使用复制算法的并行收集器，与ParNew不同的是，Parallel Scavenge的目标是达到一个可控的吞吐量，吞吐量=程序运行时间/（程序运行时间+GC时间），如程序运行了99s，GC耗时1s，吞吐量=99/（99+1）=99%。Parallel Scavenge提供了两个参数用以精确控制吞吐量，分别是用以控制最
JVM12_评估GC性能指标、垃圾收集器概述、Serial、SerialOld、ParNew、Parallel、ParallelOld
所得皆惊喜
09-26 2539
面试遇到面试官问这部分可以这样回答： 不同的厂商会考虑使用不同的JVM,不同的JVM会使用不同的垃圾收集器,下面我介绍下主流的垃圾收集器有哪些(主流的7种),下面你就可以展开去说明七种垃圾收集器的每一个细节。 (1).截止JDK 1.8，一共有7款不同的垃圾收集器。每一款不同的垃圾收集器都有不同的特点，在具体使用的时候，需要根据具体的情况选用不同的垃圾收集器 (2).不同厂商、不同版本的虚拟机实现差别很大。HotSpot 虚拟机在JDK7/8后所有收集器及组合（连线），如下图： ①. 评估GC的性能指.
Day04_JVM面试题（尚硅谷）
weixin_45014721的博客
08-20 821
JVM中常见的两种Error栈内存溢出堆内存溢出。
JVM调优实战：GC、Parallel、CMS、G1 常用参数，G1介绍、CPU100%排查
dandanforgetlove的专栏
05-15 3342
OOM：OutOfMemory。内存溢出 cpu 100%： 使用top，查看占用cpu比较高的进程，使用top -Hp 进程ID ，查看对应的占用cpu较高的线程。如果是java应用，使用 jstack 导出该线程的堆栈。然后查看哪个方法（栈帧）消耗时间 jstack。 内存飙高： 导出堆内存 jmap，使用jhat 、jvisualvm、mat 等等进行分析。 如何监控JVM： jstat、jvisualvm 等等 ...
JVM知识详解
prefect_start的博客
04-08 487
JVM 1、JVM内存结构 1.1、JVM体系概述 1.2、常见的垃圾回收算法 引用计数法 顾名思义，此种算法会在每一个对象上记录这个对象被引用的次数，只要有任何一个对象引用了次对象，这个对象的计数器就+1，取消对这个对象的引用时，计数器就-1。任何一个时刻，如果该对象的计数器为0，那么这个对象就是可以回收的。 优点： 引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。 缺点： 无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，
java架构学习——13. 垃圾回收机制算法分析&使用Jmeter压力测试工具
wmq_fly的博客
02-14 496
一、基本概念 什么是垃圾回收机制？ 垃圾回收机制不定时，向堆内存清理不可达对象。 手动GC回收 代码演示： public class GcDemo { public static void main(String[] args) { GcDemo gc = new GcDemo(); //将对象设置为不可达，垃圾回收机制将对其进行回收 gc = null; //手动...
剑指Offer(GC)——常见的老年代垃圾收集器（Full GC）
0117
11-30 903
还是先把这张图放上，然后再对于老年代这几个垃圾收集器逐一讲解。 Serial Old收集器（-XX：+UseSerialOldGC，标记-整理算法） 它是Serial GC的老年代版本，同样也是单线程的，进行垃圾收集的时候，必须暂停所有工作的线程，同样也是简单高效，适用于Client模式下默认的老年代垃圾收集器。 Parallel Old 收集器（-XX：+UseParallelOldG...
JVM学习笔记（5）之GC类型
鹏哥技术博客
01-22 1228
JDK7的5种GC类型 SerialGC ParallelGC ParallelOld GC (Parallel Compacting GC) ConcurrentMark & Sweep GC  (or “CMS”) GarbageFirst (G1) GC Serial GC 使用标记整理法 Serial GC不应该被用在服务器上。这种GC类型在单核CPU的桌面电脑时代就存在了
Parallel GC 最佳参数
weixin_42710740的博客
03-27 762
JVM的Parallel（吞吐量）垃圾收集器是以达到一定的吞吐量为目标的收集器，适合运行在多核处理器上的后台应用。Parallel GC的最佳参数取决于具体应用的工作负载和目标。: 设置垃圾收集时间占程序运行时间的比例，默认为99，即1%的时间用于GC。: 设置JVM堆的最大和最小大小，确保堆大小对GC影响最小，减少GC频率。: 启用Parallel GC，用于整个GC堆（包括新生代和老年代）。: 设置GC的最大暂停时间（目标时间），以毫秒为单位。: 启用Parallel GC，用于新生代。
JVM的GC算法由CMS切换为G1
qq_38658642的博客
11-23 1747
jvm的GC算法
【JVM】JVM内存结构之——垃圾收集器（并发与并行/ GC性能指标/ 垃圾收集器组合关系/ CMS收集器/ G1收集器）
记录各种Bug解决案例及日常学习内容
05-12 2223
目录1. System.gc()方法2. 并行与并发概念2.1 并发的概念2.2 并行的概念3. 垃圾回收器并行与串行区别4. 并行收集器(parallel) 与并发收集器(concurrent)区别5. 评估 GC 的性能指标5.1 吞吐量（throughput）5.2 暂停时间（pause time）5.3 吞吐量 vs 暂停时间区别6. 垃圾收集器发展历史7. 7款经典的垃圾收集器8. 经典的垃圾收集器关系9. 垃圾收集器组合关系10. 串行垃圾收集器Serial、Serial old10.1 串行收
JVM（Java虚拟机）优化大全和案例实战
热门推荐
碧荷故乡_胡奇的专栏
03-06 5万+
堆内存设置原理JVM堆内存分为2块：Permanent Space 和 Heap Space。Permanent 即 持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代（Old Generation），New 即 年轻代（Yo
JVM学习----七种垃圾收集器（GC）
Thomasc的博客
01-08 7382
文章目录GC垃圾收集器七种经典的垃圾回收器查看默认垃圾收集器新生代Serial垃圾收集器（单线程、 复制算法）ParNew 垃圾收集器 （Serial的多线程版本、 复制算法）Parallel Scavenge 收集器（多线程复制算法、高效）老年代Serial Old（单线程、标记整理算法）Parallel Old收集器（多线程、标记整理算法）CMS详解(Concurrent mark sweep)收集器（多线程、标记清除算法 低延迟）垃圾回收器选择小结空间分配担保G1(Garbage first)收
JVM回收策略
liuerchong的博客
09-07 626
JVM将整个堆划分为Young区、Old区和Perm区，分别存放不同年龄的对象，这三个区存放的对象有如下区别： Young：分为Eden区和两个Survivor区，其中所有新创建的对象都在Eden区，当Eden区满后会出发minor GC将Eden区仍然存好的对象复制到其中一个Survivor区中，另外一个Survivor区中的存活对象也复制到这个Survivor中，以保证始终有一个Survivor区是空的。一般情况下，Young区的大小为整个堆区的1/4，Survivor区为整个Young区的1/8
分析 /usr/local/jdk/bin/java -Xms32G -Xmx32G -Xmn4608m -XX:+UseParallelOldGC -XX:ParallelGCThreads=8 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Xloggc:/u1/logs/payment-service/log/gc.txt -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=20 -XX:GCLogFileSize=500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/u1/logs/payment-service/log/service.hprof -javaagent:/u/opentelemetry/opentelemetry-javaagent.jar
最新发布
10-01
你提供的 JVM 启动命令如下： ```bash /usr/local/jdk/bin/java \ -Xms32G -Xmx32G \ -Xmn4608m \ -XX:+UseParallelOldGC \ -XX:ParallelGCThreads=8 \ -XX:+PrintGCDetails \ -XX:+PrintGCDateStamps \ -XX:+PrintGCTimeStamps \ -Xloggc:/u1/logs/payment-service/log/gc.txt \ -XX:+UseGCLogFileRotation \ -XX:NumberOfGCLogFiles=20 \ -XX:GCLogFileSize=500m \ -XX:+HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath=/u1/logs/payment-service/log/service.hprof \ -javaagent:/u/opentelemetry/opentelemetry-javaagent.jar \ ... ``` 我们来**逐项分析其作用、潜在问题和优化建议**，特别结合 **`payment-service`（支付服务）这类关键业务系统** 的特点。 --- ## ✅ 一、参数详解与作用 | 参数 | 说明 | |------|------| | `-Xms32G -Xmx32G` | 初始堆和最大堆均为 32GB，固定大小，避免动态扩容开销 | | `-Xmn4608m` | 新生代大小为 4.5GB（4608 MB） | | `-XX:+UseParallelOldGC` | 使用 Parallel Scavenge + Parallel Old GC（吞吐量优先收集器） | | `-XX:ParallelGCThreads=8` | 设置并行 GC 线程数为 8 | | `-XX:+PrintGCDetails` | 输出详细 GC 日志 | | `-XX:+PrintGCDateStamps` | 打印 GC 发生的日期时间戳 | | `-XX:+PrintGCTimeStamps` | 打印从 JVM 启动到 GC 发生的时间（秒） | | `-Xloggc:...` | 指定 GC 日志文件路径 | | `-XX:+UseGCLogFileRotation` | 开启日志滚动 | | `-XX:NumberOfGCLogFiles=20` | 最多保留 20 个 GC 日志文件 | | `-XX:GCLogFileSize=500m` | 单个 GC 日志最大 500MB | | `-XX:+HeapDumpOnOutOfMemoryError` | OOM 时自动生成堆转储 | | `-XX:HeapDumpPath=...` | 堆转储文件保存路径 | | `-javaagent:...` | 使用 OpenTelemetry Java Agent 实现无侵入监控 | --- ## ✅ 二、核心问题分析 ### ❌ 1. `UseParallelOldGC` + 大堆（32GB） → 可能导致长时间 Full GC 停顿 > ⚠️ **Parallel GC 是“高吞吐、低停顿容忍”的垃圾回收器**，适合批处理任务，但不适合对延迟敏感的服务。 #### 问题： - 当老年代满时，触发 `Full GC (Parallel Old)`，会进行 **全局压缩（mark-compact）** - 在 32GB 堆上，一次 Full GC 的 STW（Stop-The-World）时间可能达到 **数秒甚至十几秒** - 对于支付服务这种要求 **高可用、低延迟** 的场景，这是不可接受的！ #### 示例现象： ```text 2025-04-05T10:23:45.123+0800: 1234.567: [Full GC (Ergonomics) [PSYoungGen: ...] [ParOldGen: ...] 32G->18G(32G), 8.345 secs] ``` → 应用卡住 8 秒以上，用户请求超时。 --- ### ❌ 2. `-Xmn4608m` 固定新生代太小（仅 4.5GB），可能导致频繁 Minor GC 和提前晋升 计算： - 总堆：32GB - 新生代：4.5GB → 占比约 **14%** - 老年代：≈27.5GB 👉 一般推荐新生代占堆的 **30%~50%**，尤其是短生命周期对象多的 Web 服务。 #### 风险： - Eden 区过小 → Minor GC 频繁（每几秒一次） - Survivor 区不够大 → 对象无法熬过多次 GC → 提前晋升到老年代 - 老年代增长快 → 更容易触发 Full GC --- ### ❌ 3. 缺少对 Metaspace 的控制 未设置： ```bash -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m ``` 风险： - 默认 Metaspace 动态扩展，可能导致间接内存溢出或频繁 GC - 尤其在热部署、反射、CGLIB 动态生成类较多时更明显 --- ### ✅ 4. GC 日志配置合理（值得肯定） - 开启了详细的 GC 日志 - 启用了日志滚动机制（20 × 500MB = 10GB 日志空间） - 记录时间戳，便于排查问题 👍 这是非常好的生产实践。 --- ### ✅ 5. HeapDump 配置正确 - 出现 OOM 自动 dump - 指定了路径，方便后续用 MAT / VisualVM 分析内存泄漏 👍 推荐保留。 --- ### ✅ 6. 使用 OpenTelemetry Agent ```bash -javaagent:/u/opentelemetry/opentelemetry-javaagent.jar ``` - 实现无侵入式链路追踪、指标采集 - 适合现代可观测性需求 👍 推荐继续使用。 --- ## ✅ 三、改进建议（适用于支付类关键服务） ### 🔁 推荐替换 GC 收集器为 G1GC ```diff -XX:+UseParallelOldGC +XX:+UseG1GC +XX:MaxGCPauseMillis=200 +XX:InitiatingHeapOccupancyPercent=45 +XX:+G1UseAdaptiveIHOP ``` ✅ **优势**： - 可预测的停顿时间（目标 200ms 内） - 分区域回收，避免整堆 Full GC - 更适合交互式、响应敏感型服务 --- ### 🔁 调整新生代大小（不再硬编码 `-Xmn`） ```diff # 删除 -Xmn4608m +XX:G1NewSizePercent=30 +XX:G1MaxNewSizePercent=40 ``` 让 G1 自适应调节新生代大小（约 9.6G ~ 12.8G），更适合流量波动场景。 --- ### 🔁 添加 Metaspace 控制 ```bash -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m ``` 防止元空间无限扩张。 --- ### 🔁 可选：调整线程栈大小（如有大量线程） ```bash -Xss512k ``` 默认是 1M/线程，如果线程池较大（如 Tomcat maxThreads=1000），则栈内存消耗可达 1GB。 --- ## ✅ 四、优化后的完整参数示例 ```bash /usr/local/jdk/bin/java \ -Xms32G -Xmx32G \ -XX:+UseG1GC \ -XX:MaxGCPauseMillis=200 \ -XX:InitiatingHeapOccupancyPercent=45 \ -XX:+G1UseAdaptiveIHOP \ -XX:G1NewSizePercent=30 \ -XX:G1MaxNewSizePercent=40 \ -XX:ParallelGCThreads=8 \ -XX:ConcGCThreads=4 \ -XX:MetaspaceSize=256m \ -XX:MaxMetaspaceSize=512m \ -Xss512k \ -XX:+PrintGCDetails \ -XX:+PrintGCDateStamps \ -XX:+PrintGCTimeStamps \ -Xloggc:/u1/logs/payment-service/log/gc.txt \ -XX:+UseGCLogFileRotation \ -XX:NumberOfGCLogFiles=20 \ -XX:GCLogFileSize=500m \ -XX:+HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath=/u1/logs/payment-service/log/service.hprof \ -javaagent:/u/opentelemetry/opentelemetry-javaagent.jar \ -jar payment-service.jar ``` --- ## ✅ 五、补充建议 | 项目 | 建议 | |------|------| | **监控** | 配合 Prometheus + Grafana + JMX Exporter 监控 GC 频率、堆使用等 | | **告警** | 设置规则：Minor GC > 1次/秒 或 Full GC > 1次/小时 触发告警 | | **压测验证** | 使用 JMeter / wrk 对新配置做压力测试，观察 P99 延迟变化 | | **日志分析工具** | 使用 [gceasy.io](https://gceasy.io) 分析 GC 日志，查看是否存在晋升失败等问题 | --- ## ✅ 六、总结 | 原配置 | 问题 | 建议 | |--------|------|-------| | `-XX:+UseParallelOldGC` | 大堆下 Full GC 停顿长 | 改用 `G1GC` | | `-Xmn4608m` | 新生代占比过低 | 改为百分比自适应 | | 无 Metaspace 控制 | 存在内存失控风险 | 加上限 | | GC 日志 & HeapDump | 配置良好 | 保留并加强分析 | | OpenTelemetry Agent | 优秀实践 | 继续使用 | > 🟢 **结论**：当前配置适合批处理作业，但**不适合支付类关键在线服务**。应切换为 G1GC 并优化新生代策略，以降低延迟、提高稳定性。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值