论坛首页 Java企业应用论坛

数据库连接泄露定位分享

浏览 11694 次
精华帖 (0) :: 良好帖 (3) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2012-02-17   最后修改:2012-02-22

问题表象

问题描述

1.最近有项目组的童鞋反馈,web页面频繁出现假死的状态。

2.web页面的假死出现是概率事件,且无法确定假死的引发原因。

3.是在一定的操作之后出现的,但是无法确定究竟是哪些操作引发这些操作。

问题分析

初步分析

我们都知道web容器一般都是单实例多线程的方式工作的,当页面发起请求后,tomcat发分配一个线程进行当前请求的处理,当出现页面假死,说明是由于某种原因导致了线程在等待某种资源,可以是IO、网络响应、数据库连接、等待锁等等,所以需要首先确定该线程是在等待什么资源。

 

经过初步分析,可以知道是线程阻塞导致web不能够及时返回给页面响应,导致页面出现假死的情况。所以首先确定导致线程阻塞的原因。

 

确定线程是由于什么原因导致的阻塞其实也是比较简单的,可以使用jstack工具,到出现阻塞现象后,使用jstack工具查看器堆栈,看下是等待什么。也可以使用Eclipsedebug功能,将当前线程suspend。在这里我采用第二种方式。

 

操作步骤

在本地以Debug方式启动Tomcat应用,模拟一些操作,尽量将假死项目重现,开发人员根据以往的映像去操作一些功能,过了若干时间后,果然出现了假死现象。由于是debug方式启动所以查看其debug视图,发现启动了3http线程,下图中红色部分标示的位置。



 

通过右击suspend挂起线程,发现有一个线程确实被阻塞掉了



 

观察堆栈可以确定是到连接池中去获取连接,但是当前连接池中无可用的连接,导致线程阻塞出现页面假死现象。

进一步分析

很明显这个是由于连接泄露导致无可用连接,所引起的线程阻塞,页面假死。查看连接池配置:

driver=oracle.jdbc.driver.OracleDriver

url=jdbc:oracle:thin:@127.0.0.1:1521:orcl

username=****

password=****

active=20

minidle=20

maxidle=20

maxwait=-1

出现连接泄露问题是较为难定位的问题,因为问题的表象离问题的根源较远,并没有直接的联系,所以只能凭经验和感觉去分析,另外出现该情况应当尽量将连接池连接个数配置改小,这样可以有效的拉近问题表象和问题根源之间的距离,减小问题重现的成本和最大化问题重现的概率。然后根据BTrace来进行分析。但是我们这里有BTrace这个利器来进行动态诊断。

诊断思路

只要跟踪所有的调用过BasicDataSource.getConnection这个方法的地方,然后在看看那些方法调用以后没有关系连接,而关闭连接的地方并非是Connectionclose方法,需要对连接池的工作原理有一定的了解。




 
 

如上图,连接池持有Connection代理的引用,用来维护Connection,而Connection代理实现了JDBC,通过Connection代理来操作驱动程序,在oracle中是oracle.jdbc.driver.T4CConnection



 

实际上连接池主要是通过PoolableConnection作为代理类,持有T4CConnection的引用,完成对数据的操作,并且自己实现了java.sql.Connection接口,我们看下close方法的具体实现。

 

/**
     * Returns me to my pool.
     */
     public synchronized void close() throws SQLException {
        if (_closed) {
            // already closed
            return;
        }

        boolean isUnderlyingConectionClosed;
        try {
            isUnderlyingConectionClosed = _conn.isClosed();
        } catch (SQLException e) {
            try {
                _pool.invalidateObject(this); // XXX should be guarded to happen at most once
            } catch(IllegalStateException ise) {
                // pool is closed, so close the connection
                passivate();
                getInnermostDelegate().close();
            } catch (Exception ie) {
                // DO NOTHING the original exception will be rethrown
            }
            throw (SQLException) new SQLException("Cannot close connection (isClosed check failed)").initCause(e);
        }

        if (!isUnderlyingConectionClosed) {
            //这种将connection释放,也就是放回连接池
            try {
                _pool.returnObject(this); // XXX should be guarded to happen at most once
            } catch(IllegalStateException e) {
                // pool is closed, so close the connection
                passivate();
                getInnermostDelegate().close();
            } catch(SQLException e) {
                throw e;
            } catch(RuntimeException e) {
                throw e;
            } catch(Exception e) {
                throw (SQLException) new SQLException("Cannot close connection (return to pool failed)").initCause(e);
            }
        } else {
            // Abnormal close: underlying connection closed unexpectedly, so we
            // must destroy this proxy
            try {
                _pool.invalidateObject(this); // XXX should be guarded to happen at most once
            } catch(IllegalStateException e) {
                // pool is closed, so close the connection
                passivate();
                getInnermostDelegate().close();
            } catch (Exception ie) {
                // DO NOTHING, "Already closed" exception thrown below
            }
            throw new SQLException("Already closed.");
        }
}

 

 

