OkHttp3源码详解(六)Okhttp任务队列工作原理

简介: 阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680 1 概述 1.1 引言 android完成非阻塞式的异步请求的时候都是通过启动子线程的方式来解决,子线程执行完任务的之后通过handler的方式来和主线程来完成通信。

1 概述

1.1 引言

android完成非阻塞式的异步请求的时候都是通过启动子线程的方式来解决,子线程执行完任务的之后通过handler的方式来和主线程来完成通信。无限制的创建线程,会给系统带来大量的开销。如果在高并发的任务下,启用个线程池,可以不断的复用里面不再使用和有效的管理线程的调度和数量的管理。就可以节省系统的成本,有效的提高执行效率。

1.2 线程池ThreadPoolExecutor

okhttp的线程池对象存在于Dispatcher类中。实例过程如下

1.  public  synchronized  ExecutorService executorService()  {
2.  if  (executorService ==  null)  {
3.  executorService =  ,  Integer.MAX_VALUE,  ,  TimeUnit.SECONDS,
4.  new  SynchronousQueue<Runnable>(),  Util.threadFactory("OkHttp Dispatcher",  false));
5.  }
6.  return executorService;
7.  }

1.2 Call对象

了解源码或使用过okhttp的都知道。 okttp的操作元是Call对象。异步的实现是RealCall.AsyncCall。而 AsyncCall是实现的一个Runnable接口。

1.  final  class  AsyncCall  extends  NamedRunnable  {}

所以Call本质就是一个Runable线程操作元肯定是放进excutorService中直接启动的。

2 线程池的复用和管理

2.1 图解

为了完成调度和复用,定义了两个队列分别用作等待队列和执行任务的队列。这两个队列都是Dispatcher 成员变量。Dispatcher是一个控制执行,控制所有Call的分发和任务的调度、通信、清理等操作。这里只介绍异步调度任务。

1.  /** Ready async calls in the order they'll be run. */
2.  private  final  Deque<AsyncCall> readyAsyncCalls =  new  ArrayDeque<>();

4.  /** Running asynchronous calls. Includes canceled calls that haven't finished yet. */
5.  private  final  Deque<AsyncCall> runningAsyncCalls =  new  ArrayDeque<>();

《okhttp连接池复用机制》文章中我们在缓存Connection连接的时候也是使用的Deque双端队列。这里同样的方式,可以方便在队列头添加元素,移除尾部的元素。

image

2.2 过程分析

Call代用equeue方法的时候

1.  synchronized  void enqueue(AsyncCall call)  {
2.  if  (runningAsyncCalls.size()  < maxRequests && runningCallsForHost(call)  < maxRequestsPerHost)  {
3.  runningAsyncCalls.add(call);
4.  executorService().execute(call);
5.  }  else  {
6.  readyAsyncCalls.add(call);
7.  }
8.  }

方法中满足执行队列里面不足最大线程数maxRequests并且Call对应的host数目不超过maxRequestsPerHost 的时候直接把call对象直接推入到执行队列里,并启动线程任务(Call本质是一个Runnable)。否则,当前线程数过多,就把他推入到等待队列中。Call执行完肯定需要在runningAsyncCalls 队列中移除这个线程。那么readyAsyncCalls队列中的线程在什么时候才会被执行呢。

追溯下AsyncCall 线程的执行方法

1.  @Override
2.  protected  void execute()  {
3.  boolean signalledCallback =  false;
4.  try  {
5.  Response response = getResponseWithInterceptorChain(forWebSocket);
6.  if  (canceled)  {
7.  signalledCallback =  true;
8.  responseCallback.onFailure(RealCall.this,  new  IOException("Canceled"));
9.  }  else  {
10.  signalledCallback =  true;
11.  responseCallback.onResponse(RealCall.this, response);
12.  }
13.  }  catch  (IOException e)  {
14.  if  (signalledCallback)  {
15.  // Do not signal the callback twice!
16.  Platform.get().log(INFO,  "Callback failure for "  + toLoggableString(), e);
17.  }  else  {
18.  responseCallback.onFailure(RealCall.this, e);
19.  }
20.  }  finally  {
21.  client.dispatcher().finished(this);
22.  }
23.  }
24.  }

这里做了核心request的动作,并把失败和回复数据的结果通过responseCallback 回调到Dispatcher。执行操作完毕了之后不管有无异常都会进入到dispactcherfinished方法。

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

