.NET应用架构设计—服务端开发多线程使用小结（多线程使用常识）

有一段时间没有更新博客了，最近半年都在着写书《.NET框架设计—大型企业级框架设计艺术》，很高兴这本书将于今年的10月份由图灵出版社出版，有关本书的具体介绍等书要出版的时候我在另写一篇文行作介绍。能够先透露一下，本书是博主多年来对应用框架学习的总结，里面包含了十几个重量级框架模式，这些模式都是咱们目前所常用到的，对于学习框架和框架开发来讲是很好的参考资料，你们敬请期待。

好了，进入文章主题。

最近几个月本人一直从事着SOA服务开发工做，简单点讲就是提供服务接口的；从提供前端接口WEBAPI，到提供后端接口WCF\SOAFramework，期间学到了很多有关多线程使用上的经验，这些经验有的是本人本身的错误使用后的经验，有些是公司的前辈的指点，总之这些东西你不遇到过你是不会意识到该如何使用的，因此本人以为颇有必要总结分享给广大和我同样工做在一线的博友们。

咱们从服务的处理环节为顺序来介绍：

1.使用入口线程来处理超长时间调用：

任何服务的调用都须要首先进到服务的入口方法中，该方法一般扮演着领域逻辑的门面接口（将系统用例进行服务接口的划分），经过该接口进行用例的调用。当咱们须要处理长时间过程时都会面临着头疼的超时异常，若是咱们再去设计如何作超时补偿措施就会很复杂并且是没有必要的开销。长时处理的服务调用场景多半在同步数据中，经过某个JobWs（工做服务）按期的来同步数据（本人就是在这个过程当中学到的），当咱们没法预知咱们的服务会处理多长时间时，基本上都会首先去设置调用端的链接超时时间（是否是都会这么想？）；这很正常，很来超时时间就是用来给咱们用的；可是咱们忽视了咱们当前的业务场景了，若是你的服务不返回任何有关状态值的话“其实应该开启一个独立的线程来处理同步逻辑而让服务的调用者尽早收到相应”。

 1 public class ProductApplicationService
 2     {
 3         public void SyncProducts()
 4         {
 5             Task.Factory.StartNew(() =>
 6             {
 7                 var productColl = DominModel.Products.GetActivateProducts();
 8                 if (!productColl.Any()) return; 
 9 
10                 DominModel.Products.WriteProudcts(productColl);
11             });
12         }
13     } 

View Code

这样就能够尽早解放调用者；经过开启一的单独的线程来处理具体的同步逻辑。

若是你的服务须要返回某个状态值怎么办？其实咱们能够参考”异步消息架构模式“来将消息写入到某个消息队列中，而后客户端按期来取或者推送均可以，让当前的这个服务方法可以平滑的处理，至少为系统的总体性能瓶颈作了一份贡献。

1.1异常处理：

入口位置一般都会记录下调用的异常信息，也就是加上一个try{}catch{}，用来捕获本次调用的全部异常信息。（固然你可能会说代码中充斥着try{}catch{}不是很好，能够将其放到某个看不见的地方自动处理，这有好有坏，看不见的地方咱们就必然少不了配置，少不了对自定义异常类型的配置，总之事物都有两面性。）

 1 public class ProductApplicationService
 2 {
 3     public void SyncProducts()
 4     {
 5         try
 6         {
 7             Task.Factory.StartNew(() =>
 8             {
 9                 var productColl = DominModel.Products.GetActivateProducts();
10                 if (!productColl.Any()) return; 
11 
12                 DominModel.Products.WriteProudcts(productColl);
13             });
14         }
15         catch(Exception exception)
16         {
17             //记录下来...
18         }
19     }
20 } 

View Code

像这样，看上去好像没问题哦，可是咱们仔细看看就会发现，这个try{}catch{}根本捕获不到咱们任何异常信息的，由于这个方法是在咱们开启的线程外面的，也就是说它早就结束了，开启的线程处理栈中根本就没有任何的try{}catch{}机制代码了；因此咱们须要稍微调整一下同步代码来支持异常捕获。

 1 public class ProductApplicationService
 2 {
 3     public void SyncProducts()
 4     {
 5         Task.Factory.StartNew(SyncPrdoctsTask);
 6     } 
 7 
 8     private static void SyncPrdoctsTask()
 9     {
10         try
11         {
12             var productColl = DominModel.Products.GetActivateProducts();
13             if (!productColl.Any()) return; 
14 
15             DominModel.Products.WriteProudcts(productColl);
16         }
17         catch (Exception exception)
18         {
19             //记录下来...
20         }
21     }
22 } 

View Code

若是你装了像Resharp这样的辅助插件的话会对你重构代码颇有帮助，提取某一个方法会很方便快捷；

上述代码中，就在新开的线程中包含了异常捕获的代码；这样就不会致使你程序抛出不少未处理异常，在重要的逻辑点可能会丢失数据。不是说全部的异常都应该由框架来处理，咱们须要本身手动的控制某个逻辑点的异常，这样咱们能够保证咱们本身的逻辑可以继续运行下去。有些逻辑是不可能由于异常的出现而终止整个处理过程的。

