不终止进程时完全关闭客户端Socket解决CLOSE_WAIT问题

TCP状态机中，CLOSE_WAIT是被动关闭方的专属状态：当对端主动发送FIN包断开连接，本地内核收到后自动回复ACK，套接字就会进入CLOSE_WAIT，这个状态没有内核默认超时，退出的唯一条件是本地用户态主动触发连接终止，向对端发送FIN包。
调用close(sock_fd)后仍然卡在该状态，本质原因只有一个：该套接字对应的内核文件对象引用计数没有归0，内核没有真正执行连接关闭逻辑。常见触发场景：

• 调用fork创建子进程时，套接字fd被默认继承到子进程，仅在主进程调用close只会让引用计数减1，子进程持有的fd未关闭时，引用计数不会到0
• 代码中通过dup/dup2/fcntl等接口复制过套接字fd，仅关闭了原始fd，未关闭所有复制出来的fd副本
• 代码存在逻辑分支遗漏，实际没有走到你以为的close(sock_fd)调用，比如异常分支提前return、多线程下fd被其他逻辑重新持有
• 部分异步框架、事件池（如epoll）内部会持有套接字的引用，未提前从事件池注销fd就直接调用close，也可能导致引用计数未清零

代码层面根治方案 #

• 排查fd引用泄漏：
  先通过lsof -p <进程PID> | grep CLOSE_WAIT定位卡住的套接字对应的fd编号，再通过ls -l /proc/<进程PID>/fd/<fd编号>确认套接字inode，排查是否存在多进程/多副本持有fd的情况。
  若存在fork场景，创建套接字时直接加上SOCK_CLOEXEC标志，避免fd意外泄漏给子进程；若业务确实需要子进程继承fd，要在子进程不需要该套接字时主动调用close。若代码中存在fd复制逻辑，要保证所有复制出的fd都被正确关闭，直到引用计数归0。
• 优先使用shutdown触发断连：
  由于close是文件描述符级别的操作，仅负责减引用计数，而shutdown是套接字级别的操作，会直接触发TCP断开流程。需要关闭连接时，可以先调用shutdown(sock_fd, SHUT_RDWR)触发内核发送FIN包，再逐次关闭所有持有的该套接字fd副本，避免因为引用计数问题卡在CLOSE_WAIT。
• 不要依赖内核参数自动回收：CLOSE_WAIT状态不受tcp_fin_timeout、tcp_keepalive_time等常见TCP超时参数控制，内核不会主动回收处于该状态的套接字，所有试图通过调整sysctl参数解决CLOSE_WAIT的方案都无效。

线上应急方案（无需重启进程） #

如果线上业务已经出现滞留的CLOSE_WAIT套接字，来不及发版修复，可以在不终止主进程的前提下手动清理：

1. 定位卡住的套接字对应的fd编号：执行netstat -anp | grep CLOSE_WAIT | grep <进程PID>，记录对应fd的数字编号，再通过/proc/<进程PID>/fd/路径确认该fd当前确实对应卡住的套接字，避免fd被复用后误关正常连接。
2. 用gdb attach到目标进程，直接在进程上下文执行close系统调用：

   gdb -p <进程PID>
   # 进入gdb交互后执行，替换<fd编号>为你之前查到的数字
   (gdb) call close(<fd编号>)
   (gdb) detach
   (gdb) quit
   

3. 如果是子进程持有fd导致的滞留，直接杀掉持有该fd的无关子进程即可，子进程退出后内核会自动回收其持有的fd引用，引用计数归0后主进程的套接字会自动走完关闭流程。

注意：gdb attach进程时会短暂暂停进程业务执行，操作前要评估对业务的影响，尽量在低峰期操作。

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