记一次too many open files

记一次too many open files

too many open files是个热点词汇，百度一搜一大把，有从操作系统层面深入分析的，有从具体现象查找原因的，不一而足。报错虽都是相同，背后原因却各有各的不同。最近在项目也遇到这个错，遂记下查找过程，既沾沾热点，亦备以后查询。

问题，HttpClient发请求时报too many open files。

这个问题，操作系统层面原因是程序打开的句柄数超过系统的设置，无法再建立socket连接。Linux操作系统通过ulimit -n可以查看每个程序允许的最大句柄数，默认是1024。

首先我考虑是否因为HttpClient建立的socket没有正确关闭？每次我们用HttpClient发送请求后都调用releaseConnection，这个方法将释放连接，但不关闭连接，而是把它归还连接池，等待复用。可以设置连接池PoolingClientConnectionManager最大可建立的连接数。我们程序设置是200，所以可能不是HttpClient耗尽了连接（先不考虑HttpClient可能的bug）。

不是程序作为Client耗尽连接，就有可能是程序作为Server耗尽连接。通过netstat -ano|grep tomcat端口发现大量CLOSE_WAIT状态连接，CLOSE_WAIT是被动关闭的一方保持的状态，
过多的CLOSE_WAIT连接说明被动关闭的一方没有正确处理连接关闭。关于http协议3次握手4次挥手过程及相关状态，请参考
http://www.cnblogs.com/sunxucool/p/3449068.html

经过仔细排查，发现系统有这样的业务：一个http请求处理过程中，往缓冲区Queue添加数据，采用put阻塞方法，当Queue满时，http请求处理线程阻塞，客户端会超时断开连接，服务器端因阻塞无法释放连接，就会产生大量CLOSE_WAIT状态连接。这是一个标准生产者-消费者模式，结合业务场景判断Queue缓存消息是允许丢失的，将阻塞方法put改为非阻塞方法add即解决这一问题。