0x2、并发设计

像上面HttpUrlConnection的例子，每发起一次请求，都新起一个线程，太蠢了：

• 没复用线程，频繁创建销毁线程造成不必要的开销；

• 没对最大线程数做一个限制，可能会造成过度资源竞争，系统使用率不高；

所以涉及到并发的开源项目，线程池 基本是没得走的了，再配个 任务队列 进出队列操作加锁，有时为了解耦，还会再拆出来一个 调度器，死循环 访问 任务队列，取出任务交由线程池执行。

Volley是支持并发的，看下它是如何设计的，没有找到线程池初始化代码，倒是找到了 两个线程实现类：

NetworkDispatcher 继承 Thread类，所以这里默认定义了 容量为4的线程数组，另外一个线程 CacheDispatcher。它们都在 RequestQueue → start() 中启动：

跟下start()的调用处 Volley → newRequestQueue：

就是实例化RequestQueue的时候，就创建并开启了这些线程。

0x3、请求调度设计

调用 RequestQueue → add() 请求入队，跟下具体实现：

用到三个集合，根据对应注释推演出各种用途：

• mCurrentRequests : HashSet → 正在处理的所有请求(包括等待和处理中)的集合；
• mNetworkQueue : PriorityBlockingQueue → 非缓存请求队列；
• mCacheQueue ： PriorityBlockingQueue → 缓存请求队列；

入队比较简单，接着看下具体的调度流程，不难看出分成两类，走缓存(默认)和不走缓存，先看前者~

① 不走缓存的请求

NetworkDispatcher → run()

死循环拿队列的请求，处理请求后的结果流向有四个：

• 请求处于取消状态 → request.finish("network-discard-cancelled");
• 304且响应已解析过 → request.finish("not-modified");
• 正常结束 → mDelivery.postResponse(request, response);
• 异常结束 → mDelivery.postError(request, volleyError);

先跟下 Request → finish()：

比较简单：移除集合中的请求，打日志，调用下请求结束的回调，接着看下后两个，跟下 ExecutorDelivery

跟下 mResponsePoster 初始化部分代码：

好吧，就是一个 执行器，负责将任务分发出去，因为后续操作在主线程操作，所以得用 Handler。

接着，看下任务具体做了啥 ResponseDeliveryRunnable → run()

正常请求的流转还是很好理解的，接着看下走缓存请求的调度过程~

② 走缓存的请求

直接跟 CacheDispatcher → run()，同样是死循环，直接看 processRequest() 部分代码：

简单点说：有缓存且缓存没过期直接返会，其他情况把请求加到请求队列中。接着再看看缓存这块是咋设计的~