使用druid连接池的超时回收机制排查连接泄露问题

简介:

在工程中使用了druid连接池,运行一段时间后系统出现异常:

 


 
  1. Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 60009, active 50  
  2.                 at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80)  
  3.                 at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280)  
  4.                 ... 64 more  
  5. Caused by: com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 60000, active 50  
  6.                 at com.alibaba.druid.pool.DruidDataSource.getConnectionInternal(DruidDataSource.java:1071)  
  7.                 at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:898)  
  8.                 at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4544)  


mysql数据库最大连接数设置为500,使用客户端能正常连接。连接数被未被占满。

 

 

分析原因应该是程序中有地方连接未关闭造成的。那如何来定呢?使用druid连接池的超时回收机制,在配置中增加以下内容:

 


 
  1. <!-- 超过时间限制是否回收 -->  
  2. <property name="removeAbandoned" value="true" />  
  3. <!-- 超时时间;单位为秒。180秒=3分钟 -->  
  4. <property name="removeAbandonedTimeout" value="180" />  
  5. <!-- 关闭abanded连接时输出错误日志 -->  
  6. <property name="logAbandoned" value="true" />     


运行程序,当连接超过3分钟后会强制进行回收,并输出异常日志。

 

 


 
  1. 2014-10-13 16:02:28,919 ERROR [com.alibaba.druid.pool.DruidDataSource] - <abandon connection, open stackTrace  
  2.         at java.lang.Thread.getStackTrace(Thread.java:1567)  
  3.         at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:995)  
  4.         at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4544)  
  5.         at com.alibaba.druid.filter.stat.StatFilter.dataSource_getConnection(StatFilter.java:661)  
  6.         at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4540)  
  7.         at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:919)  
  8.         at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:911)  
  9.         at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:98)  
  10.           
  11.         at cn.org.xxx.xxx.xxx.PaginationInterceptor.intercept(PaginationInterceptor.java:96)  
  12.           
  13.         at org.apache.ibatis.plugin.Plugin.invoke(Plugin.java:60)  
  14.         at com.sun.proxy.$Proxy59.query(Unknown Source)  
  15.         at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:108)  

 


很清楚地看到是在哪里打开的连接未关闭一直在占有。

 

 

此配置项会影响性能,只在排查的时候打开。系统运行时最好关闭。

标签:  JAVA连接池

本文转自 netcorner 博客园博客,原文链接:http://www.cnblogs.com/netcorner/p/4380949.html    ,如需转载请自行联系原作者

相关文章
|
5月前
|
druid 前端开发 关系型数据库
mysql使用druid时自动断开连接解决方案
mysql使用druid时自动断开连接解决方案
127 0
|
7月前
|
Arthas druid Java
一次druid数据库连接池连接泄露的排查分析
一次druid数据库连接池连接泄露的排查分析
602 1
|
7月前
|
监控 druid Java
监控druid数据库连接池连接泄露的思路
监控druid数据库连接池连接泄露的思路
678 2
|
10月前
|
存储 SQL 数据库
超时时间已到。超时时间已到,但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用,并且达到了最大池大小。
超时时间已到。超时时间已到,但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用,并且达到了最大池大小。
195 0
|
11月前
|
SQL 监控 Java
如何避免JDBC池和内存溢出?优化策略大揭秘!
0 目标 生成订单接口的基准场景是什么结果。 SQL的问题定位
424 0
|
开发框架
数据连接池的工作机制是什么?
J2EE服务器启动时会建立一定数量的池连接,并一直维持不少于此数目的池连接。
155 0
|
缓存 算法 网络协议
【Java 网络编程】客户端 Socket 配置 ( 超时时间 | 端口复用 | Nagle 算法 | 心跳包机制 | 连接关闭机制 | 缓冲区大小 | 性能权重设置 | 紧急数据设置 )
【Java 网络编程】客户端 Socket 配置 ( 超时时间 | 端口复用 | Nagle 算法 | 心跳包机制 | 连接关闭机制 | 缓冲区大小 | 性能权重设置 | 紧急数据设置 )
897 0
|
消息中间件 监控 druid
排查数据库连接池错误
最近在使用druid数据源时,碰到一个问题closed connection。在本地及测试环境都运行正常,但是在正式环境,过一段时间就出现closed conneciton问题,关闭的连接。
560 0
|
网络协议 Dubbo Oracle
数据库连接池设置多少连接才合适?
前段时间在一个老项目中经历过一个问题:一个 Dubbo 服务,启动的时候慢的要死,后来看日志查原因整个过程一直在初始化数据库连接。一看数据库连接参数,连接池大小:1024。 很多入行晚的同学没有经历过手写 JDBC 连接的日子。那个时候没有数据库连接池的概念,都是原生代码一顿搞,后来有了 iBATIS 之后 Java 开发的繁杂程度才逐渐减轻,也衍生 C3P0 数据库连接池这种基础的东西。
2335 0
数据库连接池设置多少连接才合适?
心跳 —— 超时机制分析
在C/S模式中,有时我们会长时间保持一个连接,以避免频繁地建立连接,但同时,一般会有一个超时时间,在这个时间内没发起任何请求的连接会被断开,以减少负载,节约资源。并且该机制一般都是在服务端实现,因为client强制关闭或意外断开连接,server端在此刻是感知不到的,如果放到client端实现,在上述情况下,该超时机制就失效了。本来这问题很普通,不太值得一提,但最近在项目中看到了该机制的一种糟糕的实现,故在此深入分析一下。
758 0
心跳 —— 超时机制分析