微软的Task已经出来很久了，一直没有去研究，以为就是和Thread差不多的东西。直到最近看到了Task的使用介绍，发现比Thread的语法要精炼多了，于是便在项目中用上了。
结果就出问题了，数据库连接池用一段时间就满了，排除了各种原因，最后开始怀疑是不是Task有什么不为人知的隐患。
由于对Task的使用只是停留在开一个线程去执行一个不需要返回结果的任务这种阶段。为了查明是否是Task引起的线程池满，便开始各种查资料。
最终的结果是，连接池满是因为程序中的一个SqlConnection没有关闭，和Task没有半毛钱关系......
问题解决了。Task也研究的差不多了。
下面我们来谈一下Task的使用.....
开启一个Task
开启task有以下三种方式，曾经一度纠结在到底该用哪种方式来开始一个任务，最终发现其实在没有特殊要求的情况下，这三种方式除了语法不同外，执行方式和结果是一样的
Task<int> t1 = Task.Factory.StartNew(() => { Task.Delay(1000); return 1; });
Task<int> t2 = new Task<int>(() => { Task.Delay(1000); return 1; });
t2.Start();
Task<int> t3 = Task.Run(() => { Task.Delay(1000); return 1; });
上面的示例返回一个数字，所以接收者是Task的泛型，同样也可以执行一个不带返回结果的函数。
Task返回值
1.可以直接通过Task .Result属性来获取Task的结果
使用这种方式来获取结果，主线程会等待Task执行完成。也就是说，用这种方式来获取Task的返回结果，和不使用Task并没有什么区别。
但是需要注意的是，慎用.Result或者Wait来获取Task的返回值，除非你明确地知道Task的代码逻辑。我们来看下面一段代码
当点击button2时，应用程序会卡死。因为在调用.Result时，UI线程会阻塞，
而我们给GetResult的任务指出需要用UI线程来执行任务中的代码。
UI线程在等待GetResult完成，却又无法去运行GetResult中的代码。造成死锁
2.await 和 async
先上一个测试代码
static void Main(string[] args)
{
Console.WriteLine("程序启动");
Task<int> t = GetNum();
Console.WriteLine("主线程继续执行");
int num = t.Result;
Console.WriteLine("主线程获取到数字：" + num);
}
public static async Task<int> GetNum()
{
Console.WriteLine("GetNum函数进入");
int num = await Task.Run(() => { Task.Delay(1000); return 2; });
Console.WriteLine("GetNum函数获取到数字："+num);
return num;
}
await 运算符只能用于异步方法中，所以包含await运算符的方法都需要有async修饰符来修饰，称之为异步方法。
通过实验，我们看到在异步函数中，遇到await运算符之后，主线程就继续往下执行了，更确切的解释是，Main函数开始和GetNum函数并行执行，
直到获取t.Result时，若GetNum()函数仍未执行完毕，Main函数则需要等待GetNum返回。
在GetNum函数中，await后面的代码需要等待await的Task执行完成后方可执行，等同于下面不适用await的代码
static void Main(string[] args)
{
Console.WriteLine("程序启动");
Task<int> t = GetNumNoAwait();
Console.WriteLine("主线程继续执行");
int num = t.Result;
Console.WriteLine("主线程获取到数字：" + num);
Console.Read();
}
public static Task<int> GetNumNoAwait()
{
Console.WriteLine("GetNum函数进入");
Task<int> t = Task<int>.Run(() => { Task.Delay(1000); return 2; });
t.ContinueWith(m => { Console.WriteLine("GetNum函数获取到数字：" + m.Result); });
return t;
}
通过await来获取返回值的操作，比前一种方式的优点在于他不会阻塞主线程的。这一点在winform或wpf等gui程序上可以很明显地提现出来
Task在winform中的使用
这是一个winform程序的代码片段，页面中有两个按钮，我们用maketext函数来模拟一个需要耗时的比如调用api获取数据的操作。
当点击button1时程序会一直等待结果返回，期间窗体无法拖动
而用异步方法则不会阻塞主窗体的其他操作
AsyncController
看过很多在Action中使用异步action的文章，并以此和未使用异步的Action来进行网站吞吐量的对比。
大概的代码类似于下面这样
最终都会得出一个结论，以上代码的吞吐量要远远高于未使用异步的
当时我就很不解，await就是在等待异步代码执行完成，并不会释放请求占用的线程，为什么会提升网站的吞吐量呢？
经过各种实验，仍然无法来证明以上代码的写法会使得网站的吞吐量更高，反而大多数情况下，效率稍微低了一些
（刚刚看过一本书中有介绍，通常的方法调用比使用async关键字的同样方法调用要快上40-50倍。所以异步函数在合适的场景被正确地使用也是非常重要的）
最终看了Msdn上关于异步控制器的介绍，方才找到正确的写法
以下是截取MSdn上的代码片段
首先使用 AsyncManager.OutstandingOperations.Increment()函数来设定未完成的请求操作，默认是1，然后每一个异步操作完成,通过Decrement来使计数器减1，当计数器归零之后，则会调用xxxCompleted函数来返回结果。
这样解释就行的通了，当执行完NewsAsync中的代码之后，请求线程就会释放，直到异步函数执行完成，系统会重新获取一个线程通过NewsCompleted来返回给客户端执行结果。
下面是我的测试代码
public class TaskTestController : AsyncController
{
public void GetDataAsync()
{
AsyncManager.OutstandingOperations.Increment();
WebClient client = new WebClient();
client.DownloadDataCompleted += (sender, e) =>
{
AsyncManager.Parameters["bytelength"] = e.Result.Length;
AsyncManager.OutstandingOperations.Decrement();
};
client.DownloadDataAsync(new Uri("https://docs.microsoft.com/zh-cn/dotnet/framework/get-started/"));
}
public int GetDataCompleted(int bytelength)
{
return bytelength;
}
}
public class TaskTest1Controller : Controller
{
public int GetData()
{
WebClient client = new WebClient();
var rsu = client.DownloadData(new Uri("https://docs.microsoft.com/zh-cn/dotnet/framework/get-started/"));
return rsu.Length; ;
}
}
然后我进行模拟1000个并发2000条请求，下面是测试结果
这里就可以看到异步控制器的优势已经显露出来了
然后我将iis的最大并发设置为10，模拟了一个20并发200条请求的操作，
异步控制器用时3.001s,失败0条
普通控制器用时4.551s,失败8条
测试完成，希望对有需要的人有所帮助
原文地址：https://www.cnblogs.com/Alex80/p/10560258.html