链接池的使用：

我们都知道，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<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类型的链表（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 为从链接池中找过期了的道路，寻找的方法为看那一条道路最长时间没有被使用。在寻找的过程中，可能有些道路上的干道记录错误（内存泄露），于是便在寻找的过程中将其修复。

Okhttp链接池的使用

链接池的使用：

源码解析：

总结