Okhttp连接泄漏警告问题分析

背景

  某天在查询生产日志时，发现大量的Okhttp连接泄漏警告日志，但生产上没有收到任何异常反馈。出于好奇心，本地最小化复现问题，并最终解决问题。

分析问题

1. 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
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11

   1.1 上述示例明显是Try-with-resources写法，最终会在finally里去关闭资源
   1.2 跟进string()源码发现最终也会关闭资源

2. 分析官网示例，连接泄漏可能是因为执行请求没有关闭资源并且也没有执行string方法，导致资源始终没有关闭
   
   2.1 上面示例在响应成功时就不会关闭连接资源

复现问题

1. 启动一个简单服务端，暴露一个接口供客户端访问
   
2. 客户端请求
   
   2.1 在执行请求时，会将调用者添加连接信息中（一个连接包含多个调用者），并且将调用者用虚引用包装
   
   2.2 点进CallReference发现调用者用虚引用包装
   
   2.3 在sendLocalhost方法执行完后，调用者引用关闭等待垃圾回收（当垃圾回收后，虚引用里的实际对象变为Null)
   （1）执行完sendLocalhost方法后打印断点，等待RealConnectionPool#pruneAndGetAllocationCount检查执行
   （2）在执行方法1的时候之前打上断点，通过System.gc()主动触发GC回收没有引用的调用者，这时reference.get()返回null，复现线上告警日志（为了让其触发垃圾回收，我把堆栈调的比较小)
   
   
   2.4 当连接的所有调用者都没有之后，进行连接驱逐释放

总结

1. 搜索代码，将所有没有关闭资源的地方都进行关闭。后续发现再也没有相关警告日志出现了，成功解决问题
2. 规范代码，调用请求和获取响应作为整体不进行拆分，然后将响应进行类型转换