Okhttp源码分析之大致流程

我想如果说Okhttp是Android网络库中的霸主应该没人反对吧，还记得开始进入Android这个领域的时候有很多网络库，最开始有自己封装的，后来有了Volley，XUtils，asynchttpclient等等很多的框架出现，但是后来他们慢慢又被Okhttp取代了。今天就来学习一下Okhttp源码。

转载请注明出处
https://blog.csdn.net/dreamsever/article/details/80108020

先来看一张神图，此图来自https://blog.piasy.com/2016/07/11/Understand-OkHttp/，piasy大神绘制，本来想自己绘制，但是这张图做的太完美了，我自己画感觉不会比这个好，索性直接拿来用了。基本上你看完Okhttp的源码后，再来看这张图你就会对Okhttp有一个更全面的认识和把握。当然，先看图再读源码也会让你更容易看懂源码。

1、从构造函数谈起

1.1、创建

//创建方式1
OkHttpClient client = new OkHttpClient();

public OkHttpClient() {
    this(new Builder());
}

//创建方式2
OkHttpClient okClient = new OkHttpClient().newBuilder()
            .connectTimeout(15, TimeUnit.SECONDS)
            .writeTimeout(15, TimeUnit.SECONDS)
            .readTimeout(30, TimeUnit.SECONDS)
            .addInterceptor(new TestInterceptor())
            .build();

public static final class Builder {
    ...
    public OkHttpClient build() {
      return new OkHttpClient(this);
    }
｝

前者是新建了一个Builder，参数很明显都是默认的，后者是我们创建的时候设置了一些参数例如超时时间，自定义拦截器等等。最后他们都指向了下面这里的构造方法。我相信你来看OkHttp的源码你至少已经是一个OkHttp的使用者了，有些参数你一眼看去有些眼熟，但是，由于参数太多，我们其实先大致看一下，不用具体看每一个参数，先往下走

//由于参数太多，我删除了若干行
OkHttpClient(Builder builder) {
    this.dispatcher = builder.dispatcher;
    this.proxy = builder.proxy;
    this.protocols = builder.protocols;
    this.connectionSpecs = builder.connectionSpecs;
    this.interceptors = Util.immutableList(builder.interceptors);
    this.networkInterceptors = Util.immutableList(builder.networkInterceptors);
    this.eventListenerFactory = builder.eventListenerFactory;
    this.proxySelector = builder.proxySelector;
    this.cookieJar = builder.cookieJar;
    this.cache = builder.cache;
    this.internalCache = builder.internalCache;
    this.socketFactory = builder.socketFactory;

    ...

    this.connectTimeout = builder.connectTimeout;
    this.readTimeout = builder.readTimeout;
    this.writeTimeout = builder.writeTimeout;
    this.pingInterval = builder.pingInterval;
}

2、一个请求

2.1

上面已经看到了OkHttpClient的构造函数，现在我们找一个简单的请求，看看请求的流程

private final OkHttpClient client = new OkHttpClient();

public void fun(){
    Request request = new Request.Builder()
            .url("https://api.github.com/user")
            .build();

    client.newCall(request).enqueue(new Callback() {
        @Override public void onFailure(Call call, IOException e) {
            e.printStackTrace();
        }

        @Override public void onResponse(Call call, Response response) throws IOException {
            if (!response.isSuccessful()) throw new IOException("Unexpected code " + response);

            System.out.println(response.body().string());
        }
    });
}

看图，先来分析Request的生成，Request也是Builder构建者形式创建的，里面的属性有如下，这个应该没什么说的，Request一看名字就是一个请求，包含url，请求方法 get put post delete等，请求头，请求体，请求标记。其中前面四个都是跟后台同学统一好的，一般情况下我们都是把参数封装在请求体里面发送给后台，这里不做过多介绍。

Request(Builder builder) {
    //地址
    this.url = builder.url;
    //请求方法
    this.method = builder.method;
    //请求头
    this.headers = builder.headers.build();
    //请求体
    this.body = builder.body;
    //请求标记
    this.tag = builder.tag != null ? builder.tag : this;
}

2.2

然后再来看看client.newCall(request)，这里返回一个Call，RealCall实现了Call接口，看看Call都有哪些方法

public interface Call extends Cloneable {
  Request request();

