c3p0 泄漏

一个很重要的资料来源

http://liu.fm/2015/07/15/c3p0/　

c3p0 泄漏

2011-06-16 16:53 2660人阅读 评论(0) 收藏 举报

分类：

JAVA（120）

版权声明：本文为博主原创文章，未经博主允许不得转载。

最近的项目碰到了连接泄漏的问题。 项目用的是Spring + Hibernate + c3p0，具体表现为，系统运行一段时间后，用户打开登录页后，执行登录无响应，查看后台日志，提示Could not open Connection。将c3p0日志级别调成debug之后，发现c3p0报告连接数已经达到设置的上限。 之前检查连接泄漏时，使用的是极低效的办法，目测代码，所以问题解决起来颇费周折，效果还不好。 今天查了一下c3p0官方手册，c3p0官方提供了两个参数，能够很方便的检查没有正确返回连接池的连接。

debugUnreturnedConnectionStackTraces
默认为false，如果此参数设置为true，当所有连接用完的时候，会以堆栈信息显示哪些代码使用了连接。由于跟踪连接状态会产生额外的消耗，如果程序稳定，应该将此参数恢复为默认值false。

unreturnedConnectionTimeout
设置连接被checkout后，经过多长时间还未返还连接池，则连接缓冲池直接Kill该连接，此时，结合 debugUnretrunedConnectionStackTraces，我们可以知道是什么程序持有了连接，并且没有返回。这个方法很暴力，有可能 造成应用程序不稳定，所以，如果真的出现了连接泄漏，一时半会又找不到问题点所在，可以暂时使用这个方法让应用程序跑起来。

首先，为了跟踪问题，debugUnreturnedConnectionStackTraces参数肯定是设置为true的。下面主要说明 unreturnedConnectionTimeout参数的设置，unreturnedConnectionTimeout参数是在连接被应用程序 checkout后指定时间内未checkin则由连接缓冲池执行kill操作，同时打印堆栈跟踪信息。在我的应用里，maxIdleTime的设置是 120秒，所以，我把unreturnedConnectionTimeout设置成150秒，如果达到最大存活时间后，连接还是不能被连接缓冲池正常关 闭，那么肯定出现了连接泄漏，此时，再过30秒后，由连接缓冲池主动执行kill。

通过以上设置后，确实收获了一些成果，通过分析日志，找到了连接泄漏问题代码。异常信息如下：

2011-04-06 15:49:42,599 INFO : com.mchange.v2.resourcepool.BasicResourcePool.removeResource(BasicResourcePool.java:1395) – Logging the stack trace by which the overdue resource was checked-out.
java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack trace.
at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525)
at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128)
at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:82)
at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423)
at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1547)
at org.hibernate.loader.Loader.doQuery(Loader.java:673)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2220)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
at org.hibernate.loader.Loader.list(Loader.java:2099)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152)
at com.leo.dao.XXXDAO.queryXXX(XXXDAO.java:20)
at jsp_servlet._keyareas._country.__taskcdb_add._jspService(__taskcdb_add.java:195)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:416)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:326)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:526)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:253)

通过堆栈信息，很容易就确认了问题点。这个问题点是由于DAO使用不规范导致的，XXXDAO继承了HibernateDaoSupport，在方 法中使用了getHibernateTemplate().getSessionFactory().openSession()获得session，然 后通过session.createSQLQuery()，随后却并没有执行session.close()。

关于日志大小：在目前 maxIdleTime=120,maxPoolSize=18,minPoolSize=5,idleConnectionTestPeriod=30 的情况下，日志PatternLayout %d %-5p: %l – %m%n，一天的日志记录情况大约是12M，在硬盘空间允许的情况下建议按天存储日志。

c3p0 连接池的日志配置

2009-01-15 12:19 5786人阅读 评论(1) 收藏 举报

分类：

Java（3）

版权声明：本文为博主原创文章，未经博主允许不得转载。

如果用c3p0的话，经常会看到控制台上报一个警告，具体内容不急得了，大意是无法初始化MLog日志，请初始化log4j
出现此种情况是因为使用的c3p0这个连接池，并且没有正确配置其日志，只要把下面这段加到log4j.properties中即可

#####################################################################################
#c3p0
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=OFF,A1
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=SEVERE,A1
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=WARNING,A1
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=INFO,A2
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=CONFIG,A2
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=FINE,A2
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=FINER,A2
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=FINEST,A2
log4j.category.com.mchange.v2.log.log4j.Log4jMLog=ALL,A2

#c3p0 appender
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss,SSS} [%c]-[%p] %m%n
log4j.appender.A2=org.apache.log4j.RollingFileAppender
log4j.appender.A2.File=${sntweb.root}/logs/c3p0.log
log4j.appender.A2.MaxFileSize=500KB
log4j.appender.A2.MaxBackupIndex=1
#log4j.appender.A2.layout=org.apache.log4j.HTMLLayout
log4j.appender.A2.layout=org.apache.log4j.SimpleLayout

