后来查看jetty源代码，具体原因如下：
问题：
1. web应用依赖的第三方服务临时挂掉（使用httpclient调用），导致请求量剧增（客户端重试机制），jetty停止服务。（前置机nginx->不同服务器（nginx和jetty））
现象：
1. jetty输出大量请求分配失败日志如下：
12 Jan 2016 18:59:25.828 WARN nio[243]-Dispatched Failed! SCEP@34b2eaa5{l(/127.0.0.1:29829)<->r(/127.0.0.1:8080),s=-1,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=0}-{AsyncHttpConnection@4e4b11aa,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-14,l=0,c=0},r=0} to org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager@7839e749
2.linux服务器close_wait急剧增加：
3.服务迅速不可用，暂时解决办法，对nginx切流量，重启jetty，jetty使用httpclient调用请求恢复。
解决：
1. jetty配置文件，改用默认队列（当时采用固定长度队列，是防止jetty贪吃，导致jetty崩溃问题，目前在nginx限流解决）
问题：
1. 为什么使用固定长度队列，就会出现Dispatched Failed?
1）使用固定长度队列，当httpclient请求第三服务时，第三方服务出现问题，线程池所有线程都堵塞在请求第三方服务处；2）外部请求不断过来，队列占满，请求再源源不断过来时，就会采用丢弃任务策略，就会输出Dispatched Failed
2. 服务器为什么出现大量close_wait?
1）通过ss -ant | awk '{++s[$1]} END {for(k in s) print k,s[k]}' 命令查看各个状态，发现close_wait居多，并且都是同一个服务器nginx流量打到本服务器jetty上的
2）查看nginx日志：2015/11/24 16:38:56 [error] 25941#0: *15256 upstream timed out (110: Connection timed out) while reading response header from upstream, client:
3 ）通过日志和close_wait截图看出，主要是jetty发送很多segment后，每次都超时，导致nginx关闭socket，导致出现close_wait状态。
3. 为什么使用默认无界队列，系统就没问题？
1）使用无界队列，所有请求都会能被Dispatch给线程处理，当使用httpcliet调用第三方服务出现问题，由于httpclient设有超时，web应用会自动关闭httpclient（所以jetty作为客户端调用httpclient服务不会出现close_wait）
2) 此时，相对于nginx而言，jetty没有出现Dispatched Failed错误，而是等待获取httpclient链接超时，自动关闭链接。而不是nginx端关闭，所以不会出现close_wait状态。
备注：
1. 附上jetty使用filter限流方案：http://www.eclipse.org/jetty/documentation/current/qos-filter.html#qos-understanding