  Response execute() throws IOException;

  void enqueue(Callback responseCallback);

  void cancel();

  boolean isExecuted();

  boolean isCanceled();

  Call clone();

  interface Factory {
    Call newCall(Request request);
  }
}

通过request实例化一个RealCall，由这个RealCall执行后续的enqueue操作。

@Override 
public Call newCall(Request request) {
    return new RealCall(this, request, false /* for web socket */);
}

//这里就是做了一些准备工作
RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
    final EventListener.Factory eventListenerFactory = client.eventListenerFactory();

    this.client = client;//拿到OkHttpClient
    this.originalRequest = originalRequest;//拿到请求
    this.forWebSocket = forWebSocket;//是否针对websocket,这个先不考虑
    //重试拦截器
    this.retryAndFollowUpInterceptor = new RetryAndFollowUpInterceptor(client, forWebSocket);

    // TODO(jwilson): this is unsafe publication and not threadsafe.
    this.eventListener = eventListenerFactory.create(this);
}

//执行请求
@Override 
public void enqueue(Callback responseCallback) {
    synchronized (this) {
        //线程安全的方式保证这个RealCall只执行一次enqueue，否则抛异常
        //我认为这种异常发生的概率很小，先不考虑
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    //这里用到了第一个拦截器retryAndFollowUpInterceptor，
    //拦截器是Okhttp里面非常重要的一个东西，后面细细道来，这里先过
    captureCallStackTrace();
    /**
    client.dispatcher()拿到OkHttpClient的dispatcher,刚才OkHttpClient
    构造函数那里，那么多参数，dispatcher是其中一个，顾名思义是调度器，管理异步
    请求的策略
    */
    client.dispatcher().enqueue(new AsyncCall(responseCallback));
}

传入参数是一个AsyncCall，刚才看的是RealCall，现在又有一个AsyncCall，这个AsyncCall是什么呢？AsyncCall–>NamedRunnable–>Runnable，看源码AsyncCall实现了Runnable接口

2.3

Dispatcher.java

private final Deque<AsyncCall> readyAsyncCalls = new ArrayDeque<>();
private final Deque<AsyncCall> runningAsyncCalls = new ArrayDeque<>();
//这里还有一个同步的RealCall队列，这里先不考虑
private final Deque<RealCall> runningSyncCalls = new ArrayDeque<>();

synchronized void enqueue(AsyncCall call) {

    if (runningAsyncCalls.size() < maxRequests &&
     runningCallsForHost(call) < maxRequestsPerHost) {

      runningAsyncCalls.add(call);
      executorService().execute(call);
    } else {
      readyAsyncCalls.add(call);
    }
}

如果请求的AsyncCall队列小于最大请求数maxRequests默认为64个，并且，所有AsyncCall的请求主机地址总数小于maxRequestsPerHost默认为5，那么把这个AsyncCall添加到runningAsyncCalls队列中，直接去执行。否则，先添加到待请求队列，等待有空闲了再去请求。

public synchronized ExecutorService executorService() {
    if (executorService == null) {
      executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
          new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
    }
    return executorService;
}

executorService()方法就是单例模式返回一个ThreadPoolExecutor，启动一个线程池。这个线程池核心线程数是0，最大线程数为Integer最大值，可以理解为足够多，但是一旦一个线程空闲时间超过60秒就被杀死了，用于节省内存。由于我对线程池这一块还不够深入，这里executorService().execute(call);我们就知道通过线程池开启一个AsyncCall的线程就行了。现在我们去看AsyncCall的操作。既然是线程肯定要看run方法，但是你会发现AsyncCall里面没有run方法，那就去看看父类NamedRunnable。

NamedRunnable.java

@Override 
public final void run() {
    String oldName = Thread.currentThread().getName();
    Thread.currentThread().setName(name);
    try {
      execute();
    } finally {
      Thread.currentThread().setName(oldName);
    }
}

可以看到线程run方法中调用了execute()方法，由于AsyncCall是RealCall的内部类，所以我们进去看看AsyncCall的execute()方法。
RealCall.java

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;
    }

    @Override protected void execute() {
      boolean signalledCallback = false;
      try {
        Response response = getResponseWithInterceptorChain();
        if (retryAndFollowUpInterceptor.isCanceled()) {
          signalledCallback = true;
          responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
        } else {
          signalledCallback = true;
          responseCallback.onResponse(RealCall.this, response);
        }
      } catch (IOException e) {
        if (signalledCallback) {
          // Do not signal the callback twice!
          Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e);
        } else {
          responseCallback.onFailure(RealCall.this, e);
        }
      } finally {
        client.dispatcher().finished(this);
      }
    }
}

