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 信息、花在年轻代和年老代回收上的时间比例。吞吐量优先的应用:通常吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.缘由是,这样能够尽量回收掉大部分短时间对象,减小中期的对象,而年老代尽存放长期存活对象