Java Performance - Garbage Collection/垃圾收集

标签：

 随着硬件的不断提升，Java Heap 越来越大，合理的垃圾收集调优变得愈发重要。下面介绍一些最佳实践：

注意:

1. 下面不涉及 IBM AIX Java. 同时不介绍原理，仅仅是建议以及初始配置/最佳实践，后续如何迭代优化
2. 需要理解 The Java Virtual Machine Specification  > Run-Time Data Areas 和 Memory Management Whitepaper

• 配置合适的堆内存大小
  • 通过配置 -Xms -Xmx 设定，分别表示初始和最大值
  • 可以是 4G, 8G, 12G, 16G, 甚至 24G 等等
  • 关于 YOUNG 和 OLD 默认 1:2 的比例 （ -XX:NewRatio ），不太建议一开始就调整，后续结合 GC 检查

• 垃圾收集优化建议
  • • 配置 -XX:+DisableExplicitGC
      • 很多代码里面会有 System.gc() 的调用来触发垃圾收集，带来不必要的负担；该配置会忽略该 API 调用。
    • 选择  GC Policy
      • Java 7 建议默认 - 多线程并行垃圾收集不管 YONG/OLD，线程数是 CPU 个数
      • Java 6 - 默认 YOUNG 多线程并运行，OLD 单线程。建议配置 OLD 多线程并行配置 -XX:+UseParallelOldGC
      • 线程数通过 -XX:ParallelGCThreads 配置，建议值是 CPU 个数除以 JVM 个数
    • 其它 GC 策略
      • Java 6 的 -XX:+UseConcMarkSweepGC，不太建议因为 Java 7 淘汰了; 有 BUG；同时有一个阶段还是会暂停 JVM ，并且特别久 - 6G 的堆可能要几十秒
      • Java 7 以来的 G1 - 没实践过，任何的 GC BUG 都是致命的。
        
        
• 监控 GC 状况
  • 通过配置 -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:<path>/gc.log 打印 GC 详细日志
  • 分析 GC 频率
  • 分析 GC 前后内存情况
  • 分析 GC user, sys, real 耗时
  • 比如 - 下面就明确反映操作系统 BUG，在并行 GC 情况下，大约应该是 user / GC线程数 = real
    

    [GC [PSYoungGen: 6144000K->423839K(7168000K)] 6455356K->735195K(15360000K), 182.4565520 secs] [Times: user=1.71 sys=1454.44, real=182.43 secs]
    --YOUNG GC，共 7168000K 大小，收集前用了 6144000K， 后用了 423839K，共耗时 182.4565520 sec
    [GC [PSYoungGen: 629652K->413103K(7168000K)] 941009K->724459K(15360000K), 116.7165380 secs] [Times: user=1.25 sys=932.20, real=116.70 secs]
    --YOUNG GC，user=1.25 （GC CPU 耗时） sys=932.20 （OS 耗时）, real=116.70 secs （总耗时）
    [Full GC [PSYoungGen: 367256K->0K(7495680K)] [ParOldGen: 429715K->699671K(8192000K)] 796972K->699671K(15687680K) [PSPermGen: 126393K->126390K(2097152K)], 558.1420070 secs] [Times: user=2.77 sys=4458.28, real=558.06 secs]
    --FULL GC

     

Java Performance - Garbage Collection/垃圾收集

标签：

原文地址：http://www.cnblogs.com/tang88seng/p/5117339.html