前言:最近给客户开发一个伙食费计算系统,大概需要计算2000个人的伙食。需求是按照员工的预定报餐计划对消费记录进行检查,如有未报餐有刷卡或者有报餐没刷卡的要进行一定的金额扣减等一系列规则。一开始我的想法比较简单,直接用一个for循环搞定,统计结果倒是没问题,但是计算出来太慢了需要7,8分钟。这样系统服务是报超时错误的,让人觉得有点不太爽。由于时间也不多就就先提交给用户使用了,后面逻辑又增加了,计算时间变长,整个计算一遍居然要将近10分钟了。这个对用户来说是能接收的(原来自己手算需要好几天呢),但是我自己接受不了,于是就开始优化了,怎么优化呢,用多线程呗。
一提到多线程,最先想到的是Task了,毕竟.net4.0以上Task封装了很多好用的方法。但是Task毕竟是多开一些线程去执行任务,最后整合结果,这样可以快一些,但我想更加快速一些,于是想到了另外一个对象:Parallel。之前在维护代码是确实有遇到过别人写的Parallel.Invoke,只是指定这个函数的作用是并发执行多项任务,如果遇到多个耗时的操作,他们之间又不贡献变量这个方法不错。我的情况是要并发执行一个集合,于是就用了List.ForAll 这个方法其实是拓展方法,完整的调用为:List.AsParallel().ForAll,需要先转换成支持并发的集合,等同于Parallel.ForEach,目的是对集合里面的元素并发执行一系列操作。
于是乎,把原来的foreach换成了List.AsParallel().ForAll,运行起来,果然速度惊人,不到两分钟就插入结果了,但最后却是报主键重复的错误,这个错误的原因是,由于使用了并发,这个时候变量自增,其实是在强着自增,当多个线程同时获取到了id值,都去自增然后就重复了,举个例子如下:
这段代码是让一个变量执行2000次自增,正常结果应该是2001,但实际结果如下:
有经验的同学,立马能想到需要加锁了,C#内置了很多锁对象,如lock 互斥锁,Interlocked 内部锁,Monitor 这几个比较常见,lock内部实现其实就是使用了Monitor对象。对变量自增,Interlocked对象提供了,变量自增,自减、或者相加等方法,我们使用自增方法Interlocked.Increment,函数定义为:int Increment(ref int num),该对象提供原子性的变量自增操作,传入目标数值,返回或者ref num都是自增后的结果。在之前的基础上我们增加一些代码:
我们来看运行结果:
加了锁之后ID重复算是解决了,其实别高兴太早,由于正常的环境有了ID我们还有用这些ID来构建对象呢,于是又写了写代码,用集合来添加这些ID,为了更真实的模拟生产环境,我在forAll里面又加了一层循环代码如下:
上面的代码里面我用到了线程安全集合ConcurrentBag<T>它的命名空间是:using System.Collections.Concurrent,尽管使用了线程安全集合,但是在并发面前仍然是不安全的,到了这里其实比较郁闷了,自增加锁,安全集合内部应该也使用了锁,但还是重复了。有点说不过去了,想想多线程执行时有个上下文对象,即当多个线程同时执行任务,共享了变量他们一开始传进去的对象数值应该是相同的,由于变量自增时加了锁,所以ID是不会重复了。我猜测问题应该出在Add方法了,就是说当num值自增后还没有来得及传出去就已经执行了Add方法,故添加了重复变量。于是乎,我重新写了段代码,让ID自增和集合添加都放到锁里面:
这里我测试了另外一个线程安全的集合BlockingCollection,关于这个集合的使用请自行查找MSDN文档,上面的关键代码直接添加安全集合的返回值,可以保证集合不会重复,但其实下面的lock更适用与正式环境,因为我们添加的一般都是对象不会是基础类型数值,运行结果如下:
至此,我们的问题解决了,计算时间由原来的9分多降至110秒左右,可见Parallel的处理还是很给力的,唯一不足的是,很占CPU,执行计算后CPU达到了88%。附上计算结果:
优化前后对比
总结:C#安全集合在并发的情况下其实不一定是安全的,还是需要结合实际应用场景和验证结果为准。Parallel.ForEach在对循环数量可观的情况下是可以去使用的,如果有共享变量,一定要配合锁做同步处理。还是得慎用这个方法,如果方法内部有操作数据库的记得增加事务处理,否则就呵呵了。