一次Tomcat6.0.33版本号与6.0.44版本号差异所引发的问题

Posted lxjshuju

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一次Tomcat6.0.33版本号与6.0.44版本号差异所引发的问题相关的知识,希望对你有一定的参考价值。

前序(公司应用为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,之后系统恢复正常。

以上是关于一次Tomcat6.0.33版本号与6.0.44版本号差异所引发的问题的主要内容,如果未能解决你的问题,请参考以下文章

Android 自动设置版本号与版本名称

Android SDK版本号与API Level 的对应关系-转

Android最新版本号与API级别对应关系

iOS获取当前AppStore版本号与更新

Nginx优化---隐藏版本号与网页缓存时间

JavaClass文件编译的版本号与JDK版本号的对应关系