貪吃的jetty被撐死了

在大量請求並且請求處理時間較長的情況下，jetty的nio模式會導致容器執行緩慢。

用apache ab對jetty容器發出大規模持續的併發請求，

用命令「jstat -gcutil -h 10 pid 1000"檢視gc情況，等到young、old區到100%時停止施壓。

用「jmap -histo pid | less" 可以看到大量的selectchannelendpoint物件。

首先介紹一下jetty的nio模式，如下圖

mainreactor：jetty從執行緒池中分配乙個執行緒用於接受使用者的連線請求（serversocketchannel.accpet()），

這個執行緒就做一件事，接受使用者的連線，將channel註冊到selector中。

_manager.dispatch(new runnable()
catch(ioexception e)
}}});

而jetty的subreactor執行緒詢註冊進來的channel，將channel包裝成selectchannelendpoint物件加入到_endpoints。（可以把endpoint看作是乙個連線）

private concurrentmap_endpoints = new concurrenthashmap();  
public void doselect() throws ioexception 
...}

為什麼要加入到_endpoints，為了對所有的endpoint做空閒檢查。

public void doselect() throws ioexception 
} });
}。。。
}

這裡有個問題，**動作需要從執行緒池中分配執行緒處理，而如果執行緒池中沒有空閒的執行緒時，那麼**動作將無法正常進行。所以嘗試修改__idle_tick到30毫秒（預設是400），希望能提高空閒檢查頻率，卻無法起效。

還有這個可惡的_endpoints物件，它將持有大量的endpoint，而這些endpoint又得不到及時處理，記憶體都被它消耗光。

我配置的最大執行緒池為250，任務佇列長度無限制

250

在jvm的young、old區達到100%時，250執行緒也都已經分配（可以用命令"jstack pid | grep "\"qtp" | wc -l"檢視），但是很多都block住了；因為執行緒執行過程中也會有物件建立，也需要一點記憶體空間，可已經沒有記憶體空間，杯具就這樣發生了。

如果把mainreactor比作人在吃東西，那麼subreator就是他的胃在消化，

大部分情況都是吃個7分飽，此時胃的消化能力很強，

一旦出現暴飲暴食，就會出現胃脹，消化能力反而減弱。

分析下來覺得jetty缺了胃反射功能，胃脹資訊沒有即使反饋給大腦。

可以適當擴充套件一下mainreactor，看下面的**：

_manager.dispatch(new runnable()
catch(ioexception e)
}}});

新增了_manager.islowresourcesconnections()方法，嘴巴準備吃的時候要先問一下胃先。

subreactor新增乙個新方法：

public boolean islowresourcesconnections()