之前更新了幾篇關於JVM研究的文章，其實也是在做本篇文章驗證的時候，跑的有點遠，呵呵。迴歸Netty教程，這次要講的其實是針對一個問題的研究和驗證結論。另外，最近工作比較忙，所以可能會分文章更新一些階段性的成果，而不是全部彙總更新，以免間隔過久。

起因是一個朋友，通過微博私信給我一個問題，大意是說他在用Netty做併發測試的時候，會出現大量的connection refuse資訊，問我如何解決。

沒動手就沒有發言權，所以OneCoder決定測試一下：

/**
 * @author lihzh
 * @alia OneCoder
 * @blog http://www.coderli.com
 */
 

public class ConcurrencyNettyTestHandler extends SimpleChannelHandler {

	private static int count = 0;

	/**
	 * 當接受到訊息的時候觸發
	 */
	@Override
	public void channelConnected(ChannelHandlerContext ctx,
			final ChannelStateEvent e) throws Exception {
		for (int i = 0; i < 100000; i++) {
			Thread t = new
 
 Thread(new Runnable() {
				@Override
				public void run() {
					sendObject(e.getChannel());
				}
			});
			System.out.println("Thread count: " + i);
			t.start();
		}

	}

	/**
	 * 傳送Object
	 * 
	 * @author lihzh
	 * @alia OneCoder
	 */
	private void sendObject(Channel channel) {
 

		count++;
		Command command = new Command();
		command.setActionName("Hello action.");
		System.out.println("Write: " + count);
		channel.write(command);
	}
}

執行結果：

Hello action.: 99996
Hello action.: 99997
Hello action.: 99998
Hello action.: 99999
Hello action.: 100000

你可能會驚訝，10w個請求都能通過？呵呵，細心的同學，可能會發現，這其實並不是併發，而只是所謂10w個執行緒的，單channel的偽併發，或者說是一種持續的連續訪問。並且，如果你跑一下測試用例，會發現，Server端開始接受處理訊息，是在Client端10w個執行緒請求都結束之後再開始的。這是為什麼？

其實，如果您看過OneCoder的《Java NIO框架Netty教程(七)-再談收發資訊次數問題》，應該會有所聯想。不過坦白的說，OneCoder也是在經過一番周折，一番Debug以後，才發現了這個問題。當OneCoder線上程內斷點以後，放過一個執行緒，接收端就會有一條資訊出現，這其實是和之前文章裡介紹的場景是一樣的。所以，呵呵，可能對您來說，看了這篇文章，並沒有更多的收穫，但是對OneCoder來說，確實是經歷了不小的周折，繞了挺大的彎子，也算是對程式碼的再熟悉過程吧。

下篇我們會面對真正併發的問題：）