Kotlin协程超时后线程资源泄漏致性能劣化问题求助

核心原因：SocketChannel资源泄漏 #

不管用不用协程，多次连接超时后性能暴跌，本质是超时的SocketChannel没被彻底清理。NIO的SocketChannel不是普通对象，连接失败/超时后如果不做以下几步，会导致线程、文件句柄一直占着不释放：

• 取消它在Selector上的注册（如果已经注册过）
• 强制关闭Channel（哪怕连接没建立完）
• 清理关联的ByteBuffer等资源

针对kotlinx coroutines超时的正确实现 #

之前直接用withTimeout失效，大概率是因为connectInternal()是阻塞式调用，或者没正确适配NIO的非阻塞模型。正确的做法是把NIO的非阻塞connect操作封装成挂起函数，再用withTimeout包裹，同时在所有分支（成功、超时、异常）里强制清理资源：

suspend fun connectWithTimeout(
    socketChannel: SocketChannel,
    targetAddr: SocketAddress,
    timeoutMs: Long
): Boolean = withTimeout(timeoutMs) {
    try {
        socketChannel.configureBlocking(false)
        var isConnected = socketChannel.connect(targetAddr)
        
        if (!isConnected) {
            // 用协程适配NIO的select逻辑，避免阻塞线程
            suspendCancellableCoroutine<Boolean> { continuation ->
                val selector = Selector.open()
                val key = socketChannel.register(selector, SelectionKey.OP_CONNECT)

                // 协程取消时立即清理资源
                continuation.invokeOnCancellation {
                    key.cancel()
                    selector.close()
                    socketChannel.close()
                }

                // 用IO线程池处理select，避免占用计算线程
                launch(Dispatchers.IO) {
                    while (selector.select() > 0) {
                        val keyIterator = selector.selectedKeys().iterator()
                        while (keyIterator.hasNext()) {
                            val selectedKey = keyIterator.next()
                            keyIterator.remove()
                            
                            if (selectedKey.isConnectable) {
                                val channel = selectedKey.channel() as SocketChannel
                                isConnected = channel.finishConnect()
                                
                                selectedKey.cancel()
                                selector.close()
                                continuation.resume(isConnected)
                            }
                        }
                    }
                }
            }
        }
        isConnected
    } finally {
        // 无论结果如何，强制关闭未释放的Channel
        if (socketChannel.isOpen) {
            socketChannel.keyFor(null)?.cancel()
            socketChannel.close()
        }
    }
}

通用资源清理规则（必做） #

• 所有路径（成功、超时、异常）必须调用socketChannel.close()，哪怕连接没建立成功。
• 如果SocketChannel注册到了Selector，先调用SelectionKey.cancel()，再关闭Selector（如果是临时创建的）。
• 绝对不能直接丢弃未关闭的SocketChannel，NIO资源不会被GC自动回收。

性能优化建议 #

• 用Socket连接池：别每次请求都新建SocketChannel，复用已连接的通道，减少资源创建销毁的开销。
• 复用Selector：不要每次请求都新建Selector，一个Selector可以管理多个Channel，避免线程爆炸。
• 用Dispatchers.IO处理IO操作：别用Dispatchers.Default，IO线程池是专为IO密集型任务优化的，能复用线程。

排查验证步骤 #

1. 超时后打印socketChannel.isOpen()，确认是否真的关闭了。
2. 用jstack <pid>看线程栈，有没有大量阻塞在Selector.select()的线程。
3. 用lsof -p <pid>（Linux）或Process Explorer（Windows）看socket句柄数，有没有持续增长不释放的情况。

内容的提问来源于stack exchange，提问作者Wolfy