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

開發過程中，我們往往需要大量與文件交互，但往往會出現很多令人措手不及的意外，所以對普通的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();
}

調用上面的方法，將輸入內容寫入指定的文件當中，用記事本打開log.txt可看到剛才輸入的內容。

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

相信這個枚舉類型大家會比較陌生，甚至有同學見都沒見過（慚愧的是，我也是才認識它沒多久），陌生歸陌生，但它的作用卻是不可低估，只是微軟幫我們把它封裝得比較好，以至於我們一度認為它不是什么重要角色。好吧，進入主題！

包含用於控制其他 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則是允許隨后進行刪除操作。

黑箱子里的內容

對於文件操作，我們平常使用的比較多的可能是以下幾種：

File.AppendAllText("......");
File.AppendAllLines(...);
File.AppendText(...);
FileStream fs = new FileStream(path, FileAccess.Write);
fs.Write(....);

實際上它們也是在內部初始化了FileMode/FileAccess/FileShare，例如File的靜態方法最后都會生成一個Stream實例，其中便調用了私有方法CreateFile

尾聲

現在，我們明白了，其實FileShare就是控制文件流的“訪問權限”，當然，這僅僅是入門的文件操作，自己做了筆記，也希望能給大家帶來幫助，高級篇園子里已經有不少前輩寫了文件讀寫鎖方面的文章，感興趣的同學可有搜索一下，前去觀摩！

 

轉自：空逸雲
出處：http://kongyiyun.cnblogs.com