源码解析OkHttp

请求处理

我们请求网络的时候需要OkHttpClient.newCall(request)进行execute或者enqueue操作;当调用newCall方法时，会调用如下代码：

  @Override public Call newCall(Request request) {
    return new RealCall(this, request, false /* for web socket */);
  }

实际上，返回的是newCall类，然后追踪newCall的enqueue方法。

  @Override public void enqueue(Callback responseCallback) {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    captureCallStackTrace();
    client.dispatcher().enqueue(new AsyncCall(responseCallback));
  }

可以看见，最终调用了dispacher()的enqueue方法，对dispacher进行追踪。

Dispacher任务调度

Dispacher主要用于控制并发的请求，主要维护了最大并发请求，最大请求数，消费者线程，将要运行的异步请求队列，正在运行的异步请求队列，正在运行的同步请求队列等。

先看Dispacher的构造方法：

  public Dispatcher(ExecutorService executorService) {
    this.executorService = executorService;
  }

  public Dispatcher() {
  }

  public synchronized ExecutorService executorService() {
    if (executorService == null) {
      executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
          new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
    }
    return executorService;
  }

构造方法主要用于传递线程池，我们可以自己实现线程池，也可以使用默认的线程池，默认线程池适合处理大量的耗时较短的任务。

然后来看enqueue方法：

  synchronized void enqueue(AsyncCall call) {
    if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
      runningAsyncCalls.add(call);
      executorService().execute(call);
    } else {
      readyAsyncCalls.add(call);
    }
  }

如果请求的数量小于maxRequests，请求的主机数小于maxRequestsPerHost时，就会把它添加到runningAsyncCalls中，并在线程池中执行。否则就加入readyAsyncCalls中进行缓存等待。注意传入的call是AsyncCall，是RealCall的内部类，内部实现了execute方法，其中片段如下：

finally {
        client.dispatcher().finished(this);
      }

execute方法一定会调用finished方法，追踪finished方法：

  private <T> void finished(Deque<T> calls, T call, boolean promoteCalls) {
    int runningCallsCount;
    Runnable idleCallback;
    synchronized (this) {
      if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");
      if (promoteCalls) promoteCalls();
      runningCallsCount = runningCallsCount();
      idleCallback = this.idleCallback;
    }

最终调用了promoteCalls，追踪promoteCalls：

    if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity.
    if (readyAsyncCalls.isEmpty()) return; // No ready calls to promote.

    for (Iterator<AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) {
      AsyncCall call = i.next();

      if (runningCallsForHost(call) < maxRequestsPerHost) {
        i.remove();
        runningAsyncCalls.add(call);
        executorService().execute(call);
      }

根据注解可以看出核心逻辑就是当缓存中存在call要处理，并且线程池没有满的话，把缓存的call拿出来交给线程池执行。

然后再看AsyncCall,其中片段如下：

 Response response = getResponseWithInterceptorChain();

看方法名得知请求网络并通过拦截器链得到一个response。

Interceptor拦截器

追踪getRequestWithInterceptorChain方法：

    Interceptor.Chain chain = new RealInterceptorChain(
        interceptors, null, null, null, 0, originalRequest);
    return chain.proceed(originalRequest);

创建了一个RealInterceptorChain拦截器链，执行了proceed方法。其中代码片段如下：

    // Call the next interceptor in the chain.
    RealInterceptorChain next = new RealInterceptorChain(
        interceptors, streamAllocation, httpCodec, connection, index + 1, request);
    Interceptor interceptor = interceptors.get(index);
    Response response = interceptor.intercept(next);

拦截器会拦截请求，实现监控，重写，重试调用的机制，通常用来添加，移出，修改头部信息。

缓存策略

cacheCandidate是一个可以读取缓存Header的Response,根据cacheStrategy的处理得到了networkRequest和cacheResponse两个值，两者都为空那么，返回504错误，当networkRequest为null时，也就是不进行网络请求，如果缓存可以直接使用直接返回缓存，如果其他情况那么请求网络。

在readResponse方法中，主要用来解析HTTP相应报头，如果有缓存可用，那么用缓存的数据并更新缓存，否则就用网络请求返回的数据。再看validate方法是如何判断缓存是否可用的。在validate中如果服务器返回304，那么缓存有效，然后根据响应中的last-modified来计算是否是最新数据，如果是，那么缓存有效。

失败重连

当发生IOException和RouteException时，都会执行HttpEngine的recover方法。片段如下：

return new HttpEngine(client, userRequest, bufferRequestBody, callerWritesRequestBody,
        forWebSocket, streamAllocation, (RetryableSink) requestBodyOut, priorResponse);

实际上就是重新创建了HttpEngine并返回。

复用连接池

为了解决TCP握手和挥手的效率问题，HTTP有一种叫keepalive connections的机制，连接池的主要变量如下：

  private static final Executor executor = new ThreadPoolExecutor(0 /* corePoolSize */,
      Integer.MAX_VALUE /* maximumPoolSize */, 60L /* keepAliveTime */, TimeUnit.SECONDS,
      new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp ConnectionPool", true));

  /** The maximum number of idle connections for each address. */
  private final int maxIdleConnections;
  private final long keepAliveDurationNs;
  private final Deque<RealConnection> connections = new ArrayDeque<>();
  final RouteDatabase routeDatabase = new RouteDatabase();

首先有一个线程池，类似于CachedThreadPool,使用了没有容量的SynchronousQueue.Dequeue是一个双向队列，同时具有队列和栈的性质，里面维护了socket的包装RealConnection。RouteDatabase，用来记录连接失败的路线的名单，连接失败时会把失败路线加进去。

然后看Connection的构造方法，默认空闲的最大连接数为5个，socket的keepAlive时间为5分钟。ConnectionPool是在OkHttpClient实例化的时候创建的。

缓存操作

Connection提供对Dequeue的操作的方法分别为put,get,connectionBecameIdle和evictAll这几个操作，分别对应放入连接，获取连接，移出连接和移出所有连接。

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

在添加到Dequeue之前需要清理空闲的线程。然后看get操作：

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

遍历缓存中的所有连接，当连接计数的次数小于限制的大小，并且request地址和缓存列表中连接的地址相同时，直接复用列表中的connection作为request的连接。

自动回收

OkHttp是根据StreamAllocation引用计数是否为0来实现自动回收连接的，我们在put操作时首先调用executor.execute(cleanRunnable)来清理闲置的线程。

  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方法来清理，然后返回一个等待时间，在等待时间到之后再次进行清理，不断循环。然后跟踪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;
      }
      }

首先根据pruneAndGetAllocationCount方法判断连接是否空闲，如果在使用中，那么继续去找，否则，那么空闲的连接数加1。先找到空闲线程中时间最长的线程并记录，如果最长的空闲时间大于5分钟，或者空闲的线程数大于5个，那么移出这个线程。如果空闲线程数大于0，那么返回这个线程的剩余时间，如果都是活跃线程，那么返回默认的时间5分钟，如果没有任何连接，那么返回-1。

那么pruneAndGetAllocationCount如何判断线程是否空闲，如下：

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.
      Internal.logger.warning("A connection to " + connection.route().address().url()
          + " was leaked. Did you forget to close a response body?");
      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;
      }
    }

首先遍历StreamAllocation列表，如果StreamAllocation不为空，那么遍历下一个。如果为空，那么从列表中移除，直到列表为空，那么说明连接没有被引用，那么返回0。

引用计数

OkHttp的高层代码调用中，使用类似引用计数的方法来跟踪socket流的调用，计数对象是StreamAllocation,反复执行acquire和release操作，改变StreamAllocation列表的大小，StreamAllocation数量就是socket被引用的数目。