一次服务上线没多久,页面处于刷新状态,系统发生假死,查看后台日志,并未发现任何的异常信息,在请求接口处增加debug日志后发现,程序在执行到数据库查询相关的地方卡死了。
怀疑是数据库连接的问题,但是使用Navicat连接数据库正常。通过jstack导出线程快照发现,
jstack <pid> >> jstack.log
大量处于WAITTING状态的线程,而这些线程都是在调用borrowObject方法,这个是apache common pool 从连接池中获取连接的方法,使用完毕调用returnObject(),将连接归还到连接池。
//所有的可用连接 private final Map<IdentityWrapper<T>, PooledObject<T>> allObjects = new ConcurrentHashMap<>(); //空闲的可用连接 private final LinkedBlockingDeque<PooledObject<T>> idleObjects; //获取可用连接 T borrowObject() throws Exception, NoSuchElementException, IllegalStateException; //资源释放(将连接放回连接池) void returnObject(T obj) throws Exception;
排查思路:
怀疑存在数据库连接泄漏,可能是项目代码使用完连接没有关闭。就是每次开启一个数据库连接后都需要手动关闭连接,con.close(),如果不close掉的话,这个连接将会一直被占用,直到连接池中的连接耗尽为止。 经排查项目代码并未发现连接未关闭。仔细查看线程调用信息发现,获取数据库连接是由事务拦截器发起的,
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
查看对应的项目代码发现有个@Transactional注解,这个是spring提供的事务注解,每次执行方法时就会获取一个连接。可是此时,程序并没有和数据库相关的操作,这是个纯rest请求的类,而业务系统会定时去调用这个接口, 如果此时代码在请求rest接口的时候发生阻塞,就会导致,事务无法提交,连接也会一直被该请求占用。而再大的连接池也会被耗费殆尽。从而造成系统崩溃。
总结:正确使用@Transactional事务注解,如果方法没有涉及到数据库层面的操作,则无需开启事务,只有在需要保证数据一致性的场景才需要开启事务。这样也能减少数据库连接的压力。