threadpool - 连接池和文件句柄

Question

我们对来自 Android 应用程序的所有网络流量使用 Retrofit/OkHttp3。到目前为止，一切似乎都很顺利。

但是，我们现在偶尔会遇到我们的应用程序/进程用完文件句柄的情况。

Android 允许每个进程最多 1024 个文件句柄

OkHttp 将为每个异步调用创建一个新线程

以这种方式创建的每个线程(根据我们的观察)将负责 3 个新文件句柄(2 个管道和一个套接字)。

We were able to debug this exactly, where each dispached async call using .enqueue() will lead to an increase of open file handles of 3.

问题是， ConnectionPool OkHttp 中的连接线程似乎比实际需要的时间长得多。 ( This post 讲了五分钟，虽然我在任何地方都没有看到这个。)

这意味着如果您正在快速发送请求，连接池的大小将增加 ，文件句柄数 - 直到您到达应用程序崩溃的 1024。

我已经看到可以使用 Dispatcher.setMaxRequests() 来限制并行调用的数量。 (虽然这似乎不清楚这是否真的有效，见 here )——但这仍然不能完全解决开放线程和文件句柄堆积的问题。

我们如何防止 OkHttp 创建过多的文件句柄？

Answer 1

我在这里回答我自己的问题以记录我们遇到的这个问题。我们花了一段时间才弄清楚这一点，我认为其他人也可能会遇到这个问题，并且可能会为这个答案感到高兴。

我们的问题 是我们创建了一个OkHttpClient每个请求，因为我们使用它的构建器/拦截器 API 来配置一些每个请求的参数，例如 HTTP header 或超时。
默认每个 OkHttpClient带有自己的连接池，这当然会增加连接/线程/文件句柄的数量并阻止池中的正确重用。
我们的解决方案
我们通过手动创建全局 ConnectionPool 解决了这个问题在单例中，然后将其传递给 OkHttpClient.Builder构建实际 OkHttpClient 的对象.

这仍然允许使用 OkHttpClient.Builder 进行每个请求的配置。

确保所有 OkHttpClient实例仍在使用公共(public)连接池。

然后，我们能够正确调整全局连接池的大小。