Ktor 2.0 HttpClient connection pool memory leak fix: Is the CIO engine fully leak‑free after 2.0.1?

Answer first

No. The CIO engine connection-pool leak observed in Ktor 2.0.0 is fixed in 2.0.1 for the default engine configuration, but the engine is not absolutely leak-free. The pool itself no longer retains coroutine contexts or pooled ByteBuffers under normal request completion, cancellation or timeout. Leaks can still appear if user code retains references to HttpResponse or its body beyond the request lifecycle.

Confirmed facts for 2.0.1 with default CIO

• Coroutine context release: The pool releases the coroutine context associated with each request after completion, cancellation or timeout. Regression tests in the 2.0.x series show no accumulation of coroutine objects under high-concurrency short-lived requests.
• ByteBuffer handling: ByteBuffers borrowed from the pool are returned to the pool and cleared before reuse. The pool slot is marked free and the buffer is not held by engine internals after the request ends.
• Scope of the fix: The fix applies to the default CIO engine with default settings and no experimental plugins or custom engine configuration.

Likely explanation vs remaining risk

Under the constraints you specified — default CIO, thousands of short-lived requests, no custom plugins — heap growth of coroutine contexts and pooled ByteBuffers should return to baseline after GC. The likely cause of any remaining growth is user retention, e.g., storing HttpResponse, readChannel or body bytes in a collection, logging the whole response, or keeping a reference across coroutines.

Edge cases such as large payloads or keep-alive timeouts are not documented as pool leaks in 2.0.1 for the default configuration. Applications that keep the HttpClient open for long periods with keep-alive should still monitor pool size and idle timeout settings to avoid gradual memory growth from idle connections.

The suspend-function HttpClient.close() introduced in 2.3.x improves graceful shutdown semantics for in-flight connections. It does not retroactively change 2.0.1 cleanup, and in 2.0.1 closing the client should be done after in-flight requests are finished or cancelled.

Verification steps for this case

1. Run a harness that issues thousands of short-lived GETs with default CIO, awaiting each request or cancelling on timeout.
2. Trigger GC between batches and measure live kotlin.coroutines.jvm.internal.CoroutineImpl instances and direct ByteBuffer counts via a profiler or JMX.
3. Repeat with aborts and timeouts to confirm cleanup on non-normal completion.

One diagnostic detail that changes the recommendation: are you retaining HttpResponse or body references beyond the use-site? If yes, the leak is application-side and requires explicit consume-and-drop of the body.