当前位置:首页 > 算法工程 2017年06月18日
多线程和异步编程示例和实践

本文中,分享两则我们在做多线程和异步编程中实际踩过的坑,实际生产环境遇到的问题,以及解决办法。

1. HttpClient

业务场景:使用HttpClient实现第三方业务推送,当第三方的Http服务器不通、或者返回很慢时

  • 线程数暴涨

  • Asp.Net\Asp.Net MVC场景下,并发多线程导致的线程阻塞:HttpClient.PostAysnc/GetAsync.Result

第一种线程数暴涨的问题,很容易理解,线程执行的慢,线程创建的速度快,一直在执行,导致线程不断创建线程、线程数不断暴涨。

根本原因是HttpClient的超时时间配置的太长,这点存于业务设计的问题,理论上简单请求3s没响应就该超时了,复杂长时间请求使用异步任务(我们的消息应用中心)处理。

第二种,Asp.Net或者Asp.Net MVC场景下,使用HttpClient,同时GetAsync.Result,异步变同步,这就会出现请求Hang住,线程死锁、请求没响应。

根本原因Http异步请求的上下文的互相等待导致的。详细分析可以参考下面的link:

有什么好的解决方案吗

  • HttpWebRequest代替HttpClient实现各类Http请求,这个类虽然是.net 2.0下的,但是功能的确很强大,应用一般的Http请求没啥问题!

  • 使用HttpWebRequest实现同步Get、Post请求,避免在Asp.Net场景下使用HttpClient.PostAsync/GetAsync.Result(异步变同步)带来的线程死锁,因为Asp.Net机制下Http异步请求的上下文的互相等待导致的。

  • 合理设置Http请求的超时时间,超时即返回,防止线程数暴涨

  • 对于第三方服务器的通信,建议在内存中维护一个联通性状态字典,每隔一段时间更新一次,如果不通,直接就不发起Http请求了,这个策略更像是设计上的优化,但是效果很好!

上两个示例代码:

多线程和异步编程示例和实践-踩过的坑

如果非用HttpClient不可,也是有招的:

多线程和异步编程示例和实践-踩过的坑

很简单,从WebApi,或者Controller这一层全部异步化。前后全部异步。同时,

设置:ConfigureAwait(false)

2. Winform、Console或者Windows服务下,前台线程异常导致的进程退出

这个问题是很头疼的,主要是在提供的服务容器运行的插件代码中,使用了Thread,默认是前台线程,未正确处理异常,线程异常后,导致主进程退出!!!

业务场景:Windows 服务版本下的消息应用中心,个推使用New Thread推送消息,线程未处理异常,异常后导致Windows Service异常关闭!

结果很头大,就是整个消息应用中心进程退出了,所有消息处理业务全部受影响!

根本原因:通过New Thread方式创建的线程,系统默认都是前台线程(IsBack),前台线程异常如果未处理,会导致应用程序退出,即使注册了AppDomain.CurrentDomain.UnhandledException事件处理,应用程序依然会挂掉。

解决方案:在线程内部合理处理异常:记日志、返回值处理,但是不能throw

补充:这里引出了一个重要的知识点:前台线程和后台线程

两者的区别就是:

  • 应用程序必须运行完所有的前台线程才可以退出;

  • 对于后台线程,应用程序则可以不考虑其是否已经运行完毕而直接退出,所有的后台线程在应用程序退出时都会自动结束。

那么,Thread、线程池的线程、Task都各自属于哪一类线程?

使用Thread建立的线程默认情况下是前台线程,即线程属性IsBackground=false.

属于托管线程池的线程(即其 IsThreadPoolThread 属性为 true 的线程)是后台线程


#转载至test404.com


发表评论: