(转)OkHttp3源码分析[复用连接池]

愿地址：https://blog.csdn.net/yangxi_pekin/article/details/73459908

OkHttp系列文章如下

• OkHttp3源码分析[综述]
• OkHttp3源码分析[复用连接池]
• OkHttp3源码分析[缓存策略]
• OkHttp3源码分析[DiskLruCache]
• OkHttp3源码分析[任务队列]

---

1. 概述

HTTP中的keepalive连接在网络性能优化中，对于延迟降低与速度提升的有非常重要的作用。

通常我们进行http连接时，首先进行tcp握手，然后传输数据，最后释放

图源: Nginx closed

这种方法的确简单，但是在复杂的网络内容中就不够用了，创建socket需要进行3次握手，而释放socket需要2次握手(或者是4次)。重复的连接与释放tcp连接就像每次仅仅挤1mm的牙膏就合上牙膏盖子接着再打开接着挤一样。而每次连接大概是TTL一次的时间(也就是ping一次)，在TLS环境下消耗的时间就更多了。很明显，当访问复杂网络时，延时（而不是带宽）将成为非常重要的因素。

当然，上面的问题早已经解决了，在http中有一种叫做keepalive connections的机制，它可以在传输数据后仍然保持连接，当客户端需要再次获取数据时，直接使用刚刚空闲下来的连接而不需要再次握手

图源: Nginx keep_alive

扫描二维码关注公众号，回复： 2516567 查看本文章

在现代浏览器中，一般同时开启6～8个keepalive connections的socket连接，并保持一定的链路生命，当不需要时再关闭；而在服务器中，一般是由软件根据负载情况(比如FD最大值、Socket内存、超时时间、栈内存、栈数量等)决定是否主动关闭。

Okhttp支持5个并发KeepAlive，默认链路生命为5分钟(链路空闲后，保持存活的时间)

当然keepalive也有缺点，在提高了单个客户端性能的同时，复用却阻碍了其他客户端的链路速度，具体来说如下

1. 根据TCP的拥塞机制，当总水管大小固定时，如果存在大量空闲的keepalive connections（我们可以称作僵尸连接或者泄漏连接），其它客户端们的正常连接速度也会受到影响，这也是运营商为何限制P2P连接数的道理
2. 服务器/防火墙上有并发限制，比如apache服务器对每个请求都开线程，导致只支持150个并发连接（数据来源于nginx官网），不过这个瓶颈随着高并发server软硬件的发展（golang/分布式/IO多路复用）将会越来越少
3. 大量的DDOS产生的僵尸连接可能被用于恶意攻击服务器，耗尽资源

好了，以上科普完毕，本文主要是写客户端的，服务端不再介绍。

下文假设服务器是经过专业的运维配置好的，它默认开启了keep-alive，并不主动关闭连接

2. 连接池的使用与分析

首先先说下源码中关键的对象：

• Call: 对http的请求封装，属于程序员能够接触的上层高级代码
• Connection: 对jdk的socket物理连接的包装，它内部有List<WeakReference<StreamAllocation>>的引用
• StreamAllocation: 表示Connection被上层高级代码的引用次数
• ConnectionPool: Socket连接池，对连接缓存进行回收与管理，与CommonPool有类似的设计
• Deque: Deque也就是双端队列，双端队列同时具有队列和栈性质，经常在缓存中被使用，这个是java基础

在okhttp中，连接池对用户，甚至开发者都是透明的。它自动创建连接池，自动进行泄漏连接回收，自动帮你管理线程池，提供了put/get/clear的接口，甚至内部调用都帮你写好了。

在以前的内存泄露分析文章中我写到，我们知道在socket连接中，也就是Connection中，本质是封装好的流操作，除非手动close掉连接，基本不会被GC掉，非常容易引发内存泄露。所以当涉及到并发socket编程时，我们就会非常紧张，往往写出来的代码都是try/catch/finally的迷之缩进，却又对这样的代码无可奈何。

在okhttp中，在高层代码的调用中，使用了类似于引用计数的方式跟踪Socket流的调用，这里的计数对象是StreamAllocation，它被反复执行aquire与release操作(点击函数可以进入github查看)，这两个函数其实是在改变Connection中的List<WeakReference<StreamAllocation>>大小。List中Allocation的数量也就是物理socket被引用的计数（Refference Count），如果计数为0的话，说明此连接没有被使用，是空闲的，需要通过下文的算法实现回收；如果上层代码仍然引用，就不需要关闭连接。

引用计数法：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用。它不能处理循环引用的问题。

2.1. 实例化

在源码中，我们先找ConnectionPool实例化的位置，它是直接new出来的，而它的各种操作却在OkHttpClient的static区实现了Internal.instance接口作为ConnectionPool的包装。

至于为什么需要这么多此一举的分层包装，主要是为了让外部包的成员访问非public方法，详见这里注释

2.2. 构造

1. 连接池内部维护了一个叫做OkHttp ConnectionPool的ThreadPool，专门用来淘汰末位的socket，当满足以下条件时，就会进行末位淘汰，非常像GC

   1. 1. 并发socket空闲连接超过5个

   2. 2. 某个socket的keepalive时间大于5分钟

2. 维护着一个Deque<Connection>，提供get/put/remove等数据结构的功能

3. 维护着一个RouteDatabase，它用来记录连接失败的Route的黑名单，当连接失败的时候就会把失败的线路加进去（本文不讨论）

2.3 put/get操作

在连接池中，提供如下的操作，这里可以看成是对deque的一个简单的包装

1. //从连接池中获取

2. get

3. //放入连接池

4. put

5. //线程变成空闲，并调用清理线程池

6. connectionBecameIdle

7. //关闭所有连接

8. evictAll

随着上述操作被更高级的对象调用，Connection中的StreamAllocation被不断的aquire与release，也就是List<WeakReference<StreamAllocation>>的大小将时刻变化

2.4 Connection自动回收的实现

java内部有垃圾回收GC，okhttp有socket的回收；垃圾回收是根据对象的引用树实现的，而okhttp是根据RealConnection的虚引用StreamAllocation引用计数是否为0实现的。我们先看代码

cleanupRunnable:

当用户socket连接成功，向连接池中put新的socket时，回收函数会被主动调用，线程池就会执行cleanupRunnable，如下

1. //Socket清理的Runnable，每当put操作时，就会被主动调用

2. //注意put操作是在网络线程

3. //而Socket清理是在`OkHttp ConnectionPool`线程池中调用

4. while (true) {

5. //执行清理并返回下场需要清理的时间

6. long waitNanos = cleanup(System.nanoTime());

7. if (waitNanos == -1) return;

8. if (waitNanos > 0) {

9. synchronized (ConnectionPool.this) {

10. try {

11. //在timeout内释放锁与时间片

12. ConnectionPool.this.wait(TimeUnit.NANOSECONDS.toMillis(waitNanos));

13. } catch (InterruptedException ignored) {

14. }

15. }

16. }

17. }

这段死循环实际上是一个阻塞的清理任务，首先进行清理(clean)，并返回下次需要清理的间隔时间，然后调用wait(timeout)进行等待以释放锁与时间片，当等待时间到了后，再次进行清理，并返回下次要清理的间隔时间...

Cleanup:

cleanup使用了类似于GC的标记-清除算法，也就是首先标记出最不活跃的连接(我们可以叫做泄漏连接，或者空闲连接)，接着进行清除，流程如下:

1. long cleanup(long now) {

2. int inUseConnectionCount = 0;

3. int idleConnectionCount = 0;

4. RealConnection longestIdleConnection = null;

5. long longestIdleDurationNs = Long.MIN_VALUE;

6.  

7. //遍历`Deque`中所有的`RealConnection`，标记泄漏的连接

8. synchronized (this) {

9. for (RealConnection connection : connections) {

10. // 查询此连接内部StreamAllocation的引用数量

11. if (pruneAndGetAllocationCount(connection, now) > 0) {

12. inUseConnectionCount++;

13. continue;

14. }

15.  

16. idleConnectionCount++;

17.  

18. //选择排序法，标记出空闲连接

19. long idleDurationNs = now - connection.idleAtNanos;

20. if (idleDurationNs > longestIdleDurationNs) {

21. longestIdleDurationNs = idleDurationNs;

22. longestIdleConnection = connection;

23. }

24. }

25.  

26. if (longestIdleDurationNs >= this.keepAliveDurationNs

27. || idleConnectionCount > this.maxIdleConnections) {

28. //如果(`空闲socket连接超过5个`

29. //且`keepalive时间大于5分钟`)

30. //就将此泄漏连接从`Deque`中移除

31. connections.remove(longestIdleConnection);

32. } else if (idleConnectionCount > 0) {

33. //返回此连接即将到期的时间，供下次清理

34. //这里依据是在上文`connectionBecameIdle`中设定的计时

35. return keepAliveDurationNs - longestIdleDurationNs;

36. } else if (inUseConnectionCount > 0) {

37. //全部都是活跃的连接，5分钟后再次清理

38. return keepAliveDurationNs;

39. } else {

40. //没有任何连接，跳出循环

41. cleanupRunning = false;

42. return -1;

43. }

44. }

45.  

46. //关闭连接，返回`0`，也就是立刻再次清理

47. closeQuietly(longestIdleConnection.socket());

48. return 0;

49. }

太长不想看的话，就是如下的流程：

1. 遍历Deque中所有的RealConnection，标记泄漏的连接
2. 如果被标记的连接满足(空闲socket连接超过5个&&keepalive时间大于5分钟)，就将此连接从Deque中移除，并关闭连接，返回0，也就是将要执行wait(0)，提醒立刻再次扫描
3. 如果(目前还可以塞得下5个连接，但是有可能泄漏的连接(即空闲时间即将达到5分钟))，就返回此连接即将到期的剩余时间，供下次清理
4. 如果(全部都是活跃的连接)，就返回默认的keep-alive时间，也就是5分钟后再执行清理
5. 如果(没有任何连接)，就返回-1,跳出清理的死循环

再次注意：这里的“并发”==(“空闲”＋“活跃”)==5，而不是说并发连接就一定是活跃的连接

pruneAndGetAllocationCount:

如何标记并找到最不活跃的连接呢，这里使用了pruneAndGetAllocationCount的方法，它主要依据弱引用是否为null而判断这个连接是否泄漏

1. //类似于引用计数法，如果引用全部为空，返回立刻清理

2. private int pruneAndGetAllocationCount(RealConnection connection, long now) {

3. //虚引用列表

4. List<Reference<StreamAllocation>> references = connection.allocations;

5. //遍历弱引用列表

6. for (int i = 0; i < references.size(); ) {

7. Reference<StreamAllocation> reference = references.get(i);

8. //如果正在被使用，跳过，接着循环

9. //是否置空是在上文`connectionBecameIdle`的`release`控制的

10. if (reference.get() != null) {

11. //非常明显的引用计数

12. i++;

13. continue;

14. }

15.  

16. //否则移除引用

17. references.remove(i);

18. connection.noNewStreams = true;

19.  

20. //如果所有分配的流均没了，标记为已经距离现在空闲了5分钟

21. if (references.isEmpty()) {

22. connection.idleAtNanos = now - keepAliveDurationNs;

23. return 0;

24. }

25. }

26.  

27. return references.size();

28. }

1. 遍历RealConnection连接中的StreamAllocationList，它维护着一个弱引用列表
2. 查看此StreamAllocation是否为空(它是在线程池的put/remove手动控制的)，如果为空，说明已经没有代码引用这个对象了，需要在List中删除
3. 遍历结束，如果List中维护的StreamAllocation删空了，就返回0，表示这个连接已经没有代码引用了，是泄漏的连接;否则返回非0的值，表示这个仍然被引用，是活跃的连接。

上述实现的过于保守，实际上用filter就可以大致实现，伪代码如下

1. return references.stream().filter(reference -> {

2. return !reference.get() == null;

3. }).count();

总结

通过上面的分析，我们可以总结，okhttp使用了类似于引用计数法与标记擦除法的混合使用，当连接空闲或者释放时，StreamAllocation的数量会渐渐变成0，从而被线程池监测到并回收，这样就可以保持多个健康的keep-alive连接，Okhttp的黑科技就是这样实现的。

最后推荐一本《图解HTTP》，日本人写的，看起来很不错。

再推荐阅读开源Redis客户端Jedis的源码，可以看下它的JedisFactory的实现。

如果你期待更多高质量的文章，不妨关注我或者点赞吧！

Ref

1. https://www.nginx.com/blog/http-keepalives-and-web-performance/