2.利用并行来提升多组数据的读取

位于SOA服务的最外层服务接口时，一般都须要包装内部众多服务接口来组合出外部须要的数据，此时须要查询不少接口的数据，而后等待数据都到齐了以后再将其统一的返回给前端。因为我有一段时间是专门给前端H5提供接口的，最让我感触的就是服务接口须要整合全部的数据给前端，从用户的角度讲不但愿手机的界面还出现异步的现象吧，毕竟就那么大屏幕还有白的地方。可是这个需求给咱们开发人员带来了问题，若是用顺序读取方式将数据都组合好，那个时间是人所没法接受的，因此咱们须要开启并行来同时读取多个后端服务接口的数据（前提是你这些数据没有先后依赖关系）。

 1 public static ProductCollection GetProductByIds(List<long> pIds)
 2 {
 3     var result = new ProductCollection(); 
 4 
 5     Parallel.ForEach(pIds, id =>
 6     {
 7         //并行方法
 8     }); 
 9 
10     return result;
11 } 

View Code

一切看起来很舒服，多个ID同一个时间被一块儿运行，可是这里面有个坑。

2.1控制并行线程数：

若是咱们用上述代码开启并行后，从GetProductByIds业务点来看一切会很顺利，并且效果很明显速度很快；可是若是当前GetProductByIds方法还在处理过程当中时你再发起另外一个服务调用时你就会发现服务器响应变慢了，由于全部的请求线程所有被占用了，这里Parallel并无咱们想的那么智能，能根据状况控制线程数；咱们须要本身控制咱们并行时的最大线程数，这样能够防止因为多线程被一个业务点占用而致使服务队列其余的后续请求（此时看CPU不必定很高，若是CPU太高致使不接受请求能理解，可是因为系统设置的问题让线程数不够用也是有可能的）

 1 public static ProductCollection GetProductByIds(List<long> pIds)
 2 {
 3     var result = new ProductCollection(); 
 4 
 5     Parallel.ForEach(pIds, new ParallelOptions() { MaxDegreeOfParallelism = 5 /*设置最大线程数*/}, id =>
 6     {
 7         //并行方法
 8     }); 
 9 
10     return result;
11 } 

View Code

2.2使用并行处理时数据的先后顺序是第一原则

这点上我犯了两次错，第一次是将前端须要的数据顺序打乱了，致使数据的排名出来问题；第二次是将写入数据库的同步数据的时间打乱了，致使程序没法再继续上次的结束时间继续同步。因此请你们必定要记住，当你使用并行时，首先问本身你当前的数据上下文逻辑在不在意先后顺序关系，一旦开启并行后全部的数据都是无须的。

3.手动开启一个线程来代替并行库启动的线程

如今咱们提供的服务接口多多少少会用到异步async，大概就是想让咱们的系统可以提到点并发量，让宝贵的请求处理线程可以及时的被系统再利用而不是在等待上浪费。

大概代码会是这样的，服务入口：

1 public async Task<int> OperationProduct(long ids)
2 {
3     return await DominModel.Products.OperationProduct(ids);
4 } 

View Code

业务逻辑：

 1 public static async Task<int> OperationProduct(long ids)
 2 {
 3     return await Task.Factory.StartNew<int>(() =>
 4       {
 5           System.Threading.Thread.Sleep(5000);
 6           return 100; 
 7 
 8           //其实这里开启的线程是请求线程池中的请求处理线程，说白了这样并不会提升并发等于没用。
 9       });
10 } 

View Code

其实当咱们最后开启了一个新线程时，这个新的线程和你awit的线程是同一种类型，这样并不会提升并发反而会因为频繁的切换线程影响性能。要想真的让你的async有实际意义，使用手动开启新线程来提升并发。（前提是你了解了当前系统的总体CPU和线程的比例，也就是说你开启一个两个手动线程是不会有问题的，可是你要放在并发的入口上就请慎重考虑）

在Task中开启手动线程有一点麻烦，看代码：

 1 public async Task<int> OperationProduct(long id)
 2 {
 3     var funResult = new AWaitTaskResultValues<int>();
 4     return await DominModel.Products.OperationProduct(id, funResult);
 5 } 
 6 
 7 public static Task<int> OperationProduct(long id, AWaitTaskResultValues<int> result)
 8         {
 9             var taskMock = new Task<int>(() => { return 0; });//只是一个await模拟对象，主要是让系统回收当前“请求处理线程” 
10 
11             var thread = new Thread((threadIds) =>
12             {
13                 Thread.Sleep(7000); 
14 
15                 result.ResultValue = 100; 
16 
17                 taskMock.Start();//因为没有任何的逻辑，因此处理会很快完成。
18             }); 
19 
20             thread.Start(); 
21 
22             return taskMock;
23         } 

View Code

之因此这么麻烦是为了让系统释放await线程而不是阻塞该线程。我经过简单的测试可使用少许的线程来处理更多的并发请求。

 

做者：王清培

出处：http://www.cnblogs.com/wangiqngpei557/

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面