背景:最近经常发生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多个druid线程
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();