背景

最近项目中接入了一个三方的预览云服务，开发、测试环境用起来很流畅，没有什么问题。但是上线之后，发现文件在上传到云服务这个过程中：间歇性出现超时（频率挺高），几分钟那种，这谁能忍啊？

问题定位

首先怀疑是文件太大

经过排查发现，超时的文件只有200+KB，甚至有些文件只有40+KB，这就很离谱

云服务提供商接口问题

这么小的文件都能超时，肯定是服务商接口问题超时。基于这种思想，直接就开始联系对方的技术支持。经过对方排查，没有发现任何问题。
在等待对方排查的过程中，我们对上传接口做了重试。结果并没有什么用！让运维检查了我们的服务器网络状态、带宽、并发，结果都很正常！

服务端请求路由策略问题

经过新增重试逻辑，发现超时文件重试的时候还是很容易超时，并且即使上传成功，都需要2、3分钟的时间。还是没有得到改善之后。我们怀疑是对方服务的请求路由问题。因为慢的文件，始终都慢！，于是联系对方技术排查求证，但是对方回复并没有根据请求信息做路由控制。

代码问题

经过我们双方排查，都没有发现问题所在，这是我们回到我们的代码中。**如果客观环境都没有问题，那么问题可能还是在我们自身。上传代码如下：

public ApiResponse<FileUploadResponse> upload(File file) {
    MultipartBody.Builder builder = new MultipartBody.Builder().setType(MultipartBody.FORM);
    builder.addFormDataPart("file", file.getName(), RequestBody.create(file, MediaType.parse("multipart/form-data")));
    builder.addFormDataPart("appId", properties.getAppId());
    Map<String, String> params = Maps.newHashMap();
    params.put("appId", properties.getAppId());
    builder.addFormDataPart("sign", createSign(params));
    Request request = new Request.Builder()
        .post(builder.build())
        .url(UPLOAD_API)
        .build();

    final Stopwatch stopwatch = Stopwatch.createStarted();
    return RetryTemplateUtils.getCommonRetryTemplate()
        .execute(context -> {
          try (Response response = uploadHttpClient.newCall(request).execute()) {
            String resp = Objects.requireNonNull(response.body()).string();
            log.info("[上传文件] 响应 : {}, 总耗时 : {} ms", resp, stopwatch.elapsed(TimeUnit.MILLISECONDS));
            ApiResponse<FileUploadResponse> result = JSON.parseObject(resp, new TypeReference<ApiResponse<FileUploadResponse>>() {});
            return result.getData();
          } catch (Exception e) {
            log.info("[上传文件] 失败, 重试次数 : {}, 耗时 : {} ms", context.getRetryCount(), stopwatch.elapsed(TimeUnit.MILLISECONDS), e);
            throw new ConversionException(e);
          }
        });
}

uploadHttpClient 配置：

uploadHttpClient = new OkHttpClient.Builder()
        .connectTimeout(200, TimeUnit.SECONDS)
        .readTimeout(10, TimeUnit.SECONDS)
        .writeTimeout(180, TimeUnit.SECONDS)
        .build();

很中规中矩的一个利用OkHttpClient上传文件的代码，没有什么花里胡哨的操作。似乎问题陷入了僵局，但是线上的失败请求一直在报警。

HTTP连接池

到目前，都没有发现问题所在，只能再找到运维，排查一下网关、路由。最终都没发现有什么问题，也没有发现网络波动，一切都很正常。没有办法了，只能再度回到我们的代码中。这时运维提出，不要用连接池，每次都重新建立连接，试试。（PS：OkHttp还是常见的一个框架，连接重用应该是处理的好的吧，但是实在没办法了，先试试吧！）

OkHttpClient连接池配置

这也是一个曲折的过程

• 设置连接池为NULL，很遗憾，源码是这样的：

public Builder connectionPool(ConnectionPool connectionPool) {
      if (connectionPool == null) throw new NullPointerException("connectionPool == null");
      this.connectionPool = connectionPool;
      return this;
    }

• 扩展ConnectionPool类，重写获取连接的方法，也很遗憾ConnectionPool是final的

• 没有办法了，只能研究一下ConnectionPool的构造参数了，与缓存连接的方法了，最终在方法connectionBecameIdle(RealConnection connection)中发现：

boolean connectionBecameIdle(RealConnection connection) {
    assert (Thread.holdsLock(this));
    if (connection.noNewStreams || maxIdleConnections == 0) {
      connections.remove(connection);
      return true;
    } else {
      notifyAll(); // Awake the cleanup thread: we may have exceeded the idle connection limit.
      return false;
    }
  }

把maxIdleConnections设置为0就可以实现在连接变成空闲的时候，直接删除连接，不缓存。
所以最终的uploadHttpClient配置为：

uploadHttpClient = new OkHttpClient.Builder()
        .connectTimeout(200, TimeUnit.SECONDS)
        .readTimeout(10, TimeUnit.SECONDS)
        .writeTimeout(180, TimeUnit.SECONDS)
        .connectionPool(new ConnectionPool(0, 1, TimeUnit.NANOSECONDS)) // 不缓存连接，其实后面两个参数就无所谓了
        .build();

改完，发版，惊喜的发现问题解决了！就这样解决了？

反思&总结

虽然问题这样解决了，但是我一开始是不信的。但是回过头来想想，如果这还是不能解决，我肯定是要打人了。
总的来说，过程比较曲折，耗时比较久，但是这种问题确实是不太好排查。尤其是权限受限的情况下，需要这别人一起处理，其中沟通、同步成本还是不容忽视。

最终问题（猜测）：

文件上传成功之后，云服务端会主动关闭TCP连接。
OkHttpClient连接池，可能没有处理好服务端主动关闭TCP连接的这种情况。

待后续验证

okhttp3版本: 4.2.1

    <dependency>
      <groupId>com.squareup.okhttp3</groupId>
      <artifactId>okhttp</artifactId>
      <version>4.2.1</version>
    </dependency>

JVM: java8