八股文背了一堆不如把這些答案的來歷和原理吃透一次。這篇不按語法書順序羅列分類直接把 Java IO 這套體系從設計動機、底層機制到實際踩坑串起來講。不管是你準備面試聊底層還是項目里做文件傳輸、網(wǎng)絡通信時選型讀完都能有明確判斷依據(jù)。1. Java IO 為什么設計成“流”的樣子1.1 順著水管想問題流的本質(zhì)是單向管道Java 的 IO 抽象核心就一個詞流Stream。這東西用生活里的水管來類比最好理解。數(shù)據(jù)像水一樣從水源流向目的地。Java 里的輸入流、輸出流本質(zhì)就是兩條方向不同的單向管道。記住這個“單向”很重要它決定了你在編碼時的直覺判斷InputStream 是程序從外面往內(nèi)存里“抽水”O(jiān)utputStream 是程序把內(nèi)存里的數(shù)據(jù)“排出去”。你要是想又讀又寫同一種流在經(jīng)典 IO 里是不存在的必須分別建立兩條管道。為什么這么設計因為真實世界的設備場景就是單向的鍵盤只能輸入顯示器只能輸出磁盤文件可以讀也可以寫但讀寫是兩種獨立操作。把方向分清楚各管各的實現(xiàn)類就不用在同一條管道里維護“當前方向”這種復雜狀態(tài)了。你平時用 FileInputStream 讀文件、用 FileOutputStream 寫文件文件可以同時打開這兩個流但每條流內(nèi)部的狀態(tài)是干凈且獨立的。我在面試中經(jīng)常問候選人一個問題Java 里的“流”和“集合”有什么區(qū)別很多人答不上來。集合是內(nèi)存里已經(jīng)存在的一組數(shù)據(jù)是靜態(tài)的而你拿到一個 InputStream手里并沒有數(shù)據(jù)數(shù)據(jù)還在文件/網(wǎng)絡/鍵盤那邊你得調(diào)用 read() 把它一點一點拉過來。流的本質(zhì)是“連接數(shù)據(jù)源與目的地之間的移動通道”而不是數(shù)據(jù)本身。理解這一點后面理解緩沖區(qū)、理解 NIO 的 Channel都會輕松很多。1.2 裝飾器模式為什么 Java 的流能一層套一層這是 Java IO 體系里最容易被忽略卻又最有魅力的設計。你寫代碼時一定見過這樣的寫法BufferedInputStream bis new BufferedInputStream(new FileInputStream(data.txt)); DataInputStream dis new DataInputStream(bis);外層套內(nèi)層一層包一層。這就是裝飾器模式在 JDK 里的教科書級應用Java IO 的設計者讓每個流類只負責一項能力你要什么功能就往上疊加什么功能而不是為每種組合寫一個獨立類。試想一下如果不這么設計會怎樣一個帶緩沖的、能讀基本類型的、從文件讀入的輸入流就得單獨寫一個 BufferedDataFileInputStream。再乘上各種排列組合類數(shù)量會爆炸式增長。而使用裝飾器模式后FileInputStream 負責讀取文件字節(jié)BufferedInputStream 負責加緩沖區(qū)DataInputStream 負責解析基本數(shù)據(jù)類型——各司其職自由組合。這就是為什么 JDK 的 io 包下有 60 多個類但你只需要掌握少數(shù)幾個核心類加上理解組合規(guī)則就能應對絕大多數(shù)場景。總之一句話你不需要背全 java.io 包下所有類你只需要記住四個家庭——字節(jié)輸入流、字節(jié)輸出流、字符輸入流、字符輸出流然后理解裝飾器如何給他們穿衣服。2. 字節(jié)流與字符流編碼問題的根源與解法2.1 為什么有了字節(jié)流還要搞出字符流字節(jié)流以字節(jié)為單位讀寫數(shù)據(jù)1 個字節(jié)裝 8 位二進制。計算機底層只認字節(jié)文件在磁盤里存的也是字節(jié)序列。那么字符流存在的意義是什么答案就兩個字編碼。你寫了個字符串 你好存到磁盤上它是以 UTF-8 編碼的字節(jié)序列中文 3 個字節(jié)一個字符正好 6 個字節(jié)。如果拿 InputStream 去讀這 6 個字節(jié)你得自己手動拼接、自己判斷哪幾個字節(jié)組成一個漢字這就太痛苦了。字符流干的事情就是在字節(jié)流的外面套了一層“編碼/解碼器”幫你完成字節(jié)數(shù)組到 char 數(shù)組之間的轉(zhuǎn)換每次 read() 返回的就是一個完整的字符或字符數(shù)組你不用關(guān)心這個字在 UTF-8 下占 3 個字節(jié)還是 2 個字節(jié)。所以字符流的本質(zhì)是字節(jié)流 編碼表。這個概念要刻在腦子里它是后面理解亂碼問題的鑰匙?？匆幌逻@張經(jīng)典的對應表輸入輸出底層單位適用場景InputStreamOutputStream字節(jié)圖片、視頻、壓縮包等二進制文件ReaderWriter字符文本文件、網(wǎng)絡傳輸?shù)奈谋緝?nèi)容值得一提的是字符流不是憑空產(chǎn)生的字母、數(shù)字在 ASCII 時代 1 字節(jié)確實搞定但中文、日文、韓文等多字節(jié)字符出現(xiàn)后純粹的字節(jié)操作很難滿足文本處理需求。于是 Reader/Writer 體系誕生換來的代價是字符流不能直接操作二進制你拿 FileReader 去讀一張圖片讀出來的內(nèi)容你會完全不認得還很可能因為解碼失敗產(chǎn)生亂碼。2.2 轉(zhuǎn)換流字節(jié)與字符之間的橋梁InputStreamReader 和 OutputStreamWriter 就是這座橋。很多初學者搞不懂這兩個類存在的意義直到他們在項目中遇到“從網(wǎng)絡字節(jié)流中讀取文本內(nèi)容”的場景。當你從 Socket 獲取的是 InputStream內(nèi)容卻是文本時當你讀取的文件編碼不是平臺默認編碼時——你都需要使用轉(zhuǎn)換流。代碼長這樣InputStream in new FileInputStream(data.txt); Reader reader new InputStreamReader(in, StandardCharsets.UTF_8);這里的關(guān)鍵就是把“字節(jié)”和“字符”銜接起來而且還可以指定編碼集。讀過老項目代碼的朋友應該有印象很多團隊直接寫new FileReader(xx.txt)然后出現(xiàn)亂碼——問題就出在這里FileReader 這個類在構(gòu)造時用的是平臺默認編碼在中文 Windows 上通常是 GBK在 Linux 服務器上通常是 UTF-8同一個進程換個運行環(huán)境讀同一份文件結(jié)果完全不同。所以業(yè)界約定俗成的規(guī)范是FileReader/FileWriter 老老實實別用要讀取文本文件一定要走 InputStreamReader 指定字符集這條路。同理字符流往字節(jié)流轉(zhuǎn)換時也是這樣操作Writer writer new OutputStreamWriter(new FileOutputStream(out.txt), StandardCharsets.UTF_8);這兩種轉(zhuǎn)換流的地位在 io 體系里是很特殊的它們既屬于字符流的體系又以字節(jié)流為基礎(chǔ)是兩種體系的粘合劑。2.3 編碼不一致亂碼是怎樣一步步產(chǎn)生的亂碼的根因通俗講就一句話寫入時的編碼和讀取時的編碼對不上。寫入端用 UTF-8 編碼碼 這個字變成了 3 個字節(jié) E7 A0 81讀取端卻用 GBK 解碼3 個字節(jié)被按 2 字節(jié)的寬度拆成了兩個亂碼字符于是文章里出現(xiàn)“鐮佷功錛”這類鬼畫符。這里也提醒大家IO 中有一個非常隱蔽的坑讀取字節(jié)流的長度時如果用到available()方法它會返回當前流中可讀的字節(jié)數(shù)但這個數(shù)字并不可靠尤其在網(wǎng)絡流上數(shù)據(jù)可能是分批到達的。你要是拿這個數(shù)字來 new byte[available()] 一次性讀完很容易讀不全。當初我在做文件上傳功能時踩過這個坑后來改成循環(huán)讀取 ByteArrayOutputStream 收集才徹底解決。正確讀取文本文件的方式是循環(huán)讀取或者是直接用 BufferedReader 的 readLine()讓它處理字節(jié)拼接的細節(jié)BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(filePath), StandardCharsets.UTF_8)); String line; while ((line reader.readLine()) ! null) { // 處理每一行 }3. 緩沖區(qū)機制Buffered 類為什么性能好這么多3.1 一次磁盤讀入 8KB內(nèi)存與磁盤速度差距的巨大鴻溝我們常聽說內(nèi)存比磁盤快很多倍——這個“很多倍”究竟是多少對于機械硬盤而言順序讀速度大概每秒 150MB 到 200MB而內(nèi)存隨機訪問速度是幾十 GB 每秒相差上百倍即便是 SSD隨機小塊訪問的差距依然明顯。更麻煩的是每次調(diào)用系統(tǒng) IO 接口是要有系統(tǒng)調(diào)用開銷的程序從用戶態(tài)切到內(nèi)核態(tài)內(nèi)核完成磁盤讀取再切回來這個切換本身就有成本。假設你寫了一個最樸素的復制文件代碼FileInputStream in new FileInputStream(big.mp4); FileOutputStream out new FileOutputStream(copy.mp4); int b; while ((b in.read()) ! -1) { out.write(b); }這段代碼功能完全正確性能極其糟糕。每讀 1 個字節(jié)就要觸發(fā)一次系統(tǒng)調(diào)用復制一個 1GB 的文件就等于做了上億次系統(tǒng)調(diào)用。這個性能差距用什么概念類比相當于你從圖書館借書一本一本地辦理借閱手續(xù)而不是推一輛小車一次性借走一個書架。所謂理財上的“批量處理”思維在這里體現(xiàn)得淋漓盡致。3.2 BufferedInputStream 的緩沖工作細節(jié)BufferedInputStream 做的事情正是“推車借書”。它內(nèi)部維護了一個默認大小為 8KB8192 字節(jié)的 byte 數(shù)組。當你第一次調(diào)用 read() 時它會一次性從底層輸入流中讀取 8192 字節(jié)到內(nèi)存數(shù)組里然后返回給你第一個字節(jié)。你繼續(xù) read()它直接從內(nèi)存數(shù)組中返回第 2、3、4 個字節(jié)……直到數(shù)組里的數(shù)據(jù)被讀完了它才會再跑一次系統(tǒng)調(diào)用繼續(xù)批量補充數(shù)據(jù)。這樣算下來讀取 1GB 文件系統(tǒng)調(diào)用次數(shù)從十億次降到了約 13 萬次1GB / 8KB 131072 次。性能差距是數(shù)量級的實測讀文件速度快幾十倍是很正常的事情。輸出流也是同樣的邏輯。BufferedOutputStream 內(nèi)部維護一個緩沖區(qū)你 write() 的字節(jié)先塞進內(nèi)存數(shù)組攢到 8192 字節(jié)一次性刷入磁盤。少數(shù)情況是你寫完大量數(shù)據(jù)后需要調(diào)用 flush() 方法把緩沖區(qū)中剩余的數(shù)據(jù)壓出去否則數(shù)據(jù)會滯留在內(nèi)存緩沖區(qū)里。close() 方法內(nèi)部會自動 flush但如果你要立即讀到數(shù)據(jù)比如先寫再讀就必須手動 flush。我的經(jīng)驗是凡是需要高頻、大批量、逐字節(jié)操作的 IO 場景一律在外面包上緩沖流。尤其是網(wǎng)絡流網(wǎng)絡是一個天然后進先出、分塊傳輸?shù)慕橘|(zhì)不包緩沖類每次 read() 都可能等著數(shù)據(jù)包從對端發(fā)過來延遲和開銷都很大。3.3 BufferedReader 的 readLine 為什么好用字符流家族中也有對應的緩沖類BufferedReader 和 BufferedWriter。BufferedReader 有一個獨門絕技 readLine()可以一次性讀取一整行字符不需要你自己拼接字符、處理換行符。它的內(nèi)部還是那個緩沖數(shù)組只不過這次數(shù)組存的是 char 而不是 byte。每次調(diào)用 readLine()它會在緩沖區(qū)里掃描換行符或文件結(jié)尾然后把這一整行內(nèi)容返回。有一種說法是“用 BufferedReader 逐行讀取文本文件是最優(yōu)雅的姿勢”我很認同。你既不需要考慮字節(jié)緩沖的細節(jié)也不需要處理編碼——編碼在處理字節(jié)到字符的那一層InputStreamReader已經(jīng)解決了BufferedReader 里面那層緩沖是為了高效逐行讀取。責任分離層層處理這也是 Java IO 裝飾器體系的一個完美體現(xiàn)。BufferedWriter 也值得擁有它提供了 newLine() 方法自動拼接系統(tǒng)相關(guān)的換行符可以避免跨平臺時換行符不一致的坑。雖然現(xiàn)在“\n”基本通用了但 Windows 下老編輯器打開還是可能顯示成一行所以我的習慣是每次 write() 一行就調(diào)一次 newLine()省心。4. 阻塞與 NIO經(jīng)典 IO 的天花板4.1 阻塞 IO 的線程困境理想情況下你用上面的文件 IO 技術(shù)就能應對 90% 的項目需求了。但在網(wǎng)絡編程場景里經(jīng)典 IO 會出現(xiàn)一個繞不開的問題——阻塞。在 Java 傳統(tǒng) Socket 編程中serverSocket.accept()會阻塞到有客戶端連接才返回inputStream.read()會阻塞到有數(shù)據(jù)讀入才返回。一個線程發(fā)出 read() 請求后就卡死在那了CPU 雖然在飛快運行但這個線程無法干別的事。如果一個服務器需要同時服務 1000 個客戶端就得創(chuàng)建 1000 個線程。線程不是免費的每個線程默認要分配約 1MB 的棧內(nèi)存JVM 參數(shù)可調(diào)1 萬個線程就是 10GB 內(nèi)存直接內(nèi)存爆炸。即便內(nèi)存撐得住線程的大量上下文切換也會把 CPU 耗光在調(diào)度本身上而不是業(yè)務處理上。這就是 BIOBlocking IO的核心矛盾IO 等待和線程資源綁定在一起一個線程只能服務一個連接。4.2 NIO 三件套Channel(通道)、Buffer(緩沖)、Selector(選擇器)NIONon-blocking IOJDK 1.4 起引入改變了這個格局它的核心是三個東西Channel、Buffer、Selector。Channel 直譯是通道你可以理解成它是一條雙向的管道既可以讀也可以寫FileChannel 比較特殊只能讀寫文件但 SocketChannel 在 TCP 連接上確實是雙向的。注意這里跟經(jīng)典 IO 的區(qū)別經(jīng)典流是單向的而 Channel 是雙向的。Buffer 是 NIO 另一個核心——所有讀寫操作都是圍繞 Buffer 展開的。你要讀數(shù)據(jù)先把數(shù)據(jù)從 Channel 讀入到 ByteBuffer。你要寫數(shù)據(jù)先把數(shù)據(jù)填充到 ByteBuffer再通過 Channel 寫給對方。Buffer 本質(zhì)上就是一個字節(jié)數(shù)組但用四個指針支撐起了讀寫切換的復雜度position當前讀寫位置、limit可讀寫邊界、capacity容量、mark標記位。這兒有個高頻面試考點flip()方法是干什么的它把寫模式切換為讀模式具體動作是limit positionposition 0也就是把“寫到了哪里”變成“可讀到哪里的界限”然后從頭開始讀。Selector 才是 NIO 的靈魂它做的事情是一個線程注冊多個 Channel然后調(diào)用 select() 阻塞等待當其中任意一個 Channel 有了就緒事件可讀、可寫、有新連接等select() 返回然后遍歷 SelectedKeys挨個處理就緒的 Channel。一個線程管理成千上萬個連接的網(wǎng)絡 IO 事件這就是 NIO 能支撐高并發(fā)的底層原因。給個直觀對比表格維度傳統(tǒng) IOBIONIOIO 模型阻塞同步非阻塞同步流方向單向雙向Channel數(shù)據(jù)載體Stream 直接讀字節(jié)Buffer 中轉(zhuǎn)連接與線程1 連接 1 線程1 線程管多連接Selector適用場景連接數(shù)少、短連接連接數(shù)大、長連接4.3 別什么都上 NIO場景選型的思路這里我想說點務實的。NIO 確實強但它的復雜度也是實打?qū)嵉摹Ｈ绻阌迷?NIO 寫一個 HTTP 服務器光是處理 ByteBuffer 讀寫切換、半包粘包、網(wǎng)絡事件分發(fā)這些細節(jié)就夠你調(diào)試好幾個通宵了。所以現(xiàn)實世界中99% 的工程師不會直接用原生 NIO 做網(wǎng)絡編程而是用 Netty、Mina 這類封裝好的高性能網(wǎng)絡框架。Netty 把 NIO 的復雜細節(jié)處理得妥妥帖帖你在 Netty 里寫業(yè)務只需要關(guān)注 ChannelHandler 里的回調(diào)邏輯性能還非常好。那什么時候用 BIO、什么時候用 NIO 呢我的個人判斷是分情況討論傳統(tǒng)的短連接、低頻請求如小型管理后臺、內(nèi)部 RPC 的少量調(diào)用BIO 完全夠用代碼清晰簡單維護成本低。高并發(fā)長連接場景聊天服務器、IoT 設備接入、消息推送必須上 NIO 或基于 NIO 的框架。文件讀寫這種本地 IO經(jīng)典 IO 就足夠快NIO 的 FileChannel 也未必有特別大的優(yōu)勢更高性能的 MapByteBuffer內(nèi)存映射文件倒是值得研究但那是另一個話題了。記住一個原則架構(gòu)選型要匹配系統(tǒng)規(guī)模別因為“NIO 高端”就強行上 NIO。我曾經(jīng)見過一個每天請求量只有幾百的小系統(tǒng)因為某同事“為了炫技”上了 Netty結(jié)果出了 bug 沒人能看懂維護成本翻了十幾倍這是典型的過度設計。真正的高手會用最樸素的方案解決 80% 的問題剩下的 20% 才需要重型武器。4.4 ByteBuffer 的 flip 與清除操作細節(jié)既然提到 ByteBuffer這里展開講三個關(guān)鍵操作flip()、clear()、compact()。flip() 是“寫轉(zhuǎn)讀”之前提到了。clear() 是“讀轉(zhuǎn)寫”它把 position 置為 0、limit 置為 capacity相當于把整個緩沖區(qū)的狀態(tài)重置為可寫狀態(tài)但注意 clear() 不會真正清空數(shù)據(jù)它只是移動指針舊數(shù)據(jù)下次寫的時候會被覆蓋。compact() 是“讀完了準備繼續(xù)寫但保留沒讀完的數(shù)據(jù)”它會把剩余未讀數(shù)據(jù)往前移動、position 指向剩余數(shù)據(jù)的末尾、limit 設為 capacity——這樣你繼續(xù)寫的時候不會覆蓋那些還沒處理的數(shù)據(jù)。這三個方法在面試里經(jīng)常被拿出來問答清楚一件事情就能通關(guān)你在操作字節(jié)時必須始終清楚自己處于寫模式還是讀模式以及模式切換時這些指針如何變化。如果只在讀模式下繼續(xù)調(diào)用 get()position 會越過 limit 拋 BufferUnderflowException如果寫模式下忘了 flip() 直接讀到 limit舊的殘留數(shù)據(jù)會被當成新數(shù)據(jù)讀出來。我個人對初學者的建議是不要在業(yè)務代碼里直接調(diào)原生 ByteBuffer封裝一層能規(guī)范讀寫順序的工具類或者直接依賴 Netty 的 ByteBuf——它在讀寫切換上比 JDK 的 Buffer 友好得多天然支持雙指針不再需要手動 flip安全性高一個層次。5. 流的生命周期關(guān)閉資源與 try-with-resources5.1 不關(guān)閉流的后果文件句柄泄漏弄明白了流的工作原理接下來是一個看起來很基礎(chǔ)、實際翻車率極高的環(huán)節(jié)資源關(guān)閉。在你打開了文件流后操作系統(tǒng)會給進程分配一個文件描述符file descriptor。Java 里打開一個 FileInputStream底層就占用一個 fd。在 Linux 中進程能打開的文件描述符是有限制的通常是 1024 或更高可以用 ulimit 查看。如果你只開不關(guān)fd 被耗盡再打開新文件就會拋Too many open files異常。我見過太多因為不關(guān)流或者關(guān)流姿勢不對弄崩服務器的案例了。最典型的是在循環(huán)里 new 流卻不 close跑了一段時間后系統(tǒng)報錯。當然現(xiàn)代 JVM 的 GC 有 finalize 兜底文件流實現(xiàn)了 finalize 方法但 GC 是不可預期的在高頻請求下說不定什么時候就炸了。所以把“誰打開、誰關(guān)閉”當作一條鐵律一來能保證代碼健壯二來也便于做代碼 review。5.2 try-with-resources 的推薦寫法Java 7 引入了 try-with-resources 語法這是最省心也最推薦的關(guān)閉方式它保證不管是否拋出異常資源都會被自動關(guān)閉try (InputStream in new FileInputStream(input.txt); OutputStream out new FileOutputStream(output.txt)) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } } catch (IOException e) { // 統(tǒng)一處理 IO 異常 }這里有兩個細節(jié)值得注意。第一在 try 塊中創(chuàng)建多個流時關(guān)閉順序是從后往前的——后打開的先關(guān)閉這符合資源依賴關(guān)系外層流依賴內(nèi)層流先關(guān)外層才能保證數(shù)據(jù)刷盤和釋放。第二當 try 塊正常執(zhí)行完后會自動調(diào)用所有資源的 close()。這個機制依賴的是 AutoCloseable 接口。你有沒有想過如果 close() 本身拋異常而 try 塊里也有異常會怎么樣答案是 try 塊里的異常會傳遞給調(diào)用方close() 拋出的異常會被“抑制”suppressed但你可以通過e.getSuppressed()拿到被抑制的異常集合。Java 7 起Throwable類增加了這個特性不過絕大多數(shù)場景你不需要處理它Java 已經(jīng)幫你選了對調(diào)用方最有價值的那個異常。5.3 關(guān)閉外層流就夠了嗎一個最常見的誤解很多人問我我只關(guān)閉最外層的流內(nèi)層的 FileInputStream 不關(guān)會不會泄漏答案是不會。這個問題的原理是try-with-resources 中你在 try 塊里聲明的變量就是需要關(guān)閉的流。如果你只聲明了 BufferedInputStream關(guān)閉時候會調(diào)用它的 close()而這個 close() 內(nèi)部會調(diào)用包裹的 FileInputStream 的 close()——裝飾器模式在生命周期上也是環(huán)環(huán)相扣的。所以你只需要關(guān)閉最外層內(nèi)層會自動被連帶關(guān)閉。但要小心的例外是如果你自己手動創(chuàng)建的流變量需要單獨關(guān)閉比如流被拆分成了多個臨時變量就得逐個關(guān)閉。同時在 try-with-resources 中如果只聲明外層流內(nèi)層流在 try 結(jié)束后同樣會被自動關(guān)閉可以放心。但如果為了捕獲流創(chuàng)建過程中的異常內(nèi)層流的創(chuàng)建也應該放在 try 之外并考慮到這種邊界情況在代碼審查中容易被忽略。5.4 數(shù)據(jù)丟失場景不 flush 就 close 的迷惑行為還有一個高頻坑我認為必須拿出來單獨說BufferedOutputStream 或 Writer 在 close() 時究竟會不會幫你 flush會不論底層流是誰close() 方法都會先執(zhí)行 flush確保緩沖區(qū)中殘留的數(shù)據(jù)全部寫入文件或網(wǎng)絡。這是 io 包的設計鐵律。但問題在于如果你忘寫了 flush()且把流放在一個較大的 try-with-resources 外面可能在 close() 之前就有大量數(shù)據(jù)滯留在緩沖區(qū)如果你中途直接中斷了程序或進程崩潰這部分滯留的數(shù)據(jù)就永久丟了。所以我的個人習慣是在明確知道“這一批次數(shù)據(jù)寫完了要繼續(xù)做其他事情”時主動調(diào)用 flush()在 close() 前不強迫自己調(diào)用 flush()讓 close() 兜底。但你要知道有這一層兜底是正常情況下的如果流沒正常關(guān)閉比如進程被殺、網(wǎng)絡斷開緩沖區(qū)里的數(shù)據(jù)就是真沒了。較大文件、遠程網(wǎng)絡傳輸時除了業(yè)務上的 flush 之外更要考慮的是如何保證數(shù)據(jù)完整性比如每寫一段就落盤一次或者進行端到端的校驗。這些超出 IO 流本身的范疇但寫生產(chǎn)代碼時必須考慮。6. 面試中的 IO 考察點核心是“為什么”6.1 高頻問題清單與底層應答思路前端時間在幫忙做技術(shù)面試發(fā)現(xiàn) IO 部分問得最多的就那么幾個問題但很少有人能答出深度。這里我按由淺到深的順序把高頻題和答題要點整理一下問題 1請說說 Java IO 流的分類體系回答時不要只羅列字節(jié)流/字符流、輸入流/輸出流還要把裝飾器模式和橋接層的設計一并講清楚InputStream/OutputStream 以字節(jié)為單位Reader/Writer 以字符為單位兩者之間通過 InputStreamReader/OutputStreamWriter 連接BufferedXxx 通過裝飾器增強能力。能講清楚這層“為什么這樣設計”比背出 60 個類名有價值得多。問題 2字節(jié)流和字符流有什么區(qū)別如何選擇這個問題的關(guān)鍵點是編碼。字符流內(nèi)部會處理字符集編碼能直接讀一個完整的字符字節(jié)流只處理 0/1 字節(jié)序列。二進制文件必須用字節(jié)流文本文件優(yōu)先用字符流但如果要精細控制編碼比如指定 UTF-8在字符流外層包一層即可?；卮饡r稍微展開“亂碼的根因”能立刻和普通候選人拉開差距。問題 3BufferedInputStream 為什么比 FileInputStream 讀得快回答的抓手是“減少系統(tǒng)調(diào)用次數(shù)”內(nèi)存緩沖讓高頻讀操作在用戶態(tài)解決只有緩沖區(qū)空了才觸發(fā)底層 read()系統(tǒng)調(diào)用次數(shù)從每字節(jié)一次降為每 8KB 次。要是能繼續(xù)說到 write 的 flush 時機、磁盤塊對齊等細節(jié)面試官基本就滿意了。問題 4BIO、NIO、AIO 有什么區(qū)別這是個老生常談的問題但很多人只會背“同步阻塞、同步非阻塞、異步非阻塞”這六個字。更好的答法是先說清楚阻塞/非阻塞關(guān)注的是線程在等待數(shù)據(jù)時是否被掛起同步/異步關(guān)注的是數(shù)據(jù)就緒后是由應用自己取還是內(nèi)核回推給應用。NIO 是同步非阻塞AIO 是異步非阻塞Linux 下底層是 epoll 的封裝在 TrueAsync 上實現(xiàn)不完美。如果能把 1 線程 Selector 管理萬級連接的原理講清楚幾乎就是標準答案了。問題 5談談你項目里怎么處理 IO 超時和中斷這題其實是在考察工程能力。你在 Socket 讀數(shù)據(jù)時設置了 SO_TIMEOUT超時后 read() 會拋 SocketTimeoutException你在寫大文件時如何及時響應 cancel 信號你用 Future 包裝異步 IO 任務時如何正確中斷底層線程。平時沒踩過坑的人很難答得有血有肉。6.2 從面試官視角考察的是理解和邊界感我面試候選人時不會只聽他背“BIO 一個線程處理一個連接”更希望他明確說出每種 IO 模型的取舍和適用邊界?？梢赃@么說我會問你“你的項目真的需要 NIO 嗎”如果他能從連接數(shù)、消息頻率、線程開銷、開發(fā)維護成本幾個維度有條理地分析而不是一味順著“NIO 更高端”往下說我會給他很高的評價。更進一步的加分項是聊到內(nèi)存映射文件MappedByteBuffer、零拷貝sendfile、DirectBuffer 與堆外內(nèi)存。這些是屬于 NIO 進階的知識一般中小型項目用不到但能說明你對 IO 性能有較為完整的認知。后面有機會單獨寫一篇關(guān)于 DirectByteBuffer 和零拷貝的文章這里先埋個伏筆。6.3 一個通用回答框架用“流、緩沖、阻塞、資源”四個維度串起來如果只能給一條面試技巧那就是把零散知識點串聯(lián)成一個體系并給出自己的判斷邏輯。我喜歡用一個四步框架來組織回答流說清楚數(shù)據(jù)怎么流動的單向還是雙向字節(jié)還是字符。緩沖說明緩沖存在的意義是降低系統(tǒng)調(diào)用開銷提升吞吐。阻塞說明阻塞/非阻塞對線程資源模型的影響這是網(wǎng)絡編程選型的核心。資源強調(diào)生命周期管理和異常處理這體現(xiàn)了代碼的健壯性。用這四個維度你可以應對大部分 IO 相關(guān)問題。比如面試官問“怎么把一個 1GB 的文件高效地從 A 復制到 B”你可以回答FileChannel 的 transferTo/transferFrom或者 BufferedInputStream BufferedOutputStream 加 8KB 以上緩沖區(qū)然后展開資源管理和異常處理。這樣整個回答層次分明既有技術(shù)深度又有工程意識。7. 實戰(zhàn)復盤一次文件上傳故障的完整排查鏈路7.1 現(xiàn)象小文件正常大文件總是中斷說一個我真實踩過的坑。前年做了一個文件上傳服務客戶端把文件以 multipart 方式 POST 到服務端服務端把數(shù)據(jù)流寫入本地磁盤。功能上線后一切正常直到某天用戶傳一個 1.2GB 的視頻文件傳了一半就報Connection reset。一開始以為是網(wǎng)絡問題換了網(wǎng)絡重試依舊如此。后來抓了 tcpdump 發(fā)現(xiàn)連接在某個時間點被服務端強制斷開了而服務端日志里沒有任何異常堆棧——因為異常根本沒有傳播到業(yè)務代碼里。7.2 排查過程從代碼到 OS 到網(wǎng)絡棧我首先檢查了服務端代碼。當時用的是典型的 servlet 接收然后通過 InputStream 讀、OutputStream 寫。代碼本身沒有任何問題try-with-resources 也用了。然后懷疑是 Tomcat 的連接超時設置或上傳大小限制查了配置調(diào)整了 maxPostSize 到 2GB 還是不行。接著看系統(tǒng)日志發(fā)現(xiàn)一個關(guān)鍵線索內(nèi)核日志里有大量Out of memory: Kill process的痕跡指向了 Java 進程。這時候才意識到問題可能出在堆外內(nèi)存和文件描述符上。再深挖發(fā)現(xiàn)我們?yōu)榱松蟼餍阅芤肓?NIO 相關(guān)的 FileChannel而且 ByteBuffer 用的是 allocateDirect()直接緩沖區(qū)分配在堆外。大文件傳輸時DirectBuffer 不斷分配和釋放堆外內(nèi)存碎片化嚴重最終導致進程被 OOM Killer 干掉連接隨之被重置。定位到根因后方案就很明確了控制 DirectBuffer 的使用避免大文件場景下無上限的堆外分配。對大文件改走 FileChannel 的 transferTo零拷貝內(nèi)核直接完成數(shù)據(jù)搬移不經(jīng)過用戶態(tài)緩沖區(qū)。在寫入數(shù)據(jù)時堅持循環(huán)寫出并監(jiān)控寫返回值防止半寫導致數(shù)據(jù)不完整。這里要補充的是NIO 的零拷貝并不是萬能的。transferTo 在底層走 sendfile 系統(tǒng)調(diào)用適合“文件到 Socket”或“文件到文件”的場景能顯著降低 CPU 和內(nèi)存消耗。但如果你要對數(shù)據(jù)做加工比如加密、壓縮、解析格式必須經(jīng)過內(nèi)存就不能走這條路了。7.3 復盤提煉IO 問題排查的三板斧這個案例給我們的啟發(fā)值得好好總結(jié)——排查 IO 問題時有三個檢查方向是高頻出問題的第一流有沒有正常關(guān)閉、異常有沒有被吞掉日志里看不到異常不代表沒有異常可能異常被 catch 后打印到了別的渠道或者直接沒有打印。第二緩沖區(qū)類型和大小是否匹配場景DirectBuffer 性能好但內(nèi)存管理復雜堆內(nèi)緩沖區(qū)在大塊數(shù)據(jù)時反而更穩(wěn)定。第三數(shù)據(jù)流經(jīng)的每一層是否有超時限制網(wǎng)絡層Socket 超時、應用層業(yè)務超時、服務容器層Tomcat 連接超時任何一層超時都會表現(xiàn)為“連接中斷”。IO 問題往往不是觸發(fā)在代碼那一行而是跨越了很多層次需要我們從用戶態(tài)層層往內(nèi)核態(tài)排查。盲改配置不如先抓包、先看系統(tǒng)日志工具和證據(jù)才是排障的第一語言。我在排查這一類問題時有一個比較固定的習慣先用 lsof 看進程持有多少文件描述符再用 strace 看系統(tǒng)調(diào)用是否異常再結(jié)合線程堆棧看當前阻塞在哪一個 IO 點。這套組合拳幾乎沒有落空的時候。8. 實操總結(jié)與我的推薦體系8.1 日常編碼的 IO 實踐清單根據(jù)自己的實戰(zhàn)經(jīng)驗整理了一份 IO 編碼自查清單每次寫 IO 代碼都拿出來對著過一遍讀文本文件用BufferedReader InputStreamReader FileInputStream并顯式指定 UTF-8別用 FileReader、FileWriter。讀寫二進制文件用BufferedInputStream/BufferedOutputStream或者 FileChannel 的 transferTo緩沖區(qū)推薦 8KB 到 64KB。所有流都用 try-with-resources 管理生命周期別手寫 finally close。網(wǎng)絡編程選型時先評估連接數(shù)和消息量不要盲目上 NIO/Netty。寫大數(shù)據(jù)后注意 flush 的時機別把數(shù)據(jù)滯留在內(nèi)存緩沖區(qū)里。一旦發(fā)生 IO 異常日志里要打出流此時的讀寫位置、字節(jié)數(shù)、文件路徑等上下文信息便于事后定位。涉及編碼的寫入統(tǒng)一在項目層面規(guī)定為 UTF-8避免開發(fā)機器和生產(chǎn)環(huán)境默認編碼不同導致玄學亂碼。8.2 學習路徑建議從會用、到理解、再到能排障對剛進階的 Java 工程師來說建議按這個階段學習第一階段是會用也就是 FileInputStream、FileOutputStream、BufferedReader 這幾個類的 API 玩熟 第二階段是理解設計看懂裝飾器模式、適配器模式在 io 包中的體現(xiàn)搞懂字符流與字節(jié)流的差異 第三階段是能排障能獨立處理亂碼、文件句柄泄漏、OOM 這類線上事故 第四階段才是學 NIO/Netty 的高性能模型。這個梯度和很多網(wǎng)上流傳的“21 天精通 Java IO”完全不一樣——前者是螺旋上升、真實成長的節(jié)奏后者只是讓你背一堆名詞然后自我感覺良好。我自己帶團隊的時候也遵循這個節(jié)奏新人來了先讓他寫兩周文件工具類讀讀寫寫自然就懂了很多東西而不是一上來就丟一堆設計模式概念讓他去背。從面試角度看能把第一、二階段講透的人已經(jīng)超過了大多數(shù)只背 API 的候選人三、四階段能力屬于加分項能讓你在討論系統(tǒng)設計時更有底氣。最后分享一個小技巧準備面試或者自我檢測時不要問自己“我會哪些 IO 類”而是要問“如果我現(xiàn)在要把一個大文件從磁盤傳到另一臺服務器我會怎么做、為什么這么做、性能瓶頸在哪里”。能清晰回答出這個問題的說明你的 IO 知識已經(jīng)成體系了。