跟踪 C3p0 连接池连接泄漏之参数优化与日志分析 

博客分类：

<property name="unreturnedConnectionTimeout"><value>100</value></property>

<property name="debugUnreturnedConnectionStackTraces"><value>true</value></property>

跟踪 C3p0 连接池连接泄漏

debugUnreturnedConnectionStackTraces、unreturnedConnectionTimeout参数的说明，此篇日志进一步介绍应用这两个参数后的一些经验。

首先，为了跟踪问题，debugUnreturnedConnectionStackTraces参数肯定是设置为true的。下面主要说明 unreturnedConnectionTimeout参数的设置，unreturnedConnectionTimeout参数是在连接被应用程序 checkout后指定时间内未checkin则由连接缓冲池执行kill操作，同时打印堆栈跟踪信息。在我的应用里，maxIdleTime的设置是 120秒，所以，我把unreturnedConnectionTimeout设置成150秒，如果达到最大存活时间后，连接还是不能被连接缓冲池正常关 闭，那么肯定出现了连接泄漏，此时，再过30秒后，由连接缓冲池主动执行kill。

通过以上设置后，确实收获了一些成果，通过分析日志，找到了连接泄漏问题代码。异常信息如下：

2011-04-06 15:49:42,599 INFO : com.mchange.v2.resourcepool.BasicResourcePool.removeResource(BasicResourcePool.java:1395) – Logging the stack trace by which the overdue resource was checked-out. 
    java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack trace. 
    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) 
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) 
    at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) 
    at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:82) 
    at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423) 
    at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144) 
    at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139) 
    at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1547) 
    at org.hibernate.loader.Loader.doQuery(Loader.java:673) 
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) 
    at org.hibernate.loader.Loader.doList(Loader.java:2220) 
    at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) 
    at org.hibernate.loader.Loader.list(Loader.java:2099) 
    at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289) 
    at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695) 
    at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) 
    at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152) 
    at com.leo.dao.XXXDAO.queryXXX(XXXDAO.java:20) 
    at jsp_servlet._keyareas._country.__taskcdb_add._jspService(__taskcdb_add.java:195) 
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:34) 
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) 
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) 
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300) 
    at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:416) 
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:326) 
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183) 
    at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:526) 
    at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:253)

通过堆栈信息，很容易就确认了问题点。这个问题点是由于DAO使用不规范导致的，XXXDAO继承了HibernateDaoSupport，在 方法中使用了getHibernateTemplate().getSessionFactory().openSession()获得session， 然后通过session.createSQLQuery()，随后却并没有执行session.close()。

关于日志大小：在目前 maxIdleTime=120,maxPoolSize=18,minPoolSize=5,idleConnectionTestPeriod=30 的情况下，日志PatternLayout %d %-5p: %l – %m%n，一天的日志记录情况大约是12M，在硬盘空间允许的情况下建议按天存储日志。


c3p0连接池连接泄漏检测

2016-01-09 00:56 86人阅读 评论(0) 收藏 举报

分类：

Java（29） javaweb容器（1） 数据库

版权声明：本文为博主原创文章，未经博主允许不得转载。

配置文件c3p0-config.xml中加入： 
true 
1 
debugUnreturnedConnectionStackTraces 默认为false，如果此参数设置为true，当所有连接用完的时候，会以堆栈信息显示哪些代码使用 
了连接。由于跟踪连接状态会产生额外的消耗，如果程序稳定，应该将此参数恢复为默认值false。 
unreturnedConnectionTimeout 设置连接被checkout后，经过多长时间还未返还连接池，则连接缓冲池直接Kill该连接

设置完成后重现错误，可以观察到堆栈信息如下： 
java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack trace. 
at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) 
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) 
at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) 
at com.xinge.mms.push.jdbc.C3p0ConnectionProvider.getMms2Connection(C3p0ConnectionProvider.java:47) 
at com.xinge.mms.push.manager.DBMms2Manager.isDetail(DBMms2Manager.java:78) 
at com.xinge.mms.push.handler.IosMessageHandler.getAlert(IosMessageHandler.java:83) 
at com.xinge.mms.push.handler.IosMessageHandler.sendMessage(IosMessageHandler.java:70) 
at com.xinge.mms.push.apnstask.IosMessageProcessor4Test.run(IosMessageProcessor4Test.java:59) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:744)

从中可以看到DBMms2Manager.isDetail(DBMms2Manager.java:78)，查看代码发现，其中获取连接使用完后未关闭，从而造成连接泄漏

时间： 2024-10-25 21:23:37

c3p0 泄漏的相关文章

关于c3p0数据库连接池的简单使用

在使用开发基于数据库的web程序时,传统的模式基本是按以下步骤: 在主程序(如servlet.beans)中建立数据库连接. 进行sql操作 断开数据库连接. 这种模式开发,存在的问题: 普通的JDBC数据库连接使用 DriverManager 来获取,每次向数据库建立连接的时候都要将 Connection 加载到内存中,再验证用户名和密码(得花费0.05s-1s的时间).需要数据库连接的时候,就向数据库要求一个,执行完成后再断开连接.这样的方式将会消耗大量的资源和时间.数据库的连接资源并没有得

