產品中（基于ASP.NET MVC開發）需要經常對藥品名稱及名稱拼音碼進行下拉匹配及結果查詢。為了加快查詢的速度，所以我最開始就將其加入內存中（大約有六萬五千條數據）。
下面附實體類。
public class drugInfo{ public int drug_nameid { get; set; } public string drug_name { get; set; } public string drug_search_code { get; set; }}第一次做法：
Stopwatch stopWatch = new Stopwatch();stopWatch.Start();key = key.ToLower();var resultList = cacheList.Where(m => m.drug_name.ToLower().Contains(key) || m.drug_search_code.ToLower().Contains(key)).ToList();stopWatch.Stop();double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds);
刷新頁面幾次，得到個平均用時約35MS左右。
第二次做法：
為了減少CPU的運算，我們將LINQ表達式中的轉小寫操作優化一下，先在緩存列表上做些動作，將名稱和搜索碼先轉小寫存儲。
下面為改進過的實體類。
public class drugInfo{ public int drug_nameid { get; set; } public string drug_name { get; set; } public string drug_search_code { get; set; } public string lower_drug_name { get; set; } public string lower_drug_search_code { get; set; }}Stopwatch stopWatch = new Stopwatch();stopWatch.Start();key = key.ToLower();var resultList = cacheList.Where(m => m.lower_drug_name.Contains(key) || m.lower_drug_search_code.Contains(key)).ToList();stopWatch.Stop();double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds);ViewBag.useTime = string.Format("用時{0}秒/r/n", eMseconds);刷新頁面幾次，得到個平均用時約16MS左右。
雖然這樣做，內存列表中會多一些冗余數據，但是得到的性能提升有一倍了。
第三次做法：
啟用PLINQ的并行計算，并行計算是NET4.0的特性，可以利用CPU多核的處理能力，提高運算效率，但是不一定是成倍的
LIST等泛型啟用并行計算很簡單，使用AsParallel()即可，改進如下：
Stopwatch stopWatch = new Stopwatch();stopWatch.Start();key = key.ToLower();var resultList = cacheList.AsParallel().Where(m => m.lower_drug_name.Contains(key) || m.lower_drug_search_code.Contains(key)).ToList();stopWatch.Stop();double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds);ViewBag.useTime = string.Format("用時{0}秒/r/n", eMseconds);同樣，我們多刷新頁面幾次，獲得的平均時間為10MS左右。
當然，寫到這里，大家以為這次的優化就結束了，至少我當時是這么想的。
---------------------------------------------------------------------------------------------------
但是事實上，碰到了一個大麻煩。
由于產品運行于服務器IIS上面，使用AsParallel并行特性時（默認情況下，到底使用多少個線程來執行PLINQ是在程序運行時由TPL決定的。但是，如果你需要限制執行PLINQ查詢的線程數目（通常需要這么做的原因是有多個用戶同時使用系統，為了服務器能同時服務盡可能多的用戶，必須限制單個用戶占用的系統資源），我們可以使用ParallelEnumerable. WithDegreeOfParallelism()擴展方法達到此目的。），客戶端一個請求就占用了過多的系統資源，導致應用程序池假死。無法提供服務。
我也嘗試過使用WithDegreeOfParallelism設置了一個相對較少的值，但是在使用LOADRUNNER來開啟200個并發的時候，也會產生假死的情況，于是，不得不嘗試下面第四步的辦法。
第四次做法：
Stopwatch stopWatch = new Stopwatch();stopWatch.Start();key = key.ToLower();ConcurrentBag<drugInfo> resultList = new ConcurrentBag<drugInfo>();Parallel.For(0, cacheList.Count, new ParallelOptions { MaxDegreeOfParallelism = 4 }, (i) =>{var item = cacheList[i];if (item.lower_drug_name.Contains(key) || item.lower_drug_search_code.Contains(key)){resultList.Add(item);}});stopWatch.Stop();double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds);ViewBag.useTime = string.Format("用時{0}秒/r/n", eMseconds);時間與第三步沒有什么區別，但是這樣做解決了并發時，應用程序池假死的問題。至此，困擾兩天的問題完美解決，雖然使用Parallel.For會帶來結果亂序的問題，但是結果數量已經不多了，再次排序也沒有什么關系了。
具體原因參見下面：
ParallelOptions.MaxDegreeOfParallelism指明一個并行循環最多可以使用多少個線程。TPL開始調度執行一個并行循環時，通常使用的是線程池中的線程，剛開始時,如果線程池中的線程很忙,那么,可以為并行循環提供數量少一些的線程（但此數目至少為1，否則并行任務無法執行，必須阻塞等待）。等到線程池中的線程完成了一些工作,則分配給此并行循環的線程數目就可以增加，從而提升整個任務完成的速度，但最多不會超過ParallelOptions.MaxDegreeOfParallelism所指定的數目。
PLINQ的WithDegreeOfParallelism()則不一樣，它必須明確地指出需要使用多少個線程來完成工作。當PLINQ查詢執行時，會馬上分配指定數目的線程執行查詢。
之所以PLINQ不允許動態改變線程的數目，是因為許多PLINQ查詢是“級聯”的，為保證得到正確的結果，必須同步參與的多個線程。如果線程數目不定，則要實現線程同步非常困難。
有關C# PLINQ 內存列表查詢優化歷程小編就給大家介紹這么多，希望對大家有所幫助！
新聞熱點
疑難解答