而获取连接的代码是通过PoolingDataSourcegetConnection进行获取的代码如下:

 

/**
     * Return a {@link java.sql.Connection} from my pool,
     * according to the contract specified by {@link ObjectPool#borrowObject}.
     */
    public Connection getConnection() throws SQLException {
        try {
		   //这里从连接池中获取一个连接,如果该池中没有可用的闲置连接,就会等待maxwait毫秒,直至跑出异常

            Connection conn = (Connection)(_pool.borrowObject());
            if (conn != null) {
                conn = new PoolGuardConnectionWrapper(conn);
            } 
            return conn;
        } catch(SQLException e) {
            throw e;
        } catch(NoSuchElementException e) {
            throw new SQLNestedException("Cannot get a connection, pool error " + e.getMessage(), e);
        } catch(RuntimeException e) {
            throw e;
        } catch(Exception e) {
            throw new SQLNestedException("Cannot get a connection, general error", e);
        }
    }

 

 

可以非常清楚的看到,就是通过该方法释放连接到连接池中,供后续的业务代码进行调用。

到这里基本的思路已经出来了,只要跟踪PoolingDataSourcegetConnection方法和PoolableConnectionclose方法就可以知道究竟哪些业务代码只调用了获取连接而没有调用close方法进行释放连接,导致连接泄露。

BTrace利器

通过编写BTrace脚本进行分析跟踪,只要业务代码在调用完getConnection方法后调用了close就说明没有问题,也就是getConnection方法和close方法成对出现,如果只调用了getConnection方法而没有调用close方法那就说明该业务代码有连接泄露。

 

import com.sun.btrace.annotations.*;
import static com.sun.btrace.BTraceUtils.*;

@BTrace public class BTraceConnection {
	
    @Export private static long openedCount;
    
    @Export private static long closedCount;
	
    @OnMethod(clazz="/.*PoolingDataSource/", method="getConnection", location=@Location(kind.RETURN))
    public static void m(@return Object obj) {
    	    openedCount++;
    			println("One connection is opened!");
    			println(obj);
    	    Threads.jstack();
    }
    
    @OnMethod(clazz="/.*PoolableConnection/", method="close")
    public static void d(@Self Object obj) {
    	    closedCount++;
    			println("One connection is closed!");
    			println(obj);
    	    Threads.jstack();
    }
    
    @OnExit
    public static void f(){
          print("Total opened connection:");
          println(openedCount);
          print("Total closed connection:");
          println(closedCount);	
    }
    
}

 

 

  将连接池个数修改为3,启动应用,使用jps输出应用pid运行命令btrace <pid> BTraceConnection.java > trace.log

日志分析

输出结果

 

One connection is opened!
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper@1d6fc56
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
..................
com.***************************.dao.UserDAO.checkUserState(UserDAO.java:142)
..................
java.lang.Thread.run(Thread.java:619)
One connection is opened!
..................
Total opened connection:61
Total closed connection:57

 

 

部分无用内容有删减,发现总共获取了61connection,释放了57connectioncom.***************************.dao.UserDAO.checkUserState(UserDAO.java:142)该方法没有释放连接,最终定位出了有问题的方法。

 

 其他相关内容:

BTrace系列之一:简介

BTrace系列之二:简单示例

BTrace系列之三:实际案例

BTrace系列之四:破解

 

 

 

 

  • 大小: 26.1 KB
  • 大小: 40.4 KB
  • 大小: 30.6 KB
  • 大小: 8.2 KB
   发表时间:2012-02-17   最后修改:2012-02-17
如果连接是在threadlocal中呢

另外,事务和非事务混搭的方式还容易出现资源死锁
0 请登录后投票
   发表时间:2012-02-18  
freish 写道
如果连接是在threadlocal中呢

另外,事务和非事务混搭的方式还容易出现资源死锁

一个道理,总会涉及到连接的获取和释放。另外BTrace也可以跟踪死锁。
0 请登录后投票
   发表时间:2012-02-22  
灰常强大的分析,学习
0 请登录后投票
   发表时间:2012-02-22  
很好奇dao.UserDAO.checkUserState为什么不释放连接池,一直持有连接对象干嘛,想真正check User state的时候再到连接池里拿呗,这样一直wait我觉得本身有可能也有问题
0 请登录后投票
   发表时间:2012-02-22  
