發(fā)現(xiàn)問(wèn)題

需求很簡(jiǎn)單，大致就是要批量往數(shù)據(jù)庫(kù)寫(xiě)數(shù)據(jù)，于是打算用Parallel并行的方式寫(xiě)入，希望能利用計(jì)算機(jī)多核特性加快程序執(zhí)行速度。想的很美好，于是快速擼了類(lèi)似下面的一串代碼：

using (var db = new SmsEntities())
{
Parallel.For(0, 1000, (i) =>
{
db.MemberCard.Add(new MemberCard()
{
CardNo = "NO_" + i.ToString(),
Banlance = 0,
CreateTime = DateTime.Now,
Name = "Test_" + i.ToString(),
Status = 1
});
});
db.SaveChanges();
}

可意外的是竟然無(wú)情的報(bào)錯(cuò)了:

奇葩的是當(dāng)我再次刷新的時(shí)候異常又不一樣了，于是連著刷新好多次，總結(jié)出現(xiàn)過(guò)的異常有下面這些：

1、 未將對(duì)象引用設(shè)置到對(duì)象的實(shí)例。

2、 已添加了具有相同鍵的項(xiàng)。

3、 集合已修改；可能無(wú)法執(zhí)行枚舉操作。

4、 一個(gè) EdmType 不能多次映射到 CLR 類(lèi)。EdmType“SmsModel.MemberCard”映射了一次以上。

其中1和2是出現(xiàn)最多的，而且所有異常都是出現(xiàn)在Add的時(shí)候，各種吃瓜表情~沒(méi)辦法，接著一一斷點(diǎn)調(diào)試，還是沒(méi)找出原因，出于進(jìn)度考慮，換成了另一種方案，也就是用DbSet的AddRange方法。先在Parallel中累加出一個(gè)實(shí)體List，然后一次性添加到DbSet中，代碼演變?yōu)?

List<MemberCard> list = new List<MemberCard>();
using (var db = new SmsEntities())
{
var result = Parallel.For(0, 1000, (i) =>
{
list.Add(new MemberCard()
{
CardNo = "NO_" + i.ToString(),
Banlance = 0,
CreateTime = DateTime.Now,
Name = "Test_" + i.ToString(),
Status = 1
});
});
if (result.IsCompleted)
{
db.MemberCard.AddRange(list);
db.SaveChanges();
}
}

然后編譯、測(cè)試，沒(méi)問(wèn)題，就先放著了。

分析問(wèn)題

第二天到公司心里還在糾結(jié)這個(gè)問(wèn)題，于是打開(kāi)頁(yè)面輸入生成的數(shù)據(jù)量1000（真實(shí)項(xiàng)目中的循環(huán)次數(shù)是手動(dòng)輸入的），點(diǎn)按鈕提交，嗯，又吃瓜般的異常了…：

心想昨天測(cè)試都好好的?。ㄆ鋵?shí)昨天輸入的是10，心虛臉...），沒(méi)辦法，上斷點(diǎn)吧，一看嚇一跳：

明明循環(huán)1000次，結(jié)果只有971條數(shù)據(jù)，而且里面還有為null的，經(jīng)過(guò)多次調(diào)試發(fā)現(xiàn)這是一個(gè)隨機(jī)現(xiàn)象，Count是隨機(jī)的null也是隨機(jī)的，有時(shí)出現(xiàn)有時(shí)沒(méi)有，初步判斷這是一個(gè)在多線程情況下引發(fā)的一個(gè)資源調(diào)配異常。So，上MSDN看了一下List的介紹，最后面“線程安全”寫(xiě)著：

一切貌似都清楚了，于是打算驗(yàn)證一下結(jié)果，加上了鎖，測(cè)試結(jié)果為：

list里面也沒(méi)有再出現(xiàn)null了，確認(rèn)是因?yàn)槎嗑€程安全引起的異常。于是想起昨天那個(gè)問(wèn)題是否也是同樣的問(wèn)題，再上MSDN搜了一下DbContext類(lèi)和DbSet類(lèi)，都是這樣說(shuō)的：

接著就給dbcontext上了鎖，測(cè)試，這次總算如我所料，完美運(yùn)行。但是不解的是最初那幾個(gè)異常是如何產(chǎn)生的，List中雖然數(shù)量不夠也存在為null的對(duì)象，但是并沒(méi)有直接爆出異?！，F(xiàn)在只知道是線程問(wèn)題，再詳細(xì)的也搞不清楚，有知道的大神還麻煩指點(diǎn)一下。

尋找解決方案并驗(yàn)證結(jié)論

也想過(guò)用Partitioner分區(qū)來(lái)做，但是仔細(xì)一想，雖然分區(qū)內(nèi)部是單線程，但是區(qū)與區(qū)之間還是多線程的，如果分的太細(xì)也就失去了Parallel的意義，只得另尋出路。還好Framework為我們也提供了一些線程安全的泛型集合（比如ConcurrentBag、ConcurrentQueue等），不過(guò)其本質(zhì)還是用了鎖，于是就綜合做了一下單線程list、多線程list加鎖、多線程ConcurrentBag、多線程ConcurrentQueue的性能對(duì)比，結(jié)果如下：

循環(huán)1000次時(shí)：

循環(huán)10000次時(shí)：

循環(huán)100000次時(shí)：

得出結(jié)論就是，在執(zhí)行次數(shù)超大時(shí)用線程安全類(lèi)型會(huì)更慢，在執(zhí)行次數(shù)較少時(shí)線程安全類(lèi)型也沒(méi)什么優(yōu)勢(shì)。

解決問(wèn)題

最后在經(jīng)過(guò)仔細(xì)測(cè)試驗(yàn)證和考慮項(xiàng)目實(shí)際需求（幾乎不可能一次10000）后，去繁從簡(jiǎn)，回歸原始，用最簡(jiǎn)單直白的寫(xiě)法單線程循環(huán)來(lái)完成。雖然一番折騰下來(lái)還是回到最初，但是這過(guò)程中讓我發(fā)現(xiàn)了意料之外問(wèn)題，然后找到了原因，然后測(cè)試驗(yàn)證，最終得到了最優(yōu)解決方案。還是那句話，填完坑，你就比之前更強(qiáng)大了！

最新評(píng)論