druid連接泄露故障全面分析
1、問題的如何發(fā)生的
1.1、應用功能介紹
系統(tǒng)是一個雙數(shù)據(jù)源雙寫單獨的服務。
(兩個數(shù)據(jù)源是不同的存儲，所以無法使用主從復制的模式，是一個切換存儲介質的過渡態(tài))。
歷史代碼有個更新邏輯update xx set a=b where m=n。
但是這個表中的記錄超10億。遇到需要更新的記錄比較多的場景下存在問題。
故對這個進行了sql優(yōu)化。采用的邏輯是查詢出需要更新的記錄id，然后分頁更新。
1.2、關鍵代碼
雙數(shù)據(jù)源操作
private Object runSql(List<String> sqlSessionFactotyBeanNameList, MethodInvocation invocation)
throws InvocationTargetException, IllegalAccessException {
List<SqlSession> sqlSessionList = Lists.newArrayList();
Object result = null;
try {
for (String sessionFactotyBeanName : sqlSessionFactotyBeanNameList) {
SqlSessionFactory sqlSessionFactory =
RgApplicationContextUtil.getBean(
sessionFactotyBeanName, SqlSessionFactory.class);
SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH);
Object mapper = sqlSession.getMapper(invocation.getMethod().getDeclaringClass());
Object[] param = invocation.getArguments();
result = invocation.getMethod().invoke(mapper, param);
sqlSessionList.add(sqlSession);//問題代碼，注意!!!!
sqlSession.commit();
}
} catch (Exception ex) {
sqlSessionList.stream()
.forEach(
x -> {
x.rollback();
});
} finally {
sqlSessionList.stream()
.forEach(
x -> {
x.close();
});
}
return result;
}
問題的sql
<select id="getBatchIdWithLimit" resultType="java.lang.Long">
SELECT x.id FROM context x WHERE x.oid = #{oid} ORDER BY id ASC
LIMIT #{offset}, #{limit}
</select>
關鍵的配置
maxWait 獲取連接時最大等待時間，單位毫秒。配置了maxWait之后，缺省啟用公平鎖，并發(fā)效率會有所下降，如果需要可以通過配置useUnfairLock屬性為true使用非公平鎖。
當前系統(tǒng)此參數(shù)未進行配置，所以會無限等待，使用的是公平鎖
1.3、問題出現(xiàn)的步驟
- sql中存在問題，部分數(shù)據(jù)的長度超過Integer的最大值（2147483647），映射存在問題。
- 雙數(shù)據(jù)源代碼存在bug。 List的代碼結合的 add 位置過于落后，導致反射出現(xiàn)異常的時候。當次的SqlSession未關聯(lián)到待處理的集合中，進而也就未rollback和close。造成鏈接泄露。
- 當出現(xiàn)問題的數(shù)據(jù)的時候，結合雙數(shù)據(jù)源的代碼的bug。會造成List為空，所以未進行釋放操作，(鏈接泄露了)
- 當前系統(tǒng)最大的連接數(shù)是100，出現(xiàn)了100次這樣的數(shù)據(jù)，這個服務就回無盡的等待獲取鏈接中的狀態(tài)。
1.4、問題的表象
2、如何復現(xiàn)問題
2.1、問題數(shù)據(jù)復現(xiàn)
- 把數(shù)據(jù)庫的最大連接數(shù)調整成1，maxWaitTime不設置
- 構造一條id大于2147483647的數(shù)據(jù)
- 使用api 觸發(fā)調用到這個邏輯
- 結果是:第一次調用報錯，第二次調用會卡的客戶端設置的超時時間。
2.2、數(shù)據(jù)庫連接異常復現(xiàn)
還有一種路徑是代碼都沒問題，但是由于高并發(fā)造成數(shù)據(jù)庫是鎖。mybatis是可以設置sql的執(zhí)行時長的。一旦出現(xiàn)了這種場景。問題也是會出現(xiàn)的。
但是這種場景比較難以復現(xiàn)，那么有沒有一種手段可以高效的偽造這個場景。
準備知識
set autocommit=0; //關閉數(shù)據(jù)的事務自動提交 SELECT * FROM xxx a WHERE a.id='111' for update; //獲取數(shù)據(jù)庫的行鎖 commit;//提交事務
數(shù)據(jù)默認是自動提交的，所以前置set autocommit=0;這個操作不要忘記了，踩過幾次坑。完成后執(zhí)行commit;進行解鎖。
測試完畢記得set autocommit=1;來恢復數(shù)據(jù)庫的事務自動提交的特性。
- 準備一條接口測試用的數(shù)據(jù)
- 執(zhí)行sql select …for update 進行行記錄鎖定
- 接口調用使用同一個id進行請求。因為記錄鎖定了，所以api的更新是失敗了，成功的偽造了高并發(fā)形成了行鎖造成的sql問題
3、問題總結
- 數(shù)據(jù)庫的保護配置:maxActive、maxWait都配置上，相當于熔斷保護
- mybatis對象映射需要關注數(shù)據(jù)的范圍
- 利用select for update制造行鎖偽造高并發(fā)造成的數(shù)據(jù)問題
以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關文章
最近在使用Springboot做項目的時候,遇到了一個循環(huán)依賴的問題,所以下面這篇文章主要給大家介紹了關于springboot循環(huán)依賴實現(xiàn)以及分析的相關資料,需要的朋友可以參考下2022-06-06
這篇文章主要介紹了詳解Java 中泛型的實現(xiàn)原理，幫助大家更好的理解和學習使用Java，感興趣的朋友可以了解下2021-03-03
這篇文章主要介紹了Object類中的wait()和notify()方法，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-09-09
這篇文章主要給大家介紹了關于Spring Cloud Zuul過濾器的相關資料,通過閱讀本文您將了解：Zuul過濾器類型與請求生命周期、如何編寫Zuul過濾器、如何禁用Zuul過濾器和Spring Cloud為Zuul編寫的過濾器及其功能，需要的朋友可以參考下。2017-02-02
這篇文章主要介紹了Java Lambda表達式之從集合到流知識，非常不錯，具有參考借鑒價值，需要的朋友可以參考下2017-02-02
Servlet+JDBC實現(xiàn)登陸功能的小例子(帶驗證碼)
這篇文章主要介紹了Servlet+JDBC實現(xiàn)登陸功能的小例子(帶驗證碼)，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2020-06-06
Java常用的數(shù)據(jù)脫敏方法(手機、郵箱、身份證號)
這篇文章主要給大家介紹了關于Java常用的數(shù)據(jù)脫敏(手機、郵箱、身份證號)的相關資料,信息脫敏對某些敏感信息通過脫敏規(guī)則進行數(shù)據(jù)的變形,實現(xiàn)敏感隱私數(shù)據(jù)的可靠保護,需要的朋友可以參考下2023-07-07
PowerJob的IdGenerateService工作流程源碼解讀
這篇文章主要為大家介紹了PowerJob的IdGenerateService工作流程源碼解讀,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2024-01-01
詳解SpringBoot配置devtools實現(xiàn)熱部署
本篇文章主要介紹了詳解SpringBoot配置devtools實現(xiàn)熱部署 ，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-05-05
線程池的好處和使用本篇文章就不贅敘了，這篇文章主要通過線程池的源碼帶大家深入了解一下jdk8中線程池的實現(xiàn)，感興趣的小伙伴可以了解一下2022-10-10