记一次升级Oracle驱动引起的死锁

时间 2019-12-07

原文原文链接

问题描述

近期项目须要从虚拟机环境迁移到容器环境，其中有一个项目在迁移到容器环境以后的两天以内出现了2次“死锁(deadlock)”的问题，部分关键日志以下：html

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正好相反，从而致使死锁；java

问题分析

以上的错误日志和Oracle的驱动类有关，因此猜想是驱动版本的问题，因此找相关人员分别拉取了虚拟机环境和容器环境的生产Oracle驱动jar包，结果以下：spring

#虚拟机
[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

两个环境使用了不一样的版本，容器使用了高版本(11.2.0.4.0)，虚拟机使用的是低版本(10.1.0.5.0)；Google查询了和Oracle驱动相关产生死锁的问题，查到了Oracle官方有以下文档：
Java-level deadlock with 11.2
提供给咱们的方案是“Upgraded the Oracle JDBC driver from 10.2 to 11.2.”，正好和咱们遇到的状况相反，咱们是高版本有问题，低版本没有问题，因此须要进一步分析；sql

源码分析

首先找到相关的逻辑代码类，此处为了更好的看出问题，使用了以下的模拟类，大体以下：tomcat

//测试Dao，配置在spring下的单例
public class TestDaoImpl {

    //共享的两个ArrayDescriptor
    private ArrayDescriptor param1Desc;
    private ArrayDescriptor param2Desc;

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

    public void callProc(Object param) {
        // 准备的两个ARRAY参数
        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 {
            // 关闭处理
        }
    }

    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建立了一个存储过程，而后给存储过程设置了两个ARRAY参数，在建立ARRAY时须要指定相应的ArrayDescriptor，最后执行存储过程；
产生异常分别在两次setArray的地方，线程1在setArray1的地方，线程2在setArray2的地方，全部以此为入口分别查看两个驱动版本相关类：OraclePreparedStatement，ARRAY，ArrayDescriptor以及OracleTypeADT；多线程

驱动11.2.0.4.0版本

首先查看OraclePreparedStatement中调用的setArray，最终会调用以下方法：

在方法setARRAYInternal中使用了connection做为了对象锁，接下来OraclePreparedStatement会调用ARRAY，而后ARRAY调用ArrayDescriptor，最后ArrayDescriptor在调用OracleTypeADT，为了方便看出问题直接展现OracleTypeADT中使用锁的地方：

一样使用connection作为锁对象，这样就存在同时须要获取两把锁了，而上面两把锁都是connection对象，应该不会出现死锁，可是深刻发现其实OracleTypeADT中的connection对象是从ArrayDescriptor中获取的，而ArrayDescriptor是一个共享的类变量，这样在多线程环境下就会出现被赋值不一样的connection，从而致使出现死锁的问题；
大体流程以下：
1.首先线程1获取conn1，而后线程2获取conn2；
2.而后线程1建立Array1，同时对共享的ArrayDescriptor1设置connection=conn1；
3.线程1挂起，线程2建立Array1，同时对共享的ArrayDescriptor1设置connection=conn2，对共享的ArrayDescriptor2设置connection=conn2；
4.线程2继续占用cpu，执行setArray1，这时候都是Array1和ArrayDescriptor1中的锁都是conn2，因此没有问题，继续执行setArray2，在执行完获取第一把锁conn2以后，线程2挂起；
5.线程1抢占cpu，对共享的ArrayDescriptor2设置connection=conn1，而后执行setArray1；但此时Array1中的connection是conn1，而ArrayDescriptor1中的connection是conn2，因此出现线程1占用了conn1，等待conn2锁；
6.此时线程2再次抢到cpu，可是在获取第二把锁时，此时ArrayDescriptor2中的connection已经被设置成了conn1，而conn1已经被线程1占有，因此等待获取conn1；
7.死锁出现了线程1占有了conn1锁，等待conn2锁；线程2占有了conn2锁，等待conn1锁；从而致使死锁发生；
从上面的分析能够看出主要缘由是ArrayDescriptor被设置成了类变量，被多个线程所访问，解决死锁问题能够把ArrayDescriptor改为局部变量；可是若是仅是业务形成的问题，那应该在驱动ojdbc-1.4中存在一样的死锁问题，可是此项目在虚拟机环境中一直没有出现过问题；继续看ojdbc-1.4源码；oracle

驱动10.1.0.5.0版本

一样分析此驱动版本中的相同类，同上首先查看OraclePreparedStatement中调用的setArray，最终会调用以下方法：

一样使用了connection做为对象锁，再看OracleTypeADT，相关代码以下：

能够看到这里并无使用connection做为锁，而是使用了内置锁，因此就不会出现死锁问题；app

问题总结

首先就是在迁移环境时必定要保证相关的依赖公共jar保证版本的一致，就算是低版本，高版本也不同保证向下兼容；其次也是最重要的写业务逻辑时遇到公共变量时必定要谨慎，是否会出现多线程问题；源码分析