几行代码轻松复现druid连接泄露的BUG之keepalive

本文涉及的产品
Serverless 应用引擎 SAE,800核*时 1600GiB*时
可观测链路 OpenTelemetry 版,每月50GB免费额度
简介: 几行代码轻松复现druid连接泄露的BUG之keepalive

背景介绍

一次druid数据库连接池连接泄露的排查分析介绍了连接泄露的分析排查过程,在几行代码轻松复现druid连接泄露的BUG之PhyTimeout介绍了当配置了phyTimeoutMillis参数情况下,连接泄露的场景,在几行代码轻松复现druid连接泄露的BUG之onFatalError介绍了当数据库操作出现某些异常情况下,连接泄露的场景,下面通过代码的方式来复现当配置了keepalive选项的情况下出现连接泄露的场景。

复现过程

连接泄露场景

模拟当配置了keepalive选项的情况下出现连接泄露的场景。

连接泄露模拟代码

import com.alibaba.druid.pool.DruidConnectionHolder;
import com.alibaba.druid.pool.DruidDataSource;
import com.alibaba.druid.pool.DruidPooledConnection;
import java.lang.reflect.Field;
import java.sql.SQLException;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class DruidAbandonedCase4Keepalive {
    public static void main(String[] args) throws Exception {
        Map<Long,DruidConnectionHolder> holderMap = new HashMap<>();
        DruidDataSource dataSource = new DruidDataSource();
        dataSource.setDriverClassName("com.mysql.cj.jdbc.Driver");
        dataSource.setUsername("root");
        dataSource.setPassword("123456");
        dataSource.setUrl("jdbc:mysql://127.0.0.1:3306/test?serverTimezone=UTC&useUnicode=true&characterEncoding=utf-8&useSSL=false");
        dataSource.setMinIdle(2);
        dataSource.setKeepAlive(true);
        dataSource.setTimeBetweenEvictionRunsMillis(500);
        long minEvictableIdleTimeMillis = 500L;
        dataSource.setMinEvictableIdleTimeMillis(minEvictableIdleTimeMillis);
        long keepAliveBetweenTimeMillis = 1000L;
        dataSource.setKeepAliveBetweenTimeMillis(keepAliveBetweenTimeMillis);
        dataSource.init();
        try{
            Field destroyConnectionThreadField = DruidDataSource.class.getDeclaredField("destroyConnectionThread");
            destroyConnectionThreadField.setAccessible(true);
            Thread destroyConnectionThread = (Thread)destroyConnectionThreadField.get(dataSource);
            destroyConnectionThread.interrupt();
            Thread.State state = destroyConnectionThread.getState();
            System.out.println("destroyConnectionThread state : " + state);
        }catch (Exception e){
            e.printStackTrace();
        }
        DruidPooledConnection connection1 = dataSource.getConnection();
        DruidConnectionHolder holder1 = connection1.getConnectionHolder();
        print(holder1);
        holderMap.put(holder1.getConnectionId(),holder1);
        DruidPooledConnection connection2 = dataSource.getConnection();
        DruidConnectionHolder holder2 = connection2.getConnectionHolder();
        print(holder2);
        holderMap.put(holder2.getConnectionId(),holder2);
        connection2.close();
        sleep(keepAliveBetweenTimeMillis - minEvictableIdleTimeMillis + 100L);
        connection1.close();
        sleep(minEvictableIdleTimeMillis - 100L);
        pooling(dataSource,holderMap);
        shrink(dataSource);
        pooling(dataSource,holderMap);
        sleep(100L);
        shrink(dataSource);
        pooling(dataSource,holderMap);
        System.out.println();
        print(holder1);
        print(holder2);
    }
    private static void sleep(long millis){
        try{
            Thread.sleep(millis);
        }catch (InterruptedException e){
            e.printStackTrace();
        }
    }
    private static void shrink(DruidDataSource dataSource){
        System.out.println();
        System.out.println("调用shrink");
        // 手动执行shrink
        dataSource.shrink(true);
    }
    private static void pooling(DruidDataSource dataSource,Map<Long,DruidConnectionHolder> holderMap) throws SQLException {
        System.out.println();
        System.out.println("连接池中连接情况,begin");
        List<Map<String, Object>> conns = dataSource.getPoolingConnectionInfo();
        for (Map<String, Object> conn : conns) {
            print(holderMap.get(conn.get("connectionId")));
        }
        System.out.println("连接池中连接情况,end");
    }
    private static void print(DruidConnectionHolder holder) throws SQLException {
        System.out.println(holder.getConnectionId() + /*" : " + holder +*/
                " idleMillis : " + (System.currentTimeMillis() - holder.getLastActiveTimeMillis()) + " isClosed:" + holder.getConnection().isClosed());
    }
}

运行以上程序,输出结果如下(druid 1.2.8):

destroyConnectionThread state : TIMED_WAITING
10001 idleMillis : 6 isClosed:false
10002 idleMillis : 1 isClosed:false
连接池中连接情况,begin
10002 idleMillis : 1015 isClosed:false
10001 idleMillis : 404 isClosed:false
连接池中连接情况,end
调用shrink
连接池中连接情况,begin
10001 idleMillis : 405 isClosed:false
10002 idleMillis : 1016 isClosed:false
连接池中连接情况,end
调用shrink
连接池中连接情况,begin
10001 idleMillis : 405 isClosed:false
10002 idleMillis : 1016 isClosed:false
连接池中连接情况,end
调用shrink
连接池中连接情况,begin
10002 idleMillis : 1133 isClosed:true
连接池中连接情况,end
10001 idleMillis : 522 isClosed:false
10002 idleMillis : 1133 isClosed:true

