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的滑道。

      Mr. Fronzone
      
      

      当他想要从起点到达终点的时候，会建立一条滑道（RealConnection）），滑道会因温差而融化，但显然每次都从新创建会消耗很多资源，于是其更新技术，让滑道能够保持一段时间。其中每条滑道又分为了不同的干道，类似我们的公路。一条路上可以并行跑好多车辆,也就是链接中的流。

      
      
      公路

源码解析：

源码位于RealConnectionPool中，可以自行ctrl shift F 进去。现在的版本利用Kotlin实现，同样的下载3.8.0

1. put ：将新的connection 放进列表并 执行清理闲置连接的线程(第三部分详细解析)

   fun put(connection: RealConnection) {
     connection.assertThreadHoldsLock()
   
     connections.add(connection)
     cleanupQueue.schedule(cleanupTask)//执行清理闲置连接的线程
   }
   
   

2. 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，跟踪进去可以看到，具体的条件为

   1. 当前这次连接的最大并发数没有达到上限
   2. 两个address的其他参数相同
   3. 两个address的url的host相同

   若满足以上条件，则说明host是相同的可以直接复用，如果不满足以上条件的话，仍旧有机会使用连接（将连接合并）：

   1. 首先这个连接需要使用HTTP/2
   2. 要与复用前的Ip address相同，且不能使用代理
   3. 这个连接的服务器证书授权中，必须包括新的主机。
   4. 锁定证书（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.
   }
   

3. 连接池的清理和回收

   在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<RealConnection> 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<StreamAllocation>类型的链表（references）达到效果的。起作用为记录connection 活跃情况的（>0 表示活跃=0 表示空闲)

   整体逻辑的核心为：如果 StreamAlloction 引用空闲,但是connection的引用列表中仍旧存在该项，那么便发生了内存泄露

   //用于清理可能泄露的 StreamAllocation并返回正在使用此连接的StreamA1location的数量,
   private int pruneAndGetAllocationCount(RealConnection connection, long now) {
     List<Reference<StreamAllocation>> references = connection.allocations;
     for (int i = 0; i < references.size(); ) {
       Reference<StreamAllocation> 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 为从链接池中找过期了的道路，寻找的方法为看那一条道路最长时间没有被使用。在寻找的过程中，可能有些道路上的干道记录错误（内存泄露），于是便在寻找的过程中将其修复。