Java I/O不迷茫，一文爲你導航！
https://mp.weixin.qq.com/s/tqD72l9j6k3ch28PPBb6jQ
Java I/O不迷茫，一文爲你導航！
前言：在以前的面試中，往往問到關於Java I/O 方面的東西都感受本身吃了大虧..因此這裏搶救一下..來深刻的瞭解一下在Java之中的 I/O 究竟是怎麼回事..文章可能說明類的文字有點兒多，但願能耐心讀完..html
什麼是 I/O?
學習過計算機相關課程的童鞋應該都知道，I/O 即輸入Input/ 輸出Output的縮寫，最容易讓人聯想到的就是屏幕這樣的輸出設備以及鍵盤鼠標這一類的輸入設備，其廣義上的定義就是：數據在內部存儲器和外部存儲器或其餘周邊設備之間的輸入和輸出；java
咱們能夠從定義上看到問題的核心就是：數據/ 輸入/ 輸出，在Java中，主要就是涉及到磁盤 I/O 和網絡 I/O 兩種了；linux
簡單理解Java 流（Stream）
一般咱們說 I/O 都會涉及到諸如輸入流、輸出流這樣的概念，那麼什麼是流呢？流是一個抽象但形象的概念，你能夠簡單理解成一個數據的序列，輸入流表示從一個源讀取數據，輸出流則表示向一個目標寫數據，在Java程序中，對於數據的輸入和輸出都是採用 「流」 這樣的方式進行的，其設備能夠是文件、網絡、內存等；git
流具備方向性，至因而輸入流仍是輸出流則是一個相對的概念，通常以程序爲參考，若是數據的流向是程序至設備，咱們成爲輸出流，反之咱們稱爲輸入流。程序員
能夠將流想象成一個「水流管道」，水流就在這管道中造成了，天然就出現了方向的概念。github
「流」，表明了任何有能力產出數據的數據源對象或有能力接受數據的接收端對象，它屏蔽了實際的 I/O 設備中處理數據的細節——摘自《Think in Java》web
參考資料：深刻理解 Java中的 流 (Stream)：https://www.cnblogs.com/shitouer/archive/2012/12/19/2823641.html面試
Java中的 I/O 類庫的基本架構
I/O 問題是任何編程語言都沒法迴避的問題，由於 I/O 操做是人機交互的核心，是機器獲取和交換信息的主要渠道，因此如何設計 I/O 系統變成了一大難題，特別是在當今大流量大數據的時代，I/O 問題尤爲突出，很容易稱爲一個性能的瓶頸，也正由於如此，在 I/O 庫上也一直在作持續的優化，例如JDK1.4引入的 NIO，JDK1.7引入的 NIO 2.0，都必定程度上的提高了 I/O 的性能；數據庫
Java的 I/O 操做類在包 java.io下，有將近80個類，這些類大概能夠分紅以下 4 組：編程
基於字節操做的 I/O 接口：InputStream 和 OutputStream；
基於字符操做的 I/O 接口：Writer 和 Reader；
基於磁盤操做的 I/O 接口：File；
基於網絡操做的 I/O 接口：Socket；
前兩組主要是傳輸數據的數據格式，後兩組主要是傳輸數據的方式，雖然Socket類並不在java.io包下，但這裏仍然把它們劃分在了一塊兒；I/O 只是人機交互的一種手段，除了它們可以完成這個交互功能外，咱們更多的應該是關注如何提升它的運行效率；
00.基於字節的 I/O 操做接口
基於字節的 I/O 操做的接口輸入和輸出分別對應是 InputStream 和 OutputStream，InputStream 的類層次結構以下圖：
輸入流根據數據類型和操做方式又被劃分紅若干個子類，每一個子類分別處理不一樣操做類型，OutputStream 輸出流的類層次結構也是相似，以下圖所示：
這裏就不詳細解釋每一個子類如何使用了，若是感興趣能夠本身去看一下JDK的源碼，並且的話從類名也能大體看出一二該類是在處理怎樣的一些東西..這裏須要說明兩點：
1）操做數據的方式是能夠組合使用的：
例如：
OutputStream out = new BufferedOutputStream(new ObjectOutputStream(new FileOutputStream("fileName"))；
2）必需要指定流最終寫到什麼地方：
要麼是寫到磁盤，要麼是寫到網絡中，但重點是你必須說明這一點，並且你會發現其實SocketOutputStream是屬於FileOutputStream下的，也就是說寫網絡實際上也是寫文件，只不過寫網絡還有一步須要處理，就是讓底層的操做系統知道我這個數據是須要傳送到其餘地方而不是本地磁盤上的；
01.基於字符的 I/O 操做接口
無論是磁盤仍是網絡傳輸，最小的存儲單元都是字節，而不是字符，因此 I/O 操做的都是字節而不是字符，可是在咱們平常的程序中操做的數據幾乎都是字符，因此爲了操做方便固然要提供一個能夠直接寫字符的 I/O 接口。並且從字符到字節必須通過編碼轉換，而這個編碼又很是耗時，還常常出現亂碼的問題，因此 I/O 的編碼問題常常是讓人頭疼的問題，關於這個問題有一篇深度好文推薦一下：《深刻分析 Java 中的中文編碼問題》
下圖是寫字符的 I/O 操做接口涉及到的類，Writer 類提供了一個抽象方法 write(char cbuf[], int off, int len) 由子類去實現：
讀字符的操做接口也有相似的類結構，以下圖所示：
讀字符的操做接口中也是 int read(char cbuf[], int off, int len)，返回讀到的 n 個字節數，無論是 Writer 仍是 Reader 類它們都只定義了讀取或寫入的數據字符的方式，也就是怎麼寫或讀，可是並無規定數據要寫到哪去，寫到哪去就是咱們後面要討論的基於磁盤和網絡的工做機制。
01.字節與字符的轉化接口
另外數據持久化或網絡傳輸都是以字節進行的，因此必需要有字符到字節或字節到字符的轉化。字符到字節須要轉化，其中讀的轉化過程以下圖所示：
InputStreamReader 類是字節到字符的轉化橋樑，InputStream 到 Reader 的過程要指定編碼字符集，不然將採用操做系統默認字符集，極可能會出現亂碼問題。StreamDecoder 正是完成字節到字符的解碼的實現類。也就是當你用以下方式讀取一個文件時：
try {
StringBuffer str = new StringBuffer();
char[] buf = new char[1024];
FileReader f = new FileReader("file");
while(f.read(buf)>0){
str.append(buf);
}
str.toString();
} catch (IOException e) {}
FileReader 類就是按照上面的工做方式讀取文件的，FileReader 是繼承了 InputStreamReader 類，其實是讀取文件流，而後經過 StreamDecoder 解碼成 char，只不過這裏的解碼字符集是默認字符集。
寫入也是相似的過程以下圖所示：
經過 OutputStreamWriter 類完成，字符到字節的編碼過程，由 StreamEncoder 完成編碼過程。
磁盤 I/O 的工做機制
在介紹 Java 讀取和寫入磁盤文件以前，先來看看應用程序訪問文件有哪幾種方式；
幾種訪問文件的方式
咱們知道，讀取和寫入文件 I/O 操做都調用的是操做系統提供給咱們的接口，由於磁盤設備是歸操做系統管的，而只要是系統調用均可能存在內核空間地址和用戶空間地址切換的問題，這是爲了保證用戶進程不能直接操做內核，保證內核的安全而設計的，現代的操做系統將虛擬空間劃分紅了內核空間和用戶空間兩部分並實現了隔離，可是這樣雖然保證了內核程序運行的安全性，可是也必然存在數據可能須要從內核空間向用戶用戶空間複製的問題；
若是遇到很是耗時的操做，如磁盤 I/O，數據從磁盤複製到內核空間，而後又從內核空間複製到用戶空間，將會很是耗時，這時操做系統爲了加速 I/O 訪問，在內核空間使用緩存機制，也就是將從磁盤讀取的文件按照必定的組織方式進行緩存，入股用戶程序訪問的是同一段磁盤地址的空間數據，那麼操做系統將從內核緩存中直接取出返回給用戶程序，這樣就能夠減小 I/O 的響應時間；
00. 標準訪問文件的方式
讀取的方式是，當應用程序調用read()接口時：
①操做系統首先檢查在內核的高速緩存中是否存在須要的數據，若是有，那麼直接從緩存中返回；
②若是沒有，則從磁盤中讀取，而後緩存在操做系統的緩存中；
寫入的方式是，當應用程序調用write()接口時：
從用戶地址空間複製到內核地址空間的緩存中，這時對用戶程序來講寫操做就已經完成了，至於何時在寫到磁盤中由操做系統決定，除非顯示地調用了 sync 同步命令；
01.直接 I/O 方式
所謂的直接 I/O 的方式就是應用程序直接訪問磁盤數據，而不通過操做系統內核數據緩衝區，這樣作的目的是減小一次從內核緩衝區到用戶程序緩存的數據複製；
這種訪問文件的方式一般是在對數據的緩存管理由應用程序實現的數據庫管理系統中，如在數據庫管理系統中，系統明確地知道應該緩存哪些數據，應該失效哪些數據，還能夠對一些熱點數據作預加載，提早將熱點數據加載到內存，能夠加速數據的訪問效率，而這些狀況若是是交給操做系統進行緩存，那麼操做系統將不知道哪些數據是熱點數據，哪些是隻會訪問一次的數據，由於它只是簡單的緩存最近一次從磁盤讀取的數據而已；
可是直接 I/O 也有負面影響，若是訪問的數據再也不應用程序緩存之中，那麼每次數據都會直接從磁盤進行加載，這種直接加載會很是緩慢，所以直接 I/O 一般與 異步 I/O 進行結合以達到更好的性能；
10.內存映射的方式
內存映射是指將硬盤上文件的位置與進程邏輯地址空間中一塊大小相同的區域一一對應，當要訪問內存中一段數據時，轉換爲訪問文件的某一段數據。這種方式的目的一樣是減小數據在用戶空間和內核空間之間的拷貝操做。當大量數據須要傳輸的時候，採用內存映射方式去訪問文件會得到比較好的效率。
同步和異步訪問文件的方式
另外還有兩種方式，一種是數據的讀取和寫入都是同步操做的同步方式，另外一種是是當訪問數據的線程發出請求以後，線程會接着去處理其餘事情，而不是阻塞等待的異步訪問方式，但從筆者就《深刻分析 Java Web技術內幕》一書中的內容來看，這兩種方式更像是對標準訪問方式的一個具體說明，是標準訪問方式對應的兩種不一樣處理方法，知道就行了…
Java 訪問磁盤文件
咱們知道數據在磁盤的惟一最小描述就是文件，也就是說上層應用程序只能經過文件來操做磁盤上的數據，文件也是操做系統和磁盤驅動器交互的一個最小單元。值得注意的是 Java 中一般的 File 並不表明一個真實存在的文件對象，當你經過指定一個路徑描述符時，它就會返回一個表明這個路徑相關聯的一個虛擬對象，這個多是一個真實存在的文件或者是一個包含多個文件的目錄。爲什麼要這樣設計？由於大部分狀況下，咱們並不關心這個文件是否真的存在，而是關心這個文件到底如何操做。例如咱們手機裏一般存了幾百個朋友的電話號碼，可是咱們一般關心的是我有沒有這個朋友的電話號碼，或者這個電話號碼是什麼，可是這個電話號碼到底能不能打通，咱們並非時時刻刻都去檢查，而只有在真正要給他打電話時纔會看這個電話能不能用。也就是使用這個電話記錄要比打這個電話的次數多不少。
什麼時候真正會要檢查一個文件存不存？就是在真正要讀取這個文件時，例如 FileInputStream 類都是操做一個文件的接口，注意到在建立一個 FileInputStream 對象時，會建立一個 FileDescriptor 對象，其實這個對象就是真正表明一個存在的文件對象的描述，當咱們在操做一個文件對象時能夠經過 getFD() 方法獲取真正操做的與底層操做系統關聯的文件描述。例如能夠調用 FileDescriptor.sync() 方法將操做系統緩存中的數據強制刷新到物理磁盤中。
下面以上文讀取文件的程序爲例，介紹下如何從磁盤讀取一段文本字符。以下圖所示：
當傳入一個文件路徑，將會根據這個路徑建立一個 File 對象來標識這個文件，而後將會根據這個 File 對象建立真正讀取文件的操做對象，這時將會真正建立一個關聯真實存在的磁盤文件的文件描述符 FileDescriptor，經過這個對象能夠直接控制這個磁盤文件。因爲咱們須要讀取的是字符格式，因此須要 StreamDecoder 類將 byte 解碼爲 char 格式，至於如何從磁盤驅動器上讀取一段數據，由操做系統幫咱們完成。至於操做系統是如何將數據持久化到磁盤以及如何創建數據結構須要根據當前操做系統使用何種文件系統來回答，至於文件系統的相關細節能夠參考另外的文章。
參考文章：深刻分析 Java I/O 的工做機制
關於這一part，咱們只須要了解一下就能夠，我也是直接複製就完事兒…
Java 序列化技術
Java序列化就是將一個對象轉化成一串二進制表示的字節數組，經過保存或轉移這些字節數據來達到持久化的目的。須要持久化，對象必須繼承java.io.Serializable 接口，或者將其轉爲字節數組，用於網絡傳輸；
一個實際的序列化例子
第一步：建立一個用於序列化的對象
爲了具體說明序列化在Java中是如何運做的，咱們來寫一個實際的例子，首先咱們來寫一個用於序列化的對象，而後實現上述的接口：
/**
* 用於演示Java中序列化的工做流程...
*
* @author: @我沒有三顆心臟
* @create: 2018-08-15-下午 14:37
*/
public class People implements Serializable{
public String name;
public transient int age;
public void sayHello() {
System.out.println("Hello,My Name is " + name);
}
}
注意：一個類的對象想要序列化成功，必須知足兩個條件
①實現上述的接口；
②保證該類的全部屬性必須都是可序列化的，若是不但願某個屬性序列化（例如一些敏感信息），能夠加上
transient關鍵字；
第二步：序列化對象
以下的代碼完成了實例化一個 People 對象並其序列化到D盤的根目錄下的一個操做，這裏呢按照 Java 的標準約定將文件的後綴寫成 .ser 的樣子，你也能夠寫成其餘的…
People people = new People();
people.name = "我沒有三顆心臟";
people.age = 21;
try {
FileOutputStream fileOutputStream = new FileOutputStream("D:/people.ser");
ObjectOutputStream out = new ObjectOutputStream(fileOutputStream);
out.writeObject(people);
out.close();
fileOutputStream.close();
System.out.println("Serialized data is saved in D:/");
} catch (IOException e) {
e.printStackTrace();
}
第三步：反序列化對象
下面的程序完成了對剛纔咱們序列化的文件還原成一個People對象的過程，並獲取了其中的參數，可是注意，因爲咱們但願 age 屬性是短暫的加入了transient關鍵字， 因此咱們沒法獲取到序列化時 People 的 age 屬性：
People people = null;
try {
FileInputStream fileIn = new FileInputStream("D:/people.ser");
ObjectInputStream in = new ObjectInputStream(fileIn);
people = (People) in.readObject();
in.close();
fileIn.close();
} catch (IOException i) {
i.printStackTrace();
return;
} catch (ClassNotFoundException c) {
System.out.println("People class not found");
c.printStackTrace();
return;
}
System.out.println("Deserialized People...");
System.out.println("Name: " + people.name);
System.out.println("Age: " + people.age);
輸出結果以下：
Deserialized People...
Name: 我沒有三顆心臟
Age: 0
serialVersionUID的做用
上述的例子中咱們完成了對一個 People 對象序列化和反序列化的過程，咱們如今來作一點簡單的修改，例如把age字段的transient關鍵字去掉：
public class People implements Serializable {
public String name;
public int age;
public void sayHello() {
System.out.println("Hello,My Name is " + name);
}
}
而後咱們再運行咱們剛纔反序列化的代碼，會發現，這個時候程序居然報錯了，說是serialVersionUID不一致：
事實上，若是你常常看別人的代碼的話，或許會有留意到諸如這樣的代碼：
private static final long serialVersionUID = 876323262645176354L;
就這一長串的東西也不知道是在幹嗎的，但這其實是爲了保證序列化版本的兼容性，即在版本升級後序列化仍保持對象的惟一性；咱們經過上述的修改也感覺到了其中的一二，可是問題是：咱們並無在須要序列化的對象中寫任何關於這個UID的代碼呀？
這是個有趣的問題，一般狀況下，若是咱們實現了序列化接口，可是沒有本身顯式的聲明這個UID的話，那麼JVM就會根據該類的類名、屬性名、方法名等本身計算出一個獨一無二的變量值，而後將這個變量值一同序列化到文件之中，而在反序列化的時候一樣，會根據該類計算出一個獨一無二的變量而後進行比較，不一致就會報錯，可是我懷着強烈的好奇心去反編譯了一下.class文件，並無發現編譯器寫了UDI這一類的東西，我看《深刻分析 Java Web 技術內幕》中說，其實是寫到了二進制文件裏面了；
不顯式聲明的缺點：一旦寫好了某一個類，那麼想要修改就不行了，因此咱們最好本身顯式的去聲明；
顯式聲明的方式：①使用默認的1L做用UID；②根據類名、接口名等生成一個64位的哈希字段，如今的編譯器如IDEA、Eclipse都有這樣的功能，你們感興趣去了解下；
序列化用來幹什麼？
雖然咱們上面的程序成功將一個對象序列化保存到磁盤，而後從磁盤還原，可是這樣的功能到底能夠應用在哪些場景？到底能夠幹一些什麼樣的事情呢？下面舉一些在實際應用中的例子：
Web服務器中保存Session對象，如Tomcat會在服務器關閉時把session序列化存儲到一個名爲session.ser的文件之中，這個過程稱爲session的鈍化；
網絡上傳輸對象，如分佈式應用等；
關於序列化的一些細節
1.若是一個類沒有實現Serializable接口，可是它的基類實現了，那麼這個類也是能夠序列化的；
2.相反，若是一個類實現了Serializable接口，可是它的父類沒有實現，那麼這個類仍是能夠序列化（Object是全部類的父類），可是序列化該子類對象，而後反序列化後輸出父類定義的某變量的數值，會發現該變量數值與序列化時的數值不一樣（通常爲null或者其餘默認值），並且這個父類裏面必須有無參的構造方法，否則子類反序列化的時候會報錯。
瞭解到這裏就能夠了，更多的細節感興趣的童鞋能夠自行去搜索引擎搜索..
網絡 I/O 工做機制
數據從一臺主機發送到網絡中的另外一臺主機須要通過不少步驟，首先雙方須要有溝通的意向，而後要有可以溝通的物理渠道（物理鏈路），其次，還要保障雙方可以正常的進行交流，例如語言一致的問題、說話順序的問題等等等；
Java Socket 的工做機制
看到有地方說：網絡 I/O 的實質其實就是對 Socket 的讀取；那Socket 這個概念沒有對應到一個具體的實體，它是描述計算機之間完成相互通訊一種抽象功能。打個比方，能夠把 Socket 比做爲兩個城市之間的交通工具，有了它，就能夠在城市之間來回穿梭了。交通工具備多種，每種交通工具也有相應的交通規則。Socket 也同樣，也有多種。大部分狀況下咱們使用的都是基於 TCP/IP 的流套接字，它是一種穩定的通訊協議。
下圖是典型的基於 Socket 的通訊的場景：
主機 A 的應用程序要能和主機 B 的應用程序通訊，必須經過 Socket 創建鏈接，而創建 Socket 鏈接必須須要底層 TCP/IP 協議來創建 TCP 鏈接。創建 TCP 鏈接須要底層 IP 協議來尋址網絡中的主機。咱們知道網絡層使用的 IP 協議能夠幫助咱們根據 IP 地址來找到目標主機，可是一臺主機上可能運行着多個應用程序，如何才能與指定的應用程序通訊就要經過 TCP 或 UPD 的地址也就是端口號來指定。這樣就能夠經過一個 Socket 實例惟一表明一個主機上的一個應用程序的通訊鏈路了。
創建通訊鏈路
當客戶端要與服務端通訊，客戶端首先要建立一個 Socket 實例，操做系統將爲這個 Socket 實例分配一個沒有被使用的本地端口號，並建立一個包含本地和遠程地址和端口號的套接字數據結構，這個數據結構將一直保存在系統中直到這個鏈接關閉。在建立 Socket 實例的構造函數正確返回以前，將要進行TCP 的三次握手協議，TCP 握手協議完成後，Socket 實例對象將建立完成，不然將拋出 IOException 錯誤。
與之對應的服務端將建立一個 ServerSocket 實例，ServerSocket 建立比較簡單隻要指定的端口號沒有被佔用，通常實例建立都會成功，同時操做系統也會爲 ServerSocket 實例建立一個底層數據結構，這個數據結構中包含指定監聽的端口號和包含監聽地址的通配符，一般狀況下都是「*」即監聽全部地址。以後當調用 accept() 方法時，將進入阻塞狀態，等待客戶端的請求。當一個新的請求到來時，將爲這個鏈接建立一個新的套接字數據結構，該套接字數據的信息包含的地址和端口信息正是請求源地址和端口。這個新建立的數據結構將會關聯到 ServerSocket 實例的一個未完成的鏈接數據結構列表中，注意這時服務端與之對應的 Socket 實例並無完成建立，而要等到與客戶端的三次握手完成後，這個服務端的 Socket 實例纔會返回，並將這個 Socket 實例對應的數據結構從未完成列表中移到已完成列表中。因此 ServerSocket 所關聯的列表中每一個數據結構，都表明與一個客戶端的創建的 TCP 鏈接。
數據傳輸
傳輸數據是咱們創建鏈接的主要目的，如何經過 Socket 傳輸數據，下面將詳細介紹。
當鏈接已經創建成功，服務端和客戶端都會擁有一個 Socket 實例，每一個 Socket 實例都有一個 InputStream 和 OutputStream，正是經過這兩個對象來交換數據。同時咱們也知道網絡 I/O 都是以字節流傳輸的。當 Socket 對象建立時，操做系統將會爲 InputStream 和 OutputStream 分別分配必定大小的緩衝區，數據的寫入和讀取都是經過這個緩存區完成的。寫入端將數據寫到 OutputStream 對應的 SendQ 隊列中，當隊列填滿時，數據將被髮送到另外一端 InputStream 的 RecvQ 隊列中，若是這時 RecvQ 已經滿了，那麼 OutputStream 的 write 方法將會阻塞直到 RecvQ 隊列有足夠的空間容納 SendQ 發送的數據。值得特別注意的是，這個緩存區的大小以及寫入端的速度和讀取端的速度很是影響這個鏈接的數據傳輸效率，因爲可能會發生阻塞，因此網絡 I/O 與磁盤 I/O 在數據的寫入和讀取還要有一個協調的過程，若是兩邊同時傳送數據時可能會產生死鎖，在後面 NIO 部分將介紹避免這種狀況。
NIO 的工做方式
BIO 帶來的挑戰
BIO 即阻塞 I/O，無論是磁盤 I/O 仍是網絡 I/O，數據在寫入 OutputStream 或者從 InputStream 讀取時都有可能會阻塞。一旦有線程阻塞將會失去 CPU 的使用權，這在當前的大規模訪問量和有性能要求狀況下是不能接受的。雖然當前的網絡 I/O 有一些解決辦法，如一個客戶端一個處理線程，出現阻塞時只是一個線程阻塞而不會影響其它線程工做，還有爲了減小系統線程的開銷，採用線程池的辦法來減小線程建立和回收的成本，可是有一些使用場景仍然是沒法解決的。如當前一些須要大量 HTTP 長鏈接的狀況，像淘寶如今使用的 Web 旺旺項目，服務端須要同時保持幾百萬的 HTTP 鏈接，可是並非每時每刻這些鏈接都在傳輸數據，這種狀況下不可能同時建立這麼多線程來保持鏈接。即便線程的數量不是問題，仍然有一些問題仍是沒法避免的。如這種狀況，咱們想給某些客戶端更高的服務優先級，很難經過設計線程的優先級來完成，另一種狀況是，咱們須要讓每一個客戶端的請求在服務端可能須要訪問一些競爭資源，因爲這些客戶端是在不一樣線程中，所以須要同步，而每每要實現這些同步操做要遠遠比用單線程複雜不少。以上這些狀況都說明，咱們須要另一種新的 I/O 操做方式。
NIO 的工做機制
不少人都把NIO翻譯成New IO，但我更以爲No-Block IO更接近它的本意，也就是非阻塞式IO，它雖然是非阻塞式的，但它是同步的，咱們先看一下 NIO 涉及到的關聯類圖，以下：
上圖中有兩個關鍵類：Channel 和 Selector，它們是 NIO 中兩個核心概念。咱們還用前面的城市交通工具來繼續比喻 NIO 的工做方式，這裏的 Channel 要比 Socket 更加具體，它能夠比做爲某種具體的交通工具，如汽車或是高鐵等，而 Selector 能夠比做爲一個車站的車輛運行調度系統，它將負責監控每輛車的當前運行狀態：是已經出戰仍是在路上等等，也就是它能夠輪詢每一個 Channel 的狀態。這裏還有一個 Buffer 類，它也比 Stream 更加具體化，咱們能夠將它比做爲車上的座位，Channel 是汽車的話就是汽車上的座位，高鐵上就是高鐵上的座位，它始終是一個具體的概念，與 Stream 不一樣。Stream 只能表明是一個座位，至因而什麼座位由你本身去想象，也就是你在去上車以前並不知道，這個車上是否還有沒有座位了，也不知道上的是什麼車，由於你並不能選擇，這些信息都已經被封裝在了運輸工具（Socket）裏面了，對你是透明的。
NIO 引入了 Channel、Buffer 和 Selector 就是想把這些信息具體化，讓程序員有機會控制它們，如：當咱們調用 write() 往 SendQ 寫數據時，當一次寫的數據超過 SendQ 長度是須要按照 SendQ 的長度進行分割，這個過程當中須要有將用戶空間數據和內核地址空間進行切換，而這個切換不是你能夠控制的。而在 Buffer 中咱們能夠控制 Buffer 的 capacity，而且是否擴容以及如何擴容均可以控制。
理解了這些概念後咱們看一下，實際上它們是如何工做的，下面是典型的一段 NIO 代碼：
public void selector() throws IOException {
ByteBuffer buffer = ByteBuffer.allocate(1024);
Selector selector = Selector.open();
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.configureBlocking(false);//設置爲非阻塞方式
ssc.socket().bind(new InetSocketAddress(8080));
ssc.register(selector, SelectionKey.OP_ACCEPT);//註冊監聽的事件
while (true) {
Set selectedKeys = selector.selectedKeys();//取得全部key集合
Iterator it = selectedKeys.iterator();
while (it.hasNext()) {
SelectionKey key = (SelectionKey) it.next();
if ((key.readyOps() & SelectionKey.OP_ACCEPT) == SelectionKey.OP_ACCEPT) {
ServerSocketChannel ssChannel = (ServerSocketChannel) key.channel();
SocketChannel sc = ssChannel.accept();//接受到服務端的請求
sc.configureBlocking(false);
sc.register(selector, SelectionKey.OP_READ);
it.remove();
} else if
((key.readyOps() & SelectionKey.OP_READ) == SelectionKey.OP_READ) {
SocketChannel sc = (SocketChannel) key.channel();
while (true) {
buffer.clear();
int n = sc.read(buffer);//讀取數據
if (n <= 0) {
break;
}
buffer.flip();
}
it.remove();
}
}
}
}
調用 Selector 的靜態工廠建立一個選擇器，建立一個服務端的 Channel 綁定到一個 Socket 對象，並把這個通訊信道註冊到選擇器上，把這個通訊信道設置爲非阻塞模式。而後就能夠調用 Selector 的 selectedKeys 方法來檢查已經註冊在這個選擇器上的全部通訊信道是否有須要的事件發生，若是有某個事件發生時，將會返回全部的 SelectionKey，經過這個對象 Channel 方法就能夠取得這個通訊信道對象從而能夠讀取通訊的數據，而這裏讀取的數據是 Buffer，這個 Buffer 是咱們能夠控制的緩衝器。
在上面的這段程序中，是將 Server 端的監聽鏈接請求的事件和處理請求的事件放在一個線程中，可是在實際應用中，咱們一般會把它們放在兩個線程中，一個線程專門負責監聽客戶端的鏈接請求，並且是阻塞方式執行的；另一個線程專門來處理請求，這個專門處理請求的線程纔會真正採用 NIO 的方式，像 Web 服務器 Tomcat 和 Jetty 都是這個處理方式，關於 Tomcat 和 Jetty 的 NIO 處理方式能夠參考文章《 Jetty 的工做原理和與 Tomcat 的比較》。
下圖是描述了基於 NIO 工做方式的 Socket 請求的處理過程：
上圖中的 Selector 能夠同時監聽一組通訊信道（Channel）上的 I/O 狀態，前提是這個 Selector 要已經註冊到這些通訊信道中。選擇器 Selector 能夠調用 select() 方法檢查已經註冊的通訊信道上的是否有 I/O 已經準備好，若是沒有至少一個信道 I/O 狀態有變化，那麼 select 方法會阻塞等待或在超時時間後會返回 0。上圖中若是有多個信道有數據，那麼將會將這些數據分配到對應的數據 Buffer 中。因此關鍵的地方是有一個線程來處理全部鏈接的數據交互，每一個鏈接的數據交互都不是阻塞方式，因此能夠同時處理大量的鏈接請求。
Buffer 的工做方式
上面介紹了 Selector 將檢測到有通訊信道 I/O 有數據傳輸時，經過 selelct() 取得 SocketChannel，將數據讀取或寫入 Buffer 緩衝區。下面討論一下 Buffer 如何接受和寫出數據？
Buffer 能夠簡單的理解爲一組基本數據類型的元素列表，它經過幾個變量來保存這個數據的當前位置狀態，也就是有四個索引。以下表所示：
| 索引 | 說明 |
|---|---|
| capacity | 緩衝區數組的總長度 |
| position | 下一個要操做的數據元素的位置 |
| limit | 緩衝區數組中不可操做的下一個元素的位置，limit<=capacity |
| mark | 用於記錄當前 position 的前一個位置或者默認是 0 |
在實際操做數據時它們有以下關係圖：
咱們經過 ByteBuffer.allocate(11) 方法建立一個 11 個 byte 的數組緩衝區，初始狀態如上圖所示，position 的位置爲 0，capacity 和 limit 默認都是數組長度。當咱們寫入 5 個字節時位置變化以下圖所示：
這時底層操做系統就能夠從緩衝區中正確讀取這 5 個字節數據發送出去了。在下一次寫數據以前咱們在調一下 clear() 方法。緩衝區的索引狀態又回到初始位置。
這裏還要說明一下 mark，當咱們調用 mark() 時，它將記錄當前 position 的前一個位置，當咱們調用 reset 時，position 將恢復 mark 記錄下來的值。
還有一點須要說明，經過 Channel 獲取的 I/O 數據首先要通過操做系統的 Socket 緩衝區再將數據複製到 Buffer 中，這個的操做系統緩衝區就是底層的 TCP 協議關聯的 RecvQ 或者 SendQ 隊列，從操做系統緩衝區到用戶緩衝區複製數據比較耗性能，Buffer 提供了另一種直接操做操做系統緩衝區的的方式即 ByteBuffer.allocateDirector(size)，這個方法返回的 byteBuffer 就是與底層存儲空間關聯的緩衝區，它的操做方式與 linux2.4 內核的 sendfile 操做方式相似。
Java NIO 實例
上面從 NIO 中引入了一些概念，下面咱們對這些概念再來進行簡單的複述和補充：
緩衝區Buffer：緩衝區是一個對象，裏面存的是數據，NIO進行通信，傳遞的數據，都包裝到Buffer中，Buffer是一個抽象類。子類有ByteBuffer、CharBuffer等，經常使用的是字節緩衝區，也就是ByteBuffer；
通道Channel：channel是一個通道，通道就是通流某種物質的管道，在這裏就是通流數據，他和流的不一樣之處就在於，流是單向的，只能向一個方向流動，而通道是一個管道，有兩端，是雙向的，能夠進行讀操做，也能夠寫操做，或者二者同時進行；
多路複用器Selector：多路複用器是一個大管家，他管理着通道，通道把本身註冊到Selector上面，Selector會輪詢註冊到本身的管道，經過判斷這個管道的不一樣的狀態，來進行相應的操做；
NIO 工做機制的核心思想就是：客戶端和服務器端都是使用的通道，通道具備事件，能夠將事件註冊到多路複選器上，事件有就緒和非就緒兩種狀態，就緒的狀態會放到多路複選器的就緒鍵的集合中，起一個線程不斷地去輪詢就緒的狀態，根據不一樣的狀態作不一樣的處理
參考資料：https://wangjingxin.top/2017/01/17/io/
NIO 和 IO 的主要區別
面向流與面向緩衝.
Java NIO和IO之間第一個最大的區別是，IO是面向流的，NIO是面向緩衝區的。Java IO面向流意味着每次從流中讀一個或多個字節，直至讀取全部字節，它們沒有被緩存在任何地方。此外，它不能先後移動流中的數據。若是須要先後移動從流中讀取的數據，須要先將它緩存到一個緩衝區。 Java NIO的緩衝導向方法略有不一樣。數據讀取到一個它稍後處理的緩衝區，須要時可在緩衝區中先後移動。這就增長了處理過程當中的靈活性。阻塞與非阻塞IO
Java IO的各類流是阻塞的。這意味着，當一個線程調用read() 或 write()時，該線程被阻塞，直到有一些數據被讀取，或數據徹底寫入。該線程在此期間不能再幹任何事情了。 Java NIO的非阻塞模式，使一個線程從某通道發送請求讀取數據，可是它僅能獲得目前可用的數據，若是目前沒有數據可用時，該線程能夠繼續作其餘的事情。 非阻塞寫也是如此。一個線程請求寫入一些數據到某通道，但不須要等待它徹底寫入，這個線程同時能夠去作別的事情。線程一般將非阻塞IO的空閒時間用於在其它通道上執行IO操做，因此一個單獨的線程如今能夠管理多個輸入和輸出通道（channel）。選擇器（Selectors）
Java NIO的選擇器容許一個單獨的線程來監視多個輸入通道，你能夠註冊多個通道使用一個選擇器，而後使用一個單獨的線程來「選擇」通道：這些通道里已經有能夠處理的輸入，或者選擇已準備寫入的通道。這種選擇機制，使得一個單獨的線程很容易來管理多個通道。
Java AIO 簡單瞭解
AIO就是異步非阻塞IO，A就是asynchronous的意思，由於NIO1.0雖然面向緩衝，利用多路複選器實現了同步非阻塞IO，但是在NIO1.0中須要使用一個線程不斷去輪詢就緒集合，開銷也是比較大的，因此在jdk1.7中擴展了NIO，稱之爲NIO2.0，NIO2.0中引入了AIO，此外NIO2.0中還引入了異步文件通道，那麼到底是怎麼實現異步的呢？
AIO 有三個特色，它的特色也能夠說明它是如何完成異步這樣的操做的：
①讀完了再通知我；
②不會加快 I/O，只是在讀完後進行通知；
③使用回調函數，進行業務處理；
AIO 的核心原理就是：對客戶端和服務器端的各類操做進行回調函數的註冊（經過實現一個CompletionHandler接口，其中定義了一個completed的成功操做方法和一個fail的失敗方法）。在完成某個操做以後，就會本身去調用該註冊到該操做的回調函數，達到異步的效果。
BIO/ NIO/ AIO 的簡單理解
咱們在這裏假設一個燒了一排開水的場景，BIO（同步阻塞IO）的作法就是，叫一個線程停留在一個水壺那，直到這個水壺燒開我再去處理下一個水壺；NIO（準備好再通知我，同步非阻塞IO）的作法就是叫一個線程不斷地去詢問每一個水壺的狀態，看看是否有水壺的狀態發生了變化，變化則再去作相應的處理；AIO（讀完了再通知我，異步非阻塞IO）的作法是在每一個水壺上都安裝一個裝置，當水壺燒開以後就會自動通知我水壺燒開了讓我作相應的處理；
若是還以爲理解起來有困難的童鞋建議閱讀如下這篇文章，相信會有收穫：
http://loveshisong.cn/編程技術/2016-06-25-十分鐘瞭解BIO-NIO-AIO.html
BIO、NIO、AIO適用場景分析
BIO方式適用於鏈接數目比較小且固定的架構，這種方式對服務器資源要求比較高，併發侷限於應用中，JDK1.4之前的惟一選擇，但程序直觀簡單易理解。
NIO方式適用於鏈接數目多且鏈接比較短（輕操做）的架構，好比聊天服務器，併發侷限於應用中，編程比較複雜，JDK1.4開始支持。
AIO方式使用於鏈接數目多且鏈接比較長（重操做）的架構，好比相冊服務器，充分調用OS參與併發操做，編程比較複雜，JDK7開始支持。
簡單總結
這篇文章大量複製粘貼到《深刻分析 Java Web 技術內幕》第二節「深刻分析 Java I/O 的工做機制」的內容，沒辦法確實不少描述性的概念以及說明，本身的說明也沒有達到用簡單語言能描述復瑣事物的程度..因此可能看起來這篇文章會有那麼點兒難如下嚥..我本身的話也是爲了寫着一篇文章查了不少資料，書也是翻了不少不少遍纔對Java 中的 I/O 相關的知識有所熟悉，不過耗費的時間也是值得的，同時也但願觀看文章的你可以有所收穫，也歡迎各位指正！
歡迎轉載，轉載請註明出處！
簡書ID：@我沒有三顆心臟
github：wmyskxz
歡迎關注公衆微信號：wmyskxz_javaweb
分享本身的Java Web學習之路以及各類Java學習資料
想要交流的朋友也能夠加qq羣：3382693
我沒有三顆心臟
- 1. Java I/O不迷茫，一文爲你導航！
- 2. 從迷茫到不迷茫
- 3. 誰的人生不迷茫 ？！ 迷茫的不止是你！
- 4. 你迷茫嗎？
- 5. 迷茫，迷茫在迷茫中！
- 6. 你迷茫過嗎？
- 7. 一點迷茫
- 8. 不爲找工作而迷茫，加油！
- 9. 記一次不大不小的迷茫
- 10. 一樣是迷茫
- 更多相關文章...
- • ionic 導航 - ionic 教程
- • jQuery Mobile 導航欄 - jQuery Mobile 教程
- • SpringBoot中properties文件不能自動提示解決方法
- • Java Agent入門實戰（一）-Instrumentation介紹與使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Java I/O不迷茫，一文爲你導航！
- 2. 從迷茫到不迷茫
- 3. 誰的人生不迷茫 ？！ 迷茫的不止是你！
- 4. 你迷茫嗎？
- 5. 迷茫，迷茫在迷茫中！
- 6. 你迷茫過嗎？
- 7. 一點迷茫
- 8. 不爲找工作而迷茫，加油！
- 9. 記一次不大不小的迷茫
- 10. 一樣是迷茫