Response response = getResponseWithInterceptorChain();这里通过getResponseWithInterceptorChain方法获取一个Response，Response顾名思义就是一个响应了，我们先不看getResponseWithInterceptorChain，继续往下，拿到响应后，最后的结果就是走我们来时传入的(Callback responseCallback)的onResponse或者onFailure方法了。一个请求就结束了，我们可以在response解析服务器的字符串数据。我们现在已经知道知道了头request ， 知道了尾response。下面就去拦截器。

3，核心：拦截器

3.1

现在就去看最核心的拦截器相关内容和具体请求过程getResponseWithInterceptorChain方法。

Response getResponseWithInterceptorChain() throws IOException {
    // Build a full stack of interceptors.
    //新建一个Interceptor拦截器集合
    List<Interceptor> interceptors = new ArrayList<>();
    //把用户自己定义的拦截器添加到结合中
    interceptors.addAll(client.interceptors());
    interceptors.add(retryAndFollowUpInterceptor);
    interceptors.add(new BridgeInterceptor(client.cookieJar()));
    interceptors.add(new CacheInterceptor(client.internalCache()));
    interceptors.add(new ConnectInterceptor(client));
    if (!forWebSocket) {
      interceptors.addAll(client.networkInterceptors());
    }
    interceptors.add(new CallServerInterceptor(forWebSocket));

    Interceptor.Chain chain = new RealInterceptorChain(
        interceptors, null, null, null, 0, originalRequest);
    return chain.proceed(originalRequest);
}

新建拦截器集合，然后添加各种拦截器，有用户自己定义的拦截器，还有一些默认为我们添加的拦截器。

这里摘自https://blog.piasy.com/2016/07/11/Understand-OkHttp/

1，在配置 OkHttpClient 时设置的 interceptors；
2，负责失败重试以及重定向的 RetryAndFollowUpInterceptor；
3，负责把用户构造的请求转换为发送到服务器的请求、把服务器返回的响应转换为用户友好的响应的 BridgeInterceptor；
4，负责读取缓存直接返回、更新缓存的 CacheInterceptor；
5，负责和服务器建立连接的 ConnectInterceptor；
6，配置 OkHttpClient 时设置的 networkInterceptors；
7，负责向服务器发送请求数据、从服务器读取响应数据的 CallServerInterceptor。

最后新建了一个拦截器链，执行这个拦截器链。拦截器这块用到了责任链模式，对责任链模式不了解的可以先去补补课，Android设计模式源码解析之责任链模式

责任链模式是一种对象的行为模式。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。

通俗点理解switch{case}语句就是责任链模式的低配版，就是一件事需要一个人去处理，链式询问有可能应该处理这件事的人，最后其中一个人把这件事处理掉就是责任链模式。

3.2

public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec,
      RealConnection connection) throws IOException {
    if (index >= interceptors.size()) throw new AssertionError();

    calls++;

    ...

    // 每次到下一个RealInterceptorChain里面index被+1，所以取到的是每一个拦截器
    //依次轮询每一个拦截器
    RealInterceptorChain next = new RealInterceptorChain(
        interceptors, streamAllocation, httpCodec, connection, index + 1, request);
    Interceptor interceptor = interceptors.get(index);
    Response response = interceptor.intercept(next);

    ...

    return response;
}