11.  && idleCallback !=  null)  {
12.  idleCallback.run();
13.  }
14.  }

在这里call在runningAsyncCalls队列中被移除了,重新计算了目前正在执行的线程数量。并且调用了promoteCalls() 看来是来调整任务队列的,跟进去看下

1.  private  void promoteCalls()  {
2.  if  (runningAsyncCalls.size()  >= maxRequests)  return;  // Already running max capacity.
3.  if  (readyAsyncCalls.isEmpty())  return;  // No ready calls to promote.

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

8.  if  (runningCallsForHost(call)  < maxRequestsPerHost)  {
9.  i.remove();
10.  runningAsyncCalls.add(call);
11.  executorService().execute(call);
12.  }

14.  if  (runningAsyncCalls.size()  >= maxRequests)  return;  // Reached max capacity.
15.  }
16.  }

原来实在这里对readyAsyncCalls 进行调度的。最终会在readyAsyncCalls 中通过remove操作把元素迭代取出并移除之后加入到runningAsyncCalls的执行队列中执行操作。ArrayDeque 是非线程安全的所以finished在调用promoteCalls 的时候都在synchronized块中执行的。执行等待队列线程当然的前提是runningAsyncCalls 线程数没有超上线,而且等待队列里面有等待的任务。

以上完成了线程线程池的复用和线程的管理工作。

小结,Call在执行任务通过Dispatcher把单元任务优先推到执行队列里进行操作,如果操作完成再执行等待队列的任务。

原文链接:https://www.bbsmax.com/A/VGzlBLg85b/

相关文章
|
8月前
|
Java
使用OkHttp3框架获取服务器数据
使用OkHttp3框架获取服务器数据
97 0
|
11月前
|
设计模式 缓存 监控
OKHttp3 从使用到原理分析
Okhttp3 是我们经常使用的一个网络框架,可扩展性强,支持 get 缓存, spdy、http2.0,gzip 压缩减少数据流量,同步和异步请求,连接池复用机制等特性让广大 android 开发者深爱不已,今天我就带大家从 Okhttp 简单使用,到各种好用拦截器原理了解 Okhttp3
785 0
OKHttp3 从使用到原理分析
|
存储 缓存 网络协议
源码阅读 | Okhttp
源码阅读 | Okhttp
|
缓存 JSON API
XHttp2 一个功能强悍的网络请求库,使用RxJava2 + Retrofit2 + OKHttp进行组装
XHttp2 一个功能强悍的网络请求库,使用RxJava2 + Retrofit2 + OKHttp进行组装
582 0
XHttp2 一个功能强悍的网络请求库,使用RxJava2 + Retrofit2 + OKHttp进行组装
|
存储 Android开发
OkHttp源码详解之Okio源码详解
OkHttp源码详解之Okio源码详解
OkHttp源码详解之Okio源码详解
|
设计模式 Java API
【OkHttp】OkHttp 源码分析 ( 网络框架封装 | OkHttp 4 迁移 | OkHttp 建造者模式 )
【OkHttp】OkHttp 源码分析 ( 网络框架封装 | OkHttp 4 迁移 | OkHttp 建造者模式 )
296 0
【OkHttp】OkHttp 源码分析 ( 网络框架封装 | OkHttp 4 迁移 | OkHttp 建造者模式 )
|
Java 调度
【OkHttp】OkHttp 源码分析 ( 同步 / 异步 Request 请求执行原理分析 )(二)
【OkHttp】OkHttp 源码分析 ( 同步 / 异步 Request 请求执行原理分析 )(二)
157 0
【OkHttp】OkHttp 源码分析 ( 同步 / 异步 Request 请求执行原理分析 )(二)
|
调度
【OkHttp】OkHttp 源码分析 ( 同步 / 异步 Request 请求执行原理分析 )(一)
【OkHttp】OkHttp 源码分析 ( 同步 / 异步 Request 请求执行原理分析 )(一)
244 0
|
缓存 Java 网络协议
OkHttp3源码详解(五)okhttp连接池复用机制
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680 1、概述 提高网络性能优化,很重要的一点就是降低延迟和提升响应速度。
OkHttp3源码详解(四)缓存策略
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680合理地利用本地缓存可以有效地减少网络开销,减少响应延迟。HTTP报头也定义了很多与缓存有关的域来控制缓存。

相关产品

  • 云迁移中心