TCP连接CLOSED后文件描述符仍存在的原因及lsof相关疑问

我来帮你拆解这个问题——你在lsof里看到的那些TCP <HOST>:<PORT> -> <IP>:https (CLOSED)条目，可不是单纯的历史连接标记，背后其实是进程没及时释放文件描述符（fd）的问题。下面分几个点给你讲清楚：

1. 连接CLOSED和fd释放是两回事 #

TCP连接的生命周期和进程持有的fd是关联但独立的两个东西：

• 当TCP完成四次握手（或者被对方重置），内核会把连接状态改成CLOSED，但这只是内核层面的连接终结；
• 真正释放fd的动作，得靠进程主动调用close()函数。如果进程没做这件事，哪怕连接已经死了，fd依然会留在进程的文件描述符表里，占用资源。
• 这种情况大多是代码逻辑的锅：比如程序在处理连接关闭的回调时漏了close()，或者误以为连接断了fd会自动失效，根本没去管它。

2. lsof里的(CLOSED)到底是什么意思？ #

这个状态明确告诉你：内核里的TCP连接已经不存在了，但进程还攥着对应的fd不放。此时这个fd已经没法用来读写数据了（调用read()/write()会返回EBADF之类的错误），但它依然占着进程的fd配额，直到进程主动释放或者退出。

3. 为什么等几分钟都不消失，只有进程退出才没？ #

内核不会替进程“收拾烂摊子”——fd是进程的资源，只有进程自己主动调用close()，或者进程退出时内核强制清理所有打开的fd，这些条目才会消失。只要进程还在跑，没释放的fd就会一直留在那儿。

举个直白的例子：你用socket()创建了一个fd，和服务器建立了连接，之后服务器关闭了连接（你的进程收到FIN包，连接变CLOSED），但你代码里忘了写close(fd)，那这个fd就会一直挂在进程里，lsof就会显示这种(CLOSED)的条目。

怎么解决这个问题？ #

• 检查代码逻辑：确保在检测到连接关闭（比如收到EOF、ECONNRESET错误，或者select/poll返回读就绪但读不到数据）时，立刻调用close()释放fd；
• 给fd设置FD_CLOEXEC标志（用fcntl()）：这样进程执行exec类调用时会自动关闭这个fd，能避免一部分场景下的泄漏；
• 定期排查：用lsof -p <你的进程PID>或者查看/proc/<PID>/fd目录，找到那些异常的fd，定位到代码里没及时关闭的地方。

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