有人說java nio在多線程環境下編程簡直就是個惡夢,其實你如果能把握住java nio API的要領,你就可以將之駕馭.
0. 一個 channal 對應一個SelectionKey in the same selector.
e.g:
SelectionKey sk=sc.register(selector, SelectionKey.OP_READ, handler);
sk==sc.register(selector, SelectionKey.OP_WRITE, handler) true?
selector.select() 每次返回的對同一channal的sk是否相同?
1.channel.register(...) may block if invoked concurrently with another registration[another.register(...)] or selection operation[selector.select(...)] involving *****the same selector*****.
這個是register方法jdk src上的原文,
e.g:
如果一個selection thread已經在select方法上等待ing,那么這個時候如果有另一條線程調用channal.register方法的話,那么它將被blocking.
2.selectionKey.cancel() : The key will be removed from all of the selector's key sets during *****the next selection operation[selector.select(...)]*****.
may block briefly if invoked concurrently with a cancellation[cancel()] or selection operation[select(...)] involving ***the same selector***.
這個也是cancel方法jdk src上的原文,
e.g:
你先將一個selectionKey.cancel(),然后隨即再channel.register to the same selector,
在cancel和register之間,如果沒有線程(包括當前線程)進行select操作的話,
那么 throws java.nio.channels.CancelledKeyException.
所以 cancel-->select-->re-register.
3.if don't remove the current selectedKey from selector.selectedKeys()[Set] 將導致 selector.select(...) not block [may be cpu 100%,specially when client cut the current channel(connection)].
e.g:
Iterator<SelectionKey> it=selector.selectedKeys().iterator();
...for/while it.hasNext()...
it.remove();<------*****must do it. or Keys' Set.clear() finally;
if remove the current selectedKey from selector.selectedKeys()[Set] but don't sk.interestOps(sk.interestOps()& (~sk.readyOps()));將導致 selector.select(...) not block [select() not block several times, or excepted exception]
4.op_write should not be registered to the selector. [may be cpu100%]
5. if involving wakeup() before select() [wakeup called several times >=1],the next select() not block [not block just once].
盡管以前有些人分析了nio的wakeup性能及not block in linux的bug,但是java nio依然是高效的,那些c/c++的牛人們去看看jre/bin目錄下的nio.dll/nio.so吧,java nio是基于select模型(這個是c/c++中常用網絡編程模型之一)的.
基于java nio的服務器:mina,girzzly[glassfish],jetty(基于girzzly),tomcat6[可以配置Http11NioProtocol]...
其中從本人對girzzly,tomcat6的源碼分析來看,它們都還沒有真正發揮出nio異步處理請求的優點,它們的讀寫還都是blocking的雖然使用了selectorPool,此外tomcat6要剝離出socket通信還要花費一定的功夫.而mina卻是名不符其實,還有bug哦.