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