java NIO教程

NIO 是 New I/O 的縮寫，要了解它真正的內涵，需要掌握的知識還是比較多的。我努力在這幾篇筆記裡，勾勒出整個io的面貌。為大家的深入學習鋪路。

I/O簡史

想理解I/O的全部，java的I/O歷史是必須要了解的。 java的I/O歷史也從一個側面反應了java的發展史。

JDK1.0-1.3

在這個時期的java中，基本上可以說沒有完整的I/O支援。因為這時期的java I/O操作是阻塞的，所以I/O效率是較為底下的，基本上想要有比較好的I/O解決方案，基本上靠自己。這時期java在伺服器端一直沒有重複使用，和糟糕的I/O效率是有很大的關係的。不但I/O弄的不好，而且一連串週邊措施都沒弄好。所支援的字符集編碼有限，經常要進行手工的編碼工作。而且沒有正規表達式，處理資料十分困難。

JDK1.4-1.6

2002年發布的java1.4中，非阻塞I/O以JSR-51的身份加入java語言。同時字符集的編解碼能力大大提升。而且有了基於perl實作的正規表示式類別庫。同時部分舊I/O底層實現，也用新I/O的方式重寫，使得舊I/O的性能也有了提升。終於java在伺服器端開始流行了起來。

同時，第三方也開始發力。谷歌發布了Guava類別庫，其中的I/O部分，極大的簡化了一些文件的操作和資料的傳輸。同時Trustin Lee領導編寫的nio框架netty與mina也廣為流傳開來，這對java nio的發展業是有著極大的推動力的。

JDK1.7至今

隨著JSR-203的推出，是我們在java1.7中見到了NIO2。它為我們提供了必非阻塞更強大的非同步I/O操作能力，同時提供了一系列極為方便的對檔案系統和檔案屬性進行操作的API。以及更強大的網路I/O

I/O區別

阻塞I/O、非阻塞I/O、非同步I/O之間到底有什麼區別？為什麼每一次的進步，都會促使java I/O能力的大幅提升？我們舉一個種菜遊戲的例子。

假如有一個種菜遊戲（就跟之前的QQ農場類似），在玩家種菜以後，必須一直呆在那個網頁上，看著菜成熟，才可以收菜。這是極度浪費時間的，使用者體驗一定不會好。這個遊戲後來進行了改版，玩家種菜之後不用再一直停留在那個網頁上了，只是需要時不時來看一遍，如果某一次查看時發現菜成熟了，就可以收菜了。當然，用戶體驗極大的提升了，用戶所浪費的時間也減少了，但是為了更加提升用戶體驗，遊戲又進行了改版。玩家種菜之後，不用再查看菜是否成熟了，等到菜成熟後，該遊戲會自動給用戶發送通知，告訴他，菜已成熟、趕緊來收。這樣用戶的基本上再也不用浪費時間了。

剛剛例子中的三個遊戲版本，代表了三種I/O。阻塞I/O：在資料沒有讀寫完成之前，CPU不可以進行下一步操作，這樣CPU只好眼睜睜的在那裡傻等。非阻塞I/O：在資料沒有讀寫完成之前，CPU可以離開，只需要每隔一段時間詢問一次。非同步I/O：在資料沒有讀寫完成之前，CPU可以離開也不用時不時的關心一下I/O，在資料讀寫完成時，主動通知CPU。三種I/O之間的效率，高低立判。

新I/O

咱們以java1.4所提出的非阻塞I/O，為切入點，開始了解全貌。

Channels

Buffers

Selectors

這三個類別構成了非阻塞I/O的核心API。

Buffer譯為快取區，它是一塊可以儲存資料的記憶體。 Channel有點像流，但它可讀可寫、從本地I/O到網路I/O都可以，絕大多數NIO都從一個Channel開始的，資料可以從Channel讀到Buffer中，也可以從Buffer 寫到Channel中。

非阻塞I/O中，CPU可以在資料沒有讀寫完成之前離開，只需要每隔一段時間詢問一次。詢問資料是否讀寫完成，所需的CPU能力是極小的，但如果CPU經常切換任務所需的保留現場和恢復現場的時間是較大的。所以可以就用一​​個執行緒來詢問資料是否準備好。一個執行緒在多個通道內詢問資料是否準備好，就需要管理多個通道的方式，這就是

使用Selector，得向Selector註冊Channel，然後呼叫它的select()方法。這個方法會一直阻塞到某個註冊的通道有事件就緒。一旦這個方法返回，線程就可以處理這些事件。