做后端開發(fā)或者Linux下C/C編程的人大概率都有過這么一段迷惑期明明在大學C語言課上學過fopen、fread、fwrite自我感覺文件操作已經(jīng)很熟練了結果到了Linux環(huán)境里看到open、read、write、close這一套系統(tǒng)調(diào)用突然又不敢下手了。更別說遇到一切皆文件這種說法時自己心里其實并沒有真正理解——文件描述符究竟是個什么東西內(nèi)核又是怎么把磁盤文件、鍵盤、屏幕、網(wǎng)絡連接這些八竿子打不著的東西統(tǒng)一叫成文件的。這篇內(nèi)容就是想把Linux基礎IO這層窗戶紙捅破。我會從文件描述符的本質(zhì)講起拆解open/read/write/lseek/close這幾個最常用的系統(tǒng)調(diào)用再深入到內(nèi)核數(shù)據(jù)結構層面看一個read背后到底發(fā)生了什么。最后還會分享一些實際開發(fā)里踩過的坑和排查思路。不管你是正在學操作系統(tǒng)課程的學生還是剛接觸Linux服務端開發(fā)的工程師這篇文章應該都能讓你對文件操作有個更踏實的理解。1. 先從文件這個詞說起1.1 一切皆文件到底是怎么個一切法Linux世界里有一句經(jīng)典的話一切皆文件。這句話既是設計哲學也常常是初學者理解上的第一道坎。磁盤上的普通txt文件是文件這好理解但鍵盤、鼠標、顯示器、網(wǎng)絡連接、管道甚至進程間通信用的匿名管道在Linux里也統(tǒng)統(tǒng)被抽象成文件。為什么這么設計因為文件這個概念有一個共同的操作模型讀、寫、控制。統(tǒng)一抽象之后內(nèi)核與設備交互的代碼可以共用一套接口上層開發(fā)者也可以拿同一套read/write邏輯去操作完全不同的底層設備。說穿了就是只要你有讀取或者寫入的接口內(nèi)核就統(tǒng)一給你一個文件描述符你拿著它來描述要操作的對象。但我得提醒一句凡事都有例外。一切皆文件是抽象出來給應用層用的底層驅動的實現(xiàn)千差萬別。你用read去讀一個普通文件內(nèi)核走的是磁盤IO和頁緩存你用read去讀一個socket內(nèi)核走的是協(xié)議棧和網(wǎng)卡隊列。這兩種讀背后的實現(xiàn)完全不同只是API長得一樣而已。搞清楚這一點后面分析很多問題才不會鉆牛角尖。1.2 文件描述符就是那張取貨單文件描述符簡稱fd在Linux里就是一個小整數(shù)。你可能會覺得一個整數(shù)而已怎么就能代表一個打開的文件我習慣用一個生活化的類比fd就像商場寄存處的取貨單。你把行李交給寄存處工作人員給你一張單子上面寫著一個號碼比如07。之后你拿著07號取貨單去取行李工作人員按號去倉庫里找不用你親自進去翻你的包長什么樣。內(nèi)核的倉庫就是打開文件表里面記錄著這個文件打開時用的權限、當前的讀寫位置、文件的狀態(tài)標志等那張取貨單上印著的號碼就是fd。為什么內(nèi)核不直接把文件的所有信息都交給你直接給你一個結構體指針不是更方便嗎原因有兩層。第一層是隔離安全如果應用層能直接操縱內(nèi)核的文件結構體那改錯一個字段整個操作系統(tǒng)就可能出問題必須把底層結構封裝起來。第二層是簡化接口read(fd, buf, size)這樣的接口只用一個整數(shù)就能定位到一個完整的文件對象參數(shù)表極簡內(nèi)核處理也高效。另外還有一個重要規(guī)律Linux分配文件描述符時采用最小未使用整數(shù)策略。在一個進程里文件描述符0、1、2通常默認分別被標準輸入、標準輸出、標準錯誤占用。你新打開一個文件只要這三個還占著拿到的fd大概率就是從3開始的。這個規(guī)律理解起來很簡單但后面分析重定向、fd復用和泄漏問題時特別有用。2. 最基礎的四個系統(tǒng)調(diào)用一次講透2.1 open打開文件的姿勢決定后面的一切先看最常見的用法#include sys/types.h #include sys/stat.h #include fcntl.h int fd open(data.txt, O_RDWR | O_CREAT | O_TRUNC, 0644); if (fd 0) { perror(open); return -1; }open的flags參數(shù)可以分成三組來看。第一組是訪問模式?jīng)Q定你是只讀、只寫還是讀寫分別對應O_RDONLY、O_WRONLY、O_RDWR這三個里邊必須選一個而且只能選一個。第二組是創(chuàng)建相關O_CREAT表示文件不存在就創(chuàng)建O_EXCL通常配合O_CREAT使用文件已存在時直接返回失敗O_TRUNC表示打開時把文件長度截斷為0。第三組是狀態(tài)標志O_APPEND是追加寫O_NONBLOCK是非阻塞模式O_SYNC是同步寫。第三個參數(shù)mode只有在flags里帶了O_CREAT時才有效它指定新文件的權限位比如0644表示用戶讀寫、組內(nèi)讀、其他人讀。這里有個最常見的坑mode不會原樣生效它會跟進程的umask做一次過濾。假如你open的時候給了0666但當前進程的umask是0022最終創(chuàng)建出來的文件權限就是0644。所以排查為什么我明明給了0777文件權限卻不對這個問題先看umask多半問題出在這。open成功返回一個非負的fd失敗返回-1并設置errno。很多人判斷失敗只寫一句fd -1不就行了但最好養(yǎng)成讀errno的習慣。哦對perror可以直接把errno對應的描述打到標準錯誤上定位問題非?？?。2.2 read和write返回值才是靈魂read和write的簽名長這樣ssize_t read(int fd, void *buf, size_t count); ssize_t write(int fd, const void *buf, size_t count);很多新手最大的誤解是把count當成必須讀到的字節(jié)數(shù)。實際上count只是你請求的字節(jié)數(shù)內(nèi)核不保證一定讀滿。比如從一個非阻塞的socket讀數(shù)據(jù)緩沖區(qū)里只有10個字節(jié)你請求讀4096個字節(jié)read只會返回10如果緩沖區(qū)里一個字節(jié)都沒有read直接返回-1errno設置為EAGAIN表示現(xiàn)在沒有數(shù)據(jù)你晚點再來。read的返回值三種情況要刻在腦子里返回值大于0表示實際讀到的字節(jié)數(shù)返回值等于0表示已經(jīng)到了文件末尾EOF返回值等于-1表示出錯。處理普通磁盤文件時一次read基本能讀滿但處理管道、socket、終端這些流式設備時你要用循環(huán)去讀直到返回0或者出錯。write同理它返回的也是實際寫入的字節(jié)數(shù)可能比count小。什么情況下write會寫不完整磁盤滿了、寫網(wǎng)絡連接時對端緩沖區(qū)不夠、被信號打斷等都可能。嚴謹?shù)某绦蚨紤撗h(huán)write確保寫入完整。還有一個細節(jié)read和write的第一個參數(shù)是fd第二個是緩沖區(qū)地址第三個是字節(jié)數(shù)。緩沖區(qū)類型是void *所以傳字符數(shù)組、傳結構體指針都行只要保證內(nèi)存連續(xù)、長度正確。2.3 lseek操作一個看不見的偏移量每個打開的文件表項里都保存著一個當前文件偏移量file offset它記錄了下一次讀寫從文件的哪個位置開始。open剛打開時偏移量是0每read或write成功一次偏移量就自動向后移動實際讀寫字節(jié)數(shù)那么多。lseek就是用來手動挪動這個偏移量的off_t lseek(int fd, off_t offset, int whence);whence有三個取值。SEEK_SET把偏移量設置成offsetSEEK_CUR在當前位置基礎上加上offsetSEEK_END從文件末尾開始算偏移。比如我想看一個文件有多少字節(jié)可以這樣off_t size lseek(fd, 0, SEEK_END);這是一行非常有用的代碼不會真的讀數(shù)據(jù)只是把偏移量挪到末尾然后取返回值。lseek有個容易忽略的特點它不觸發(fā)任何磁盤IO只修改文件表項里的一個數(shù)字所以非常快。但很多人不知道的是利用lseek可以制造空洞文件。比如你open一個新文件lseek到1GB的位置寫一個字節(jié)這個文件在ls -l里看到的長度是1GB1字節(jié)但它實際上只占了一個磁盤塊中間那1GB全是空洞不占實際存儲。數(shù)據(jù)庫、虛擬機磁盤鏡像經(jīng)常用這個技術做稀疏文件。2.4 close隨手關門是好習慣也是好職業(yè)習慣close的簽名最簡單int close(int fd);成功返回0失敗返回-1。很多教科書對close一句話帶過但實際工程里不寫close的后果很嚴重。每個進程能打開的fd數(shù)量是有限的默認通常是1024用ulimit -n能看到。如果你在一個循環(huán)里不斷open卻從不closefd會一路漲到上限最后open返回EMFILE打開的文件太多。更麻煩的是fd耗盡時你連日志文件都打不開排查起來非常痛苦。close還有一個作用它是釋放資源的信號。fd背后可能掛著一個socket連接、一個文件鎖、一個管道緩沖區(qū)close把引用計數(shù)減一當引用計數(shù)歸零時內(nèi)核才真正清理這些資源。頻繁open/close確實有開銷但和fd泄漏帶來的線上事故相比這點開銷根本不值一提。我個人的做法是每寫一個open立刻在下面寫好對應的close然后再往中間填邏輯。這聽起來很機械但真的能避免一大半資源泄漏問題。3. 內(nèi)核數(shù)據(jù)結構fd表、文件表、inode的關系3.1 三個結構分別是什么要真正理解fd不能只看用戶態(tài)那層皮得知道內(nèi)核里發(fā)生了什么。打開一個文件內(nèi)核至少維護三個數(shù)據(jù)結構。第一是進程級文件描述符表每個進程一張。這張表可以理解成一個數(shù)組下標就是fd每個元素指向一個打開文件表項同時記錄一些fd自身的標志比如close-on-exec。第二是打開文件表項也叫file對象內(nèi)核全局維護。它包含當前文件偏移量、打開時的訪問模式讀/寫/讀寫、文件狀態(tài)標志比如O_APPEND、O_NONBLOCK、指向inode的指針還有一個引用計數(shù)。多個fd可以指向同一個file對象。第三是inode索引節(jié)點。這是文件在磁盤上的身份證包含文件類型、權限、大小、時間戳、數(shù)據(jù)塊位置等信息。一個文件不管被open多少次inflight的磁盤上始終只有一個inode。用文字畫一下關系大概是這樣的進程P的fd表: fd 0 - 標準輸入文件表項 fd 1 - 標準輸出文件表項 fd 2 - 標準錯誤文件表項 fd 3 - data.txt文件表項 - inode(data.txt)這個關系網(wǎng)決定了非常多重要的行為下面兩條最重要。3.2 同一個文件open兩次為什么拿到兩個fd先看這個例子int fd1 open(log.txt, O_WRONLY | O_CREAT | O_APPEND, 0644); int fd2 open(log.txt, O_WRONLY | O_CREAT | O_APPEND, 0644); write(fd1, aaaa, 4); write(fd2, bbbb, 4);fd1和fd2是兩個不同的數(shù)字它們各自指向不同的file對象因此各自有獨立的文件偏移量。但因為對應同一個inode它們寫的是同一個磁盤文件。如果沒有O_APPEND情況會變得危險兩個fd的偏移量都是從0開始fd1寫完后它的偏移量變成4fd2寫的時候偏移量還是自己的0于是fd2的數(shù)據(jù)覆蓋掉fd1的數(shù)據(jù)文件里只剩bbbb。加了O_APPEND之后內(nèi)核保證每次write從文件末尾開始算偏移兩個fd追加的數(shù)據(jù)不會互相覆蓋最終文件內(nèi)容是aaaabbbb。這就是為什么多進程寫同一個日志文件時一定要用O_APPEND。有個經(jīng)典面試題問O_APPEND原子性到底指什么答案就是內(nèi)核在write系統(tǒng)調(diào)用內(nèi)部把定位偏移量到文件末尾和寫入數(shù)據(jù)這兩件事合在一次操作里完成對應用程序來說是原子的不會被其他fd或進程的寫操作插隊。3.3 dup和dup2復制一張取貨單有時候你需要生成一個新的fd但它指向的還是原來那個打開文件表項。dup和dup2就是干這個的int newfd dup(oldfd); int ret dup2(oldfd, newfd);區(qū)別在于dup返回當前最小的未使用fddup2可以指定你要復制到哪個fd上如果newfd已經(jīng)被占用dup2會先把它關掉再復制。dup2最經(jīng)典的應用是shell重定向。你在終端敲下cmd out.txtshell做的事情大致是int fd open(out.txt, O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, 1); // 把標準輸出重定向到out.txt close(fd);因為fd 1原本指向終端dup2讓fd 1改指向out.txt的文件表項之后進程里所有printf的內(nèi)容都會寫進文件而不是終端。這就是重定向的本質(zhì)不是什么魔法就是把文件描述符表的指針換了個指向。dup出來的fd和原fd共享同一個file對象這意味著它們共享同一個文件偏移量。你用fd1寫了幾行再到fd2上讀讀到的位置是fd1停下的位置而不是文件開頭。理解這點寫多路IO的代碼時會少走很多彎路。3.4 fork之后有一個隱藏坑fork和文件描述符有個容易忽略的交集。子進程會復制父進程的fd表復制出來的fd和父進程的fd指向同一個file對象偏移量是共享的。所以如果父子進程同時往同一個fd寫日志它們的寫入位置是連續(xù)推進的不是相互覆蓋的獨立偏移量這跟兩個進程各自open同一個文件是兩碼事。這個特性在某些場景下很頭疼。比如父進程用read讀文件讀到一半fork出子進程子進程接著讀會把父進程還沒讀的內(nèi)容讀走。所以設計多進程協(xié)作時要明確規(guī)定哪個fd歸誰用或者干脆在fork之后按需關閉不需要的fd。4. 緩沖區(qū)與IO效率為什么頻繁write會慢4.1 用戶態(tài)緩沖和內(nèi)核態(tài)緩沖不是一回事很多人測下來發(fā)現(xiàn)一個現(xiàn)象用fwrite寫一萬次小數(shù)據(jù)比用write寫一萬次小數(shù)據(jù)快很多。原因就是緩沖。標準C庫stdio在用戶態(tài)維護了一個緩沖區(qū)。fwrite把數(shù)據(jù)先寫進這個緩沖區(qū)等緩沖區(qū)滿了或者明確調(diào)用fflush或者正常fclose才真正發(fā)起write系統(tǒng)調(diào)用。read同理fread可能一次性從內(nèi)核讀一大塊數(shù)據(jù)到用戶緩沖區(qū)然后慢慢按請求分給你。這樣一萬次fwrite可能只觸發(fā)幾十次系統(tǒng)調(diào)用自然快。write就不同了它是真正陷入內(nèi)核的系統(tǒng)調(diào)用每次都要經(jīng)歷用戶態(tài)到內(nèi)核態(tài)的切換然后回到用戶態(tài)。一次兩次還好上萬次小寫入每次切換的開銷累積起來就很可觀。必須澄清一個常見誤解stdio緩沖是用戶態(tài)的跟內(nèi)核里的頁緩存是兩個層級。就算你調(diào)用fwrite數(shù)據(jù)先到用戶態(tài)緩沖區(qū)等緩沖區(qū)滿了調(diào)用writewrite進內(nèi)核后可能只把數(shù)據(jù)寫進頁緩存并沒有落盤。真正落盤要等內(nèi)核把臟頁刷下去或者你fsync/fdatasync主動要求。所以數(shù)據(jù)寫進文件和數(shù)據(jù)保存到磁盤之間還隔著一層。4.2 stdio的三種緩沖模式stdio默認緩沖規(guī)則很多人背過但沒理解。全緩沖普通磁盤文件默認全緩沖緩沖區(qū)滿了才寫通常緩沖區(qū)大小是4096字節(jié)或8192字節(jié)。行緩沖終端設備默認行緩沖碰到換行符就把緩沖區(qū)的數(shù)據(jù)寫出去終端上printf帶\n立刻能看到就是這個原因。無緩沖stderr默認無緩沖錯誤信息不經(jīng)過緩沖直接輸出這是為了保證程序崩潰前最后一條錯誤日志能出現(xiàn)在屏幕上。這解釋了一個經(jīng)典迷惑行為printf(hello ); // 進入stdout行緩沖 write(1, world, 5); // 直接進內(nèi)核在終端上運行輸出可能是worldhello 因為write立刻到達終端而printf里的hello要等遇到換行或者程序退出才被刷新。如果你把stdout重定向到文件stdout變成全緩沖順序甚至可能反過來非常容易讓新手懷疑人生。解決辦法在write之前調(diào)用fflush(stdout)或者干脆統(tǒng)一用stdio或者統(tǒng)一用系統(tǒng)調(diào)用不要混著來。4.3 高效IO的幾條實用原則第一減少系統(tǒng)調(diào)用次數(shù)是性能優(yōu)化的第一目標。批量讀寫比多次小讀寫快這是母庸置疑的。讀文件時一次性讀8192字節(jié)到緩沖區(qū)再逐條解析比自己緩沖區(qū)都不設、每次read一個字節(jié)快幾個數(shù)量級。第二write盡量湊夠整塊。如果業(yè)務上必須寫很多小片段可以在用戶態(tài)自己攢一個buffer湊夠了再write一次效果跟stdio的緩沖是一樣的。第三順序寫用O_APPEND隨機寫用lseek精確定位。內(nèi)核和磁盤對順序IO的友好程度遠高于隨機IO能順序就不要來回跳。第四到底要不要用O_SYNCO_SYNC讓每次write都強制落盤數(shù)據(jù)安全但性能暴跌。多數(shù)業(yè)務場景不需要寧可依賴內(nèi)核定期刷盤或者關鍵時刻單獨調(diào)用fsync。5. 常見問題排查與實戰(zhàn)心得5.1 數(shù)據(jù)沒寫進文件先分清緩沖層級遇到文件里沒數(shù)據(jù)這種問題我排查的順序是先看代碼里有沒有fflush或fclose再看這個fd是什么時候打開的有沒有O_APPEND、O_TRUNC干擾了偏移量和原有內(nèi)容最后才是考慮磁盤空間和權限。真實案例里最常見的不是程序邏輯錯誤而是忘了刷新stdio緩沖區(qū)或者忘了close。程序正常運行結束會隱式flush但你常駐后臺的服務卻不會自動close日志半天不落盤很可能就是緩沖區(qū)還沒滿。5.2 fd耗盡和泄漏怎么定位懷疑fd泄漏時先到Linux的/proc接口看一眼數(shù)字。某進程PID是1234執(zhí)行l(wèi)s /proc/1234/fd | wc -l可以看到進程當前打開的fd數(shù)量。不斷刷新這個數(shù)字如果持續(xù)增長不回落基本可以確定有fd泄漏。再用ls -l /proc/1234/fd看看都是哪些文件通常能直接看出問題出在哪段邏輯。排查代碼層面重點找兩條一是open/socket之后有沒有配合close二是循環(huán)里有沒有條件分支提前return導致close沒執(zhí)行。一個老練的做法是故意在關鍵路徑上把fd當作資源登記在日志里打印open和close的成對記錄誰的半路沒了錯誤棧自然浮現(xiàn)。5.3 partial read和EINTR怎么處理處理管道或socket時read返回的字節(jié)數(shù)小于你請求的字節(jié)數(shù)是不可能的場景但確實家常便飯。很多人寫循環(huán)read忘了處理返回值等于0的情況導致死循環(huán)。標準寫法是ssize_t n; while ((n read(fd, buf total, len - total)) 0) { total n; }讀到返回0說明EOF跳出循環(huán)。至于EINTR信號打斷系統(tǒng)調(diào)用時read/write返回-1且errno是EINTR此時邏輯上應該重試而不是直接判失敗退出。嚴謹一點的代碼會寫do { n write(fd, buf off, len - off); } while (n 0 errno EINTR);很多線上偶發(fā)的寫入失敗最后定位到都是沒處理EINTR和部分寫入。5.4 權限和路徑問題文件操作的報錯里權限類問題占比不低。遇到permission denied先確認當前進程的用戶身份別想當然以為就是你終端登錄的那個用戶。daemon進程經(jīng)常以nobody或者專用賬號運行人家對目標路徑根本沒有寫權限。然后看目標路徑的父目錄權限Linux對一個文件的寫權限不夠對文件所在目錄的寫權限也會影響能否創(chuàng)建新文件。還有一類問題用相對路徑打開文件時進程當前工作目錄可能不是你預期的目錄。服務型程序的工作目錄一般通過chdir設置過打印一下getcwd或者用絕對路徑能省掉大量無謂的調(diào)試時間。最后分享兩個工作習慣講這么多再聊兩個我個人的實操習慣。第一個打開文件后第一件事是把close寫好這個前面提過但它真的幫我避免過太多線上事故值得再說一遍。第二個凡是涉及文件IO的問題排查順序永遠是用戶、路徑、umask這三個字先驗證當前進程是哪個用戶、工作目錄在哪、umask是多少這三個變量往往能解釋一大半詭異現(xiàn)象。然后再去看代碼邏輯千萬別一上來就懷疑內(nèi)核或者編譯器出了問題。Linux底層IO這塊內(nèi)容看著基礎但它是理解網(wǎng)絡編程、理解一切IO框架比如epoll、libuv、各種異步庫的地基。地基不牢后面看什么東西都像懸空的。把這幾個系統(tǒng)調(diào)用的語義和內(nèi)核里的那幾張表都想明白再回頭讀其他框架的源碼語言和工具不斷變化但底層的東西從來沒變過。