多线程和异步编程示例和实践-踩过的坑
上两篇文章，主要介绍了Thread、ThreadPool和TPL
多线程异步编程示例和实践-Thread和ThreadPool
本文中，分享两则我们在做多线程和异步编程中实际踩过的坑，实际生产环境遇到的问题，以及解决办法。
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：
http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
有什么好的解决方案吗？
- 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 的线程）是后台线程
Task都是后台线程：Task需要在其运行过程中至少有一个前台线程在跑，否则会直接退出.
周国庆
2017/6/16
