IO技術在JDK中算是極其複雜的子產品，其複雜的一個關鍵原因就是IO操作和系統核心的關聯性，另外網絡程式設計，檔案管理都依賴IO技術，而且都是程式設計的難點，想要整體了解IO流，先從Linux作業系統開始。IO流正常讀寫模式，即讀取到資料然後寫出，還有一種緩沖模式，即資料先加載到緩沖數組，在讀取的時候判斷是否要再次填充緩沖區，緩沖模式的優點十分明顯，保證讀寫過程的高效率，并且與資料填充過程隔離執行，在BufferedInputStream、BufferedReader類中是對緩沖邏輯的具體實作。
IO技術在JDK中算是極其複雜的子產品，其複雜的一個關鍵原因就是IO操作和系統核心的關聯性，另外網絡程式設計，檔案管理都依賴IO技術，而且都是程式設計的難點，想要整體了解IO流，先從Linux作業系統開始。
Linux空間隔離
Linux使用是區分使用者的，這個是基礎常識，其底層也區分使用者和核心兩個子產品：
User space：使用者空間
Kernel space：核心空間
常識使用者空間的權限相對核心空間操作權限弱很多，這就涉及到使用者與核心兩個子產品間的互動，此時部署在服務上的應用如果需要請求系統資源，則在互動上更為複雜：
使用者空間本身無法直接向系統釋出排程指令，必須通過核心，對于核心中資料的操作，也是需要先拷貝到使用者空間，這種隔離機制可以有效的保護系統的安全性和穩定性。
參數檢視
可以通過Top指令動态檢視各項資料分析，程序占用資源的狀況：
<code>us</code>：使用者空間占用CPU的百分比;
<code>sy</code>：核心空間占用CPU的百分比；
<code>id</code>：空閑程序占用CPU的百分比；
<code>wa</code>：IO等待占用CPU的百分比；
對<code>wa</code>名額，在大規模檔案任務流程裡是監控的核心項之一。
IO協作流程
此時再看上面圖【1】的流程，當應用端發起IO操作的請求時，請求沿着鍊路上的各個節點流轉，有兩個核心概念：
節點互動模式：同步與異步；
IO資料操作：阻塞與非阻塞；
這裡就是檔案流中常說的：【同步/異步】IO,【阻塞/非阻塞】IO，下面看細節。
使用者線程與核心的互動方式，應用端請求對應一個線程處理，整個過程中accept(接收)和read(讀取)方法都會阻塞直至整個動作完成：
在正常CS架構模式中，這是一次IO操作的基本過程，該方式如果在高并發的場景下，用戶端的請求響應會存在嚴重的性能問題，并且占用過多資源。
在同步阻塞IO的基礎上進行優化，目前線程不會一直等待資料就緒直到完成複制：
線上程請求後會立即傳回，并不斷輪詢直至拿到資料，才會停止輪詢，這種模式的缺陷也是顯而易見的，如果資料準備好，在通知線程完成後續動作，這樣就可以省掉很多中間互動。
在異步模式下，徹底摒棄阻塞機制，過程分段進行互動，這與正常的第三方對接模式很相似，本地服務在請求第三方服務時，如果請求過程耗時很大，會異步執行，第三方第一次回調，确認請求可以被執行；第二次回調則是推送處理結果，這種思想在處理複雜問題時，可以很大程度的提高性能，節省資源：
異步模式對于性能的提升是巨大的，當然其相應的處理機制也更複雜，程式的疊代和優化是無止境的，在NIO模式中再次對IO流模式進行優化。
File類作為檔案和目錄路徑名的抽象表示，用來擷取磁盤檔案的相關中繼資料資訊，例如：檔案名稱、大小、修改時間、權限判斷等。
注意：File并不操作檔案承載的資料内容，檔案内容稱為資料，檔案自身資訊稱為中繼資料。
上述案例使用了File類中的基本構造和常用方法（讀取、判斷、建立、删除）等，JDK源碼在不斷的更新疊代，通過類的構造器、方法、注釋等去判斷類具有的基本功能，是作為開發人員的必備能力。
在File檔案類中缺乏兩個關鍵資訊描述：類型和編碼，如果經常開發檔案子產品的需求，就知道這是兩個極其複雜的點，很容易出現問題，下面站在實際開發的角度看看如何處理。
如圖所示，在正常的檔案流任務中，會涉及【檔案、流、資料】三種基本形式的轉換：
基本過程描述：
源檔案生成，推送檔案中心；
通知業務使用節點擷取檔案；
業務節點進行邏輯處理；
很顯然的一個問題，任何節點都無法适配所有檔案處理政策，比如類型與編碼，面對複雜場景下的問題，<code>規則限制</code>是常用的解決政策，即在約定規則之内的事情才處理。
上面流程中，源檔案節點通知業務節點時的資料主體描述：
把整個過程當做一個任務進行封裝，即：任務批次、檔案資訊、業務庫表路由等，當然這些資訊也可以直接标記在檔案命名的政策上，處理的手段類似：
基于主體描述的資訊，也可以轉化到命名規則上：命名政策：編号_壓縮_Excel_編碼_庫_表，這樣一來在業務處理時，不符合約定的檔案直接排除掉，降低檔案異常導緻的資料問題。
IO流向
基本編碼邏輯：<code>源檔案->輸入流->邏輯處理->輸出流->目标檔案</code>；
基于不同的角度看，流可以被劃分很多模式：
流動方向：輸入流、輸出流；
流資料類型：位元組流、字元流；
IO流的模式有很多種，相應的API設計也很複雜，通常複雜的API要把握住核心接口與常用的實作類和原理。
基礎API
位元組流：InputStream輸入、OutputStream輸出；資料傳輸的基本機關是位元組；
read()：輸入流中讀取資料的下一個位元組；
read(byte b[])：讀資料緩存到位元組數組；
write(int b)：指定位元組寫入輸出流；
write(byte b[])：數組位元組寫入輸出流；
字元流：Reader讀取、Writer寫出；資料傳輸的基本機關是字元；
read()：讀取一個單字元；
read(char cbuf[])：讀取到字元數組；
write(int c)：寫一個指定字元；
write(char cbuf[])：寫一個字元數組；
緩沖模式
IO流正常讀寫模式，即讀取到資料然後寫出，還有一種緩沖模式，即資料先加載到緩沖數組，在讀取的時候判斷是否要再次填充緩沖區：
緩沖模式的優點十分明顯，保證讀寫過程的高效率，并且與資料填充過程隔離執行，在BufferedInputStream、BufferedReader類中是對緩沖邏輯的具體實作。
API關系圖：
位元組流基礎API：
位元組流緩沖API：
位元組流應用場景：資料是檔案本身，例如圖檔，視訊，音頻等。
字元流基礎API：
字元流緩沖API：
字元流應用場景：檔案作為資料的載體，例如Excel、CSV、TXT等。
編碼：字元轉換為位元組；
解碼：位元組轉換為字元；
亂碼出現的根本原因，就是在編碼與解碼的兩個階段使用的編碼類型不同。
序列化：對象轉換為流的過程；
反序列化：流轉換為對象的過程；
注意：引用類型的成員對象也必須是可被序列化的，否則會抛出<code>NotSerializableException</code>異常。
NIO即（NonBlockingIO），面向資料塊的處理機制，同步非阻塞模型，服務端的單個線程可以處理多個用戶端請求，對IO流的處理速度有極高的提升，三大核心元件：
Buffer(緩沖區)：底層維護數組存儲資料；
Channel(通道)：支援讀寫雙向操作；
Selector(選擇器)：提供Channel多注冊和輪詢能力；
API使用案例
上述案例隻是NIO最基礎的檔案複制能力，在網絡通信中，NIO模式的發揮空間十分寬廣。
服務端的單線程可以處理多個用戶端請求，通過輪詢多路複用器檢視是否有IO請求，這樣一來，服務端的并發能力得到極大的提升，并且顯著降低了資源的消耗。
API案例：服務端模拟
API案例：用戶端模拟
SelectionKey綁定Selector和Chanel之間的關聯，并且可以擷取就緒狀态下的Channel集合。
IO流同系列文章：
| IO流概述 | MinIO中間件 | FastDFS中間件 | Xml和CSV檔案 | Excel和PDF檔案 | 檔案上傳邏輯 |
閱讀标簽
【Java基礎】【設計模式】【結構與算法】【Linux系統】【資料庫】
【分布式架構】【微服務】【大資料元件】【SpringBoot進階】【Spring&Boot基礎】
【資料分析】【技術導圖】【 職場】