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