5.OkHttp请求调度的分析

5.OkHttp请求调度的分析

大工程搞完了，，咱们接着来抠细节，聊一聊OkHttp的连接池管理和任务队列管理

连接池

OkHttp的链接迟相关的类是

ConnectionPool

StreamAllocation

如果这边眼生的朋友请看之前的文章； StreamAllocation里面有个ConnectionPool的引用，SteamAllocation是协调connection,strams,calls 三者之间的关系的，我们按照之前的顺序来看StreamAllocation具体和ConnectionPool之间有着什么不可描述的事情。

SteamAllocation在ConnectionInterceptor里面的调用的方法如下：

java

//获取HttpCodec

HttpCodec httpCodec = streamAllocation.newStream(client, doExtensiveHealthChecks);

//开始连接

RealConnection connection = streamAllocation.connection();

然后对比到SteamAllocation里面 ，他调用 findHealthyConnection —>findConnection—>Internal.instance.get(connectionPool, address, this, null);

Internal 是在okHttpClient里面的静态域里面初始化的，他的get的具体就是调用connectionPool的get方法，我们直接找ConnectionPool.get(address, streamAllocation, route),这个方法是找在池里面背回来的链接，如果没有的话返回null，再到下面进行初始化，直接new RealConnection(connectionPool, selectedRoute);创建了一个连接，然后添加计数，添加计数就是在RealConnection里面的

public final List<Reference<StreamAllocation>> allocations = new ArrayList<>();

新增一个WeakReference \

上述系列操作完之后就是一个RealConnection诞生了， 然连接上Socket，把当前的链接放到ConnectionPool里，调用的也是Internal.instance.put—>ConnectionPool.put>,把RealConnection传递过去，他的put操作：

“““java

void put(RealConnection connection) {

assert (Thread.holdsLock(this));

//如果清除空闲链接的线程没启动的话启动清除空闲链接

if (!cleanupRunning) {

cleanupRunning = true;

executor.execute(cleanupRunnable);

}

//添加链接到connections

connections.add(connection);

}

“““

他的清理线程的工作就是一个while（true）的循环：

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);// waitMillis = 300 000
synchronized (ConnectionPool.this) {
try {
ConnectionPool.this.wait(waitMillis, (int) waitNanos);
} catch (InterruptedException ignored) {
}
}
}
}
}
};

可以看出是不是要等待全靠cleanup （为啥我想到了4396.。。）

java

在此池上执行维护，如果超过了保持活动限制或空闲连接限制，则会逐渐消除空闲时间最长的连接 返回以纳秒为单位的睡眠持续时间，直到下一次调用此方法。 如果不需要进一步的清理，则返回-1。

可以看到，okhttp的辣鸡回收就在这个方法里，方法就在ConnectionPool里有兴趣的同学可以去看一下，这里我直接说个比较关键的地方：

他会判断链接是否在使用中，判断的依据就是WeakReference是否为空（mmp，没想到吧）如果为空的话就remove掉,把RealConnection的noNewStreams设置为true,这种方式依赖虚拟机的GC

整个流程如下图所示

任务队列

说完连接池，，我们接着说他的任务队列，这个任务队列存在的场景是在调用enqueue里面的，相关的类是：

Dispatcher

每个

OkHttpClient

只有一个任务队列，是在OkHttpClient里面初始化的，在RealCall里面代用的时候会把这个AsyncCall添加到Dispatcher里面

java

@Override

public void enqueue(Callback responseCallback) {

synchronized (this) {

if (executed) throw new IllegalStateException("Already Executed");

executed = true;

}

captureCallStackTrace();

client.dispatcher().enqueue(new AsyncCall(responseCallback));

}

我们跑进去看看enqueue的源码

java

public final class Dispatcher {

synchronized void enqueue(AsyncCall call) {

if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) <    maxRequestsPerHost) {

runningAsyncCalls.add(call);

executorService().execute(call);

} else {

readyAsyncCalls.add(call);

}

}

}

看这个方法 判断的条件是：

当前运行的集合大小小宇最大请求数量，

当前运行的这个Host请求的数量小于最大Host的请求量

这边都是利用Deque来实现的，之前的文章有讲到过：

deque 即双端队列。是一种具有队列和栈的性质的数据结构。双端队列中的元素可以从两端弹出，其限定插入和删除操作在表的两端进行。

如果符合条件，进去添加到runningAsyncCalls里面，去执行，如果不符合条件就放到readyAsyncCalls里面

在RealCall里面的enqueue里当前的执行完之后，在finally里面就调用finished方法 ，会去readyAsyncCalls里面寻找下一个要执行的AsnyCall

这里的executorService()是一个线程池，可能关于线程池的一些东西大家不是特别清楚 这里稍微解释一下，首先是他的构造函数

ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit,
BlockingQueue<Runnable> workQueue, RejectedExecutionHandler handler)
corePoolSize： 线程池维护线程的最少数量
maximumPoolSize：线程池维护线程的最大数量
keepAliveTime： 线程池维护线程所允许的空闲时间
unit： 线程池维护线程所允许的空闲时间的单位
workQueue： 线程池所使用的缓冲队列
handler： 线程池对拒绝任务的处理策略

上面的SynchronousQueue可能一般同学看的不是特别熟悉这里解释一下：

SynchronousQueue是一个没有数据缓冲的BlockingQueue，生产者线程对其的插入操作put必须等待消费者的移除操作take，反过来也一样。

SynchronousQueue的一个使用场景的典型就是在线程池里。Executors.newCachedThreadPool()就使用了SynchronousQueue，这个线程池根据需要（新任务到来时）创建新的线程，如果有空闲线程则会重复使用，线程空闲了60秒后会被回收。执行是调用execute方法。

所以

整个dispatcher类负责分发了所有的请求,完成了所有请求的调度，避免了拥塞

我们用一张图来总结



现在把上面流程整体串一下，也是OkHttp的核心