这两天那些事情也弄的差不多了，也就回头又看了看OkHttp源码。它太多地方值得深入和学习。也为了提高自己，于是又从头看了一遍，也希望有更多的收获。目前已在这家公司超过三年，说不出什么感觉，，不知道是不是麻木了。。。。！！！！
源码分析
从发起一个简单的http网络请求开始
//构造OkhttpClient对象
OkHttpClient okHttpClient= new OkHttpClient();
//构造请求体 url ，tag ，header ext...
Request request = new Request.Builder().url("http://www.baidu.com").build()
//发起一个异步请求
okHttpClient.newCall(request).enqueue(new Callback() {
@Override
public void onFailure(Call call, IOException e) {
Log.d(tag,e.toString());
}
@Override
public void onResponse(Call call, Response response) throws IOException {
//处理响应结果
int code = response.code();
ResponseBody body = response.body();
Log.d(tag,body.string());
});
从上面的例子，我们可以知道使用OkHttp发起一个http请求主要有三步：
1，构造一个OkHttpClient对象
2，构造请求体（包含url，tag，header，etc...）
3，发起请求
当然最后一步就是等待服务器响应，根据状态码处理响应体。
可以看出，使用OkHttp发起一个网络请求，是非常简单的，仅需三步就可以拿到我们服务器的响应结果，在这么简单的背后，OkHttp在背后到底为我们做了什么呢？我们提交的请求是怎么被执行的呢？响应是如何拿到的呢？其实我们也可以设想一下，内部一定是开启了一个子线程去帮我们处理请求，必定我们从学Android第一天就知道，耗时任务不能在主线程被执行，可能猜到这里，我们又会抛出疑问，在哪起的线程，任务在哪被执行,又或者是否使用了线程池执行任务等等......
带着这一连串的疑问，我们先看一下请求的提交流程
请求提交流程
从上面的例子，我们看到通过调用OkHttpClient对象的newCall()方法然后调用enqueue提交请求，我们进入OkHttpClient，查看一下newCall()方法的源码：
/**
* Prepares the {@code request} to be executed at some point in the future.
*/
@Override public Call newCall(Request request) {
return RealCall.newRealCall(this, request, false /* for web socket */);
}
newCall()方法内部调用了RealCall对象的newRealCall()方法，通过newCall()方法的返回值，我们知道 RealCall.newRealCall()返回了一个Call对象。我们继续跟踪RealCall的源码，发现RealCall是okhttp3.Call接口的实现，okhttp3.Call表示一个等待执行的请求，并且它只能被执行一次，为什么只能被执行一次，我们后面分析原因，暂且放一放，okHttp3.Call中的源码：
public interface Call extends Cloneable {
//返回请求关联的Request对象，前面例子中构造的Request对象
Request request();
//立即执行请求，等待并阻塞直到返回请求结果
Response execute() throws IOException;
//请求入列，异步执行，
void enqueue(Callback responseCallback);
//取消一个请求，
void cancel();
boolean isExecuted();
boolean isCanceled();
Timeout timeout();
Call clone();
interface Factory {
Call newCall(Request request);
}
}
从前面的例子okHttpClient.newCall(request).enqueue()，发起请求，enqueue()这个方法实际是定义在Call中的，我们跟踪发现在整个OkHttp源码中，Call的唯一实现就是RealCall,它表示一个准备好被执行的请求，可以发起请求，取消请求等等...
拿到okHttp3.Call唯一实例，RealCall对象后，我们调用它的enqueue()方法：
@Override public void enqueue(Callback responseCallback) {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
eventListener.callStart(this);
client.dispatcher().enqueue(new AsyncCall(responseCallback));
}
前面我们提到okhttp3.Call表示一个等待执行的请求，并且它只能被执行一次，看到这里，问题就解决了，如果第二次执行就会抛出Already Executed异常，原因就在这里。上面最核心的代码就是
client.dispatcher().enqueue(new AsyncCall(responseCallback))；，应该是整个请求的核心地方，它帮我们做了两件事：
1，创建一个AsyncCall对象
2，调用Dispatcher中的enqueue方法，将请求入列
AsyncCall是什么，跟进去看一下源码：
final class AsyncCall extends NamedRunnable {
private final Callback responseCallback;
AsyncCall(Callback responseCallback) {
super("OkHttp %s", redactedUrl());
this.responseCallback = responseCallback;
}
String host() {
return originalRequest.url().host();
}
Request request() {
return originalRequest;
}
RealCall get() {
return RealCall.this;
}
void executeOn(ExecutorService executorService) {
//...
}
@Override protected void execute() {
//...
}
}
我们跟踪发现，AsyncCall 其实就是一个Runnable,用于执行任务。
我们还是回到我们之前提到的 client.dispatcher().enqueue(new AsyncCall(responseCallback));
client.dispatcher()返回了调度器Dispatcher对象，Dispatcher是OkHttp中相当核心的类：
//同时最多发起64个请求
private int maxRequests = 64;
//同一host做多发起5个请求
private int maxRequestsPerHost = 5;
private @Nullable Runnable idleCallback;
/** Executes calls. Created lazily. */
//将会异步创建的线程池
private @Nullable ExecutorService executorService;
/** Ready async calls in the order they'll be run. */
//等待异步执行的请求队列
private final Deque readyAsyncCalls = new ArrayDeque<>();
/** Running asynchronous calls. Includes canceled calls that haven't finished yet. */
//正在执行的异步请求队列（其中包括取消没有完成的请求）
private final Deque runningAsyncCalls = new ArrayDeque<>();
/** Running synchronous calls. Includes canceled calls that haven't finished yet. */
//正在运行的同步请求队列
private final Deque runningSyncCalls = new ArrayDeque<>();
public Dispatcher(ExecutorService executorService) {
this.executorService = executorService;
}
public Dispatcher() {
}
public synchronized ExecutorService executorService() {
if (executorService == null) {
//默认核心线程为0，最多数量不限制，消息队列为SynchronousQueue，有请求时会不断创建线程
executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
new SynchronousQueue(), Util.threadFactory("OkHttp Dispatcher", false));
}
return executorService;
}
//...
最后调用了Dispatcher分发器的enqueue()方法：
void enqueue(AsyncCall call) {
synchronized (this) {
readyAsyncCalls.add(call);
}
promoteAndExecute();
}
上面我们可以得到两个信息：
1，加入等待的readyAsyncCalls队列
2，推进并执行(暂且这样理解，字面翻译）
promoteAndExecute()字面是推进并执行，我们跟进去一探究竟，到底是怎么执行的：
private boolean promoteAndExecute() {
assert (!Thread.holdsLock(this));
List executableCalls = new ArrayList<>();
boolean isRunning;
synchronized (this) {
//迭代
for (Iterator i = readyAsyncCalls.iterator(); i.hasNext(); ) {
//取出当前asyncCall
AsyncCall asyncCall = i.next();
//如果当前请求数大于64，直接跳出
if (runningAsyncCalls.size() >= maxRequests) break; // Max capacity.
//如果当前主机连接数大于5，继续遍历
if (runningCallsForHost(asyncCall) >= maxRequestsPerHost) continue; // Host max capacity.
i.remove();
//加入executableCalls集合
executableCalls.add(asyncCall);
//加入正在执行的队列
runningAsyncCalls.add(asyncCall);
}
//标识是否正在执行请求队列
isRunning = runningCallsCount() > 0;
}
for (int i = 0, size = executableCalls.size(); i < size; i++) {
AsyncCall asyncCall = executableCalls.get(i);
//调用AsyncCall.executeOn()开始执行请求任务
asyncCall.executeOn(executorService());
}
return isRunning;
}
我们从promoteAndExecute()中知道：
1，在OkHttp中一般会存在一个Dispather对象，并且一个okHttpClienet能发起的最多请求是Diapatcher中定义的64个
2，同一个主机最多能发起的求请是5个
3，Dispatcher中有三个队列保持同步和异步请求
4，OkHttp中默认的线程核心数为0，最多数量Int的最大值，也就是不限制，消息队列为SynchronousQueue，有请求时会不断创建线程
任务是怎样被执行的呢？在方法的最后，有一个列表executableCalls存入了要执行的任务，然后遍历，调用了 asyncCall.executeOn(executorService());这里面又做了什么：
void executeOn(ExecutorService executorService) {
assert (!Thread.holdsLock(client.dispatcher()));
boolean success = false;
try {
executorService.execute(this);
success = true;
} catch (RejectedExecutionException e) {
InterruptedIOException ioException = new InterruptedIOException("executor rejected");
ioException.initCause(e);
eventListener.callFailed(RealCall.this, ioException);
responseCallback.onFailure(RealCall.this, ioException);
} finally {
if (!success) {
client.dispatcher().finished(this); // This call is no longer running!
}
}
}
还记得我们之前提到的AsyncCall，他本质是一个Runnable(),这里我们还是看不出，我们只是知道AsyncCall实现了NamedRunnable，NamedRunnable是个啥：
public abstract class NamedRunnable implements Runnable {
protected final String name;
public NamedRunnable(String format, Object... args) {
this.name = Util.format(format, args);
}
@Override public final void run() {
String oldName = Thread.currentThread().getName();
Thread.currentThread().setName(name);
try {
execute();
} finally {
Thread.currentThread().setName(oldName);
}
}
protected abstract void execute();
}
是不是恍然大悟，当我们在executeOn()中调用了executorService.execute(this);实质就是把我们的任务加入到了executorService并执行任务，到这里我么们了解了一个请求从提交到执行背后所经历的所有流程，用一张小图总结一下：
最后我们还是分析OkHttp线程池配置参数情况，
//核心线程书，最大线程数，闲置时间，SynchronousQueue，线程池工程
SynchronousQueue synchronousQueue = new SynchronousQueue();
ExecutorService executorService =
new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECO
synchronousQueue,
Util.threadFactory("OkHttp Dispatcher", false));
1，OkHttp线程池配置：
1，核心线程数为0
2，最大线程数，不限制
3，线程闲置时间为60s
4，队列为SynchronousQueue
5，线程池工厂，无守护线程
这样配置有什么特点呢？答：高并发，最大吞吐量，这也是我们前面提到有请求时不断创建线程的原因。
2，可不可以换成别的队列代替SynchronousQueue？先看下面这个例子：
//核心线程书，最大线程数，闲置时间，SynchronousQueue，线程池工程
//SynchronousQueue synchronousQueue = new SynchronousQueue();
ArrayBlockingQueue arrayBlockingQueue = new ArrayBlockingQueue<>(1);
ExecutorService executorService =
new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
arrayBlockingQueue,
Util.threadFactory("OkHttp Dispatcher", false));
executorService.execute(()->{
System.out.println("任务一");
for (;;);
});
executorService.execute(()->{
System.out.println("任务二");
});
我们发现任务二，永远无法执行，所以ArrayBlockingQueue不能代替SynchronousQueue，
LinkedBlockingQueue可不可以代替？它的内部实现是使用链表，区别是我们初始化的时候可以不传容量，如果不传容量为默认的Integer.MAX_VALUE,如果我现在往队列里，放了一百个任务，后面的99个永远得不到执行。
从上面分析，就可以知道为什么OkHttp使用了SynchronousQueue并且没有核心线程数的原因。
总结
通过上面的分析，主要弄明白了OkHttp发起一个请求的基本流程，以及线程池为什么要这样配置，总的来说发起请求流程还是非常容易理解的，后续我们继续分析OkHttp的拦截器，也是它的核心。如果有疑问，欢迎留言讨论。