DBCP1.3连接泄露问题
2017-03-14 20:56
337 查看
线上使用的dbcp版本
如图中所示,会话撑满100个(上限默认的为100),连接全部是IDLE。
在参考issue DBCP-470后经本地测试发现问题重现。
问题主要原因是当所连接的数据库停机后,此时通过程序创建BasicDataSource对象来访问数据库时validateConnectionFactory方法抛异常导致datasource成员变量一直为空。
主要问题在于
通过
创建连接池
问题在于
连接泄露
上面由于在异常时没有实例化dataSource变量,当重复调用
GC无法回收
在
jmap生成dump文件分析
线上数据库确实如图中所示有那么多连接数被占用。
但是官网并没有release 1.4.1版本。
随便通过在GIT上找到commons-dbcp源码,在其1.4版本的分支中发现问题已经解决。
此处已经
此时下载该版本的源代码编译打包后,再经测试发现问题已经解决了。
编译后的jar包下载地址
1.3,数据库为达梦7。
问题
在生产环境下发现,dbcp所连接的库一旦因为其它原因挂掉,再次重启数据库后会话将直接撑爆数据库,接着导致数据库再次挂掉。
如图中所示,会话撑满100个(上限默认的为100),连接全部是IDLE。
在参考issue DBCP-470后经本地测试发现问题重现。
问题主要原因是当所连接的数据库停机后,此时通过程序创建BasicDataSource对象来访问数据库时validateConnectionFactory方法抛异常导致datasource成员变量一直为空。
主要问题在于
createDataSource()方法。
通过
dataSource !=null来防止重复创建数据源
创建连接池
问题在于
createPoolableConnectionFactory方法里会调用
validateConnectionFactory方法来校验目的库是否可连接。如果不可连接将抛出异常,这将导致
createDataSourceInstance()不会走,也就不会实例化dataSource变量。
连接泄露
上面由于在异常时没有实例化dataSource变量,当重复调用
createDataSource()方法时,将导致
createConnectionPool()方法会重复调用。
GC无法回收
在
createConnectionPool()方法中,调用
GenericObjectPool的
setTimeBetweenEvictionRunsMillis()方法时会开启一个Timer。这将导致GenericObjectPool对象由于被Timer对象引用而一直无法被回收掉。
jmap生成dump文件分析
线上数据库确实如图中所示有那么多连接数被占用。
解决问题
在dbcp-470问题中提到解决版本为1.4.1但是官网并没有release 1.4.1版本。
随便通过在GIT上找到commons-dbcp源码,在其1.4版本的分支中发现问题已经解决。
此处已经
try-catch了,并有在
finally块中关闭了上面创建的连接池。
此时下载该版本的源代码编译打包后,再经测试发现问题已经解决了。
编译后的jar包下载地址
相关文章推荐
- DBCP1.3连接泄露问题
- DBCP1.3连接泄露问题
- DBCP1.3连接泄露问题
- DBCP1.3连接泄露问题
- DBCP1.3连接泄露问题
- DBCP1.3连接泄露问题
- DBCP1.3数据库连接泄漏问题
- 使用druid连接池的超时回收机制排查连接泄露问题
- mysql连接空闲8小时自动断开问题DBCP解决方案
- dbcp第一次获取连接的时间问题
- 解决SpringBoot连接池TOMCAT-JDBC(默认) DBCP或C3P0连接超时异常问题
- DBCP连接mysql出现“8小时”问题解决
- 使用druid连接池的超时回收机制排查连接泄露问题
- 使用 APACHE COMMON DBCP +COMMON POOL+MYSQL连接无效的问题
- DBCP连接池泄露问题
- DBCP配置数据库连接乱码问题
- 使用druid连接池的超时回收机制排查连接泄露问题
- Spring 的 HibernateDaoSupport 类的 getSession() 导致的连接泄露问题
- go的mgo,连接未释放问题,连接泄露。
- 使用druid连接池的超时回收机制排查连接泄露问题