GC调优

调优步骤

打印GC日志

根据日志得到关键性能指标

分析GC原因,调优JVM参数

初始设置

-XX:+HeapDumpOnOutOfMemoryError  //内存溢出时,生产hprof文件

-XX:HeapDumpPath=./   //hprof文件的保存位置,./是指当前路径

-XX:+PrintGCDetails   //打印GC详细信息

-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps     //打印CG发生的时间戳 

-Xloggc:../logs/gc.log     //日志文件的输出路径

-XX:+DisableExplicitGC  //不允许使用system.gc 回收垃圾

Parallel GC

指导原则

除非确定,否则不要设置最大堆内存

优先设置吞吐量目标

如果吞吐量目标达不到,调大最大内存,不能让OS使用Swap,如果仍然达不到,降低目标

吞吐量能达到,GC时间太长,设置停顿时间的目标

指导文档

GC调优指南:

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

调优过程

 

吞吐量

最小停顿时间

最大停顿时间

平均停顿时间

YGC

FullGC

调优前

96.78%

0.02017

0.10323

0.0487

11

2

一次调优后

98.13%

0.01901

0.05685

0.03576

10

0

二次调优后

97.71%

0.01519

0.06736

0.03442

12

0

三次调优后

98.14%

0.01966

0.06622

0.04111

10

0

第一次调优

 

YoungGC发生11次垃圾回收,其中有2次metaspace引起

FullGC次,其中2次metaspace引起

 

工具中观察,metaspace的内存空间34M

增加相关参数:

-XX:MetaspaceSize=64M

第二次调优

##设置吞吐量目标

-XX:GCTimeRatio=99         //设置吞吐量为99%

##设置响应时间目标

-XX:MaxGCPauseMillis=100    //设置最大的停顿时间是100毫秒

第三次调优

##每次发生young gc时,内存要动态调大,默认是20%,调整为30%,可以减少younggc的次数

-XX:YoungGenerationSizeIncrement=30

G1 GC

指导原则

年轻代的大小:避免使用-Xmn、-XX:NewRatio等显示设置Young区大小,会覆盖暂停时间目标

暂停时间目标:暂停时间不要太严苛,其吞吐量目标是90%的应用程序时间和10%的垃圾回收时间,太苛刻会影响吞吐量

关于MixGC调优

-XX:InitiatingHeapOccupancyPercent

【堆占有率达到这个数值则触发global concurrent marking,默认是45%】

-XX:G1HeapWastePercent

【在global concurrent marking结束之后,可以知道区有多少空间要被回收,在每次YGC之后和再次发生MixedGC之前,会检查垃圾占比是否达到此参数,只有达到了,下次才会发生Mixed GC】

-XX:G1MixedGCLiveThresholdPercent

【Old区的region被回收的时候的存活对象占比】

-XX:G1MixedGCCountTarget

【一次global concurrent marking之后,最多执行Mixed GC的次数】

-XX:G1OldCsetRegionThresholdPercent

【一次Mixed GC中能选入CSet的最多old去区的region数量】

G1调优相关参数

-XX:+UseG1GC

-Xms 128M

-Xmx 128M

-XX:MetaspaceSize=64M

-XX:MaxGCPauseMillis=100

调优过程

 

吞吐量

最小停顿时间

最大停顿时间

平均停顿时间

YGC

FullGC

调优前

93.96%

0.00001

0.33139

0.02246

188

3

一次调优后

95.4%

0.01901

0.22914

0.0217

168

0

二次调优后

97.26%

0.00041

0.04276

0.031131

339

0

第一次调优

 

发现metaspace导致发生full gc

添加相关参数:

-XX:MetaspaceSize=64M

效果

第二次调优

虽然fullgc不错在了,但younggc发生了138次,将堆大小改为固定值

添加相关参数:

-Xms 128M -Xmx 128M

 

### Java GC 方法及参数配置 #### 一、GC的目标 GC的主要目标在于避免因垃圾回收引起的程序性能下降。具体来说,主要关注以下几个核心指标[^3]: - **垃圾回收吞吐量**: 用户代码执行时间 / (用户代码执行时间 + GC 时间),通常希望尽可能接近100%。 - **延迟**: 包括GC本身的延迟和业务逻辑执行过程中的中断时间。 - **内存使用量**: 需要平衡堆内存分配与实际应用的需求。 #### 二、发现并诊断问题 为了实现有效的GC,首先需要识别潜在的性能瓶颈,并对其进行详细的分析。以下是常用的工具及其功能描述: - **jstat**: 提供关于垃圾回收的关键统计数据,可以通过`jstat -gc <PID> <interval> <count>`来获取特定进程的GC详情。 - **VisualVM**: 结合其插件(如Visual GC),能够直观展示Java进程中堆内存结构的变化趋势以及GC活动的时间分布情况。 - **Prometheus + Grafana**: 对于复杂的生产环境而言,这套组合提供了高度定制化的监控解决方案,尽管部署成本较高。 #### 三、化策略 ##### 1. 整JVM内存大小 合理的内存分配对于降低GC频率至关重要。如果堆空间过小,则可能导致频繁的小型GC;反之,过大可能增加老年代GC所需时间。一般建议依据应用程序的实际负载动态整初始堆(-Xms)和最大堆(-Xmx)尺寸[^4]: ```bash java -Xms512m -Xmx4g ... ``` ##### 2. 选择合适的垃圾收集器 不同类型的垃圾收集器适用于不同的场景: - **Serial Collector (-XX:+UseSerialGC)**: 单线程工作模式,适合小型单核设备上的简单应用场景。 - **Parallel Collector (-XX:+UseParallelGC)**: 多线程并发处理,注重整体吞吐量提升,在后台服务器端表现良好。 - **Concurrent Mark Sweep(CMS) Collector (-XX:+UseConcMarkSweepGC)**: 努力缩短STW(stop-the-world)事件持续时长,更适合交互性强的服务端应用。 - **Garbage First(G1) Collector (-XX:+UseG1GC)**: 新一代混合型算法,既追求高吞吐又兼顾低延迟能力,推荐用于大容量数据集场合. ##### 3. 设置GC线程数 可通过JMX或其他管理接口查看当前系统中运行了多少个GC线程。适当节这些线程的数量有助于改善多处理器架构下的效率。例如: ```bash java -XX:ParallelGCThreads=8 ... ``` 注意此选项仅对某些特定种类的收集器生效[^1]。 ##### 4. 使用现代日志机制替代旧版标志位 自JDK 9起,传统打印细节(`-XX:+PrintGCDetails`)已被弃用,取而代之的是统一的日志框架-Xlog[:what][:where][:modifiers][^2]。比如记录所有级别的GC消息到文件可写成如下形式: ```bash java -Xlog:gc*:file=my_gc_log.txt:time,uptime,level,tags ... ``` 最后还需强一点,任何改动都应经过充分测试才能投入正式环境中去实施。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值