俗话说技多不压身，当年苦读《深入理解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各阶段细致的配置则需要更量化的分析。