java-GC调优

一.目的
    GC 的时间够小
    GC 的次数够少
    发生 Full GC 的周期足够的长,时间合理,最好是不发生。
二.调优的原则和步骤
    1. 大多数的 java 应用不需要 GC 调优
    2. 大部分需要 GC 调优的的,不是参数问题,是代码问题
    3. 在实际使用中,分析 GC 情况优化代码比优化 GC 参数要多得多;
    4. GC 调优是最后的手段
三.GC调优的最重要的三个选项:
    第一位:选择合适的 GC 回收器
    第二位:选择合适的堆大小
    第三位:选择年轻代在堆中的比重
四.步骤
    1:监控 GC的状态使用各种 JVM 工具,查看当前日志,分析当前 JVM 参数设置,并且分析当前堆内存快照和 gc 日志,根据实际的各区域内存划分和 GC 执行时间,觉得是否进行优化;
    2:分析结果,判断是否需要优化如果各项参数设置合理,系统没有超时日志出现,GC 频率不高,GC 耗时不高,那么没有必要进行 GC 优化;如果 GC 时间超过 1-3 秒,或者频繁 GC,则必须优化;
        注: 如果满足下面的指标,则一般不需要进行 GC :
                Minor GC 执行时间不到 50ms;
                Minor GC 执行不频繁,约 10 秒一次;
                Full GC  执行时间不到 1s ;
                Full GC 执行频率不算频繁,不低于 10 分钟 1 次;
    3:调整GC类型和内存分配如果内存分配过大或过小,或者采用的 GC 收集器比较慢,则应该优先调整这些参数,并且先找1台或几台机器进行beta,然后比较优化过的机器和没有优化的机器的性能对比,并有针对性的做出最后选择;
    4:不断的分析和调整通过不断的试验和试错,分析并找到最合适的参数
    5:全面应用参数如果找到了最合适的参数,则将这些参数应用到所有服务器,并进行后续跟踪。
五.学会阅读GC日志
以参数-Xms5m -Xmx5m -XX:+PrintGCDetails -XX:+UseSerialGC 为例:
[DefNew: 1855K->1855K(1856K), 0.0000148 secs][Tenured: 2815K->4095K(4096K),0.0134819 secs] 4671K
DefNew 指明了收集器类型,而且说明了收集发生在新生代。1855K->1855K(1856K)表示,回收前 新生代占用 1855K,回收后占用 1855K,新生代大小 1856K。0.0000148 secs 表明新生代回收耗时。Tenured 表明收集发生在老年代2815K->4095K(4096K),0.0134819 secs:含义同新生代最后的 4671K 指明堆的大小。
收集器参数变为-XX:+UseParNewGC,日志变为:
[ParNew: 1856K->1856K(1856K), 0.0000107 secs][Tenured: 2890K->4095K(4096K),0.0121148 secs]
收集器参数变为-XX:+ UseParallelGC 或 UseParallelOldGC,
日志变为:
[PSYoungGen: 1024K->1022K(1536K)] [ParOldGen: 3783K->3782K(4096K)]4807K->4804K(5632K),
CMS 收集器和 G1 收集器会有明显的相关字样
六.其他与GC相关的参数
    调试跟踪之打印简单的GC信息参数: -verbose:gc, -XX:+PrintGC
    打印详细的GC信息 -XX:+PrintGCDetails, +XX:+PrintGCTimeStamps
    -Xlogger:logpath设置gc的日志路,如: -Xlogger:log/gc.log, 将 gc.log 的路径设置到当前目录的 log 目录下.    应用场景: 将 gc 的日志独立写入日志文件,将 GC 日志与系统业务日志进行了分离,方便开发人员进行追踪分析。
    -XX:+PrintHeapAtGC, 打印推信息参数设置: 
    -XX:+PrintHeapAtGC   应用场景:获取 Heap 在每次垃圾回收前后的使用状况
    -XX:+TraceClassLoading参数方法: 
    -XX:+TraceClassLoading应用场景,在系统控制台信息中看到class加载的过程和具体的class信息,可用以分析类的加载顺序以及是否可进行精简操作。
    -XX:+DisableExplicitGC 禁止在运行期显式地调用 System.gc()
    -XX:-HeapDumpOnOutOfMemoryError 默认关闭,建议开启,在java.lang.OutOfMemoryError 异常出现时,输出一个 dump.core 文件,记录当时的堆内存快照。
    -XX:HeapDumpPath=./java_pid<pid>.hprof 默认是 java 进程启动位置,用来设置堆内存快照的存储文件路径。
七.推荐策略-年轻代大小选择
· 响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.· 吞吐量优先的应用:尽可能的设置大,可能到达 Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合 8CPU 以上的应用.· 避免设置过小.当新生代设置过小时会导致:1.YGC 次数更加频繁 2.可能导致 YGC 对象直接进入旧生代,如果此时旧生代满了,会触发 FGC.年老代大小选择0.响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎 片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:并发垃圾收集信息、持久代并发收集次数、传统 GC 信息、花在年轻代和年老代回收上的时间比例。吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值