前序（公司应用为Web应用， 部署serverLinux + Nginx + Tomcat ）
一天收到公司报警邮件，显示个别机器方法调用严重超时，寻常都是在100ms以内响应的方法，突然某段时间响应时间上升到几秒，開始怀疑是机器的问题，暂时把机器从线上摘掉。重新启动完之后再挂到线上，通过一段时间观察发现各方法响应时间正常。
又过了几天，发现好几台机器都出现这种情况，感觉不是机器的问题，開始对jvm进行分析，通过分析发现，系统young gc耗时从開始的10ms左右慢慢上升到几百毫秒，old区使用超过了90%。并且系统没有进行过full gc，再看其它方法响应时间正常的机器，young gc一般10ms左右。可是每隔一小时运行一次full gc，full gc耗时几百毫秒，而old区差点儿每隔四小时就会清空，感觉机器响应慢的问题与young gc耗时长有非常大关系。通过上网查找资料。发现young gc耗时与old区使用大小有非常大关系，假设old区使用太大。运行young gc就会非常耗时。导致系统响应时间变慢。
尽管找到了系统响应时间变慢的原因，可是不知道详细是什么原因导致的。由于机器都是同样的，并且也没有显示调用System.gc()的代码，后来通过对照异常机器与正常机器的各项配置，发现正常的机器Tomcat版本号号为6.0.33。异常机器Tomcat版本号号都为6.0.44。咋一看感觉Tomcat版本号都一样。没有区别，只是还是不放心。就找到这两个Tomcat版本号的源代码。查找是否有显式调用System.gc()的方法，通过查找发现，Tomcat版本号6.0.33
的内存泄露监听器JreMemoryLeakPreventionListener。每隔一小时就会调用一次System.gc(),而Tomcat版本号6.0.44的内存泄露监听器调用一次System.gc()的时间间隔为Integer.max
-1 s,差点儿不会显式的调用System.gc()。
以上最终找到了问题所在，Tomcat版本号改为了6.0.33,之后系统恢复正常。
