增加GC相關選項：
-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
- 如果不能確定所需內存，使用自動jvm自動調優；
- 大致確定所需內存后，使用-Xmx -Xms設置堆大小；
- 觀察GC log確定FullGC后剩余堆大小（即為活躍數據大小）；
- 整個堆大小宜為老年代活躍數據大小的3-4倍；
- 永久帶大小應該比永久帶活躍數據大1.2~1.5倍；
- 新生代空間應該為老年代空間活躍數據的1~1.5倍；
- 通過top命令觀察棧占用空間、直接內存占用空間，決定所需機器內存大小；
- 新生代大小決定了Minor GC的周期和時長，縮短新生代大小可以減少停頓時長，但是增加了GC頻率；在調整新生代大小時，盡量保持老年代大小不變；
- 老年代大小不應該小于活躍數據的1.5倍；新生代空間至少為java堆大小的10%；增加堆大小時，注意不要超過可用物理內存數；
- 從throughput收集器遷移到CMS時，需要將老年代空間增加20%~30%；
- 新生代分為Eden和Survivor兩部分，Survivor可以通過
-XX:SurvivorRatio=xx來控制，對應的大小為-Xmn<value>/(ratio+2)； - 通過
-XX:MaxTenuringThreshold=<n>來指定晉升閾值（年齡），n為0~15之間； - 期望Survivor空間為剩余總存活對象大小的2倍(age=1；
- 注意調節Survivor大小時，保持Eden大小不變；
- 如果Survivor空間足夠大，且對象大部分并未到達老年代，那么就可以將晉升年紀指定的足夠大（15）。在Eden與Survivor之間復制和CMS老年代空間壓縮之間，我們寧愿選擇前者；
- CMS必須能以對象從新生代提升到老年代的同等速度對老年代中的對象進行收集，否則，就會失速；
- 如果觀察到'concurrent mode failures'，意味著失速已經發生，必須減少
-XX:CMSInitiatingOccupancyFraction=<percent>的值； - 使用上述選項的同時，最好同時使用
-XX:+UseCMSInitiatingOccupancyOnly，強制使用該比例,該比例的大小應該大于老年代占用空間和活躍數據大小之比，一般而言老年代大小*該比例>1.5*老年代活躍數據大小； - 使用
-XX:+ExplicitGCInvokesConcurrentAndUnloadsCloasses可以使用CMS進行顯式垃圾回收（System.gc())；通過-XX:+DisableExplicitGC關閉顯示垃圾回收（慎用）； - 使用
-XX:+CMSClassUnloadingEnabled打開永久帶垃圾回收，使用-XX:+CMSPermGenSweepingEnabled打開CMS對永久帶的掃描；使用-XX:CMSInitiatingPermOccupancyFraction=<perscent>激活回收比例閾值； - 使用
-XX:ParallelGCThreads=<n>控制掃描線程數；使用-XX:+CMSScavengeBeforeRemark強制重新標記前進行一次MinorGC；如果由大量的引用對象或可終結對象要處理，使用-XX:+ParallelRefProcEnabled； - CMS包括Minor GC所帶來的開銷應該小于10%；
- 如果缺少長時間調優的條件，安全起見，可以使用G1，僅設置如下參數即可：
-d64-Xmx5g-Xms5g-XX:PermSize=100m-XX:MaxPermSize=100m-XX:MaxDirectMemorySize=1g-XX:+UseG1GC-XX:MaxGCPauseMillis=80
G1不必明確設置新生代大小，其自動調優也十分可靠，對于停頓時間往往在長時間運行后可以達到預期效果；對吞吐量優先的應用，可能不是那么明顯。