服务器产生大量CLOSE_WAIT状态的socket问题的排查过程

        周一高高兴兴来上班，突然同事说网关服务G挂了，偶尔正常。

        什么，10台服务竟然大部分都挂了，以下是排查步骤：

        服务简称G、A，G转发到A，服务器地址简称AIP1、AIP2。。。GIP1、GIP2。。。

       1.登到服务器上去，查看端口8000，进程还在，然后curl本地地址，可以连接，尝试其他服务器也都正常；

        2.于是联系运维同事查看网络以及负载，发现负载转发到AIP上的nginx，然后由该nginx转发到GIP上的8080端口；

        3.竟然不是不是8000端口，是不是搞错了，于是查看GIP服务器上8080端口，也在，这真是好尴尬，同一个应用，竟然在一个服务器启动两个；

        4.于是查看8080端口是否可用，还是curl，不可用，查看应用信息：netstat -antp | grep 8080，拿到pidG后查看进程信息netstat -antp | grep pidG，好多CLOSE_WAIT的socket连接；

        5. 由于是生产问题，先将pidG的信息保存下来，然后dump下堆信息:jmap -dump:live,format=b,file=heap.bin <pid>，迅速重启应用，客户端访问正常；

        6.那问题在哪呢，开始怀疑是httpClient有资源没有被关闭导致，简单查了下代码没有发现问题；

        7.万能的baidu，查了下，有说可能是tomcat的bug，于是对比生产、测试、以及本地的tomcat代码，发现确实有部分跟网上描述的一致：http://mp.weixin.qq.com/s/ppNIA__uYaEeQ6HOdY8x0Q，在此处查了不少时间；

        8.之后想到除了tomcat启动还使用了内嵌的jetty启动，于是查看8000端口是否存在问题，发现是存在的，排除tomcat的问题；

        9.继续排查代码，检查各种异常，终于发现有个地方在处理异常时没有判断G中是否有A的响应，而直接给调用方响应，很可能导致A的响应没有被正确关闭，增加这部分关闭代码；

        10.部署到测试环境，进行压测10000次，再没发现CLOSE_WAIT状态的socket，ok。

        备注：CLOSE_WAIT状态为远端已发送关闭连接信号，等待关闭的socket状态，具体可参见：http://blog.csdn.net/xiaofei0859/article/details/6044567