一、问题背景
某日，运维突然在群里突然丢出告警信息：
对象类型：主机
检测规则：NET.TCP.CLOSE.WAIT
告警内容：CLOSE_WAIT状态的TCP连接数大于500
....
上面告警信息已经说的很明白，CLOSE_WAIT状态的TCP连接数过多。
如果没有网络编程经验或对网络协议也不了解的人，看着这提示可能还是一脸懵逼不知所：
CLOSE_WAIT是什么鬼？
应用上很多连接第三方服务，到底是哪个服务有问题？
如何定位哪里的代码有问题？
二、问题分析
CLOSE_WAIT是什么？
CLOSE_WAIT是TCP的一个状态，它在ESTABLISHED（连接建立）基础上，收到对方的FIN且我方已回ACK，说白了就是对方已关闭我方尚未关闭。
如果有长时间和大量的TCP处于CLOSE_WAIT状态时，代码可能是问题的，原因是连接未正确关闭。
三、如何定位代码问题
如果系统代码简单，直接去看对应的代码有没可能导致连接未关闭即可。
如果系统代码量大且对接的第三方比较多，Linux平台可以通过netstat –nap | grep CLOSE_WAIT | grep ${pid} 看看哪个IP的连接出现了问题，再针对性的查找代码。
如果IP不够直观，可以通过IP反解析成域名，如：
IP地址反查域名在线工具
http://ip.yqie.com/iptodomain.aspx
当然如果本地环境可以复现最好不过了，可以在java.net.Socket或java.net.InetSocketAddress$InetSocketAddressHolder类的构造函数设置断点进行DEBUG
如果是生产环境，可以使用arthas(https://alibaba.github.io/arthas/)的stack命令，再加入IP过滤参数：
stack java.net.InetSocketAddress$InetSocketAddressHolder <init>
然后静静地等等Socket连接的建立即可知道产生连接代码的位置：
紧急的生产问题一般都会heap dump然后重启应用的，理论上可以通过MAT查找分析属性released状态为false的org.apache.http.impl.execchain.ConnectionHolder对象，再找到关联的incoming references对象CloseableHttpResponse（限于HttpClient）。
四、CLOSE_WAIT有什么影响？
如果代码有问题导致出现大量的CLOSE_WAIT会有什么影响呢，会影响业务吗？
Socket网络连接是一种资源，资源泄露肯定会有影响的。
首先对于系统的影响，每个Socket连接都需要一个随机端口号（作为Client），而系统理论上最大支持65535；
另外，在Linux中，网络连接是一个文件描述符，受限于系统ulimit –n参数，如果达到最大会导致“Too many open files”。
对于应用来说，应用一般是使用连接池，连接池是有最大数量限制的，如果没有及时释放导致连接泄露耗尽，线程就无法获取新的连接而影响业务。如果连接池的maxWait设置过大会造成线程阻塞时间过长，对于流量大的系统极容易造成大量请求阻塞甚至雪崩。
五、问题总结
任何与资源相关的必须要确保关闭。Java有Closeable接口，可以通过try ... 语法糖自动关闭释放。
了解基本的网络编程知识和相应的定位工具。
开发阶段加强代码审查，压力测试也是发现资源问题的必要手段，同时生产环境配备必要的基础监控能力。
六、参考
CLOSE_WAIT问题分析与定位
https://mp.weixin.qq.com/s/_YmYVxwMOzZjETYlnbToZw
我是如何确认线上CLOSE_WAIT产生的原因及如何解决的
https://www.cnblogs.com/dukuan/p/8178728.html#4334700
简单的 HTTP 调用，为什么时延这么大？
https://mp.weixin.qq.com/s/lvs-3VXfrScdOQVRkkLyRw