代码执行逻辑描述:

  1. 为了便于测试,中断Druid-ConnectionPool-Destroy-xx线程,以便手动调用shrink;
  2. 获取connectionId为1001的连接,打印连接信息;
  3. 获取connectionId为1002的连接,打印连接信息;
  4. 调用close,归还connectionId为1002的连接
  5. sleep (keepAliveBetweenTimeMillis - minEvictableIdleTimeMillis + 100L)时长
  6. 调用close,归还connectionId为1001的连接
  7. sleep (minEvictableIdleTimeMillis - 100L)时长(两个sleep是为了让1002 idleMillis大于keepAliveBetweenTimeMillis,让1001小于minEvictableIdleTimeMillis)
  8. 打印连接池中连接信息
  9. 执行shrink
  10. 打印连接池中连接信息
  11. sleep 100ms
  12. 执行shrink
  13. 打印连接池中连接信息
  14. 打印1001和1002连接信息

期望执行结果:

  • connectionId为1001和1002的连接都应该被连接池管理,且连接状态都应该是未关闭状态

实际执行结果:

  • connectionId为1001的连接已从连接池中删除,且连接状态是未关闭状态,泄露的连接【不符合期望】;
  • connectionId为1002的连接虽然在连接池中,但是连接状态是关闭状态【不符合期望】。

测试看,keepalive选项是从druid 1.1.16引入的,druid 1.1.16-1.1.24,1.2.0-1.2.17都存在连接泄露问题,druid 1.2.18-1.2.20不存在连接泄露问题。

目录
相关文章
|
8月前
|
数据采集 域名解析 网络协议
Python爬虫过程中DNS解析错误解决策略
Python爬虫过程中DNS解析错误解决策略
|
9月前
|
druid 数据库
几行代码轻松复现druid连接泄露的BUG之onFatalError
几行代码轻松复现druid连接泄露的BUG之onFatalError
178 0
|
9月前
|
druid 数据库
几行代码轻松复现druid连接泄露的BUG之PhyTimeout
几行代码轻松复现druid连接泄露的BUG之PhyTimeout
133 0
|
安全 Linux API
​Apache Solr未授权上传漏洞复现及验证POC编写
​Apache Solr未授权上传漏洞复现及验证POC编写
|
安全 Java fastjson
Log4j2漏洞复现&原理&补丁绕过
Log4j2漏洞复现&原理&补丁绕过
|
开发框架 安全 .NET
IIS6.0文件解析漏洞原理/复现
IIS文件解析漏洞原理 IIS6.0存在文件解析漏洞 , 文件名中分号( ; )后面的内容不会被解析 比如 a.asp;jpg 文件 会被IIS解析成 a.asp 这个漏洞是逻辑上的问题,IIS6.0只是简单的根据扩展名来识别文件类型 , IIS底层使用C++写的,分号在C++中是结束符号 , 解析文件名读取到分号的时候,IIS会认为代码已经结束,从而停止解析
995 0
IIS6.0文件解析漏洞原理/复现
|
开发框架 安全 .NET
IIS6.0目录解析漏洞原理/复现
目录解析漏洞原理 IIS6.0版本存在目录解析漏洞 , ,asp格式命名的文件夹,其目录下的所有文件都会被IIS当做asp文件来解析 漏洞复现 环境准备 Windows 2003系统 , IIS 6.0 服务
212 0
IIS6.0目录解析漏洞原理/复现
|
缓存 安全 JavaScript
苹果cms漏洞POC原理分析与V8 V10被挂马解决办法分享
苹果CMS漏洞是越来越多了,国内很多电影网站都使用的是maccms V10 V8版本,就在2020年初该maccms漏洞爆发了,目前极少数的攻击者掌握了该EXP POC,受该BUG的影响,百分之80的电影站都被攻击了,很多电影站的站长找到我们SINE安全来解决网站被挂马的问题,通过分析我们发现大部分客户网站在数据库中都被插入了挂马代码,尤其电影片名d_name值被直接篡改,并且是批量挂马,导致用户打开网站访问直接弹窗广告并跳转。
1180 0
苹果cms漏洞POC原理分析与V8 V10被挂马解决办法分享
|
XML 安全 Java
网站apache环境S2-057漏洞 利用POC 远程执行命令漏洞复现
S2-057漏洞,于2018年8月22日被曝出,该Struts2 057漏洞存在远程执行系统的命令,尤其使用linux系统,apache环境,影响范围较大,危害性较高,如果被攻击者利用直接提权到服务器管理员权限,网站数据被篡改,数据库被盗取都会发生。
132 0
网站apache环境S2-057漏洞 利用POC 远程执行命令漏洞复现
|
安全 PHP 数据安全/隐私保护
thinkphp网站有漏洞怎么解决修复
2019年1月14日消息,thinkphp又被爆出致命漏洞,可以直接远程代码执行,getshell提权写入网站木马到网站根目录,甚至直接提权到服务器,该漏洞影响版本ThinkPHP 5.0、ThinkPHP 5.0.10、ThinkPHP5.0.12、ThinkPHP5.0.13、ThinkPHP5.0.23、thinkphp 5.0.22版本。
597 0
thinkphp网站有漏洞怎么解决修复