C#運用讀寫鎖三行代碼復雜處理多線程並發的問題。本站提示廣大學習愛好者：（C#運用讀寫鎖三行代碼復雜處理多線程並發的問題）文章只能為提供參考，不一定能成為您想要的結果。以下是C#運用讀寫鎖三行代碼復雜處理多線程並發的問題正文
在開發順序的進程中，難免少不了寫入錯誤日志這個關鍵功用。完成這個功用，可以選擇運用第三方日志插件，也可以選擇運用數據庫，還可以自己寫個復雜的辦法把錯誤信息記載到日志文件。
選擇最後一種辦法完成的時分，若對文件操作與線程同步不熟習，問題就有能夠呈現了，由於同一個文件並不允許多個線程同時寫入，否則會提示“文件正在由另一進程運用，因而該進程無法訪問此文件”。
這是文件的並發寫入問題，就需求用到線程同步。而微軟也給線程同步提供了一些相關的類可以到達這樣的目的，本文運用到的 System.Threading.ReaderWriterLockSlim 便是其中之一。
該類用於管理資源訪問的鎖定形態，可完成多線程讀取或停止獨占式寫入訪問。應用這個類，我們就可以防止在同一時間段內多線程同時寫入一個文件而招致的並發寫入問題。
讀寫鎖是以 ReaderWriterLockSlim 對象作為鎖管理資源的，不同的 ReaderWriterLockSlim 對象中鎖定同一個文件也會被視為不同的鎖停止管理，這種差別能夠會再次招致文件的並發寫入問題，所以 ReaderWriterLockSlim 應盡量定義為只讀的靜態對象。
ReaderWriterLockSlim 有幾個關鍵的辦法，本文僅討論寫入鎖：
調用 EnterWriteLock 辦法 進入寫入形態，在調用線程進入鎖定形態之前不斷處於阻塞形態，因而能夠永遠都不前往。
調用 TryEnterWriteLock 辦法 進入寫入形態，可指定阻塞的距離時間，假如調用線程在此距離時期並未進入寫入形式，將前往false。
調用 ExitWriteLock 辦法 加入寫入形態，應運用 finally 塊執行 ExitWriteLock 辦法，從而確保調用方加入寫入形式。
Don't talk, show me the code.
1.多線程同時寫入文件
class Program
{
static int LogCount = 100;
static int WritedCount = 0;
static int FailedCount = 0;
static void Main(string[] args)
{
//迭代運轉寫入日志記載，由於多個線程同時寫入同一個文件將會招致錯誤
Parallel.For(0, LogCount, e =>
{
WriteLog();
});
Console.WriteLine(string.Format("\r\nLog Count:{0}.\t\tWrited Count:{1}.\tFailed Count:{2}.", LogCount.ToString(), WritedCount.ToString(), FailedCount.ToString()));
Console.Read();
}
static void WriteLog()
{
try
{
var logFilePath = "log.txt";
var now = DateTime.Now;
var logContent = string.Format("Tid: {0}{1} {2}.{3}\r\n", Thread.CurrentThread.ManagedThreadId.ToString().PadRight(4), now.ToLongDateString(), now.ToLongTimeString(), now.Millisecond.ToString());
File.AppendAllText(logFilePath, logContent);
WritedCount++;
}
catch (Exception ex)
{
FailedCount++;
Console.WriteLine(ex.Message);
}
}
}
運轉後果：
不運用讀寫鎖，只要局部日志成功寫入了日志文件。
2.多線程運用讀寫鎖同步寫入文件
class Program
{
static int LogCount = 100;
static int WritedCount = 0;
static int FailedCount = 0;
static void Main(string[] args)
{
//迭代運轉寫入日志記載
Parallel.For(0, LogCount, e =>
{
WriteLog();
});
Console.WriteLine(string.Format("\r\nLog Count:{0}.\t\tWrited Count:{1}.\tFailed Count:{2}.", LogCount.ToString(), WritedCount.ToString(), FailedCount.ToString()));
Console.Read();
}
//讀寫鎖，當資源處於寫入形式時，其他線程寫入需求等候本次寫入完畢之後才干持續寫入
static ReaderWriterLockSlim LogWriteLock = new ReaderWriterLockSlim();
static void WriteLog()
{
try
{
//設置讀寫鎖為寫入形式獨占資源，其他寫入懇求需求等候本次寫入完畢之後才干持續寫入
//留意：長時間持有讀線程鎖或寫線程鎖會使其他線程發作饑餓 (starve)。 為了失掉最好的功能，需求思索重新結構使用順序以將寫訪問的繼續時間增加到最小。
// 從功能方面思索，懇求進入寫入形式應該緊跟文件操作之前，在此處進入寫入形式僅是為了降低代碼復雜度
// 因進入與加入寫入形式應在同一個try finally語句塊內，所以在懇求進入寫入形式之前不能觸發異常，否則釋放次數大於懇求次數將會觸發異常
LogWriteLock.EnterWriteLock();
var logFilePath = "log.txt";
var now = DateTime.Now;
var logContent = string.Format("Tid: {0}{1} {2}.{3}\r\n", Thread.CurrentThread.ManagedThreadId.ToString().PadRight(4), now.ToLongDateString(), now.ToLongTimeString(), now.Millisecond.ToString());
File.AppendAllText(logFilePath, logContent);
WritedCount++;
}
catch (Exception)
{
FailedCount++;
}
finally
{
//加入寫入形式，釋放資源占用
//留意：一次懇求對應一次釋放
// 若釋放次數大於懇求次數將會觸發異常[寫入鎖定未經堅持即被釋放]
// 若懇求處置完成後未釋放將會觸發異常[此形式不下允許以遞歸方式獲取寫入鎖定]
LogWriteLock.ExitWriteLock();
}
}
}
運轉後果：
運用讀寫鎖，全部日志成功寫入了日志文件。
3.測試復雜多線程環境下運用讀寫鎖同步寫入文件
class Program
{
static int LogCount = 1000;
static int SumLogCount = 0;
static int WritedCount = 0;
static int FailedCount = 0;
static void Main(string[] args)
{
//往線程池裡添加一個義務，迭代寫入N個日志
SumLogCount += LogCount;
ThreadPool.QueueUserWorkItem((obj) =>
{
Parallel.For(0, LogCount, e =>
{
WriteLog();
});
});
//在新的線程裡，添加N個寫入日志的義務到線程池
SumLogCount += LogCount;
var thread1 = new Thread(() =>
{
Parallel.For(0, LogCount, e =>
{
ThreadPool.QueueUserWorkItem((subObj) =>
{
WriteLog();
});
});
});
thread1.IsBackground = false;
thread1.Start();
//添加N個寫入日志的義務到線程池
SumLogCount += LogCount;
Parallel.For(0, LogCount, e =>
{
ThreadPool.QueueUserWorkItem((obj) =>
{
WriteLog();
});
});
//在新的線程裡，迭代寫入N個日志
SumLogCount += LogCount;
var thread2 = new Thread(() =>
{
Parallel.For(0, LogCount, e =>
{
WriteLog();
});
});
thread2.IsBackground = false;
thread2.Start();
//在以後線程裡，迭代寫入N個日志
SumLogCount += LogCount;
Parallel.For(0, LogCount, e =>
{
WriteLog();
});
Console.WriteLine("Main Thread Processed.\r\n");
while (true)
{
Console.WriteLine(string.Format("Sum Log Count:{0}.\t\tWrited Count:{1}.\tFailed Count:{2}.", SumLogCount.ToString(), WritedCount.ToString(), FailedCount.ToString()));
Console.ReadLine();
}
}
//讀寫鎖，當資源處於寫入形式時，其他線程寫入需求等候本次寫入完畢之後才干持續寫入
static ReaderWriterLockSlim LogWriteLock = new ReaderWriterLockSlim();
static void WriteLog()
{
try
{
//設置讀寫鎖為寫入形式獨占資源，其他寫入懇求需求等候本次寫入完畢之後才干持續寫入
//留意：長時間持有讀線程鎖或寫線程鎖會使其他線程發作饑餓 (starve)。 為了失掉最好的功能，需求思索重新結構使用順序以將寫訪問的繼續時間增加到最小。
// 從功能方面思索，懇求進入寫入形式應該緊跟文件操作之前，在此處進入寫入形式僅是為了降低代碼復雜度
// 因進入與加入寫入形式應在同一個try finally語句塊內，所以在懇求進入寫入形式之前不能觸發異常，否則釋放次數大於懇求次數將會觸發異常
LogWriteLock.EnterWriteLock();
var logFilePath = "log.txt";
var now = DateTime.Now;
var logContent = string.Format("Tid: {0}{1} {2}.{3}\r\n", Thread.CurrentThread.ManagedThreadId.ToString().PadRight(4), now.ToLongDateString(), now.ToLongTimeString(), now.Millisecond.ToString());
File.AppendAllText(logFilePath, logContent);
WritedCount++;
}
catch (Exception)
{
FailedCount++;
}
finally
{
//加入寫入形式，釋放資源占用
//留意：一次懇求對應一次釋放
// 若釋放次數大於懇求次數將會觸發異常[寫入鎖定未經堅持即被釋放]
// 若懇求處置完成後未釋放將會觸發異常[此形式不下允許以遞歸方式獲取寫入鎖定]
LogWriteLock.ExitWriteLock();
}
}
}
運轉後果：
局部日志文件內容：
... Tid: 36 2016年12月11日 15:29:22.825 Tid: 29 2016年12月11日 15:29:22.830 Tid: 6 2016年12月11日 15:29:22.838 Tid: 26 2016年12月11日 15:29:22.845 Tid: 34 2016年12月11日 15:29:22.854 Tid: 24 2016年12月11日 15:29:22.863 Tid: 27 2016年12月11日 15:29:22.872 Tid: 14 2016年12月11日 15:29:22.877 Tid: 23 2016年12月11日 15:29:22.886 Tid: 20 2016年12月11日 15:29:22.892 Tid: 30 2016年12月11日 15:29:22.898 Tid: 9 2016年12月11日 15:29:22.904 Tid: 21 2016年12月11日 15:29:22.909 Tid: 22 2016年12月11日 15:29:22.915 Tid: 7 2016年12月11日 15:29:22.920 Tid: 3 2016年12月11日 15:29:22.925 Tid: 12 2016年12月11日 15:29:22.931 Tid: 5 2016年12月11日 15:29:22.937 Tid: 13 2016年12月11日 15:29:22.942 Tid: 11 2016年12月11日 15:29:22.947 Tid: 19 2016年12月11日 15:29:22.953 Tid: 37 2016年12月11日 15:29:22.958 Tid: 37 2016年12月11日 15:29:22.964 Tid: 40 2016年12月11日 15:29:22.970 Tid: 40 2016年12月11日 15:29:22.975 Tid: 40 2016年12月11日 15:29:22.980 Tid: 40 2016年12月11日 15:29:22.985 Tid: 40 2016年12月11日 15:29:22.991 Tid: 40 2016年12月11日 15:29:22.997 Tid: 31 2016年12月11日 15:29:23.3 Tid: 31 2016年12月11日 15:29:23.9 Tid: 31 2016年12月11日 15:29:23.14 Tid: 31 2016年12月11日 15:29:23.20 Tid: 31 2016年12月11日 15:29:23.27 Tid: 31 2016年12月11日 15:29:23.33 Tid: 31 2016年12月11日 15:29:23.38 Tid: 31 2016年12月11日 15:29:23.44 Tid: 31 2016年12月11日 15:29:23.49 Tid: 31 2016年12月11日 15:29:23.57 Tid: 31 2016年12月11日 15:29:23.63 Tid: 31 2016年12月11日 15:29:23.68 Tid: 31 2016年12月11日 15:29:23.74 Tid: 16 2016年12月11日 15:29:23.80 Tid: 16 2016年12月11日 15:29:23.86 Tid: 16 2016年12月11日 15:29:23.93 Tid: 16 2016年12月11日 15:29:23.99 Tid: 16 2016年12月11日 15:29:23.105 Tid: 16 2016年12月11日 15:29:23.110 Tid: 16 2016年12月11日 15:29:23.116 Tid: 38 2016年12月11日 15:29:23.122 Tid: 38 2016年12月11日 15:29:23.128 Tid: 28 2016年12月11日 15:29:23.134 Tid: 19 2016年12月11日 15:29:23.139 Tid: 25 2016年12月11日 15:29:23.146 Tid: 37 2016年12月11日 15:29:23.152 Tid: 39 2016年12月11日 15:29:23.158 Tid: 32 2016年12月11日 15:29:23.164 Tid: 33 2016年12月11日 15:29:23.170 Tid: 31 2016年12月11日 15:29:23.176 Tid: 35 2016年12月11日 15:29:23.182 Tid: 40 2016年12月11日 15:29:23.189 Tid: 15 2016年12月11日 15:29:23.194 Tid: 18 2016年12月11日 15:29:23.202 Tid: 17 2016年12月11日 15:29:23.208 Tid: 10 2016年12月11日 15:29:23.215 Tid: 16 2016年12月11日 15:29:23.221
復雜多線程環境下運用讀寫鎖，全部日志成功寫入了日志文件，由ThreadId和DateTime可以看出是由不同的線程同步寫入。
以上就是本文的全部內容，希望本文的內容對大家的學習或許任務能帶來一定的協助，同時也希望多多支持！
