okHttp分发器

1、okHttp使用

通过 OkHttpClient.Builder().build()得到client对象，调用newCall()方法得到用来请求网络的对象RealCall
RealCall通过分发器和拦截器实现真正的网络请求

2、分发器

Dispatcher，就是来调配请求任务的，内部包含一个线程池。可以在创建okhttpClient对象时，传递我们自己定义的线程池来创建分发器。Dispatcher中的成员有

// 异步请求同时存在的最大请求数
var maxRequests = 64
// 异步请求同一域名同时存在的最大请求数
var maxRequestsPerHost = 5
// 异步请求使用的线程池
private var executorServiceOrNull: ExecutorService
// 异步请求等待执行队列
private val readyAsyncCalls = ArrayDeque()
// 异步请求正在执行队列
private val runningAsyncCalls = ArrayDeque()
// 同步请求正在执行队列
private val runningSyncCalls = ArrayDeque()

异步请求enqueue：

  internal fun enqueue(call: AsyncCall) {
    synchronized(this) {
      readyAsyncCalls.add(call)

      // Mutate the AsyncCall so that it shares the AtomicInteger of an existing running call to
      // the same host.
      if (!call.call.forWebSocket) {
        val existingCall = findExistingCallWithHost(call.host)
        if (existingCall != null) call.reuseCallsPerHostFrom(existingCall)
      }
    }
    promoteAndExecute()
  }

  private fun promoteAndExecute(): Boolean {
    this.assertThreadDoesntHoldLock()

    val executableCalls = mutableListOf()
    val isRunning: Boolean
    synchronized(this) {
      val i = readyAsyncCalls.iterator()
      while (i.hasNext()) {
        val asyncCall = i.next()
        // 判断正在执行的队列是否小于65
        if (runningAsyncCalls.size >= this.maxRequests) break // Max capacity.
        if (asyncCall.callsPerHost.get() >= this.maxRequestsPerHost) continue // Host max capacity.

        i.remove()
        asyncCall.callsPerHost.incrementAndGet()
        executableCalls.add(asyncCall)
        runningAsyncCalls.add(asyncCall)
      }
      isRunning = runningCallsCount() > 0
    }

    for (i in 0 until executableCalls.size) {
      val asyncCall = executableCalls[i]
      asyncCall.executeOn(executorService)
    }

    return isRunning
  }

以上代码是异步请求时遍历等待执行的队列，如果正在执行请求的队列小于64，并且同一主机的请求小于5从等待队列移除，放入正在执行的队列。并且全部放入线程池中。
AsyncCall是一个Runnable对象，再放入线程池过程中放生异常会执行dispatcher的finished方法，在run方法中调用getResponseWithInterceptorChain()进行网络请求，并且在try{}catch{}代码块finally中执行dispatcher的finished方法。

 private fun  finished(calls: Deque, call: T) {
    val idleCallback: Runnable?
    synchronized(this) {
      if (!calls.remove(call)) throw AssertionError("Call wasn't in-flight!")
      idleCallback = this.idleCallback
    }

    val isRunning = promoteAndExecute()

    if (!isRunning && idleCallback != null) {
      idleCallback.run()
    }
  }

可以看出又调用了promoteAndExecute()方法执行以上代码逻辑

同步请求

因为同步请求不需要线程池，也不存在任何限制。所以分发器仅做一下记录。

  override fun execute(): Response {
    check(executed.compareAndSet(false, true)) { "Already Executed" }

    timeout.enter()
    callStart()
    try {
      client.dispatcher.executed(this)
      return getResponseWithInterceptorChain()
    } finally {
      client.dispatcher.finished(this)
    }
  }

分发线程池

前面我们提过，分发器就是来调配请求任务的，内部会包含一个线程池。当异步请求时，会将请求任务交给线程池来执行。那分发器中默认的线程池是如何定义的呢？

 executorServiceOrNull = ThreadPoolExecutor(0, Int.MAX_VALUE, 60, TimeUnit.SECONDS,
            SynchronousQueue(), threadFactory("$okHttpName Dispatcher", false))

在OkHttp的分发器中的线程池定义如上，其实就和 Executors.newCachedThreadPool() 创建的线程一样。首先核
心线程为0，表示线程池不会一直为我们缓存线程，线程池中所有线程都是在60s内没有工作就会被回收。而最大线
程 Integer.MAX_VALUE 与等待队列 SynchronousQueue 的组合能够得到最大的吞吐量。即当需要线程池执行任务
时，如果不存在空闲线程不需要等待，马上新建线程执行任务！等待队列的不同指定了线程池的不同排队机制。一般来说，等待队列 BlockingQueue 有： ArrayBlockingQueue 、 LinkedBlockingQueue 与 SynchronousQueue 。
假设向线程池提交任务时，核心线程都被占用的情况下：
ArrayBlockingQueue ：基于数组的阻塞队列，初始化需要指定固定大小。
当使用此队列时，向线程池提交任务，会首先加入到等待队列中，当等待队列满了之后，再次提交任务，尝试加入队列就会失败，这时就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任务。所以最终可能出现后提交的任务先执行，而先提交的任务一直在等待。
LinkedBlockingQueue ：基于链表实现的阻塞队列，初始化可以指定大小，也可以不指定。
当指定大小后，行为就和ArrayBlockingQueu 一致。而如果未指定大小，则会使用默认的 Integer.MAX_VALUE 作为队列大小。这时候就会出现线程池的最大线程数参数无用，因为无论如何，向线程池提交任务加入等待队列都会成功。最终意味着所有任务都是在核心线程执行。如果核心线程一直被占，那就一直等待。
SynchronousQueue : 无容量的队列。
使用此队列意味着希望获得最大并发量。
因为无论如何，向线程池提交任务，往队列提交任务都会失败。而失败后
如果没有空闲的非核心线程，就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任
务。完全没有任何等待，唯一制约它的就是最大线程数的个数。因此一般配合 Integer.MAX_VALUE 就实现了真正的无等待。

但是需要注意的时，我们都知道，进程的内存是存在限制的，而每一个线程都需要分配一定的内存。所以线程并不
能无限个数。那么当设置最大线程数为 Integer.MAX_VALUE 时，OkHttp同时还有最大请求任务执行个数: 64的限
制。这样即解决了这个问题同时也能获得最大吞吐。