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

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

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

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的發展業是有著極大的推動力的。

隨著JSR-203的推出，是我們在java1.7中見到了NIO2。它為我們提供了必非阻塞更加強大的異步I/O操作能力，同時提供了一系列極為方便的對文件系統和文件屬性進行操作的API。以及更加強大的網絡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之間的效率，高低立判。

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

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

Buffer譯為緩存區，它是一塊可以存儲數據的內存。Channel有點像流，但它可讀可寫、從本地I/O到網絡I/O都可以，絕大多數NIO都從一個Channel開始的，數據可以從Channel讀到Buffer中，也可以從Buffer 寫到Channel中。非阻塞I/O中，CPU可以在數據沒有讀寫完成之前離開，只需要每隔一段時間詢問一次。詢問數據是否讀寫完成，需要的CPU能力是極小的，但如果CPU經常切換任務所需要的保留現場和恢復現場的時間是較大的。所以可以就用一個線程來詢問數據是否準備好。一個線程在多個通道內詢問數據是否準備好，就需要管理多個通道的方式，這就是。使用Selector，得向Selector注冊Channel，然后調用它的select()方法。這個方法會一直阻塞到某個注冊的通道有事件就緒。一旦這個方法返回，線程就可以處理這些事件。

說了這么多，我們該從什么地方開始呢？ 咱們從java7的新文件系統開始吧