Okhttp框架总结(1)

okhttp 整个网络请求的流程图：

OkHttp的拦截器有5种：RetryAndFollowUpInterceptor、BridgeInterceptor、CacheInterceptor、ConnectInterceptor、CallServerInterceptor。他们之间采用的是责任链模式，每一个拦截器里面链接着下一个拦截器，固定了处理的顺序。

各个拦截器的功能如下：

RetryAndFollowUpInterceptor：重试和请求失败后重定向拦截器。主要作用是初始化拦截器数据的工作，创建StreamAllocation对象。
BridgeInterceptor：桥接和适配拦截器，补充用户创建使用过程中缺少的OkHttp请求头。
CacheInterceptor：处理缓存的一些功能。交出之前读取并判断是否使用缓存，获得结果后判断是否缓存。
ConnectInterceptor：核心拦截器之一，网络交互的关键。他是CallServerInterceptor拦截器的基础，主要负责建立可用的网络连接。
CallServerInterceptor：核心拦截器之二，网络交互的关键。主要负责将网络请求写进网络IO流中，并从网络IO流中读取服务端返回给我们的数据。
提高网络性能优化，很重要的一点就是降低延迟和提升响应速度。

通常我们在浏览器中发起请求的时候header部分往往是这样的

keep-alive 就是浏览器和服务端之间保持长连接，这个连接是可以复用的。在HTTP1.1中是默认开启的。

连接的复用为什么会提高性能呢？
通常我们在发起http请求的时候首先要完成tcp的三次握手，然后传输数据，最后再释放连接。三次握手的过程可以参考这里 TCP三次握手详解及释放连接过程

一次响应的过程

在高并发的请求连接情况下或者同个客户端多次频繁的请求操作，无限制的创建会导致性能低下。

如果使用keep-alive

在timeout空闲时间内，连接不会关闭，相同重复的request将复用原先的connection，减少握手的次数，大幅提高效率。

并非keep-alive的timeout设置时间越长，就越能提升性能。长久不关闭会造成过多的僵尸连接和泄露连接出现。

那么okttp在客户端是如果类似于客户端做到的keep-alive的机制。

2、连接池的使用
连接池的类位于okhttp3.ConnectionPool。我们的主旨是了解到如何在timeout时间内复用connection，并且有效的对其进行回收清理操作。

其成员变量代码片

/**

• Background threads are used to cleanup expired connections. There will be at most a single
• thread running per connection pool. The thread pool executor permits the pool itself to be
• garbage collected.
  /
  private static final Executor executor = new ThreadPoolExecutor(0 / corePoolSize /,
  Integer.MAX_VALUE / maximumPoolSize /, 60L / keepAliveTime */, TimeUnit.SECONDS,
  new SynchronousQueue(), Util.threadFactory(“OkHttp ConnectionPool”, true));

/** The maximum number of idle connections for each address. */
private final int maxIdleConnections;

private final Deque connections = new ArrayDeque<>();
final RouteDatabase routeDatabase = new RouteDatabase();
boolean cleanupRunning;

excutor : 线程池，用来检测闲置socket并对其进行清理。
connections : connection缓存池。Deque是一个双端列表，支持在头尾插入元素，这里用作LIFO（后进先出）堆栈，多用于缓存数据。
routeDatabase ：用来记录连接失败router

2.1 缓存操作

ConnectionPool提供对Deque进行操作的方法分别为put、get、connectionBecameIdle、evictAll几个操作。分别对应放入连接、获取连接、移除连接、移除所有连接操作。

put操作

void put(RealConnection connection) {
assert (Thread.holdsLock(this));
if (!cleanupRunning) {
cleanupRunning = true;
executor.execute(cleanupRunnable);
}
connections.add(connection);
}

可以看到在新的connection 放进列表之前执行清理闲置连接的线程。

既然是复用，那么看下他获取连接的方式。

/** Returns a recycled connection to {@code address}, or null if no such connection exists. */
RealConnection get(Address address, StreamAllocation streamAllocation) {
assert (Thread.holdsLock(this));
for (RealConnection connection : connections) {
if (connection.allocations.size() < connection.allocationLimit
&& address.equals(connection.route().address)
&& !connection.noNewStreams) {
streamAllocation.acquire(connection);
return connection;
}
}
return null;
}

遍历connections缓存列表，当某个连接计数的次数小于限制的大小以及request的地址和缓存列表中此连接的地址完全匹配。则直接复用缓存列表中的connection作为request的连接。

streamAllocation.allocations是个对象计数器，其本质是一个 List<Reference> 存放在RealConnection连接对象中用于记录Connection的活跃情况。

连接池中Connection的缓存比较简单，就是利用一个双端列表，配合CRD等操作。那么connection在timeout时间类是如果失效的呢，并且如果做到有效的对连接进行清除操作以确保性能和内存空间的充足。

2.2 连接池的清理和回收

在看ConnectionPool的成员变量的时候我们了解到一个Executor的线程池是用来清理闲置的连接的。注释中是这么解释的：

Background threads are used to cleanup expired connections

我们在put新连接到队列的时候会先执行清理闲置连接的线程。调用的正是 executor.execute(cleanupRunnable); 方法。观察cleanupRunnable

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) {
}
}
}
}
}
};

线程中不停调用Cleanup 清理的动作并立即返回下次清理的间隔时间。继而进入wait 等待之后释放锁，继续执行下一次的清理。所以可能理解成他是个监测时间并释放连接的后台线程。

了解cleanup动作的过程。这里就是如何清理所谓闲置连接的和行了。怎么找到闲置的连接是主要解决的问题。

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;

}

在遍历缓存列表的过程中，使用连接数目inUseConnectionCount 和闲置连接数目idleConnectionCount 的计数累加值都是通过pruneAndGetAllocationCount() 是否大于0来控制的。那么很显然pruneAndGetAllocationCount() 方法就是用来识别对应连接是否闲置的。>0则不闲置。否则就是闲置的连接。

进去观察

private int pruneAndGetAllocationCount(RealConnection connection, long now) {
List<Reference> 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.
  Platform.get().log(WARN, "A connection to " + connection.route().address().url()
      + " was leaked. Did you forget to close a response body?", null);
  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();

}
}

好了，原先存放在RealConnection 中的allocations 派上用场了。遍历StreamAllocation 弱引用链表，移除为空的引用，遍历结束后返回链表中弱引用的数量。所以可以看出List<Reference> 就是一个记录connection活跃情况的 >0表示活跃 =0 表示空闲。StreamAllocation 在列表中的数量就是就是物理socket被引用的次数

解释：StreamAllocation被高层反复执行aquire与release。这两个函数在执行过程中其实是在一直在改变Connection中的 List<WeakReference>大小。

搞定了查找闲置的connection操作，我们回到cleanup 的操作。计算了inUseConnectionCount和idleConnectionCount 之后程序又根据闲置时间对connection进行了一个选择排序，选择排序的核心是：

// If the connection is ready to be evicted, we’re done.
long idleDurationNs = now - connection.idleAtNanos;
if (idleDurationNs > longestIdleDurationNs) {
longestIdleDurationNs = idleDurationNs;
longestIdleConnection = connection;
}
}
…

通过对比最大闲置时间选择排序可以方便的查找出闲置时间最长的一个connection。如此一来我们就可以移除这个没用的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);
}

总结：清理闲置连接的核心主要是引用计数器List<Reference> 和 选择排序的算法以及excutor的清理线程池。