JavaWeb学习过程 之c3p0的使用

这几天在学习使用MVC模式来做几个小项目,在学习的过程中,用到了数据库连接池.便特意去学习了一下. 一.谈一谈为什么要使用数据库连接池 在开发基于数据库的web程序时,传统的模式(在servlet,beans 中建立数据库链接,进行sql操作, 断开数据库链接) 存在着一些问题. 每次连接都需要验证用户,消耗了大量的资源和时间.数据库的连接资源并没有得到很好地重复利用.再如,同时几万人在线频繁的连接数据库,系统资源消耗巨大,内存可能泄漏,服务器也可能会崩溃. 二.什么是数据库连接池 1.基本思想

jdbc连接池c3p0/dbcp强制连接超过设置时间后失效

通常来说,各种技术实现的优化参数或者选项或者歪门邪道之所以能被想出来,通常是因为开发者或者实现的贡献者曾经遇到过导致此结果的问题,所以才出了对应的策略选项. 在有些情况下,比如存在客户端或者服务端连接级别内存泄漏或者资源不释放,但是在较短的周期内无法解决的时候亦或是从经济角度或其他角度我们不愿意更改和修复的时候,公司当前版本的某个关键性产品就存在这么个问题,因为在存储过程中使用了不计其数的prepare动态SQL,而mysql在此实现上存在着服务端连接的内存泄露,起初我们通过将空闲连接数设置为0

【转】JDBC学习笔记(8)——数据库连接池(dbcp&amp;C3P0)

转自:http://www.cnblogs.com/ysw-go/ JDBC数据库连接池的必要性 一.在使用开发基于数据库的web程序时,传统的模式基本是按一下步骤: 1)在主程序(如servlet/beans)中建立数据库连接 2)进行sql操作 3)断开数据库连接 二.这种模式开发,存在的问题: 1)普通的JDBC数据库连接使用DriverManager来获取,每次向数据库建立连接的时候都要将Connection加载进内存中,再验证用户名和密码(得花费0.05s~1s的时间).需要数据库连接

数据库连接池简单介绍和 C3P0的JDBC配置

前面一节我们介绍了怎样利用jdbc连接数据库,已经实现了数据库的连接,可是在实际的项目开发中,能够发现基本上都使用了数据库连接池技术.为什么要使用数据库连接池呢?根源在于对数据库连接的低效管理 答: 普通的JDBC数据库连接,用户请求一次查询的时候就会向数据库发起一次连接.运行完后就断开连接,这种方式会消耗大量的资源和时间.数据库的连接资源并没有得到非常好的重复利用. 若是同一时候有几百人甚至几千人在线.频繁地进行数据库连接操作,这将会占用非常多的系统资源,严重的甚至会造成server的奔溃.这

c3p0、dbcp和proxool的优缺点比较及配置

1.数据库连接池的概念 数据库连接池概述: 数据库连接是一种关键的有限的昂贵的资源,这一点在多用户的网页应用程序中体现得尤为突出.对数据库连接的管理能显著影响到整个 应用程序的伸缩性和健壮性,影响到程序的性能指标.数据库连接池正是针对这个问题提出来的. 数据库连接池负责分配.管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而再不是重新建立一个:释放空闲时 间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏.这项技术能明显提高对数据库操作的性能. 数

关于Mysql com.mysql.jdbc.StatementImpl$CancelTask内存泄漏问题及解决办法

近来在负责公司短信网关的维护及建设,随着公司业务发展对短信依赖越来越严重了,短信每天发送量也比以前每天40多w发送量暴增到每天达到200w发送量.因为是采用Java做发送底层,压力递增情况下不可避免的面对内存问题.在发送量接近200w情况下,出现内存泄露问题了. 经过对系统运行检查发现: 1)每次重启系统3-4个小时后,均发现一点不稳定: 2)在3-4个小时后,出现out of memory的错误:java.lang.OutOfMemoryError: GC overhead limit exc

详解C3P0（数据库连接池）

一.基本定义 C3P0是一个开源的JDBC连接池,它实现了数据源与JNDI绑定,支持JDBC3规范和实现了JDBC2的标准扩展说明的Connection和Statement池的DataSources对象. 即将用于连接数据库的连接整合在一起形成一个随取随用的数据库连接池(Connection pool). 二.使用C3P0(数据库连接池)的必要性 当我们在进行基于数据库的web程序开发时,我们可以先在主程序(如Servlet.Bean)中通过JDBC中的DriverManager建立数据库连接,

C3P0 APPARENT DEADLOCK

一,c3p0执行一段时间后报错例如以下 W 07-26_00:58:27 ThreadPoolAsynchronousRunner.java 608 com[email protected]70929ab6 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks! W 07-26_00:58:39 ThreadPoolAsynchronousRunner.java 608 com[email