阿里Druid數(shù)據(jù)連接池引發(fā)的線上異常解決

更新時間：2022年03月05日 14:31:28 作者：kl

這篇文章主要為大家介紹了一次關于阿里Druid數(shù)據(jù)連接池引發(fā)的線上異常問題的解決方案，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步

前言

事件起因：項目使用了activiti工作流，系統(tǒng)是由老的spring mvc項目改造成的spring boot項目，數(shù)據(jù)庫鏈接池從dbcp切換到druid，新系統(tǒng)上線后，同事多次系統(tǒng)隔一段時間后數(shù)據(jù)查詢就很慢，基本出不來。

由此開始了線上bug排查之路。這個問題從一開始就模糊定位到數(shù)據(jù)庫層面的問題，因為只有和數(shù)據(jù)相關的操作會很慢，其他服務不受影響，并且在中午休息時沒有問題，在下午剛上班后不就出現(xiàn)。

過程一：定位工作流

首先第一反應是看日志：日志一切正常，并沒有任何異常信息拋出，然后將日志級別調(diào)整到debug，發(fā)現(xiàn)了一些問題，中午休息時，用戶沒有操作的情況下，日志一直在輸出jpa的連接信息，最后定位是工作流的異步執(zhí)行器在輪詢，因為在spring boot環(huán)境下spring.activiti.async-executor-activate=true默認是true的，如果不需要使用可以設置為false，改完后情況依舊

過程二：定位JPA的OpenEntityManagerInViewInterceptor

使用OpenEntityManagerInViewInterceptor后服務端在接收到一個請求的時候開啟EntityManager，在請求結束的時候才去關閉這個EntityManager，所以在用戶數(shù)多，并發(fā)高，操作耗時的情況下會造成數(shù)據(jù)連接不夠用的情況，而我們的業(yè)務有這個特征。

在spring boot環(huán)境中，OpenEntityManagerInViewInterceptor默認是開啟的，然而我們使用spring.jpa.open-in-view=false關閉后，問題依舊，不過比之前的間隔時間久一點了

過程三：定位Druid，真正的罪魁禍首

使用top定位到程序pid，然后使用jstack -l 2591 >>dump.out 拿到當前堆棧快照后發(fā)現(xiàn)如下

"http-nio-8080-exec-54" daemon prio=10 tid=0x0000000000e61000 nid=0xcc9 waiting on condition [0x00007f4a753d4000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007a143f230> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
	at com.alibaba.druid.pool.DruidDataSource.takeLast(DruidDataSource.java:1732)
	at com.alibaba.druid.pool.DruidDataSource.getConnectionInternal(DruidDataSource.java:1330)
	at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:1198)
	at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4619)

所有的請求都被druid的獲取連接操作阻塞了，最后看源碼如下