开始你看拦截器这块代码的时候可能会比较难懂，他们具体是怎么走的呢？其实基本上就是一个一个的走的，看下图

为什么是这样呢，且听我细细道来。我们先不考虑自己添加的拦截器，也就是说上面的拦截器我们只需要关心getResponseWithInterceptorChain–>retryAndFollowUpInterceptor–>BridgeInterceptor–>CacheInterceptor–>ConnectInterceptor–>CallServerInterceptor这个链条。

第一次执行chain.proceed，到了一个新的RealInterceptorChain 去执行

Interceptor interceptor = interceptors.get(index);
Response response = interceptor.intercept(next);

这时候index=0,所以拿到的是interceptors拦截器集合中的第一个，也就是 retryAndFollowUpInterceptor，执行的是这个拦截器的intercept方法，其实每一个拦截器都有一个intercept方法，等会看代码你就会发现在不考虑缓存等特殊情况，他们是依次调用的。

@Override 
public Response intercept(Chain chain) throws IOException {
    Request request = chain.request();

    streamAllocation = new StreamAllocation(
        client.connectionPool(), createAddress(request.url()), callStackTrace);

    int followUpCount = 0;
    Response priorResponse = null;
    while (true) {
      if (canceled) {
        streamAllocation.release();
        throw new IOException("Canceled");
      }

      Response response = null;
      boolean releaseConnection = true;
      try {
        response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);
        releaseConnection = false;
      } catch (RouteException e) {
        // The attempt to connect via a route failed. The request will not have been sent.
        if (!recover(e.getLastConnectException(), false, request)) {
          throw e.getLastConnectException();
        }
        releaseConnection = false;
        continue;
      } catch (IOException e) {
        // An attempt to communicate with a server failed. The request may have been sent.
        boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
        if (!recover(e, requestSendStarted, request)) throw e;
        releaseConnection = false;
        continue;
      } finally {
        // We're throwing an unchecked exception. Release any resources.
        if (releaseConnection) {
          streamAllocation.streamFailed(null);
          streamAllocation.release();
        }
      }

      // Attach the prior response if it exists. Such responses never have a body.
      if (priorResponse != null) {
        response = response.newBuilder()
            .priorResponse(priorResponse.newBuilder()
                    .body(null)
                    .build())
            .build();
      }

      Request followUp = followUpRequest(response);

      if (followUp == null) {
        if (!forWebSocket) {
          streamAllocation.release();
        }
        return response;
      }

      closeQuietly(response.body());

      if (++followUpCount > MAX_FOLLOW_UPS) {
        streamAllocation.release();
        throw new ProtocolException("Too many follow-up requests: " + followUpCount);
      }

      if (followUp.body() instanceof UnrepeatableRequestBody) {
        streamAllocation.release();
        throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
      }

      if (!sameConnection(response, followUp.url())) {
        streamAllocation.release();
        streamAllocation = new StreamAllocation(
            client.connectionPool(), createAddress(followUp.url()), callStackTrace);
      } else if (streamAllocation.codec() != null) {
        throw new IllegalStateException("Closing the body of " + response
            + " didn't close its backing stream. Bad interceptor?");
      }

      request = followUp;
      priorResponse = response;
    }
}

retryAndFollowUpInterceptor就是一个失败重试以及重定向的拦截器，如果失败去重试，重试次数是MAX_FOLLOW_UPS = 20;它的核心代码是

response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);

证明这里又要去执行刚才3.2处新建的RealInterceptorChain，这时候这个RealInterceptorChain里面的index被传入的是0+1=1，也就是拿到的下一个Interceptor 去执行intercept，这个Interceptor是BridgeInterceptor

Interceptor interceptor = interceptors.get(index);
Response response = interceptor.intercept(next);

同理再次来到BridgeInterceptor的intercept方法，Bridge顾名思义是桥梁的意思，这个拦截器恰好是用户请求和Http请求之间的桥梁，而且，它还是Http响应和Okhttp给用户响应的桥梁。

