5.OkHttp请求调度的分析

5.OkHttp请求调度的分析

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

连接池

OkHttp的链接迟相关的类是

  1. ConnectionPool
  2. 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);
}
}
}

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

  1. 当前运行的集合大小小宇最大请求数量,
  2. 当前运行的这个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的核心
这里写图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值