背景
某天在查询生产日志时,发现大量的Okhttp连接泄漏警告日志,但生产上没有收到任何异常反馈。出于好奇心,本地最小化复现问题,并最终解决问题。
分析问题
-
okhttp官网的demo示例
OkHttpClient client = new OkHttpClient(); String run(String url) throws IOException { Request request = new Request.Builder() .url(url) .build(); try (Response response = client.newCall(request).execute()) { return response.body().string(); } }
1.1 上述示例明显是Try-with-resources写法,最终会在finally里去关闭资源
1.2 跟进string()源码发现最终也会关闭资源 -
分析官网示例,连接泄漏可能是因为执行请求没有关闭资源并且也没有执行string方法,导致资源始终没有关闭
2.1 上面示例在响应成功时就不会关闭连接资源
复现问题
- 启动一个简单服务端,暴露一个接口供客户端访问
- 客户端请求
2.1 在执行请求时,会将调用者添加连接信息中(一个连接包含多个调用者),并且将调用者用虚引用包装
2.2 点进CallReference发现调用者用虚引用包装
2.3 在sendLocalhost方法执行完后,调用者引用关闭等待垃圾回收(当垃圾回收后,虚引用里的实际对象变为Null)
(1)执行完sendLocalhost方法后打印断点,等待RealConnectionPool#pruneAndGetAllocationCount检查执行
(2)在执行方法1的时候之前打上断点,通过System.gc()主动触发GC回收没有引用的调用者,这时reference.get()返回null,复现线上告警日志(为了让其触发垃圾回收,我把堆栈调的比较小)
2.4 当连接的所有调用者都没有之后,进行连接驱逐释放
总结
- 搜索代码,将所有没有关闭资源的地方都进行关闭。后续发现再也没有相关警告日志出现了,成功解决问题
- 规范代码,调用请求和获取响应作为整体不进行拆分,然后将响应进行类型转换