kakaluyi 写道
很好奇dao.UserDAO.checkUserState为什么不释放连接池,一直持有连接对象干嘛,想真正check User state的时候再到连接池里拿呗,这样一直wait我觉得本身有可能也有问题


这个方法没有释放连接的原因还是比较的复杂,所以在博文中并没有具体的解释为什么这个方法没有释放连接。

是这样的,我们项目组通过spring的hibernateTemplate来集成的hibernate,如果都是通过hibernateTemplate来操作hibernate的话是没有问题的,spring会在操作完成后自动释放连接,但是UserDAO.checkUserSate是通过这种方式Session session = this.getSession();来获取的session导致spring无法管理该session。

还有就是和事务也有关系,当checkUserState加到事务中后,不管是使用哪种方式都没有问题,因为spring会保证一个线程获取session,到事务结束后自然会释放连接。

而那天刚好有人把事务配置更改了,有些不正确的调用hibernate导致连接泄露。
0 请登录后投票
   发表时间:2012-02-22  
如果我在一个方法里获取了个连接,接下来多态调用了个方法,该方法可能有四五种实现,有的实现里关闭了连接,有的还需要调用另外的多态方法,不知道是如何做出判断的

或者说,方法本身根本就没有提供实现,而是由使用者实现,只是有一个document,标明了必须在实现的方法里关闭传入的数据库连接

对于这种情形,又如何做判断的?
0 请登录后投票
   发表时间:2012-02-22  
freish 写道
如果我在一个方法里获取了个连接,接下来多态调用了个方法,该方法可能有四五种实现,有的实现里关闭了连接,有的还需要调用另外的多态方法,不知道是如何做出判断的

或者说,方法本身根本就没有提供实现,而是由使用者实现,只是有一个document,标明了必须在实现的方法里关闭传入的数据库连接

对于这种情形,又如何做判断的?

对于这种情况可以使用打印connection对象内存地址来分析,如果一个connection对象在getConnection方法和close都出现过,那说明该connection对象被正确的释放。
0 请登录后投票
   发表时间:2012-02-22  
mgoann 写道
kakaluyi 写道
很好奇dao.UserDAO.checkUserState为什么不释放连接池,一直持有连接对象干嘛,想真正check User state的时候再到连接池里拿呗,这样一直wait我觉得本身有可能也有问题


这个方法没有释放连接的原因还是比较的复杂,所以在博文中并没有具体的解释为什么这个方法没有释放连接。

是这样的,我们项目组通过spring的hibernateTemplate来集成的hibernate,如果都是通过hibernateTemplate来操作hibernate的话是没有问题的,spring会在操作完成后自动释放连接,但是UserDAO.checkUserSate是通过这种方式Session session = this.getSession();来获取的session导致spring无法管理该session。

还有就是和事务也有关系,当checkUserState加到事务中后,不管是使用哪种方式都没有问题,因为spring会保证一个线程获取session,到事务结束后自然会释放连接。

而那天刚好有人把事务配置更改了,有些不正确的调用hibernate导致连接泄露。

噢 原来是这样~解决方法应该是手动把连接给关了,或者统一用spring管理比较好
0 请登录后投票
   发表时间:2012-02-22  
kakaluyi 写道
mgoann 写道
kakaluyi 写道
很好奇dao.UserDAO.checkUserState为什么不释放连接池,一直持有连接对象干嘛,想真正check User state的时候再到连接池里拿呗,这样一直wait我觉得本身有可能也有问题


这个方法没有释放连接的原因还是比较的复杂,所以在博文中并没有具体的解释为什么这个方法没有释放连接。

是这样的,我们项目组通过spring的hibernateTemplate来集成的hibernate,如果都是通过hibernateTemplate来操作hibernate的话是没有问题的,spring会在操作完成后自动释放连接,但是UserDAO.checkUserSate是通过这种方式Session session = this.getSession();来获取的session导致spring无法管理该session。

还有就是和事务也有关系,当checkUserState加到事务中后,不管是使用哪种方式都没有问题,因为spring会保证一个线程获取session,到事务结束后自然会释放连接。

而那天刚好有人把事务配置更改了,有些不正确的调用hibernate导致连接泄露。

噢 原来是这样~解决方法应该是手动把连接给关了,或者统一用spring管理比较好

是的!的确是这样,我们是使用的spring来管理session的,可有些童鞋对hibernateTemplate不熟悉,还是用hibernate直接获取session来操作数据库而没有手动释放连接导致的。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics