Okhttp的源码分析
Okhttp的线程池和高并发
Okhttp链接池的使用
Okhttp的缓存机制
Okhttp的责任链模式
链接池的使用:
建议安装目录插件食用
我们都知道,http基于tcp,每次通信都需要通过三握手建立连接,然而在高并发的情况下,连接的频繁建立和释放会使得性能低下。因此,出现了keep-alive机制,即在数据传输完毕的一定时间(timeout)内,继续持有连接(keep-alive)。
- 目的:减少创建tcp链接的次数,
- 方法:在一定时间内(timeout),保证链接keepalive,从而复用
- 重要的结构体解析
- connections : connection 缓存池,类似于上篇博文的线程池。用Deque 实现,是一个双端列表,支持在头尾插入元素,
- excutor : 线程池,用来检测闲置socket并对其进行清理。
- RealConnection:Connection的实现类代表着一条经过了三次握手了的链接(其中又包含了多个流)
- StreamAllocation 作用:为一次"请求"寻找"连接"并建立"流"
- 请求:也就是我们使用的时候调用的Call
- 链接:即RealConnection,也就是一个socket
- 流:http发展过程中应用的多路复用技术,如果有多个流都是连接在一个host和port上,那么它们就可以共同使用同一个socket链接,这样做的好处就是可以减少TCP三次握手的时间
-
类比
连接池也就是链接的复用,可以比作成《超人总动员中》冰冻超人Frozone的滑道。
当他想要从起点到达终点的时候,会建立一条滑道(RealConnection)),滑道会因温差而融化,但显然每次都从新创建会消耗很多资源,于是其更新技术,让滑道能够保持一段时间。其中每条滑道又分为了不同的干道,类似我们的公路。一条路上可以并行跑好多车辆,也就是链接中的流。
源码解析:
源码位于RealConnectionPool中,可以自行ctrl shift F 进去。现在的版本利用Kotlin实现,同样的下载3.8.0
-
put :将新的connection 放进列表并 执行清理闲置连接的线程(第三部分详细解析)
fun put(connection: RealConnection) { connection.assertThreadHoldsLock() connections.add(connection) cleanupQueue.schedule(cleanupTask)//执行清理闲置连接的线程 }
-
get,创建connection对象,遍历缓存池,如果满足条件,就中缓存池中取出该连接,返回给request。
@Nullable RealConnection get(Address address, StreamAllocation streamAllocation, Route route) { assert (Thread.holdsLock(this)); for (RealConnection connection : connections) { if (connection.isEligible(address, route)) { streamAllocation.acquire(connection); return connection; } } return null; } //acquire跟踪进去为: reportedAcquired设置为true, 并向connection持有的allocations中增加了一条新的流的弱引用 也就是往这条连接中增加了一条流。
而其中的条件为isEligible,跟踪进去可以看到,具体的条件为
- 当前这次连接的最大并发数没有达到上限
- 两个address的其他参数相同
- 两个address的url的host相同
若满足以上条件,则说明host是相同的可以直接复用,如果不满足以上条件的话,仍旧有机会使用连接(将连接合并):
- 首先这个连接需要使用HTTP/2
- 要与复用前的Ip address相同,且不能使用代理
- 这个连接的服务器证书授权中,必须包括新的主机。
- 锁定证书(certificatePinner)必须匹配主机
public boolean isEligible(Address address, @Nullable Route route) { // If this connection is not accepting new streams, we're done. if (allocations.size() >= allocationLimit || noNewStreams) return false; // If the non-host fields of the address don't overlap, we're done. if (!Internal.instance.equalsNonHost(this.route.address(), address)) return false; // If the host exactly matches, we're done: this connection can carry the address. if (address.url().host().equals(this.route().address().url().host())) { return true; // This connection is a perfect match. } // At this point we don't have a hostname match. But we still be able to carry the request if // our connection coalescing requirements are met. See also: // https://hpbn.co/optimizing-application-delivery/#eliminate-domain-sharding // https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ // 1. This connection must be HTTP/2. if (http2Connection == null) return false; // 2. The routes must share an IP address. This requires us to have a DNS address for both // hosts, which only happens after route planning. We can't coalesce connections that use a // proxy, since proxies don't tell us the origin server's IP address. if (route == null) return false; if (route.proxy().type() != Proxy.Type.DIRECT) return false; if (this.route.proxy().type() != Proxy.Type.DIRECT) return false; if (!this.route.socketAddress().equals(route.socketAddress())) return false; // 3. This connection's server certificate's must cover the new host. if (route.address().hostnameVerifier() != OkHostnameVerifier.INSTANCE) return false; if (!supportsUrl(address.url())) return false; // 4. Certificate pinning must match the host. try { address.certificatePinner().check(address.url().host(), handshake().peerCertificates()); } catch (SSLPeerUnverifiedException e) { return false; } return true; // The caller's address can be carried by this connection. }
-
连接池的清理和回收
在put方法中已经用过了连接池的清理和回收 executor.execute(cleanupRunnable);现在变来详细看下其所做的事情:跟踪进入cleanupRunnable,发现其逻辑为定时执行cleanup,其中的定时等待是加入了同步锁,不允许打断。
private final Runnable cleanupRunnable = new Runnable() { @Override public void run() { while (true) { long waitNanos = cleanup(System.nanoTime()); if (waitNanos == -1) return; if (waitNanos > 0) { long waitMillis = waitNanos / 1000000L; waitNanos -= (waitMillis * 1000000L); synchronized (ConnectionPool.this) { try { ConnectionPool.this.wait(waitMillis, (int) waitNanos); } catch (InterruptedException ignored) { } } } } } };
下面聚焦的重点clean up之中。总的来说他的作用是找到限制的链接并清理,具体分析可以发现:
- 其通过inUseConnectionCount记录正在使用的链接数目,利用idleConnectionCount记录闲置的链接数。这两个链接数目的改变,都是通过pruneAndGetAllocationCount()方法控制的,起作用也就自然而然为判断传入的链接是闲置的还是运行的。
- 程序又根据闲置时间对connection 选择了一个限制时间最长的链接,如果其大于keep_alive的极限时间(keepAliveDurationNs 5分钟),或者空闲链接个数大于连接池的最大值(maxIdleConnections5个),则移除该connection
long cleanup(long now) { int inUseConnectionCount = 0; int idleConnectionCount = 0; RealConnection longestIdleConnection = null; long longestIdleDurationNs = Long.MIN_VALUE; // Find either a connection to evict, or the time that the next eviction is due. synchronized (this) { for (Iterator
i = connections.iterator(); i.hasNext(); ) { RealConnection connection = i.next(); // If the connection is in use, keep searching. if (pruneAndGetAllocationCount(connection, now) > 0) { inUseConnectionCount++; continue; } idleConnectionCount++; // If the connection is ready to be evicted, we're done. long idleDurationNs = now - connection.idleAtNanos; if (idleDurationNs > longestIdleDurationNs) { longestIdleDurationNs = idleDurationNs; longestIdleConnection = connection; } } if (longestIdleDurationNs >= this.keepAliveDurationNs || idleConnectionCount > this.maxIdleConnections) { // We've found a connection to evict. Remove it from the list, then close it below (outside // of the synchronized block). connections.remove(longestIdleConnection); } else if (idleConnectionCount > 0) { // A connection will be ready to evict soon. return keepAliveDurationNs - longestIdleDurationNs; } else if (inUseConnectionCount > 0) { // All connections are in use. It'll be at least the keep alive duration 'til we run again. return keepAliveDurationNs; } else { // No connections, idle or in use. cleanupRunning = false; return -1; } } closeQuietly(longestIdleConnection.socket()); // Cleanup again immediately. return 0; } 跟踪进去,发现其是通过维护Reference
类型的链表(references)达到效果的。起作用为记录connection 活跃情况的(>0 表示活跃=0 表示空闲) 整体逻辑的核心为:如果 StreamAlloction 引用空闲,但是connection的引用列表中仍旧存在该项,那么便发生了内存泄露
//用于清理可能泄露的 StreamAllocation并返回正在使用此连接的StreamA1location的数量, private int pruneAndGetAllocationCount(RealConnection connection, long now) { List
> references = connection.allocations; for (int i = 0; i < references.size(); ) { Reference reference = references.get(i); if (reference.get() != null) { i++; continue; } //表示该流活跃 // We've discovered a leaked allocation. This is an application bug. StreamAllocation.StreamAllocationReference streamAllocRef = (StreamAllocation.StreamAllocationReference) reference; String message = "A connection to " + connection.route().address().url() + " was leaked. Did you forget to close a response body?"; Platform.get().logCloseableLeak(message, streamAllocRef.callStackTrace); references.remove(i); connection.noNewStreams = true; // If this was the last allocation, the connection is eligible for immediate eviction. if (references.isEmpty()) { connection.idleAtNanos = now - keepAliveDurationNs; return 0; } } return references.size(); }
总结
链接池的使用重点为三个方法,用通俗的语言来讲:
put为将用完的链接放入到连接池中去,在放入的过程中检查连接池中是否有过期的待被清理。
get为从连接池中取出链接复用,通俗的来讲,其需要满足线路起点重点相同,线路不能过度拥挤,否则不允许从连接池中复用
cleanup 为从链接池中找过期了的道路,寻找的方法为看那一条道路最长时间没有被使用。在寻找的过程中,可能有些道路上的干道记录错误(内存泄露),于是便在寻找的过程中将其修复。