掃碼支付接口將要上線，近幾天在優化系統性能。昨天把日志Helper類的日志記錄改成了使用Queue<T>對象來實現異步處理。
做了單元測試，并模擬多線程來測試，是快了不少。
今天將站點部署到準生產環境，用loadrunner壓測時，發現運行一段時間后報如下異常，并且導致iis進程掛掉：
2017/2/16 11:50:08 [ClientPayAPI_115007438_1CD2C]酷寶獲取二維碼異常：System.ArgumentException: 目標數組的長度不夠。請檢查 destIndex 和長度以及數組的下限。
在 System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
在 System.Collections.Generic.Queue`1.SetCapacity(Int32 capacity)
在 System.Collections.Generic.Queue`1.Enqueue(T item)
在 CommonUtils.LogHelper.InputFile(String log, LogType logType)
在 CommonUtils.LogHelper.Write(String logText)
在 PaymentBLL.HttpMessageSignService.ValidPayRequestSign_New(String requestJson)
在 PaymentPlatform.Kubao.QuickPay.ClientPayAPI.ExecFun_New(String request)
在 PaymentPlatform.Kubao.QuickPay.ClientPayAPI.ProcessRequest(HttpContext context)
本地再次模擬高并發測試，發現復現的幾率很小。不過，無論如何，既然好在可以復現，就要解決。
經查，Queue<T>以及List<T>不是線程安全的。在并發操作時，內部操作可能會出現問題。通過ILSpy（.Net 反編譯軟件，可以打開.NET 的exe和DLL等程序集，前提要求程序集未加密/未加殼/未做強度混淆），或者去微軟官方（referencesource.microsoft.com，.net 已經開源了）可以查看Enqueue方法的實現，可知并未控制并發。
#region 程序集 mscorlib.dll, v4.0.0.0
// C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
#endregion
// Adds item to the tail of the queue.
//
/// <include file='doc\Queue.uex' path='docs/doc[@for="Queue.Enqueue"]/*' />
public void Enqueue(T item) {
if (_size == _array.Length) {
int newcapacity = (int)((long)_array.Length * (long)_GrowFactor / 100);
if (newcapacity < _array.Length + _MinimumGrow) {
newcapacity = _array.Length + _MinimumGrow;
}
SetCapacity(newcapacity);
}
_array[_tail] = item;
_tail = (_tail + 1) % _array.Length;
_size++;
_version++;
}
對此問題，解決方案有2個：
【方案一】入隊時使用并發鎖lock。
【方案二】使用ConcurrentQueue<T>。ConcurrentQueue<T>表示線程安全的先進先出 (FIFO) 集合。這個類在.net類庫的System.Collections.Concurrent下。System.Collections.Concurrent命名空間提供多個線程安全集合類。當有多個線程并發訪問集合時，應使用這些類來代替System.Collections和System.Collections.Generic命名空間中的對應類型。
