Tomcat假死排查方案

古城堡

　　使用Tomcat作为Web服务器的时候偶尔会遇到Tomcat停止响应的情况，通过netstat查看端口情况会发现tomcat的端口出现大量的CLOSE_WAIT，此时Tomcat会停止响应前端请求，同时服务端的日志，操作等将全部停止，而且没有出现任何异常，此时就需要排查是哪方面的原因，此案以以前的解决为例总结排查方案

　　1、首先确认页面端正常时请求没有问题
　　2、对于使用Nginx作为前端负载均衡Tomcat集群，通过Nginx的访问日志(access.log)确认页面到Nginx没有问题
　　3、查看Tomcat的访问日志(localhost_access_log.txt)查看前端请求是否访问到Tomcat

　　4、查看Tomcat的状态控制台，查看Tomcat的请求和内存占用情况

　　查看那些请求处于等待状态，排查这些请求的服务是否存在问题(长事务、频繁事务)
　　5、查看数据库进程查看当前数据库实例是否出现死锁

　　如果出现死锁，排查代码中出现死锁的原因，解决死锁问题
　　6、如果以上都没有问题，排查代码中的定时任务
　　查看定时任务事务是否存在问题(长事务、频繁事务)
　　7、检查是否是频繁的写日志造成Tomcat阻塞
　　对于访问量比较大的系统，如果项目采用Info或者Debug日志级别的话会造成Tomcat频繁的读写几百兆甚至上G的日志文件，造成Tomcat阻塞
　　曾经遇到的一次Tomcat出现CLOSE_WAIT时，通过排查发现是一位同事在通过定时任务做其他系统的数据同步时时出现的问题造成的，问题总结如下：
　　1、同步其他系统的数据是耗时较长，其采用Spring的切面事务，造成同步时事务时间长达几分钟时间，存在死锁风险
　　2、同步数据完需要处理数据，此时的处理数据逻辑会存在多达几万次的数据库变更，当前操作没有采用切面事务，而是采用框架的AutoCommit自动提交事务，这样就会造成处理数据时出现几万次的创建事务，提交事务，关闭事务，此时造成事务阻塞
　　解决方案：
　　1、处理时间较长的操作，如果当前操作中间出现问题对业务没有影响下次操作时会修正当前业务，这样的话可以不适用切面事务而是使用框架的AutoCommit提交事务，如果当前操作确实需要保证原子性时，请手动回复数据装填
　　2、不要频繁的开启、提交事务，采用批量的方式提交事务