背景
最近项目中接入了一个三方的预览云服务，开发、测试环境用起来很流畅，没有什么问题。但是上线之后，发现文件在上传到云服务这个过程中：间歇性出现超时（频率挺高），几分钟那种，这谁能忍啊？
问题定位
首先怀疑是文件太大
经过排查发现，超时的文件只有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
