FileShare文件讀寫鎖解決「文件XXX正由另外一進程使用，所以該進程沒法訪問此文件」（轉）

開發過程當中，咱們每每須要大量與文件交互，讀文件，寫文件已成屢見不鮮，本地運行完美，但一上到投產環境，每每會出現不少使人措手不及的意外，或開發中的煩惱，所以，我對普通的C#文件操做作了一次總結，問題大部分以下：

 

 1：寫入一些內容到某個文件中，在另外一個進程/線程/後續操做中要讀取文件內容的時候報異常，提示 System.IO.IOException: 文件「XXX」正由另外一進程使用，所以該進程沒法訪問此文件。

 2：在對一個文件進行一些操做後（讀/寫），隨後想追加依然報System.IO.IOException: 文件「XXX」正由另外一進程使用，所以該進程沒法訪問此文件。次問題與1類似。

 3：對一個文件進行一些操做後，想刪除文件，依然報System.IO.IOException: 文件「XXX」正由另外一進程使用，所以該進程沒法訪問此文件。

看到這些，有經驗的同窗應該就會說資源沒被釋放掉，但也存在以下可能性。咱們對文件的操做很是頻繁，因此寫了特定的操做類/組件來維護文件之間的操做，知道特定的時刻才結束，常見的如日誌，隨着程序的啓動便開始寫日誌，直到程序關閉。但其中也存在咱們須要提供一個特殊的操做（讀/寫/刪除）來操做文件，例如咱們須要提供一個日誌查看器來查看當前日誌或全部日誌，這時，便無可避免的發生了以上的問題。

static void WriteFile(FileMode fileMode, FileAccess fileAccess, FileShare fileShare)
{
    Console.WriteLine("please input your content.");
    var content = Console.ReadLine();
    FileStream fs = new FileStream(FILEPATH, fileMode, fileAccess, fileShare);
    var buffer = Encoding.Default.GetBytes(content);
    fs.Write(buffer, 0, buffer.Length);
    fs.Flush();
}

首先，我聲明瞭一個寫文件方法，並調用它，它將我輸入的內容寫入指定的文件當中。

WriteFile(FileMode.Create, FileAccess.Write, FileShare.Read);
Console.ReadKey();

 

 

 

可是，在寫文件操做結束以後，我並無釋放掉文件流的資源。因此，此時會對文件形成一個鎖。我嘗試在windows中刪除它。

 

很明顯我沒法刪除掉這個文件，接下來，我嘗試讀取它。

 

static void ReadFile(FileAccess fileAccess, FileShare fileShare)
{
    FileStream fs = new FileStream(FILEPATH, FileMode.Open, fileAccess, fileShare);
    var buffer = new byte[fs.Length];
    fs.Position = 0;
    fs.Read(buffer, 0, buffer.Length);
    Console.WriteLine(Encoding.Default.GetString(buffer));
}

 

我實現了一個讀文件方法，並調用了它。

WriteFile(FileMode.Create, FileAccess.Write, FileShare.Read);
ReadFile(FileAccess.Read, FileShare.Read);

 

一切都很簡單，訪問模式爲只讀，這樣應該就不會與上面的寫鎖進行衝突！

 

可是，結果並不是咱們所預想的那樣，爲何會提示沒法訪問？回想一下，在前面，我用windows的記事本打開了這個文件，並無提示說文件被鎖定，我也的確能訪問，那爲什麼到了程序裏就沒法訪問了呢？或許，咱們應該把重點放在FileMode，FileAccess，FileShare這三個枚舉身上，說不定就是它們搞的鬼。

 

FileMode

MSDN上的解釋是指定操做系統打開文件的方式，我想這個應該不須要解釋了，你們平時用得比較多了。MSDN的表格也很好的闡述了各個枚舉值的做用，我就不在解釋了。

FileAccess

定義用於文件讀取、寫入或讀取/寫入訪問權限的常數。

 

這個枚舉也用得比較多了，描述也很通俗易懂，我也不便再解釋了。^_^!

FileShare

相信這個枚舉類型你們會比較陌生，甚至有同窗見都沒見過（慚愧的是，我也是才認識它沒多久），陌生歸陌生，但它的做用力也是不可低估，只是.Net幫咱們把它封裝得比較好，以致於咱們一度認爲它不是什麼重要角色。好吧，進入主題！

包含用於控制其餘 FileStream 對象對同一文件能夠具備的訪問類型的常數。這句話是什麼意思呢？說實話，我如今看句話仍是以爲很糾結，相信不少同窗看到也是一頭霧水，不要緊，咱們先跳過！

 

看它的成員描述，和FileAccess非常類似，那咱們就嘗試着來揭開它暫時神祕的面紗吧！

FileShare.Read

從字面上的意思，咱們能夠理解爲首先打開一個文件以後（資源未釋放），咱們能夠再用只讀的方式讀取文件從而不會拋出文件沒法訪問的異常。利用剛纔實現的方法，能夠輕易的再完成這個實驗：

 

WriteFile(FileMode.Create, FileAccess.Write, FileShare.Read);
ReadFile(FileAccess.Read, FileShare.Read);

這是什麼回事？不是都設置成已讀了嗎？或許只能在讀文件的時候才能設置爲只讀共享。咱們再嘗試一下：
 

ReadFile(FileAccess.Read, FileShare.Read);
ReadFile(FileAccess.Read, FileShare.Read);

 

此次的確是能在第一次沒釋放資源時再讀，那咱們再試試可否在設置只讀共享後寫文件：

ReadFile(FileAccess.Read, FileShare.Read);
WriteFile(FileMode.Create, FileAccess.Write, FileShare.Read);

 

 

首先正確的讀出了文件的內容，但當我嘗試寫入一些內容的時候卻又報錯了。那麼，根據以上的實驗，就能夠得知這個只讀的共享只有是在連續讀取文件纔有效！

 

FileShare.Write

結合Read的經驗，字面上的意思應該能夠理解爲，只有在寫文件時設置共享方式爲Write，隨後才能繼續寫入文件，不然會拋出異常。這裏比較好玩的時，設置Write以後，萬能的Window記事本也打不開文件了。

 

 

FileShare.ReadWrite

有了以上的經驗，從字面上理解，能夠認爲這個ReadWrite必定是結合了Read和Write的特性。那到底它有什麼用呢？上面咱們知道，在讀文件設置Read共享能繼續讀而不能寫，在寫文件時設置Write共享則能繼續寫而不能讀，可是當咱們設置了寫共享後並想讀取文件時怎麼辦？只能先釋放資源再從新加載了嗎？不須要，ReadWrite就是爲此而生的。

 

WriteFile(FileMode.Create, FileAccess.Write, FileShare.Read);
ReadFile(FileAccess.Read, FileShare.ReadWrite);

 

不過這裏寫文件的時候並不容許把共享設置成Write，不然讀文件時用ReadWrite則無效（報異常），但都設置爲ReadWrite能夠。這必定，即可以解決不少平常開發中的煩惱。

FileShare.None/FileShare.Delete

有了上面的經驗，相信這兩個你也很容易的就理解了，None則爲不容許後續有任何操做，而Delete則是容許你隨後進行刪除操做。

原文連接FileShare枚舉的使用(文件讀寫鎖)