Java的NIO以及線程并發
一、NIO的出現
NIO是JDK1.4里面才出現的東東，他給大家帶來的***好處是異步socket。其它file,pipe暫時就不多談了。
在JDK1.4出現之前，如果你需要編寫一個Java服務器，為了實現異步操作，你必須為每個連接請求生成一個Java線程，當連接請求很多時，線程的調度，上下文切換，所付出的代價是非常昂貴，而且由于Java是跨平臺的，各個平臺對線程的支持并不相同，性能也不相同，因此傳統的Java服務器編程架構是低效的且代價貴，dl大俠寫了個util.concurrent包后，總算是減輕了線程調度給java程序員帶來的痛苦，但是相比之與C、C＋＋寫出來的服務器，java服務器在性能要求很高的情況下，基本上沒有什么競爭力，甚至是入圍的權利的都沒有。
二、異步socket的實現
NIO出現后，好像讓java的程序員有了楊眉吐氣的機會，怎么個吐氣法，當時大家是個什么感受，俺是不知道，因為當時俺不搞java，對java的認識有限。
NIO是一個基于事件的IO架構，最基本的思想就是：有事件我通知你，你再去做你的事情，沒事件時你大可以節約大把時間去做其它任何事情。而且NIO的主線程only one，不像傳統的模型，需要N個線程去，也減輕了JVM的工作量，使得JVM處理任務時顯得更加高效。
剛開始接觸NIO時，被N層的Channel架構、網上鋪天蓋地的好評給鎮住了，想想也應當是個很成熟的產品了，網上資料這么多，抄一抄Jetty、Tomcat以及其它一些牛B的源代碼，基本上就能搞定了，此時沒有想到大家受同步的影響這么深，也沒有想到連最基本的異步概念都沒有搞清楚就去寫代碼，搞出一堆的問題來（這是后話，后面再說）。
現在研究了NIO以后，發現NIO實際上在Java中做的工作是很簡單，就是將事件進行收集和分發，我們結合一個經典的調用例子來說明這個問題，我就不從NIO的基本使用說起了，大家可以查其它的資料，網上一大把。
當Channel注冊至Selector以后，我們的最經典的調用方法，是這樣子的。
- while(somecondition)
- {
- int n = selector.select(TIMEOUT);
- if(n == 0) continue;
- for (Iterator iter = selector.selectedKeys().iterator(); iter.hasNext();)
- {
- if (key.isAcceptable())
- doAcceptable(key);
- if (key.isConnectable())
- doConnectable(key);
- if (key.isValid() && key.isReadable())
- doReadable(key);
- if (key.isValid() && key.isWritable())
- doWritable(key);
- iter.remove();
- }
- }
這只是個小例子啊，什么異常我就懶得抓了。
nio中取得事件通知，就是在selector的select事件中完成的，在selector事件時有一個線程，這個線程具體的處理簡單點說就是：向操作系統詢問，selector中注冊的Channel&&SelectionKey的偶對各種事件是否有發生，如果有則添加到selector的selectedKeys屬性Set中去，并返回本次有多少個感興趣的事情發生。程序員發現這個值>0，表示有事件發生，馬上迭代selectedKeys中的SelectionKey，根據Key中的表示的事件，來做相應的處理。
實際上，這段說明表明了異步socket的核心，即異步socket不過是將多個socket的調度（或者還有他們的線程調度）全部交給操作系統自己去完成，異步的核心Selector，不過是將這些調度收集、分發而已。因為操作系統的socket、線程調度再咋D也比你JVM中要強，效率也高。
而且就算jvm做的和操作系統一樣好，性能一樣高（當然這是不現實的），使用異步socket你至少也節約了一半的系統消耗，想想假定操作系統本身也是使用線程來維護N個socket連接，在傳統的java編程中，你還必須為這些socket還多起一個java線程，那至少是2N個線程，現在只需要N+1。在高并發的情況下，你自己去想吧。
懂了這個道理，異步socket也就好寫了，也不會搞得思路混亂了。
三、 異步Socket中應當注意的事情
1. 讀
異步socket最基本的理念就是事件通知，前面也說了，有事件通知你了，你才該做你應當做的事情。在異步socket中當注冊了一個OP_READ事件后，你就等著Selector通知你吧，如果沒有通知你，你在家睡大覺都行。
在這里，我們有人出現的錯誤就是受同步的影響，自己去主動讀，而且還搞出了多線程，如果仔細考慮一下，就不會出現這個問題了。同步socket中，調用read方法讀取IO中的數據時，通常情況下如果沒有數據read方法會阻塞，且是同步的，所以當多個線程同時訪問時，read方法是線程安全的。
而在異步下就不同，異步是不會阻塞的，有什么就返回什么，你主動去讀，只要有數據，你就可以拿走，在多線程的情況下，也許你是想讓***個線程讀取，but此時來數據時正好是線程2讀到了，那線程2就高高興興的拿去，而線程1還在苦苦等待，這樣導致數據混亂不說，如果后面再也不來數據了，線程1就是死循環啦。
2. 寫
在異步socket中，寫是唯一一個主動點的操作，但是也不能直接去寫Channel，而是應當先把自身注冊為OP_WRITABLE，這時Selector就會發現你的存在，并把給發一個write事件，你這時后就可以寫了，不過這時候有個小小的技巧，就是你執行寫操作之前，請取消掉你的寫注冊，否則你的cpu肯定是100%。
3. 等待
在傳統的服務器編程中，由于對于每個請求都是產生的一個線程，因此你在你每個請求線程中wait也好,sleep也好，不會影響別人。但是異步不同，他的主線程只有一個，基本上每個處理都是線性的，也就是說處理完***個，然后才能處理第二個，因此nio是一個極好的處理短連接的架構。
我們現在出現的問題是，有人受同步的影響，沒有搞清異步是如何處理，竟然在方法處理中用上sleep，而且一等還是3秒，這意味著什么，3秒才能處理一個請求，My god，我要一個3秒才能處理一個請求的服務器干嘛啊，還是60年代啊：（
如果出現這樣的需要等待的情況，應當另起一個線程（推薦使用線程池）去完成這個“長”時間的任務，或者將其它交給一個消息隊列，通過發消息的方式將給別人去完成也行，客戶端能等，你服務器怎么也能等呢？寫出這樣的代碼，基本上一個服務器也就廢了。
原文鏈接：http://www.cnblogs.com/sunwei2012/archive/2010/02/11/1667501.html
【編輯推薦】