@Override 
public Response intercept(Chain chain) throws IOException {
    Request userRequest = chain.request();
    Request.Builder requestBuilder = userRequest.newBuilder();

    /**
    这里主要做了一些操作，把RequestBody里面的参数重新构建一个新的Request
    前面已经传了一个Request这里为什么还要构建Request，这是因为前面的Request是user的
    Request，我们这里构建的是Http的Request
    */
    RequestBody body = userRequest.body();
    if (body != null) {
      MediaType contentType = body.contentType();
      if (contentType != null) {
        requestBuilder.header("Content-Type", contentType.toString());
      }

      long contentLength = body.contentLength();
      if (contentLength != -1) {
        requestBuilder.header("Content-Length", Long.toString(contentLength));
        requestBuilder.removeHeader("Transfer-Encoding");
      } else {
        requestBuilder.header("Transfer-Encoding", "chunked");
        requestBuilder.removeHeader("Content-Length");
      }
    }

    if (userRequest.header("Host") == null) {
      requestBuilder.header("Host", hostHeader(userRequest.url(), false));
    }

    if (userRequest.header("Connection") == null) {
      requestBuilder.header("Connection", "Keep-Alive");
    }

    // If we add an "Accept-Encoding: gzip" header field we're responsible for also decompressing
    // the transfer stream.
    boolean transparentGzip = false;
    if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
      transparentGzip = true;
      requestBuilder.header("Accept-Encoding", "gzip");
    }

    List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());
    if (!cookies.isEmpty()) {
      requestBuilder.header("Cookie", cookieHeader(cookies));
    }

    if (userRequest.header("User-Agent") == null) {
      requestBuilder.header("User-Agent", Version.userAgent());
    }

    //这里将请求传递到下一个拦截器
    Response networkResponse = chain.proceed(requestBuilder.build());

    //拿到Response Http响应，后面将这个响应转换为Okhttp给用户的响应
    HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());

    Response.Builder responseBuilder = networkResponse.newBuilder()
        .request(userRequest);

    if (transparentGzip
        && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding"))
        && HttpHeaders.hasBody(networkResponse)) {
      GzipSource responseBody = new GzipSource(networkResponse.body().source());
      Headers strippedHeaders = networkResponse.headers().newBuilder()
          .removeAll("Content-Encoding")
          .removeAll("Content-Length")
          .build();
      responseBuilder.headers(strippedHeaders);
      responseBuilder.body(new RealResponseBody(strippedHeaders, Okio.buffer(responseBody)));
    }

    return responseBuilder.build();
}

继续去下一个拦截器CacheInterceptor的，一看这就是缓存拦截器了，缓存拦截器需要我们配置缓存策略，当有缓存时直接拿缓存返回，节约用户时间和流量。由于我感觉缓存拦截器有的说，这里我不做过多分析，后面打算具体分析一下缓存拦截器和它的使用场景。

