俗話說技多不壓身，當年苦讀《深入理解JVM》還專門整理了筆記，現在就用上了～
筆記 http://www.cnblogs.com/syjkfind/p/3901774.html
【症狀】 用戶操作數據導出時總會發生卡頓，後台占內存的定時任務發生時也會。JVM參數就不貼了，比較普通且相對合理。
【思路】
查gc日志是發生了full gc，tomcat日志零零散散有很多exception。
另外憑著對代碼的了解，觸發時同時刻的日志顯示正在執行較大數據量的查詢而且裝載進JVM，方法調用和臨時變量也很多。
【分析】
1.minor gc很頻繁，但時間短所以問題不大，觸發原因基本都是申請空間失敗。
2.偶爾有System.gc()，時間大概1分鐘。代碼中沒有顯式調用，基本確定是監控程序RMI訪問觸發的。可以加參數禁用 -XX:+DisableExplicitGC 。
3.時常有promotion failed，即在minor gc時年輕代的存活區空間不足而進入老年代，老年代又空間不足而觸發full gc。時間大概3分鐘。解決思路一種是增大存活區，一種則相反是去掉存活區增大老年代。相關參數一般有：
-XX:SurvivorRatio=32 存活區除以伊甸區的比率，存活區有from和to兩個，所以這裡的意思是單個存活區占年輕代的1/34；
-XX:OldSize=60M 老年代大小；
-XX:MaxTenuringThreshold=15 即多少次minor gc後存活的年輕代對象會晉升老年代。
4.經常有concurrent mode failure，即CMS執行過程中老年代空間不足，這時會變成Serial Old收集器導致更長時間的停頓。時間大概5分鐘。其中引發這一問題的情況可能是浮動垃圾太多、可能是CMS收集器本身也占用堆空間、也可能是老年代太多碎片，但都是CMS收集器的特性導致的。相關配置一般有：
-XX:CMSInitiatingOccupancyFraction=80 即老年代滿80%時觸發CMS(full gc)，調高則full gc相對減少，調低則full gc處理得比較快；
-XX:UseCMSCompactAtFullCollection 或 -XX:CMSFullGCsBeforeCompaction=5 即full gc前或後做碎片整理。
5.另有個有趣的文章，過多過長的exception會導致promotion failed
http://www.th7.cn/Program/java/201511/685711.shtml
可能挺符合我們的場景的，沒有運維權限，下次可以考慮找運維dump個分析一下對象。
以前為了追蹤錯誤關閉了“快拋” -XX:-OmitStackTraceInFastThrow 即反復出現的exception不會用一個靜態的沒堆棧信息的實例去代替，這個要權衡一下了。
【解決】
創建很多對象占了年輕代？大對象導致占滿老年代？浮動垃圾（CMS時繼續在產生臨時對象）或老年代碎片？
調優多少是可以改善的，但似乎代碼本身更有問題，恐怕分配再多的內存都不夠吃。比如沒有應用較完善的一級緩存二級緩存，比如經常粗暴地把上萬條記錄加載進來，還沒做分頁，還有藏的比較深的做了切面觸發異步服務把異步服務隊列占滿了。初期享受了框架的便利而考慮設計的少，而現在則要開始還技術債務了～
所幸的是在有限的時間裡，我們有簡單粗暴有效的方法緩解這些問題：加服務器，把大任務剝離出來～
而中長期的考慮來看，在不改變現有框架的前提下，整改exception、整改業務代碼做分頁、封裝數據庫分頁查詢框架、改造數據庫層二級緩存（集群范圍內緩存）會是比較有效的措施。
更長遠的肯定就是回歸Spring系主流框架，再者進軍服務化了。。。但那個幾乎要把業務代碼重新寫一遍，是後話了。
回歸主題如果是調優來解決問題，最好是dump了做更深入的分析。主觀上看來啟用快拋、gc後碎片整理、增大存活區應該是比較有針對性的調整，而CMSInitiatingOccupancyFraction取值和CMS各階段細致的配置則需要更量化的分析。
