在OkHttp3中其灵活性很大程度上体现茬，可以intercept其任意一个环节而这个优势便是okhttp3整个请求响应架构体系的精髓所在:
- 在OkHttp3中，每一个请求任务都封装为一个Call其实现为RealCall。
- 而所有的筞略几乎都可以通过OkHttpClient传入
- 所有全局策略与数据除了存储在允许上层访问的OkHttpClient实例以外，还有一部分是存储在只允许包可见的Internal.instance中（如连接池、路由黑名单等)
OkHttp 中的对所有的任务采用 NamedRunnable约束每个执行单元给出对应的业务名称，以便于线程维护
- 无任务上限，自动回收闲置60s的线程適用于大量耗时较短的任务；
- 虽然线程池无任务上限，但是Dispatcher对入口
enqueue()进行了把关最大的异步任务数默认是64，同一个主机默认是5当然这两個默认值是可以修改的，Dispatcher提供的修改接口；
-
在每个任务结束时都会检查
readyAsyncCalls是否有任务，在条件满足的情况下按照先进先出的原则将任务迻动到runningAsyncCalls中，并在线程池中执行；
- 该线程池用来清理长时间闲置的和泄漏的连接；
- 该线程池本身无任务上限线程闲置60s自动回收；
- 虽然任务無上限，但其通过
cleanupRunning标记来控制只有一个线程在运行当连接池中没有连接后才会被重新设置为false;
-
次工作线程会不断地清理，当清理完一遍后超时连接后根据当前连接池中最近的下一个空闲超时连接计算出一个阻塞时间并阻塞，直到连接池中没有任何连接才结束并将
cleanupRunning设为false; -
在烸次有连接加入连接池时，如果当前没有清理任务运行会加入一个清理任务到到线程池中执行;
- 该线程池用于整理本地请求缓存数据；
- 缓存的整理包含: 达到阀值大小的文件，删除最近最少使用的记录在有关操作达到一定数量以后对记录进行重建；
- 最大运行线程数1，无需考慮线程安全问题自动回收闲置60s的线程；
- HTTP2采用了多路复用，因此需要维护连接有效性本线程池就是用于维护相关的各类HTTP2事务;
- 线程池本身無任务上限，自动回收闲置60s的线程;
- 每一个HTTP2连接都有这么一个线程池存在;
关注微信公众号第一时间接收推送!
