Retrofit结合CompletableFuture使用时，能否摆脱对OkHttp连接池的依赖及相关线程模型疑问

Let’s walk through your questions step by step, tying back to your core goal of maintaining ThreadLocal-based request log correlation:

1. How does Retrofit’s CompletableFuture adapter affect OkHttp’s multi-threading? #

Yes, by default, Retrofit’s CompletableFuture CallAdapter will submit your HTTP requests to the OkHttpClient Dispatcher’s thread pool. Here’s the breakdown:

• Retrofit’s built-in CompletableFuture adapter uses OkHttp’s asynchronous Call.enqueue() under the hood, which hands off the request to the Dispatcher’s executor service for execution.
• This means the actual HTTP work (connecting, reading/writing responses) happens on a thread from the Dispatcher’s pool, not the thread that called your Retrofit interface method.
• If you’ve built a custom CompletableFuture adapter, this depends on your implementation—but unless you explicitly use Call.execute() (synchronous) inside your adapter, it’s almost certainly using the Dispatcher’s thread pool.

For your log correlation problem: since the request runs on a different thread, your ThreadLocal-stored log ID won’t carry over automatically. You’ll need to explicitly propagate the thread context when wrapping the request in your CallAdapter. For example:

// Inside your custom CallAdapter's adapt method
String currentLogId = YourThreadLocalLogHolder.get();
return CompletableFuture.supplyAsync(() -> {
    YourThreadLocalLogHolder.set(currentLogId);
    try {
        return call.execute().body();
    } finally {
        YourThreadLocalLogHolder.remove();
    }
}, client.dispatcher().executorService());

2. Does OkHttp’s connection pool get used regardless of sync/async mode? #

Absolutely. The connection pool is separate from OkHttp’s threading model—it exists to reuse HTTP/1.1 keep-alive connections and HTTP/2 multiplexed connections, reducing the overhead of TCP handshakes.

• For synchronous execute() calls: the thread that invokes execute() will fetch a reusable connection from the pool (if available) or create a new one.
• For asynchronous enqueue() calls: the thread from the Dispatcher’s pool does the same connection lookup/reuse.

The only way to disable the connection pool is to explicitly configure it with zero idle connections and zero keep-alive time:

ConnectionPool noPool = new ConnectionPool(0, 0, TimeUnit.NANOSECONDS);
OkHttpClient client = new OkHttpClient.Builder()
    .connectionPool(noPool)
    .build();

But this is strongly discouraged—it will cripple performance by forcing a new TCP connection for every request.

3. Is OkHttp’s Dispatcher irrelevant in synchronous mode? Can we make OkHttp avoid providing any thread pool? #

When using only synchronous Call.execute() (no enqueue()), the Dispatcher’s thread pool is indeed irrelevant. The Dispatcher’s executor service is solely for handling asynchronous requests—synchronous calls run directly on the thread that invokes them, bypassing the Dispatcher’s thread management entirely.

As for avoiding a thread pool altogether:

• The default Dispatcher creates a thread pool automatically, but if you never use asynchronous requests, this pool will just sit idle. Its threads will timeout and be destroyed after 60 seconds of inactivity (OkHttp’s default), so it’s not a huge resource drain.
• If you want to explicitly prevent the default thread pool from being created, you can initialize a Dispatcher with an executor service that has zero threads (though it’s a bit of a hack):

  Dispatcher dispatcher = new Dispatcher(Executors.newFixedThreadPool(0));
  OkHttpClient client = new OkHttpClient.Builder()
      .dispatcher(dispatcher)
      .build();
  

  But again, if you’re only using synchronous calls, this is unnecessary—the default pool will just idle away.

A key note for your scenario: since you’re using Retrofit with CompletableFuture, you’re likely relying on asynchronous execution (even if it feels "synchronous" to your code). That means the Dispatcher’s thread pool will be used, so you need to handle thread context propagation as mentioned earlier to keep your log IDs correlated.

内容的提问来源于stack exchange，提问作者Andrea Di Lisio