亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

公告：魔扣目錄網(wǎng)為廣大站長提供免費(fèi)收錄網(wǎng)站服務(wù)，提交前請做好本站友鏈：【網(wǎng)站目錄：http://www.430618.com 】，免友鏈快審服務(wù)（50元/站），

網(wǎng)站：51998
待審：31
小程序：12
文章：1030137
會(huì)員：747

記一次升級Oracle驅(qū)動(dòng)引發(fā)的死鎖問題分析源碼分析驅(qū)動(dòng)11.2.0.4.0版本驅(qū)動(dòng)10.1.0.5.0版本問題總結(jié)

發(fā)布時(shí)間：2023-07-03 15:48:05 作者：網(wǎng)友整理

近期項(xiàng)目需要從虛擬機(jī)環(huán)境遷移到容器環(huán)境，其中有一個(gè)項(xiàng)目在遷移到容器環(huán)境之后的兩天之內(nèi)出現(xiàn)了2次“死鎖(deadlock)”的問題，部分關(guān)鍵日志如下：

Found one JAVA-level deadlock:
=============================
"DefaultMessageListenerContainer-9":
 waiting to lock monitor 0x00007fde3400bf38 (object 0x00000000dda358d0, a oracle.jdbc.driver.T4CConnection),
 which is held by "DefaultMessageListenerContainer-7"
"DefaultMessageListenerContainer-7":
 waiting to lock monitor 0x00007fdea000b478 (object 0x00000000dda35578, a oracle.jdbc.driver.T4CConnection),
 which is held by "DefaultMessageListenerContainer-9"
Java stack information for the threads listed above:
===================================================
"DefaultMessageListenerContainer-9":
 at oracle.jdbc.oracore.OracleTypeADT.linearize(OracleTypeADT.java:1280)
 - waiting to lock <0x00000000dda358d0> (a oracle.jdbc.driver.T4CConnection)
 at oracle.sql.ArrayDescriptor.toBytes(ArrayDescriptor.java:653)
 at oracle.sql.ARRAY.toBytes(ARRAY.java:711)
 - locked <0x00000000dda35578> (a oracle.jdbc.driver.T4CConnection)
 at oracle.jdbc.driver.OraclePreparedStatement.setArrayCritical(OraclePreparedStatement.java:6049)
 at oracle.jdbc.driver.OraclePreparedStatement.setARRAYInternal(OraclePreparedStatement.java:6008)
 - locked <0x00000000dda35578> (a oracle.jdbc.driver.T4CConnection)
 at oracle.jdbc.driver.OraclePreparedStatement.setArrayInternal(OraclePreparedStatement.java:5963)
 at oracle.jdbc.driver.OracleCallableStatement.setArray(OracleCallableStatement.java:4833)
 at oracle.jdbc.driver.OraclePreparedStatementWrApper.setArray(OraclePreparedStatementWrapper.java:114)

"DefaultMessageListenerContainer-7":
 at oracle.jdbc.oracore.OracleTypeADT.linearize(OracleTypeADT.java:1280)
 - waiting to lock <0x00000000dda35578> (a oracle.jdbc.driver.T4CConnection)
 at oracle.sql.ArrayDescriptor.toBytes(ArrayDescriptor.java:653)
 at oracle.sql.ARRAY.toBytes(ARRAY.java:711)
 - locked <0x00000000dda358d0> (a oracle.jdbc.driver.T4CConnection)
 at oracle.jdbc.driver.OraclePreparedStatement.setArrayCritical(OraclePreparedStatement.java:6049)
 at oracle.jdbc.driver.OraclePreparedStatement.setARRAYInternal(OraclePreparedStatement.java:6008)
 - locked <0x00000000dda358d0> (a oracle.jdbc.driver.T4CConnection)
 at oracle.jdbc.driver.OraclePreparedStatement.setArrayInternal(OraclePreparedStatement.java:5963)
 at oracle.jdbc.driver.OracleCallableStatement.setArray(OracleCallableStatement.java:4833)
 at oracle.jdbc.driver.OraclePreparedStatementWrapper.setArray(OraclePreparedStatementWrapper.java:114)
 at

日志還是挺明顯的，線程DefaultMessageListenerContainer-9獲得了鎖0x00000000dda35578，等待獲取0x00000000dda358d0；而DefaultMessageListenerContainer-7正好相反，從而導(dǎo)致死鎖；

問題分析

以上的錯(cuò)誤日志和Oracle的驅(qū)動(dòng)類有關(guān)，所以猜測是驅(qū)動(dòng)版本的問題，所以找相關(guān)人員分別拉取了虛擬機(jī)環(huán)境和容器環(huán)境的生產(chǎn)Oracle驅(qū)動(dòng)jar包，結(jié)果如下：

#虛擬機(jī)
[19:38:21 oracle@Tomcat-384 lib]$ ls -l ojdbc-1.4.jar
-rw-r--r-- 1 oracle oinstall 1378346 Jul 3 2014 ojdbc-1.4.jar
 
#容器
[oracle@7f666c76b7-dx2gq lib]$ ls -l ojdbc6.jar
-rw-r--r-- 1 oracle oinstall 2739670 Aug 11 2015 ojdbc6.jar

