当前位置: 移动技术网 > IT编程>开发语言>c# > 在Parallel中使用DbSet.Add()发现的一系列多线程问题和解决思路详解

在Parallel中使用DbSet.Add()发现的一系列多线程问题和解决思路详解

2019年07月18日  | 移动技术网IT编程  | 我要评论

发现问题

需求很简单,大致就是要批量往数据库写数据,于是打算用parallel并行的方式写入,希望能利用计算机多核特性加快程序执行速度。想的很美好,于是快速撸了类似下面的一串代码:

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();
}

可意外的是竟然无情的报错了:

奇葩的是当我再次刷新的时候异常又不一样了,于是连着刷新好多次,总结出现过的异常有下面这些:

1、 未将对象引用设置到对象的实例。

2、 已添加了具有相同键的项。

3、 集合已修改;可能无法执行枚举操作。

4、 一个 edmtype 不能多次映射到 clr 类。edmtype“smsmodel.membercard”映射了一次以上。

其中1和2是出现最多的,而且所有异常都是出现在add的时候,各种吃瓜表情~没办法,接着一一断点调试,还是没找出原因,出于进度考虑,换成了另一种方案,也就是用dbset的addrange方法。先在parallel中累加出一个实体list,然后一次性添加到dbset中,代码演变为:

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();
}
}

然后编译、测试,没问题,就先放着了。

分析问题

第二天到公司心里还在纠结这个问题,于是打开页面输入生成的数据量1000(真实项目中的循环次数是手动输入的),点按钮提交,嗯,又吃瓜般的异常了…:

心想昨天测试都好好的啊(其实昨天输入的是10,心虚脸...),没办法,上断点吧,一看吓一跳:

明明循环1000次,结果只有971条数据,而且里面还有为null的,经过多次调试发现这是一个随机现象,count是随机的null也是随机的,有时出现有时没有,初步判断这是一个在多线程情况下引发的一个资源调配异常。so,上msdn看了一下list的介绍,最后面“线程安全”写着:

一切貌似都清楚了,于是打算验证一下结果,加上了锁,测试结果为:

list里面也没有再出现null了,确认是因为多线程安全引起的异常。于是想起昨天那个问题是否也是同样的问题,再上msdn搜了一下dbcontext类和dbset类,都是这样说的:

接着就给dbcontext上了锁,测试,这次总算如我所料,完美运行。但是不解的是最初那几个异常是如何产生的,list中虽然数量不够也存在为null的对象,但是并没有直接爆出异常。现在只知道是线程问题,再详细的也搞不清楚,有知道的大神还麻烦指点一下。

寻找解决方案并验证结论

也想过用partitioner分区来做,但是仔细一想,虽然分区内部是单线程,但是区与区之间还是多线程的,如果分的太细也就失去了parallel的意义,只得另寻出路。还好framework为我们也提供了一些线程安全的泛型集合(比如concurrentbag、concurrentqueue等),不过其本质还是用了锁,于是就综合做了一下单线程list、多线程list加锁、多线程concurrentbag、多线程concurrentqueue的性能对比,结果如下:

循环1000次时:

循环10000次时:

循环100000次时:

得出结论就是,在执行次数超大时用线程安全类型会更慢,在执行次数较少时线程安全类型也没什么优势。

解决问题

最后在经过仔细测试验证和考虑项目实际需求(几乎不可能一次10000)后,去繁从简,回归原始,用最简单直白的写法单线程循环来完成。虽然一番折腾下来还是回到最初,但是这过程中让我发现了意料之外问题,然后找到了原因,然后测试验证,最终得到了最优解决方案。还是那句话,填完坑,你就比之前更强大了!

如对本文有疑问, 点击进行留言回复!!

相关文章:

验证码:
移动技术网