一、文件讀寫的用戶程序、操作系統、磁盤交互原理
最近為了徹底搞懂文件讀寫原理，我特意查詢了很多資料，包括Java讀寫文件的API代碼、操作系統處理文件以及磁盤硬件知識等。由於網上現存技術文章，幾乎沒有找到一篇能夠徹底綜合講明白這個原理的文章。心中還是有很多疑問。且有不少文章包括書籍所闡述的隨機/順序讀寫原理講述的都是錯誤或誤導性的。所以我綜合了一下我能查閱到的所有資料，深入細節知識，給大家徹底講明白這事。原創文章，轉發請保留第一作者著作權。謝謝！
如下圖所示。我們編寫的用戶程序讀寫文件時必須經過的OS和硬件交互的內存模型。
1、讀文件
用戶程序通過編程語言提供的讀取文件api發起對某個文件讀取。此時程序切換到內核態，用戶程序處於阻塞狀態。由於讀取的內容還不在內核緩沖區中，導致觸發OS缺頁中斷異常。然后由OS負責發起對磁盤文件的數據讀取。讀取到數據后，先存放在OS內核的主存空間，叫PageCache。然后OS再將數據拷貝一份至用戶進程空間的主存ByteBuffer中。此時程序由內核態切換至用戶態繼續運行程序。程序將ByteBuffer中的內容讀取到本地變量中，即完成文件數據讀取工作。
2、寫文件
用戶程序通過編程語言提供的寫入文件api發起對某個文件寫入磁盤。此時程序切換到內核態用戶程序處於阻塞狀態，由OS負責發起對磁盤文件的數據寫入。用戶寫入數據后，並不是直接寫到磁盤的，而是先寫到ByteBuffer中，然后再提交到PageCache中。最后由操作系統決定何時寫入磁盤。數據寫入PageCache中后，此時程序由內核態切換至用戶態繼續運行。
用戶程序將數據寫入內核的PageCache緩沖區后，即認為寫入成功了。程序由內核態切換回用於態，可以繼續后續的工作了。PageCache中的數據最終寫入磁盤是由操作系統異步提交至磁盤的。一般是定時或PageCache滿了的時候寫入。如果用戶程序通過調用flush方法強制寫入，則操作系統也會服從這個命令。立即將數據寫入磁盤然后由內核態切換回用戶態繼續運行程序。但是這樣做會損失性能，但可以確切的知道數據是否已經寫入磁盤了。
一、文件讀寫詳細過程
1、讀文件
如下所示為一典型Java讀取某文件內容的用戶編程代碼。接下來我們詳細解說讀取文件過程。
// 一次讀多個字節 byte[] tempbytes = new byte[100]; int byteread = 0; in = new FileInputStream(fileName);//① ReadFromFile.showAvailableBytes(in); // 讀入多個字節到字節數組中，byteread為一次讀入的字節數 while ((byteread = in.read(tempbytes)) != -1) { //② System.out.write(tempbytes, 0, byteread); }
首先通過位置①的代碼發起一個open的系統調用，程序由用戶態切換到內核態。操作系統通過文件全路徑名在文件目錄中找到目標文件名對應的文件iNode標識ID，然后用這個iNode標識ID在iNode索引文件找到目標文件iNode節點數據並加載到內核空間中。這個iNode節點包含了文件的各種屬性（創建時間，大小以及磁盤塊空間占用信息等等）。然后再由內核態切換回用戶態，這樣程序就獲得了操作這個文件的文件描述。接下來就可以正式開始讀取文件內容了。
然后再通位置②，循環數次獲取固定大小的數據。通過發起read系統調用，操作系統通過文件iNode文件屬性中的磁盤塊空間占用信息得到文件起始位的磁盤物理地址。再從磁盤中將要取得數據拷貝到PageCache內核緩沖區。然后將數據拷貝至用戶進程空間。程序由內核態切換回用戶態，從而可以讀取到數據，並放入上面代碼中的臨時變量tempbytes中。
整個過程如下圖所示。
至於上面說到的操作系統通過iNode節點中的磁盤塊占用信息去定位磁盤文件數據。其細節過程如下圖所示。
①根據文件路徑從文件目錄中找到iNode ID。
用戶讀取一個文件，首先需要調用OS中文件系統的open方法。該方法會返回一個文件描述符給用戶程序。OS首先根據用戶傳過來的文件全路徑名在目錄索引數據結構中找到文件對應的iNode標識ID。目錄數據是存在於磁盤上的，在OS初始化時就會加載到內存中，由於目錄數據結構並不會很龐大，一次性加載駐留到內存也不是不可以或者部分加載，等需要的時候在從磁盤上調度進內存也可以。根據文件路徑在目錄中查找效率應該是很高的，因為目錄本身就是一棵樹，應該也是類似數據庫的樹形索引結構。所以它的查找算法時間復雜度就是O(logN)。具體細節我暫時還沒弄清楚，這不是重點。
iNode就是文件屬性索引數據了。磁盤格式化時OS就會把磁盤分區成iNode區和數據區。iNode節點就包含了文件的一些屬性信息，比如文件大小、創建修改時間、作者等等。其中最重要的是還存有整個文件數據在磁盤上的分布情況（文件占用了哪些磁盤塊）。
②根據iNode ID從Inode索引中找到文件屬性。
得到iNode標識的ID后，就可以去iNode數據中查找到對應的文件屬性了,並加載到內存，方便后續讀寫文件時快速獲得磁盤定位。iNode數據結構應該類似哈希結構了，key就是iNode標識ID，value就是具體某個文件的屬性數據對象了。所以它的算法時間復雜度就是O(1)。具體細節我暫時還沒弄清楚，這不是重點。
我們系統中的文件它的文件屬性（iNode）和它的數據正文是分開存儲的。文件屬性中有文件數據所在磁盤塊的位置信息。
③根據文件屬性中的磁盤空間塊信息找到需要讀取的數據所在的磁盤塊的物理位置
文件屬性也就是iNode節點這個數據結構，里面包含了文件正文數據在磁盤物理位置上的分布情況。磁盤讀寫都是以塊為單位的。所以這個位置信息其實也就是一個指向磁盤塊的物理地址指針。
其結構圖如下。
文件屬性里就包含了文件正文數據占有磁盤所有信息。但是由於文件屬性大小有限制，而文件大小沒有限制。這樣會導致磁盤塊占用信息超出限制。所以最后一個磁盤數據項設計為特殊的作用。它是一個指向更多磁盤占用信息數據的指針。這些更多信息存放在普通的數據區。這樣當文件iNode加載到內存后，可以把其他更多磁盤塊信息一起加載進來。這樣就避免了iNode索引文件太大的問題。
后續的文件讀寫系統調用，由用戶態切換至內核態。操作系統就可以根據文件數據的相對位置（偏移量）快速從iNode中的磁盤塊占用數據結構中找到其對應的磁盤物理位置在哪里了。很明顯這個數據結構類似哈希結構，其算法復雜度就是O(1)。
比如我們現在討論的讀取數據。每次用戶代碼的api調用read方法時。由於時從頭開始讀取，所以OS就從上圖中“磁盤塊0”數據項開始迭代，獲取對應的物理磁盤塊起始地址開始讀取數據並拷貝至PageCache緩沖區，再拷貝至用戶進程緩沖區。這樣用戶代碼就可以獲取這些數據了。
考慮到另外一種隨機讀的場景。我們並不是把整個文件從頭開始讀一遍。而是需要直接定位到文件的中間某個位置開始 讀取部分內容。如下所示。
RandomAccessFile raf=new RandomAccessFile(new File("D:\\3\\test.txt"), "r"); //獲取RandomAccessFile對象文件指針的位置，初始位置是0 System.out.println("RandomAccessFile文件指針的初始位置:"+raf.getFilePointer()); raf.seek(pointe);//移動文件指針位置 byte[] buff=new byte[1024]; //用於保存實際讀取的字節數 int hasRead=0; //循環讀取 while((hasRead=raf.read(buff))>0){ //打印讀取的內容,並將字節轉為字符串輸入 System.out.println(new String(buff,0,hasRead)); }
程序代碼調用seek方法直接定位到某個文件相對位置開始讀取內容。實際上就是調用了OS管理文件的系統調用seek函數。這個系統調用需要傳遞一個文件相對位置也就是偏移量，不是指磁盤的物理位置。文件的相對位置偏移量是從0開始的，結束位置和文件的大小字節數相等。操作系統拿到這個偏移量后，就可以計算出文件所屬的邏輯塊編號。因為每個塊是固定大小的，所以能計算出來。通過文件屬性的邏輯磁盤塊信息就能得到磁盤塊的物理位置。從而可以快速直接定位到磁盤物理塊讀取到需要的數據。這里說的邏輯塊和物理塊的概念是有區別的。邏輯塊屬於當前的文件從0開始編號，物理塊才是磁盤真正的存放數據的區域，屬於全局的。編號自然不是從0開始的。
2、寫文件
寫文件的過程和前面闡述的差不多，相關的知識點也在讀文件中已經順帶描述了。就不在贅述了。這里就說些特別需要注意的點就行。
③根據空閑塊索引找到可以寫入的物理位置並寫入
如上圖所示，OS寫文件內容時首先要訪問磁盤空閑塊索引表。這是個什么東西呢？由於磁盤很大，不可能每次寫數據時，都讓磁頭從頭到尾遍歷一次才能找到空閑位置。這樣效率可想而知的差勁。所以OS會把磁盤上的空閑塊索引起來存放在磁盤某個位置上。后續磁盤存儲和刪除文件內容時都通過這個空閑塊索引表快速定位，同時刪除數據也會更新索引表增加空閑塊。
空閑塊記錄索引的實現常用有兩種，一種是我們熟悉的鏈表結構，還有一種是位圖結構。這里就不詳細討論了。
④寫入數據后更新iNode里的磁盤占用塊索引
數據寫入后，那么這個空閑塊就被占用了，自然也就需要更新下iNode文件屬性里的磁盤占用塊索引數據了。
我們前面說的寫文件都是只講了尾部追加這種方式。但是實際上我們可以通過
RandomAccessFile類實現文件隨機位置寫功能。但是我們同時也有一些困惑。為啥不能直接在中間某個位置插入我們要寫的內容，而是要先把插入位置后面的內容截取放入臨時文件中。插入新內容后，再把臨時文件內容尾部追加到原來的文件中來實現文件修改？代碼如下所示。
public static void insert(String fileName, long pos, String insertContent) throws IOException{ File file = File.createTempFile("tmp", null); file.deleteOnExit(); RandomAccessFile raf = new RandomAccessFile(fileName, "rw"); FileInputStream fileInputStream = new FileInputStream(file); FileOutputStream fileOutputStream = new FileOutputStream(file); raf.seek(pos); byte[] buff = new byte[64]; int hasRead = 0; while((hasRead = raf.read(buff)) > 0){ fileOutputStream.write(buff); } raf.seek(pos); raf.write(insertContent.getBytes()); //追加文件插入點之后的內容 while((hasRead = fileInputStream.read(buff)) > 0){ raf.write(buff, 0, hasRead); } raf.close(); fileInputStream.close(); fileOutputStream.close(); }
按照我們上面的闡述，寫入的文件內容完全可以存入磁盤上的一個新塊，然后更新下iNode屬性里的占用磁盤塊索引數據即可。也不需要真的去移動磁盤上的所有數據塊。看上去成本也很小，可為啥我們的編程api卻都不支持呢？
我想答案可能是這樣的。假如允許我們上面那種操作，如果一個很大的文本文件。你現在只是編輯了文本中間某個位置的一個字，即插入了一個文本字符。那么此時這個新增的文本內容就得在磁盤上找到一個新的塊存儲下來。這樣是不是有點浪費空間呢？因為磁盤上的一個塊只能分配給一個文件使用，塊大小如果是64kb的話，一個字符也就占用了2個字節的空間。更要命的是這樣一搞，使得原本滿存狀態的塊，出現很多不連續的空洞。這樣就會使得讀取文件時數據是不連續的，系統需要額外信息記錄這些中間的存儲空洞。加大了讀取難度。這就是我猜測的原因。實際上操作系統層面也沒有這種操作插入的系統調用函數。故編程語言層面也就沒法支持了。
操作系統層面給上層應用程序提供了寫文件的兩個系統調用。write和append，其中append是write的限制形式，即只能在文件尾部追加。而write雖然提供了隨機位置寫，但是並不是將新內容插入其中，而是覆蓋原有的數據。我們平時使用Word文本編輯軟件時，如果對一個很大的文件進行編輯，然后點擊保存，你會發現很慢。同時你還能看到文件所在的目錄下生成了一個新的處於隱藏狀態的臨時文件。這些現象也能說明我們上面的觀點。即編輯文件時，需要一個成本很高的過程。如下圖所示。
三、常見認知誤區澄清
1、磁盤上文件存儲數據結構是鏈表，每一塊文件數據節點里有一個指針指向下一塊數據節點。理解錯誤！
很多人都知道磁盤存儲一個文件不可能是連續分配空間的。而是東一塊西一塊的存儲在磁盤上的。就誤以為這些分散的數據節點就像鏈表一樣通過其中一個指針指向下一塊數據節點。如下圖所示。
怎么說呢？這種方案以前也是有一些文件系統實現過的方案，但是現在常見的磁盤文件系統都不再使用這種落后的方案。而是我前面提到的iNode節點方案。也就是說磁盤上存儲的文件數據塊就是純數據，沒有其他指針之類的額外信息。之所以我們能順利定位這些數據塊，都全靠iNode節點屬性中磁盤塊信息的指針。
2、append文件尾部追加方法是順序寫，也就是磁盤會分配連續的空間給文件存儲。理解錯誤！
這種觀點，包括網上和某些技術書籍里的作者都有這種觀點。實際上是錯誤的。或許是他們根本沒有細究文件存儲底層OS和磁盤硬件的工作原理導致。我這里就重新總結糾正一下這種誤導性觀點。
前面說過，append系統調用是write的限制形式，即總是在文件末尾追加內容。看上去好像是說順序寫入文件數據，因為是在尾部追加啊！所以這樣很容易誤導大家以為這就是順序寫，即磁盤存儲時分配連續的空間給到文件，減少了磁盤尋道時間。
事實上，磁盤從來都不會連續分配空間給哪個文件。這是我們現代文件系統的設計方案。前面介紹iNode知識時也給大家詳細說明了。所以就不再贅述。我們用戶程序寫文件內容時，提交給OS的緩沖區PageCache后就返回了。實際這個內容存儲在磁盤哪個位置是由OS決定的。OS會根據磁盤未分配空間索引表隨機找一個空塊把內容存儲進去，然后更新文件iNode里的磁盤占用塊索引數據。這樣就完成了文件寫入操作。所以append操作不是在磁盤上接着文件末尾內容所在塊位置連續分配空間的。最多只能說邏輯上是順序的。
那么邏輯上的隨機寫write是不是會慢呢？根據前面介紹的原理，應該是相同的效率。我們可以做如下測試驗證。使用RandomAccessFile 實現，因為只有這個類支持隨機位置寫入，其他寫文件類都只提供尾部追加方式。打開一個20M的文本文件“test.txt”。分別采用如下兩個方法，隨機位置寫入和尾部追加寫入做100000次操作，多次測得大概的平均耗時數據。
// 文件隨機位置寫入 耗時：1000ms public static void randomWrite1(String path,String content) throws Exception { RandomAccessFile raf=new RandomAccessFile(path,"rw"); Random random=new Random(); for(int i=0;i<100000;i++){ raf.seek(random.nextInt((int)raf.length())); // 在文件隨機位置寫入覆蓋 raf.write((i+content+System.lineSeparator()).getBytes()); } raf.close(); } // 文件尾部位置寫入 耗時：800ms public static void randomWrite2(String path,String content) throws Exception { RandomAccessFile raf=new RandomAccessFile(path,"rw"); for(int i=0;i<100000;i++){ raf.seek(raf.length()); // 總是在文件尾部追加 raf.write((i+content+System.lineSeparator()).getBytes()); } raf.close(); }
看上去采用尾部追加性能略高。實際上也相差不大。多出的200ms只是生成隨機數消耗的。因為如果說隨機位置寫需要某些人認為的磁盤磁頭來回反復移動，則性能不可能只差這么一丟丟。實際上我去掉隨機數生成的代碼，改用固定中間位置寫入，這兩個方法耗時幾乎沒有區別了。這說明無論是尾部追加還是隨機位置寫入方式，性能都是一樣的。因為根據前面介紹的原理，OS通過iNode中的磁盤占用塊哈希表，可以快速定位到目標磁盤物理位置，其算法時間復雜度是O(1)。所以尾部追加也是一樣的定位效率。
可能也有些人想說怎么不試試BufferWriter、FileWriter等寫入類，效率高幾個數量級比RandomAccessFile 。我也的確測試過，但是這些類都是采用尾部追加模式，無法和其隨機位置寫入做比較。所以沒法拿出來測試說明。但是這些類寫入性能之所以遠高於直接用RandomAccessFile 尾部追加。我想是因為api方法做了用戶程序層面的優化，比如批量寫入，批量轉化成Byte之類的。而RandomAccessFile 可能就是最原始的直接對接OS系統調用層的API了。
3、mmap內存映射技術之所以快，是因為直接把磁盤文件映射到用戶空間內存，不走內核態。理解錯誤！
這也是一種常見的認知誤區，實際上這個技術是操作系統給用戶程序提供的一個系統調用函數。它把文件映射到OS內核緩沖區空間，同時共享給用戶進程，也可以共享給多個用戶進程。映射過程中不會產生實際的數據從磁盤真正調取動作，只有用戶程序需要的時候才會調入部分數據。總之也是和普通文件讀取一樣按需調取。那么mmap技術為什么在讀取數據時會比普通read操作快幾個數量級呢？
上面我們講述了普通讀寫操作的內存模型。用戶程序要讀取到磁盤上的數據。要經歷4次內核態切換以及2次數據拷貝操作。那么mmap技術由於是和用戶進程共享內核緩沖區，所以少了一次拷貝操作（數據從內核緩沖區到用戶進程緩沖區）。從而大大提高了性能。如下圖所示。
4、mmap內存映射技術寫文件快是因為順序寫磁盤。理解錯誤！
上面的問題基本已經讓我們理解了mmap技術的內存模型。同樣的，我們寫文件時，由於也少了一次數據從用戶緩沖區到內核緩沖區的拷貝操作。使得我們的寫效率非常的高。並不是很多人認為的數據直達磁盤，中間不經過內核態切換，並且連續在磁盤上分配空間寫入。這些理解都是錯誤的。
5、隨機讀寫文件比順序讀寫文件慢，是因為磁盤移動磁頭來回隨機移動導致。理解錯誤！
這也是一種常見的誤區。我看過很多文章都是這樣認為的。其實所有的寫操作在硬件磁盤層面上都是隨機寫。這是由現代操作系統的文件系統設計方案決定的。我們用戶程序寫入數據提交給OS緩沖區之后，就與我們沒關系了。操作系統決定何時寫入磁盤中的某個空閑塊。所有的文件都不是連續分配的，都是以塊為單位分散存儲在磁盤上。原因也很簡單，系統運行一段時間后，我們對文件的增刪改會導致磁盤上數據無法連續，非常的分散。
當然OS提交PageCache中的寫入數據時，也有一定的優化機制。它會讓本次需要提交給磁盤的數據規划好磁頭調度的策略，讓寫入成本最小化。這就是磁盤調度算法中的電梯算法了。這里就不深入講解了。
至於讀文件，順序讀也只是邏輯上的順序，也就是按照當前文件的相對偏移量順序讀取，並非磁盤上連續空間讀取。即便是seek系統調用方法隨機定位讀，理論上效率也是差不多的。都是使用iNode的磁盤占用塊索引文件快速定位物理塊。