兩個(gè)環(huán)境使用了不同的版本，容器使用了高版本(11.2.0.4.0)，虛擬機(jī)使用的是低版本(10.1.0.5.0)；google查詢了和Oracle驅(qū)動(dòng)相關(guān)產(chǎn)生死鎖的問題，查到了Oracle官方有如下文檔：
Java-level deadlock with 11.2(https://support.oracle.com/knowledge/Middleware/1271651_1.html)
提供給我們的方案是“Upgraded the Oracle JDBC driver from 10.2 to 11.2.”，正好和我們遇到的情況相反，我們是高版本有問題，低版本沒有問題，所以需要進(jìn)一步分析；

源碼分析

首先找到相關(guān)的邏輯代碼類，此處為了更好的看出問題，使用了如下的模擬類，大致如下：

//測試Dao，配置在spring下的單例
public class TestDaoImpl {

 //共享的兩個(gè)ArrayDescriptor
 private ArrayDescriptor param1Desc;
 private ArrayDescriptor param2Desc;

 private String param1;
 private String param2;
 private DataSource dataSource;

 public void callProc(Object param) {
 // 準(zhǔn)備的兩個(gè)ARRAY參數(shù)
 ARRAY param1Array = null;
 ARRAY param2Array = null;

 CallableStatement callable = null;
 Connection conn = null;

 try {
 // 從連接池獲取連接
 conn = DataSourceUtils.getConnection(dataSource);
 param1Array = wrapProcParameter1(param, conn);
 param2Array = wrapProcParameter2(param, conn);

 callable = conn.prepareCall("{ call testProc " + "(?,?,?)}");
 callable.setArray(1, param1Array);
 callable.setArray(2, param2Array);

 callable.execute();

 } catch (Exception e) {
 // 異常處理
 } finally {
 // 關(guān)閉處理
 }
 }

 private ARRAY wrapProcParameter1(Object param, Connection conn) throws SQLException {
 if (null == this.param1Desc) {
 this.param1Desc = new ArrayDescriptor(this.param1, conn);
 }
 //省略
 ARRAY array1 = new ARRAY(this.param1Desc, conn, param);
 return array1;
 }

 private ARRAY wrapProcParameter2(Object param, Connection conn) throws SQLException {
 if (null == this.param2Desc) {
 this.param2Desc = new ArrayDescriptor(this.param2, conn);
 }
 //省略
 ARRAY array2 = new ARRAY(this.param2Desc, conn, param);
 return array2;
 }
}

大致的邏輯是通過從連接池獲取的Connection創(chuàng)建了一個(gè)存儲(chǔ)過程，然后給存儲(chǔ)過程設(shè)置了兩個(gè)ARRAY參數(shù)，在創(chuàng)建ARRAY時(shí)需要指定相應(yīng)的ArrayDescriptor，最后執(zhí)行存儲(chǔ)過程；
產(chǎn)生異常分別在兩次setArray的地方，線程1在setArray1的地方，線程2在setArray2的地方，所有以此為入口分別查看兩個(gè)驅(qū)動(dòng)版本相關(guān)類：OraclePreparedStatement，ARRAY，ArrayDescriptor以及OracleTypeADT；

驅(qū)動(dòng)11.2.0.4.0版本

首先查看OraclePreparedStatement中調(diào)用的setArray，最終會(huì)調(diào)用如下方法：

在方法setARRAYInternal中使用了connection作為了對象鎖，接下來OraclePreparedStatement會(huì)調(diào)用ARRAY，然后ARRAY調(diào)用ArrayDescriptor，最后ArrayDescriptor在調(diào)用OracleTypeADT，為了方便看出問題直接展示OracleTypeADT中使用鎖的地方：

同樣使用connection做為鎖對象，這樣就存在同時(shí)需要獲取兩把鎖了，而上面兩把鎖都是connection對象，應(yīng)該不會(huì)出現(xiàn)死鎖，但是深入發(fā)現(xiàn)其實(shí)OracleTypeADT中的connection對象是從ArrayDescriptor中獲取的，而ArrayDescriptor是一個(gè)共享的類變量，這樣在多線程環(huán)境下就會(huì)出現(xiàn)被賦值不同的connection，從而導(dǎo)致出現(xiàn)死鎖的問題；
大致流程如下：
1.首先線程1獲取conn1，然后線程2獲取conn2；
2.然后線程1創(chuàng)建Array1，同時(shí)對共享的ArrayDescriptor1設(shè)置connection=conn1；
3.線程1掛起，線程2創(chuàng)建Array1，同時(shí)對共享的ArrayDescriptor1設(shè)置connection=conn2，對共享的ArrayDescriptor2設(shè)置connection=conn2；
4.線程2繼續(xù)占用cpu，執(zhí)行setArray1，這時(shí)候都是Array1和ArrayDescriptor1中的鎖都是conn2，所以沒有問題，繼續(xù)執(zhí)行setArray2，在執(zhí)行完獲取第一把鎖conn2之后，線程2掛起；
5.線程1搶占cpu，對共享的ArrayDescriptor2設(shè)置connection=conn1，然后執(zhí)行setArray1；但此時(shí)Array1中的connection是conn1，而ArrayDescriptor1中的connection是conn2，所以出現(xiàn)線程1占用了conn1，等待conn2鎖；
6.此時(shí)線程2再次搶到cpu，但是在獲取第二把鎖時(shí)，此時(shí)ArrayDescriptor2中的connection已經(jīng)被設(shè)置成了conn1，而conn1已經(jīng)被線程1占有，所以等待獲取conn1；
7.死鎖出現(xiàn)了線程1占有了conn1鎖，等待conn2鎖；線程2占有了conn2鎖，等待conn1鎖；從而導(dǎo)致死鎖發(fā)生；

從上面的分析可以看出主要原因是ArrayDescriptor被設(shè)置成了類變量，被多個(gè)線程所訪問，解決死鎖問題可以把ArrayDescriptor改成局部變量；但是如果僅是業(yè)務(wù)造成的問題，那應(yīng)該在驅(qū)動(dòng)ojdbc-1.4中存在同樣的死鎖問題，但是此項(xiàng)目在虛擬機(jī)環(huán)境中一直沒有出現(xiàn)過問題；繼續(xù)看ojdbc-1.4源碼；