在上節(《Java NIO框架Netty教程(十二)-併發訪問測試(中)》)，我們從各個角度對Netty併發的場景進行了測試。這節，我們將重點關注上節最後提到的問題。在多執行緒併發訪問的情況下，會出現

警告: EXCEPTION, please implement one.coder.netty.chapter.eight.ObjectClientHandler.exceptionCaught() for proper handling. java.net.ConnectException: Connection refused: no further information

的錯誤警告。 之前

OneCoder層懷疑過是埠數不夠的問題，所以還準備了一套修改作業系統埠數限制的配置。

a) windows -- 1、開啟登錄檔：regedit 2、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 3、新建 DWORD值，name：TcpTimedWaitDelay，value：0（十進位制） –> 設定為0 4、新建 DWORD值，name：MaxUserPort，value：65534（十進位制） –> 設定最大連線數65534 5、重啟系統 b) linux -- 1、檢視有關的選項 /sbin/sysctl -a|grep net.ipv4.tcp_tw    net.ipv4.tcp_tw_reuse = 0    #表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉；    net.ipv4.tcp_tw_recycle = 0    #表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉 2、修改 vi /etc/sysctl.conf    net.ipv4.tcp_tw_reuse = 1    net.ipv4.tcp_tw_recycle = 1 3、使核心引數生效sysctl -p

這套配置在測試Restlet框架併發的時候，起到了明顯的效果。

然後，這次即使 OneCoder 修改配置，併發連線也沒有明顯的上升。 OneCoder 決定換個思路，啟動多個程序對同一個服務進行持續訪問，以證明之前的連線拒絕就是因為客戶端多執行緒併發自身的問題(其實 OneCoder 一直非常懷疑是這個問題)還是服務端連線處理的問題。 修改了一下客戶端發動訊息的程式碼，使其在其執行緒內部，不停的給服務端傳送資訊。

	**
	 * 傳送Object
	 * 
	 * @param channel
	 * @author lihzh
	 * @alia OneCoder
         *
 
 @blog http://www.coderli.com
	 */
	private void sendObject(final Channel channel) {
		new Thread(new Runnable() {

			@Override
			public void run() {
				// TODO Auto-generated method stub
				for (;;) {
					Command command = new Command();
					command.setActionName("Hello action.");
					channel.write(command);
					try {
						Thread.sleep(1000);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
				}
			}
		}).start();
	}

啟動多個客戶端，效果如圖：

果然，在單個程序數量控制合理的情況下，服務端可以處理所有請求，不會出現連結拒絕的情況。總連線數輕鬆達到4，5k。（ OneCoder 注：以前超過1000都容易出錯。這裡只是測試到以前完全沒有辦法支援的情形，並沒有測試最大壓力值。） 對於測試Netty服務端壓力來說，這樣的測試， OneCoder 認為完全可以起到效果，有參考價值。因為即使單程序網路連線方面無上限，單程序能啟動的執行緒數也是有限制的，效率也一定會受到影響。所以，對於併發測試來說， OneCoder 認為可以採用上面的方式。 對於，單程序多執行緒的時，拒絕連線的問題。是在sun.nio.ch.SocketChannelImple 中的native方法checkConnect中丟擲的。這應該是跟作業系統密切相關的。 OneCoder 沒有在linux下進行測試，但是猜測在linux下，上面的設定引數是可以起到作用的，也就是會比windows下可以開啟的併發執行緒數多。當然這只是猜測。 對於windows來說，揪淨能開啟多個執行緒的併發，這個資料在 OneCoder 的環境下也是非常不穩定的。最開始的時候是，起1000個執行緒，成功的350個執行緒左右。後來， OneCoder 懷疑啟動的程式過多，尤其是跟網路相關的程式會影響測試結果，關閉了很多程式。結果，多次1000執行緒都成功連線。 OneCoder仔細排查了一下，猛然發現 OneCoder 使用了Proxifier這個代理。在代理開啟的情況下，一般只能跑到300左右。關閉有1000個執行緒基本穩定通過。最多可以跑到1500左右。目前被列為最大“嫌疑人” 以 OneCoder 目前的知識構成來說，Netty併發的測試基本可以告一段落了。再簡單的總結嘮到幾句：

1. 如果需要測試併發，可以考慮多程序，程序內多執行緒的方式測試服務端壓力。
2. OneCoder 沒有測試Netty最大可以支援多少併發，因為從目前測試的效果來看。（5個程序，每個程序1000執行緒，持續訪問同一個服務），已經完全可以滿足 OneCoder 的要求了。您也可以繼續測試下去。
3. OneCoder 使用的是windows7 32位作業系統，在測試過程其實也修改了登錄檔中的若干引數，包括上面提到的兩個。不知道是否起到了一定的作用，也就是是否使單程序可以支援的多執行緒數增加，或者服務端可以支援的連線數增加，您在測試的過程中，可以配合考慮這些引數。
4. 對於，connection refuse的具體原因， OneCoder 希望能隨著自己知識的慢慢積累，找到其真正的答案。