-verbose:gc
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=512K
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/var/app/log/Push-server/gc.log

1. 如果不能确定所需内存，使用自动jvm自动调优；
2. 大致确定所需内存后，使用-Xmx -Xms设置堆大小；
3. 观察GC log确定FullGC后剩余堆大小（即为活跃数据大小）；
4. 整个堆大小宜为老年代活跃数据大小的3-4倍；
5. 永久带大小应该比永久带活跃数据大1.2~1.5倍；
6. 新生代空间应该为老年代空间活跃数据的1~1.5倍；
7. 通过top命令观察栈占用空间、直接内存占用空间，决定所需机器内存大小；
8. 新生代大小决定了Minor GC的周期和时长，缩短新生代大小可以减少停顿时长，但是增加了GC频率；在调整新生代大小时，尽量保持老年代大小不变；
9. 老年代大小不应该小于活跃数据的1.5倍；新生代空间至少为java堆大小的10%；增加堆大小时，注意不要超过可用物理内存数；
10. 从throughput收集器迁移到CMS时，需要将老年代空间增加20%~30%；
11. 新生代分为Eden和Survivor两部分，Survivor可以通过-XX:SurvivorRatio=xx来控制，对应的大小为-Xmn<value>/(ratio+2)；
12. 通过-XX:MaxTenuringThreshold=<n>来指定晋升阈值（年龄），n为0~15之间；
13. 期望Survivor空间为剩余总存活对象大小的2倍(age=1；
14. 注意调节Survivor大小时，保持Eden大小不变；
15. 如果Survivor空间足够大，且对象大部分并未到达老年代，那么就可以将晋升年纪指定的足够大（15）。在Eden与Survivor之间复制和CMS老年代空间压缩之间，我们宁愿选择前者；
16. CMS必须能以对象从新生代提升到老年代的同等速度对老年代中的对象进行收集，否则，就会失速；
17. 如果观察到'concurrent mode failures'，意味着失速已经发生，必须减少-XX:CMSInitiatingOccupancyFraction=<percent>的值；
18. 使用上述选项的同时，最好同时使用-XX:+UseCMSInitiatingOccupancyOnly，强制使用该比例,该比例的大小应该大于老年代占用空间和活跃数据大小之比，一般而言老年代大小*该比例>1.5*老年代活跃数据大小；
19. 使用-XX:+ExplicitGCInvokesConcurrentAndUnloadsCloasses可以使用CMS进行显式垃圾回收（System.gc())；通过-XX:+DisableExplicitGC关闭显示垃圾回收（慎用）；
20. 使用-XX:+CMSClassUnloadingEnabled打开永久带垃圾回收，使用-XX:+CMSPermGenSweepingEnabled打开CMS对永久带的扫描；使用-XX:CMSInitiatingPermOccupancyFraction=<perscent>激活回收比例阈值；
21. 使用-XX:ParallelGCThreads=<n>控制扫描线程数；使用-XX:+CMSScavengeBeforeRemark强制重新标记前进行一次MinorGC；如果由大量的引用对象或可终结对象要处理，使用-XX:+ParallelRefProcEnabled；
22. CMS包括Minor GC所带来的开销应该小于10%；
23. 如果缺少长时间调优的条件，安全起见，可以使用G1，仅设置如下参数即可：

-d64
-Xmx5g
-Xms5g
-XX:PermSize=100m
-XX:MaxPermSize=100m
-XX:MaxDirectMemorySize=1g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=80

G1不必明确设置新生代大小，其自动调优也十分可靠，对于停顿时间往往在长时间运行后可以达到预期效果；对吞吐量优先的应用，可能不是那么明显。

GC 日志

生成下面日志使用的选项： -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:d:/GClogs/tomcat6-gc.log。

4.231: [GC 4.231: [DefNew: 4928K->512K(4928K), 0.0044047 secs] 6835K->3468K(15872K), 0.0045291 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
 
4.445: [Full GC (System) 4.445: [Tenured: 2956K->3043K(10944K), 0.1869806 secs] 4034K->3043K(15872K), [Perm : 3400K->3400K(12288K)], 0.1870847 secs] [Times: user=0.05 sys=0.00, real=0.19 secs] 

最前面的数字 4.231 和 4.445 代表虚拟机启动以来的秒数。

[GC 和 [Full GC 是垃圾回收的停顿类型，而不是区分是新生代还是年老代，如果有 Full 说明发生了 Stop-The-World 。如果是调用 System.gc() 触发的，那么将显示的是 [Full GC (System) 。

接下来的 [DefNew, [Tenured, [Perm 表示 GC 发生的区域，区域的名称与使用的 GC 收集器相关。 Serial 收集器中新生代名为 "Default New Generation"，显示的名字为 "[DefNew"。对于ParNew收集器，显示的是 "[ParNew"，表示 “Parallel New Generation”。 对于 Parallel Scavenge 收集器，新生代名为 "PSYoungGen"。年老代和永久代也相同，名称都由收集器决定。

方括号内部显示的 “4928K->512K(4928K)” 表示 “GC 前该区域已使用容量 -> GC 后该区域已使用容量 (该区域内存总容量) ”。

再往后的 “0.0044047 secs” 表示该区域GC所用时间，单位是秒。

再往后的 “6835K->3468K(15872K)” 表示 “GC 前Java堆已使用容量 -> GC后Java堆已使用容量 （Java堆总容量）”。

再往后的 “0.0045291 secs” 是Java堆GC所用的总时间。

最后的 “[Times: user=0.00 sys=0.00, real=0.00 secs]” 分别代表 用户态消耗的CPU时间、内核态消耗的CPU时间 和 操作从开始到结束所经过的墙钟时间。墙钟时间包括各种非运算的等待耗时，如IO等待、线程阻塞。CPU时间不包括等待时间，当系统有多核时，多线程操作会叠加这些CPU时间，所以user或sys时间会超过real时间。

堆的分代

在上图中：

• young区域就是新生代，存放新创建对象；
• tenured是年老代，存放在新生代经历多次垃圾回收后仍存活的对象；
• perm是永生代，存放类定义信息、元数据等信息。

当GC发生在新生代时，称为Minor GC，次收集；当GC发生在年老代时，称为Major GC，主收集。 一般的，Minor GC的发生频率要比Major GC高很多。