做Linux開發(fā)這些年文件操作大概是寫過的代碼里出現(xiàn)頻率最高的場景了。不管你是寫C、C還是Python底層跑的都是那幾個系統(tǒng)調(diào)用——open、read、write、close、lseek。很多人能熟練地用fopen、fread做讀寫但一旦碰上文件描述符泄露、部分讀寫、信號中斷這類問題就開始抓瞎。這就是因為對系統(tǒng)調(diào)用層的理解還停留在API會返回一個值的程度。這篇文章我會把Linux文件操作最核心的幾條系統(tǒng)調(diào)用掰開揉碎講透——不只是講函數(shù)原型和參數(shù)重點講清楚內(nèi)核在背后做了什么、為什么這么設(shè)計、以及實操時最容易踩的坑。我盡量用我這幾年實際調(diào)試的經(jīng)驗來講內(nèi)容既適合剛接觸Linux編程的新手建立完整認知框架也適合有經(jīng)驗的老手查漏補缺。文中的所有示例代碼都是可編譯運行的最小實現(xiàn)可以直接拿去實驗。1. 一切從open開始文件描述符是怎么回事1.1 為什么Linux里一切皆文件Linux從一開始的設(shè)計哲學里就有一個核心抽象——一切皆文件。普通文件是文件設(shè)備是文件管道是文件socket是文件甚至/proc下面那些虛擬的進程信息也是文件。這個設(shè)計的好處在于程序員只需要學會一套操作接口就能處理幾乎所有I/O場景。而支撐起這套統(tǒng)一抽象的就是文件描述符簡稱fdfile descriptor。你可以把它理解成一張票據(jù)或者說索引號。每次你調(diào)用open打開一個文件時內(nèi)核就會在當前進程的文件描述符表里分配一個空閑的整數(shù)號這個整數(shù)就是fd。之后所有針對該文件的操作——讀、寫、移動位置、收尾關(guān)閉——都是基于這個整數(shù)進行的。這里有個非常關(guān)鍵的概念需要澄清fd是屬于進程的而不是屬于文件的。同一個文件被同一個進程open兩次會得到兩個不同的fd它們在文件描述符表里對應(yīng)兩個完全獨立的打開文件記錄各自的讀寫位置offset互不影響。實操心得新手寫程序時經(jīng)常忘了同一個文件兩次打開是兩個獨立的讀寫位置這一點。如果你想讓兩個fd共享同一個offset要用dup或dup2做描述符復(fù)制而不是重新open一次。1.2 open系統(tǒng)調(diào)用的完整參數(shù)拆解open的原型是#include fcntl.h #include sys/types.h #include sys/stat.h int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode);第一個參數(shù)pathname是路徑這個沒什么好說的。關(guān)鍵在第二個參數(shù)flags——它由三部分構(gòu)成訪問模式、創(chuàng)建選項、輔助選項。訪問模式必須是O_RDONLY只讀、O_WRONLY只寫、O_RDWR讀寫三選一。這是主模式內(nèi)核必須根據(jù)它來檢查進程是否有相應(yīng)權(quán)限。創(chuàng)建選項常用的包括O_CREAT如果文件不存在就創(chuàng)建它需要搭配第三個參數(shù)mode指定權(quán)限。O_EXCL如果同時指定了O_CREAT而文件已經(jīng)存在open直接失敗。這個選項常用于防止覆蓋已有文件比如創(chuàng)建鎖文件時。O_TRUNC如果文件已存在且以寫模式打開會立刻把文件長度截斷為0。注意O_TRUNC和O_RDONLY搭配時會直接報錯因為只讀模式不允許改變文件大小。輔助選項里最經(jīng)典的是O_APPEND和O_NONBLOCK。O_APPEND會讓每次write前都先把offset移動到文件末尾兩個或多個進程同時以追加模式寫同一個文件時數(shù)據(jù)不會互相覆蓋。O_NONBLOCK用于打開FIFO、設(shè)備等特殊文件時讓open本身不被阻塞。第三個參數(shù)mode只有在指定O_CREAT時才有效。這里要注意mode不是直接作為文件的最終權(quán)限它還要與進程的umask做一次取反后再按位與的操作。比如你傳0644rw-r--r--但umask是022時最終文件權(quán)限是0644 ~022 0644如果umask是077最終就變成0600了。int fd open(/tmp/example.txt, O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd 0) { perror(open); return -1; }我在實際項目中見過一個典型的bug調(diào)用open時忘了傳第三個參數(shù)結(jié)果創(chuàng)建出來的文件權(quán)限是隨機的有時是0600有時是0000搞得其他用戶讀不了排查了很久才發(fā)現(xiàn)是umask和垃圾棧數(shù)據(jù)導(dǎo)致的。2. read與write數(shù)據(jù)搬運工的自我修養(yǎng)2.1 read的返回值是靈魂read系統(tǒng)調(diào)用的原型是#include unistd.h ssize_t read(int fd, void *buf, size_t count);這里第一個坑就是類型。ssize_t是有符號的size_t是無符號的為什么返回值要用有符號類型因為read要返回三種情況成功讀到的字節(jié)數(shù)、0表示到達文件末尾、 -1表示出錯。我在評審代碼時經(jīng)?？吹接腥诉@么寫char buf[4096]; while (1) { int n read(fd, buf, sizeof(buf)); // 這里沒有判斷n 0的情況 if (n 0) break; write(1, buf, n); }如果read返回-1n是負數(shù)被隱式轉(zhuǎn)成int如果不判斷就直接傳給write就往標準輸出寫了巨大的一坨東西——因為-1當成size_t參數(shù)傳遞時會變成一個天文數(shù)字。更致命的是這種bug不一定每次都會觸發(fā)只有在信號中斷或磁盤出錯的時候才會暴露。正確寫法是ssize_t n; while ((n read(fd, buf, sizeof(buf))) 0) { if (write(STDOUT_FILENO, buf, n) ! n) { perror(write); exit(1); } } if (n 0) { perror(read); exit(1); }2.2 write的部分寫問題遠比想象中常見write的原型是ssize_t write(int fd, const void *buf, size_t count);很多人想當然地認為write一次寫了多少就返回多少寫少的情況只有磁盤滿了。這個想法在普通文件上基本成立但在socket、管道、終端等場景下完全不成立。write只保證成功地把count個字節(jié)從用戶空間拷貝到了內(nèi)核緩沖區(qū)但它不能保證內(nèi)核緩沖區(qū)一次性全部接收。對于管道和socket當緩沖區(qū)空間不足時write只會寫入一部分字節(jié)就返回返回值小于count。而對于普通文件通常情況下一旦寫入內(nèi)核頁緩存就不會返回部分寫但如果你用O_NONBLOCK或者碰上了某些文件系統(tǒng)同樣可能部分寫。這也是為什么所有成熟的網(wǎng)絡(luò)服務(wù)庫都要自己做寫緩沖和循環(huán)寫邏輯——因為一次write根本不夠無線程序用。我給自己的文件拷貝工具封裝過一個safe_write函數(shù)ssize_t safe_write(int fd, const void *buf, size_t count) { size_t written 0; while (written count) { ssize_t n write(fd, (const char *)buf written, count - written); if (n 0) { if (errno EINTR) continue; // 信號中斷重試 return -1; } if (n 0) { errno EIO; return -1; } written n; } return (ssize_t)written; }這個函數(shù)里有兩個關(guān)鍵點一是循環(huán)寫直到寫完二是處理EINTR。EINTR問題是后面第4節(jié)要展開講的實戰(zhàn)熱點話題。3. lseek、close與文件描述符的底層語義3.1 lseek的移動方式和細節(jié)lseek的原型#include unistd.h off_t lseek(int fd, off_t offset, int whence);whence有三個取值SEEK_SET從文件頭開始offset是絕對值。SEEK_CUR從當前讀寫位置開始offset是相對值。SEEK_END從文件末尾開始offset是相對值。lseek本身是同步的、瞬時完成的它只是修改了文件描述符對應(yīng)的那個當前讀寫位置變量并沒有發(fā)生真正的磁盤I/O。所以lseek的返回值是移動后的最終位置。有一個很多人不知道但很實用的技巧用lseek(fd, 0, SEEK_CUR)來獲取當前文件的讀寫位置不需要多余變量維護。另一個技巧是用lseek(fd, 0, SEEK_END)快速拿到文件大小。但注意一個坑lseek只能用于普通文件如果用在管道、socket、終端等不可定位unseekable的文件上會返回-1并置errno為ESPIPE。所以在寫通用工具時不能假設(shè)所有fd都能lseek。3.2 close為什么可能失敗close的原型很簡單int close(int fd);關(guān)閉文件時內(nèi)核會做以下事情從進程的文件描述符表中移除該fd、釋放對應(yīng)的打開文件記錄、檢查該文件是否還有其他的打開引用包括其它進程的fd或dup出來的fd如果引用計數(shù)降到0則真正釋放inode刷新所有臟數(shù)據(jù)頁。很多人忽略的一點是close在極端情況下也可能失敗。比如NFS文件系統(tǒng)上數(shù)據(jù)延遲刷新到服務(wù)器時出錯close會返回-1errno是EIO另外一個可能的是EBADF表示fd本身不合法。你以為關(guān)閉成功了實際數(shù)據(jù)根本就沒落到磁盤上。所以嚴謹?shù)某绦蛟谕瓿蓪懖僮骱髴?yīng)當if (fsync(fd) 0) { // 處理同步失敗 } if (close(fd) 0) { // 處理關(guān)閉失敗 }當然項目中是否需要每次都fsync得看對數(shù)據(jù)安全性的要求和性能預(yù)算。fsync一次往往要等磁盤真正落盤SSD上面大概零點幾毫秒到幾毫秒機械盤上能到幾十毫秒頻繁調(diào)用對性能影響非常大。4. 系統(tǒng)調(diào)用和庫函數(shù)為什么fwrite比write高級4.1 用戶空間緩沖區(qū)是怎么回事很多人會有疑問既然底層是open/read/write那fopen/fread/fwrite是干什么的是不是多余的這就是標準C庫stdio層的意義。stdio在這幾個系統(tǒng)調(diào)用之上又加了一層用戶空間的緩沖區(qū)。默認情況下fopen打開的文件是帶緩沖的默認大小通常是4096或8192字節(jié)。你fread幾字節(jié)時它一次性從內(nèi)核讀一大塊到用戶空間buf里下次fread就直接從buf里取不用頻繁陷入內(nèi)核。read/write是無緩沖的系統(tǒng)調(diào)用每次調(diào)用都要觸發(fā)一次用戶態(tài)到內(nèi)核態(tài)的切換如果讀1個字節(jié)就調(diào)一次read性能慘不忍睹。舉個例子我之前做過一個性能對比實驗用read/write循環(huán)每次讀寫1字節(jié)復(fù)制一個100MB的文件耗時約幾秒到十幾秒。用fread/fwrite循環(huán)每次讀寫1字節(jié)耗時只有前者的幾十分之一。用read/write配合4KB緩沖區(qū)耗時和fread/fwrite差不多。原因就在于系統(tǒng)調(diào)用上下文切換的開銷被攤薄了。一次read(1字節(jié))和一次read(4096字節(jié))系統(tǒng)調(diào)用的固定開銷幾乎一樣都是那幾十個納秒的陷阱syscall成本所以你一次讀得越多攤到每個字節(jié)上的開銷就越小。4.2 用strace觀察真實系統(tǒng)調(diào)用如果你想親眼看看程序到底調(diào)用了哪些系統(tǒng)調(diào)用strace是最好的工具。一行命令strace -e traceopenat,read,write,close ./my_program輸出里會清清楚楚地列出每次系統(tǒng)調(diào)用、參數(shù)和返回值。帶-f參數(shù)還能跟蹤fork出來的子進程。我用這個方法定位過不少詭異問題——比如程序?qū)懭氲奈募笮「A(yù)期不符strace一下就看出來read只被調(diào)用了部分次數(shù)或者write被分裂成了多次小寫。實操建議碰到文件內(nèi)容不完整程序行為奇怪這類問題先別急著查邏輯跑一遍strace看系統(tǒng)調(diào)用序列大多數(shù)情況下問題一秒現(xiàn)形。怎樣判斷一個fd是否帶緩沖這是很多人的知識盲區(qū)。其實就看你是用read/write還是fread/fwrite在操作它。read/write是直接穿透用戶空間緩沖直達內(nèi)核頁緩存fread/fwrite則套了一層用戶態(tài)緩沖。同一個fd你混著用這兩種接口會出大問題——數(shù)據(jù)可能在stdio的緩沖區(qū)里還沒被flush就被write到了fd導(dǎo)致亂序。項目里最好的實踐是要么只用一層接口要么在切換接口前顯式調(diào)用fflush同步緩沖區(qū)。5. 實操寫一個靠譜的cp工具并讓它足夠快5.1 基礎(chǔ)版本的文件拷貝很多公司的筆試題就是讓你用C語言實現(xiàn)一個cp命令。最簡單的版本長這樣#include fcntl.h #include unistd.h #include stdio.h #include stdlib.h int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, Usage: %s src dst\n, argv[0]); exit(1); } int src open(argv[1], O_RDONLY); if (src 0) { perror(open src); exit(1); } int dst open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0644); if (dst 0) { perror(open dst); exit(1); } char buf[8192]; ssize_t n; while ((n read(src, buf, sizeof(buf))) 0) { ssize_t written 0; while (written n) { ssize_t w write(dst, buf written, n - written); if (w 0) { perror(write); exit(1); } written w; } } if (n 0) { perror(read); exit(1); } close(src); close(dst); return 0; }這個版本功能上是對的但有幾個專業(yè)問題沒處理close失敗。沒調(diào)用fsync數(shù)據(jù)可能還在頁緩存里突然斷電文件內(nèi)容不完整。緩沖區(qū)大小8KB在絕大多數(shù)場景下夠用但如果你想追求極致性能緩沖區(qū)大小至少要到256KB甚至1MB這樣能大幅減少系統(tǒng)調(diào)用次數(shù)。5.2 一個更專業(yè)的實現(xiàn)考慮權(quán)限、時間戳和錯誤處理專業(yè)級的cp還要考慮復(fù)制權(quán)限和文件時間戳。復(fù)制權(quán)限需要用到fstat系列調(diào)用復(fù)制時間戳則要用到utimensat。讓我寫一個更快一點點的版本把幾個關(guān)鍵點塞進去#include fcntl.h #include unistd.h #include stdio.h #include stdlib.h #include sys/stat.h #include sys/types.h int copy_file(const char *src_path, const char *dst_path) { int src open(src_path, O_RDONLY); if (src 0) { perror(open src); return -1; } struct stat st; if (fstat(src, st) 0) { perror(fstat); close(src); return -1; } int dst open(dst_path, O_WRONLY | O_CREAT | O_TRUNC, st.st_mode 0777); if (dst 0) { perror(open dst); close(src); return -1; } // 用大緩沖區(qū)減少系統(tǒng)調(diào)用次數(shù) size_t bufsize 1024 * 128; char *buf malloc(bufsize); if (!buf) { close(src); close(dst); return -1; } ssize_t n, written; while ((n read(src, buf, bufsize)) 0) { size_t off 0; while (off (size_t)n) { written write(dst, buf off, n - off); if (written 0) { perror(write); free(buf); close(src); close(dst); return -1; } off written; } } free(buf); close(src); if (fsync(dst) 0) { perror(fsync); close(dst); return -1; } if (close(dst) 0) { perror(close dst); return -1; } return 0; } int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, Usage: %s src dst\n, argv[0]); return 1; } return copy_file(argv[1], argv[2]) 0 ? 0 : 1; }這個版本我沒有復(fù)制文件的所有擴展屬性只覆蓋了權(quán)限和內(nèi)容。完整實現(xiàn)cp命令還應(yīng)該考慮硬鏈接、符號鏈接、ACL、時間戳等這里點到為止重點在于把系統(tǒng)調(diào)用用對了。5.3 性能變數(shù)與內(nèi)核頁緩存的關(guān)系有意思的是文件拷貝性能不只取決于緩沖區(qū)大小還跟內(nèi)核頁緩存的狀態(tài)強相關(guān)。第一次拷貝一個大文件時數(shù)據(jù)從磁盤讀入內(nèi)核頁緩存page cache再從頁緩存拷貝到用戶空間buf最后又從用戶空間寫到內(nèi)核頁緩存關(guān)聯(lián)到目標文件的臟頁。整個過程其實是在磁盤 - 頁緩存 - 用戶空間 - 頁緩存 - 磁盤之間轉(zhuǎn)了兩道。如果目錄項、inode、塊映射信息都已被緩存了第二次拷貝同樣的文件源和目標都在緩存里會快很多。這也是為什么性能測試必須做冷緩存和熱緩存兩輪對比第一次跑是真實磁盤IO第二次跑可能已經(jīng)完全被頁緩存覆蓋了數(shù)據(jù)根本不落盤。經(jīng)驗之談在Linux上做性能基準時echo 3 /proc/sys/vm/drop_caches 可以清掉頁緩存需要root權(quán)限確保每次跑的是相對真實的磁盤性能。6. 實戰(zhàn)排查文件操作中遇到的幾個問題6.1 EINTR信號中斷問題這是多線程/信號處理程序里最經(jīng)典的坑。假設(shè)你的程序注冊了定時器信號SIGALRM或者用signalfd接信號那么當信號到達時如果程序正阻塞在一個慢速系統(tǒng)調(diào)用上比如read一個慢設(shè)備、還被阻塞在等數(shù)據(jù)系統(tǒng)調(diào)用會被信號打斷內(nèi)核直接返回到用戶空間此時read返回-1errno被置為EINTR。最惡心的在于它不是一個確定的錯誤——文件操作每次都成功偶爾一次失敗然后程序直接退出。這就是典型的EINTR沒處理好。處理方法很簡單把read/write包一層循環(huán)碰到EINTR就重試ssize_t n; do { n read(fd, buf, sizeof(buf)); } while (n 0 errno EINTR);我見過生產(chǎn)環(huán)境下一個日志服務(wù)莫名其妙地丟數(shù)據(jù)排查到最后就是某個write被信號中斷后日志模塊直接break了循環(huán)一條日志就這么消失了。6.2 文件讀取不完整詭異又常見還有一次一個同事寫的程序把一個大文件讀入內(nèi)存他用fseek拿文件大小malloc一塊內(nèi)存然后用一次fread把它全讀進來。在小文件上沒問題但文件超過幾十MB后他寫的fread只調(diào)用了一次而且沒有檢查返回值是不是等于期望的字節(jié)數(shù)。而fread在普通文件上通?？梢砸淮巫x完但在某些文件系統(tǒng)上或者當內(nèi)存壓力大時會分多次返回。后來我給他推薦了兩種寫法。第一種循環(huán)讀取直到EOFsize_t total 0; ssize_t n; while ((n read(fd, buf total, size - total)) 0) { total n; }第二種更優(yōu)雅的做法是用mmap直接把文件映射到進程地址空間省去反復(fù)read和搬移數(shù)據(jù)的開銷。這個后面第7節(jié)細講?？偟膩碚f通用教訓是永遠不要假設(shè)一次read/fread能讀完肉眼看著合理的代碼在極端條件下不一定正確。6.3 磁盤空間滿時的write行為磁盤滿了write會失敗返回-1errno為ENOSPC。這個大家都會判斷但有個隱蔽點部分寫也可以發(fā)生在磁盤滿的場景。想象你write了8192字節(jié)內(nèi)核先接受了4096字節(jié)然后發(fā)現(xiàn)磁盤塊不夠了此時write返回的是4096還是-1POSIX語義是這樣的對于普通文件write通常是在頁緩存層面完成的數(shù)據(jù)先進入緩存落盤發(fā)生在后臺。只要頁緩存能放得下write就返回成功即使磁盤實際滿了也只是后臺刷盤時出錯。但如果文件系統(tǒng)在寫入路徑上就檢測到空間不足比如分配不了新塊這常見于一些日志式文件系統(tǒng)就會導(dǎo)致部分寫。那你怎么知道該不該重試重試可能無限循環(huán)因為空間一直沒釋放。做法是write返回-1且errnoENOSPC時停止寫入清理臨時文件或者提示用戶釋放空間。項目里處理這個問題的標準邏輯是if (w 0) { if (errno ENOSPC) { fprintf(stderr, no space left on device\n); return -1; } }6.4 文件描述符泄露燙手的山芋寫長期運行的服務(wù)時fd泄露比內(nèi)存泄露還致命。內(nèi)存泄露可能只是進程占用內(nèi)存變大fd耗盡后open直接返回EMFILE之后連日志都寫不了。我之前排查過一個后臺服務(wù)運行一周后所有新連接都建立失敗strace看到錯誤是Too many open files?？戳诉M程的/proc/pid/fd目錄發(fā)現(xiàn)大量指向同一個日志文件的描述符——代碼里每次寫日志都open一次但close被放在了某條錯誤分支之后結(jié)果異常退出時沒關(guān)掉。排查技巧很簡單ls /proc/pid/fd | wc -l對比正常值lsof -p pid或者直接看 /proc/pid/fd 目錄按文件的inode歸類就能快速看出哪些fd重復(fù)打開了。7. 進階內(nèi)容mmap、O_DIRECT和原子操作把小細節(jié)打通7.1 mmap把文件變成內(nèi)存mmap是文件操作的高階話題它能把文件的一部分直接映射到進程的虛擬地址空間。映射完成后讀寫文件就像讀寫內(nèi)存數(shù)組一樣不需要read/write系統(tǒng)調(diào)用也不需要自己管理用戶空間緩沖區(qū)。#include sys/mman.h #include sys/stat.h #include fcntl.h #include unistd.h #include stdio.h int main() { int fd open(/tmp/data.bin, O_RDONLY); if (fd 0) { perror(open); return 1; } struct stat st; fstat(fd, st); char *addr mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if (addr MAP_FAILED) { perror(mmap); close(fd); return 1; } // 直接像訪問數(shù)組一樣訪問文件內(nèi)容 printf(first byte: %d\n, addr[0]); // 要修改文件內(nèi)容就用 PROT_WRITE | MAP_SHARED munmap(addr, st.st_size); close(fd); return 0; }mmap讀取的性能優(yōu)勢在讀大文件時很明顯因為省掉了用戶空間緩沖的拷貝零拷貝的思想算是它的簡化版而且內(nèi)核按需調(diào)頁文件內(nèi)容不需要一次性全部調(diào)入內(nèi)存。讀一個2GB的文件mmap后訪問其中一小段內(nèi)存開銷很小。需要注意mmap映射的長度不能超過文件實際大小否則訪問越界部分會觸發(fā)SIGBUS。另外文件被截斷truncate而映射還在時訪問截斷后的區(qū)域同樣會SIGBUS。7.2 O_DIRECT繞過頁緩存O_DIRECT是open時的一個標志它的含義是讀寫操作直接訪問用戶空間的緩沖區(qū)繞過內(nèi)核頁緩存。注意這不是更高級這個模式通常只有數(shù)據(jù)庫這類需要自己管理緩存的應(yīng)用才用。普通程序用O_DIRECT反而可能導(dǎo)致性能更差因為少了頁緩存這層緩沖區(qū)。使用O_DIRECT時緩沖區(qū)地址和長度有對齊要求——通常要求對齊到文件系統(tǒng)邏輯塊大小一般512字節(jié)或4KB。不滿足對齊條件read/write會返回EINVAL錯誤。int fd open(/tmp/data.bin, O_RDONLY | O_DIRECT);如果你自己寫演示程序建議先用posix_memalign分配內(nèi)存且長度是512的整數(shù)倍這樣最常見。心得在云服務(wù)器上我發(fā)現(xiàn)O_DIRECT在文件系統(tǒng)被緩存污染嚴重時比如大量隨機寫導(dǎo)致緩存命中率下降反而能帶來性能提升。但大多數(shù)場景里讓內(nèi)核管頁緩存是更優(yōu)的選擇。7.3 文件操作中的原子性O(shè)_APPEND已經(jīng)保證了多進程追加寫時每次write的原子性指偏移量定位和寫入是一個原子操作不會出現(xiàn)兩個進程寫重疊。但這并不保證你的寫不會交錯——如果你一次只寫一行字符串而多個進程同時寫同一個日志文件行與行之間可能出現(xiàn)錯亂因為每個write本身是原子的但兩次write之間不一定連續(xù)。還有個經(jīng)典技巧是創(chuàng)建臨時文件后rename。寫文件時先寫一個臨時文件寫完并fsync然后rename到目標路徑。rename是原子的——任何時刻目標路徑要么指向舊文件要么指向新文件不會出現(xiàn)中間狀態(tài)。這是處理配置文件更新時崩潰問題的最佳實踐。8. 面試題視角這些系統(tǒng)調(diào)用你會被問到什么Linux崗位面試里文件操作是必考模塊下面幾個問題我總結(jié)了一下面試官問的角度在實戰(zhàn)中很有價值open返回的fd一定是最小的可用fd嗎 答案是是的。Linux內(nèi)核分配fd時總是從當前進程的fd表中選取最小的空閑數(shù)字。這個細節(jié)可以用在關(guān)閉標準輸出重定向再打開文件的場景里。兩個進程同時open同一個文件它們的offset是獨立的還是共享的 獨立。每個進程的fd是獨立的內(nèi)核中的打開文件記錄也是獨立的所以offset自然獨立。如果兩個進程都想追加寫需要用O_APPEND來保證定位和寫入的原子性。read一個socket返回0是讀到EOF了嗎 不一定。對socket來說返回0通常表示對端關(guān)閉了連接FIN但這不等于底層數(shù)據(jù)已經(jīng)全部讀完——準確說是不會再讀到新數(shù)據(jù)了。write到pipebuffer滿時會發(fā)生什么 阻塞模式下write會一直阻塞直到有讀者消費掉數(shù)據(jù)或?qū)懭肴砍晒Ψ亲枞Ｊ较铝⒓捶祷?1errno為EAGAIN或EWOULDBLOCK。這個場景在并發(fā)編程中很常見。符號鏈接和硬鏈接在open時表現(xiàn)一樣嗎 不一樣。open符號鏈接時內(nèi)核會透明地跟隨它找到目標文件再打開而用openO_NOFOLLOW可以直接控制是否跟隨。硬鏈接本質(zhì)是同一個inode的另一個目錄項open結(jié)果完全一樣。再分享一個小技巧寫代碼之前用man 2 open、man 2 read這樣的命令看看官方文檔比任何博客都靠譜。Linux的man手冊把這些系統(tǒng)調(diào)用的語義、錯誤碼、邊界條件寫得很詳細很多疑難問題都能從里面找到答案。我在實際工作里還有一個習慣就是在寫涉及文件I/O的代碼時先在草稿紙上把成功路徑和失敗路徑的fd生命周期畫出來確保每個分支都正確關(guān)閉fd。這個習慣幫我避免過很多次fd泄露問題也讓我給代碼加錯誤處理時不再覺得麻煩。文件操作看似基礎(chǔ)但因為太基礎(chǔ)反而容易被輕視。希望這篇文章能幫你把系統(tǒng)調(diào)用這塊補齊——只有理解了內(nèi)核在背后干什么你寫出來的代碼才能在程序里真正站穩(wěn)腳跟。