排查一次线程泄漏

背景:最近经常发生K8S健康检查到应用的心跳接口超时不通,然后发生了重启,第一时间进入pod内部使用任何jvm命令都会导致java进程重启(也包括arthas工具使用不了),dump不下来,事故现场没法保留,事故发生时间不稳定大多数在业务高峰期,经过多次守候dump下来了堆文件,经过分析认定内存有异常,继而排查到DruidDataSource 创建和销毁线程过多定位到线程泄漏问题;

1. 案发前发现程序内存接近6G,K8S限制内存也是6G,猜测K8s自动重启的

使用dmesg [-T 标准时间格式],查看系统时间 (截图后补的)

dmesg -T

发现确实是发生了OOM memory: usage 1310720kB, limit 1310720kB, failcnt 32425595,内存限制了

2. 看来内存有问题了,蹲了一次案发前,使用top命令查看内存5.9G,使用arthas查看发现内存只有5.4G, 很好奇消失的500MB去哪里了

使用arthas dashboard 查看堆和非堆配置发现发现确实少了500MB没有统计出来,那猜测

按照内存模型来说推测线程问题 ,jstack导出一看线程确实过多,5000多个

3. 排查代码所有创建DruidDataSource的地方发现只有一处,也就说DruidDataSource线程池并没有被回收,通过dump文件也验证了

4. 验证问题:

  @Test
    public void test() throws Exception {

        Properties pro = new Properties();
        pro.setProperty(DruidDataSourceFactory.PROP_DRIVERCLASSNAME, "com.mysql.cj.jdbc.Driver");
        pro.setProperty(DruidDataSourceFactory.PROP_URL, "jdbc:mysql://127.0.0.1:3306/test?useUnicode=true&characterEncoding=utf8");
        pro.setProperty(DruidDataSourceFactory.PROP_USERNAME, "root");
        pro.setProperty(DruidDataSourceFactory.PROP_PASSWORD, "123456");
        DruidDataSource druidDataSource = (DruidDataSource) DruidDataSourceFactory.createDataSource(pro);
        druidDataSource.init();

        Connection connection =(Connection) druidDataSource.getConnection();

        PreparedStatement callableStatement = connection.prepareStatement("select * from a");
        ResultSet resultSet = callableStatement.executeQuery();
        while (resultSet.next()){
            System.out.println(resultSet.getString("id"));
        }

        resultSet.close();
        callableStatement.close();
        connection.close();

        String hashcode = String.valueOf(druidDataSource.hashCode());
        System.out.println("hashcode:"+hashcode);

        //druidDataSource = null 后不会被回收, 要执行druidDataSource.close()
        druidDataSource = null;

//        Thread.sleep(100000);

        System.gc();
        System.out.println("GC查看");
//        Thread.sleep(100000000);

    }

5. 结论:

DruidDataSource 线程池创建后不主动close是不会释放的,即使设置了DruidDataSource=null,也不会被自然回收

6.修复:使用完主动close()

DruidDataSource.close();

相关推荐

  1. 超时导致的协泄露

    2024-07-22 21:46:03       17 阅读
  2. 4、内存泄漏检测(多线)

    2024-07-22 21:46:03       55 阅读
  3. 线

    2024-07-22 21:46:03       46 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-07-22 21:46:03       52 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-07-22 21:46:03       54 阅读
  3. 在Django里面运行非项目文件

    2024-07-22 21:46:03       45 阅读
  4. Python语言-面向对象

    2024-07-22 21:46:03       55 阅读

热门阅读

  1. 多站点环境下Memcached的配置与管理

    2024-07-22 21:46:03       18 阅读
  2. Vue3 深入组件

    2024-07-22 21:46:03       17 阅读
  3. Leetcode热题100 Day4

    2024-07-22 21:46:03       16 阅读
  4. Python每日学习

    2024-07-22 21:46:03       15 阅读
  5. web前端 React 框架面试200题(七)

    2024-07-22 21:46:03       15 阅读
  6. 鸡兔同笼求解器

    2024-07-22 21:46:03       17 阅读
  7. 深度学习中的损失函数和网络优化方法

    2024-07-22 21:46:03       13 阅读
  8. VUE复习

    VUE复习

    2024-07-22 21:46:03      10 阅读
  9. Unity扩展 UI线段绘制组件——UI上的LineRenderer

    2024-07-22 21:46:03       14 阅读
  10. IDM破解

    IDM破解

    2024-07-22 21:46:03      12 阅读