@Override 
public Response intercept(Chain chain) throws IOException {
    Response cacheCandidate = cache != null
        ? cache.get(chain.request())
        : null;

    long now = System.currentTimeMillis();

    CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
    Request networkRequest = strategy.networkRequest;
    Response cacheResponse = strategy.cacheResponse;

    if (cache != null) {
      cache.trackResponse(strategy);
    }

    if (cacheCandidate != null && cacheResponse == null) {
      closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it.
    }

    // If we're forbidden from using the network and the cache is insufficient, fail.
    if (networkRequest == null && cacheResponse == null) {
      return new Response.Builder()
          .request(chain.request())
          .protocol(Protocol.HTTP_1_1)
          .code(504)
          .message("Unsatisfiable Request (only-if-cached)")
          .body(Util.EMPTY_RESPONSE)
          .sentRequestAtMillis(-1L)
          .receivedResponseAtMillis(System.currentTimeMillis())
          .build();
    }

    // If we don't need the network, we're done.
    if (networkRequest == null) {
      return cacheResponse.newBuilder()
          .cacheResponse(stripBody(cacheResponse))
          .build();
    }

    Response networkResponse = null;
    try {
        //继续到下一个拦截器去获取Response
      networkResponse = chain.proceed(networkRequest);
    } finally {
      // If we're crashing on I/O or otherwise, don't leak the cache body.
      if (networkResponse == null && cacheCandidate != null) {
        closeQuietly(cacheCandidate.body());
      }
    }

    // If we have a cache response too, then we're doing a conditional get.
    if (cacheResponse != null) {
      if (networkResponse.code() == HTTP_NOT_MODIFIED) {
        Response response = cacheResponse.newBuilder()
            .headers(combine(cacheResponse.headers(), networkResponse.headers()))
            .sentRequestAtMillis(networkResponse.sentRequestAtMillis())
            .receivedResponseAtMillis(networkResponse.receivedResponseAtMillis())
            .cacheResponse(stripBody(cacheResponse))
            .networkResponse(stripBody(networkResponse))
            .build();
        networkResponse.body().close();

        // Update the cache after combining headers but before stripping the
        // Content-Encoding header (as performed by initContentStream()).
        cache.trackConditionalCacheHit();
        cache.update(cacheResponse, response);
        return response;
      } else {
        closeQuietly(cacheResponse.body());
      }
    }

    Response response = networkResponse.newBuilder()
        .cacheResponse(stripBody(cacheResponse))
        .networkResponse(stripBody(networkResponse))
        .build();

    if (cache != null) {
      if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) {
        // Offer this request to the cache.
        CacheRequest cacheRequest = cache.put(response);
        return cacheWritingResponse(cacheRequest, response);
      }

      if (HttpMethod.invalidatesCache(networkRequest.method())) {
        try {
          cache.remove(networkRequest);
        } catch (IOException ignored) {
          // The cache cannot be written.
        }
      }
    }

    return response;
}

然后是ConnectInterceptor的intercept方法，

@Override 
public Response intercept(Chain chain) throws IOException {
    RealInterceptorChain realChain = (RealInterceptorChain) chain;
    Request request = realChain.request();
    StreamAllocation streamAllocation = realChain.streamAllocation();

    // We need the network to satisfy this request. Possibly for validating a conditional GET.
    boolean doExtensiveHealthChecks = !request.method().equals("GET");
    //HttpCodec是用来编码HTTP请求和解码HTTP Response的
    HttpCodec httpCodec = streamAllocation.newStream(client, doExtensiveHealthChecks);
    RealConnection connection = streamAllocation.connection();

    return realChain.proceed(request, streamAllocation, httpCodec, connection);
}

由于比较复杂，关于ConnectInterceptor和CallServerInterceptor的分析我单独写了一篇

关于自定义拦截器

关于自定义拦截器，我们可以在构造OkHttpClient 的时候,,添加自己的拦截器，举个例子也是在我们项目中正在使用的是刷新Token拦截器。

OkHttpClient okClient = new OkHttpClient().newBuilder()
            .addInterceptor(new TokenInterceptor())
            .build();

服务器为了安全考虑，我们请求服务器数据的时候都带有一个Token，Token有一定的有效时间，一旦过期，就需要我们去调用刷新接口。但是比如用户今天在我们app中玩的挺爽，第二天又来了，但是每次打开发现第一次请求都是失败的–因为每次打开多执行了一次刷新token操作。我们应该让后台刷新token对用户来说是无感知的。也许你有其他方案可以实现这种需求，但是你用拦截器来实现的话更方便。看拦截器的流程图我们发现我们自己定义的拦截器都是在最前面执行也就是在最前面拿到request，当然也是在最后面拿到返回的response的。这时候我们就可以在拿到的response中的服务器返回，比如返回的状态码提示我们token过期，我们就可以同步等待去执行一个请求刷新token的请求，拿到token后，我们通过请求的克隆再去请求一次，最终安全的拿到开始请求的数据。

拦截器使用起来真的很方便很强大，因为你有最开始的request和最终的response，可以做一些统一的处理。

参考链接：

https://blog.piasy.com/2016/07/11/Understand-OkHttp/
https://juejin.im/entry/57c1119fc4c97100618112ff
https://www.jianshu.com/p/92a61357164b