异步编程的概念
多核心CPU超线程CPU
1. 多核心处理器（CPU）指在一块处理器（CPU）中含有多个处理单元，每一个处理单元它就相当于一个单核处理器（CPU）。因此，多核处理器的功能就相当于多台单核处理器电脑联机作战。
2.超线程处理器（CPU）指在一块CPU中，用虚拟的方法将一个物理核心模拟成多个核心（一般情况是一个单物理核心，模拟成二个核心，也即所谓的二线程。只有当线程数比物理核心数多才能叫超线程。如四核四线程并不是超线程，而四核八线程才能叫超线程）。
3.优缺点：
1)多核心是真正的物理核心，一块多核心的处理器（CPU），就相当于多块单核心的处理器（CPU）相互协作。因此，从理论上说，多核心比超线程具有更高运算能力。虽然多核心比超线程的运算速度快很多，但多核心也有一个明显的缺点，那就是多核心的使用效率比超线程处理器（CPU）低。因为，多核心在处理数据时，它们相互“合作”的并不是很完美，常常某个核心需要等待其他核心的计算数据，从而耽误时间，被迫怠工。另外，由于目前多核心都是采用共享三级缓存，这更使多核心的CPU运算速度减慢不少。
2)超线程是用虚拟的方法将一个物理核心虚拟成多个核心，它能够最大限度地利用现有的核心资源，具有较高性价比。
操作系统对多核处理器的优化
主要体现在调度和中断上：
1.对任务的分配进行优化。使同一应用程序的任务尽量在同一个核上执行。
2.对任务的共享数据优化。由于多核处理器（Chip Multi-Processor，CMP）体系结构共享二级缓存（目前），可以考虑改变任务在内存中的数据分布，使任务在执行时尽量增加二级缓存的命中率。
3.对任务的负载均衡优化。当任务在调度时，出现了负载不均衡，考虑将较忙处理器中与其他任务最不相关的任务迁移，以达到数据的冲突最小。
进程和线程
1. 进程 进程是应用程序的执行实例，每个进程是由私有的虚拟地址空间、代码、数据和其它各种系统资源组成，进程在运行过程中创建的资源随着进程的终止而被销毁，所使用的系统资源在进程终止时被释放或关闭。
2. 线程 线程是进程内部的一个执行单元。系统创建好进程后，实际上就启动执行了该进程的主执行线程。主执行线程终止了，进程也就随之终止。
每个线程都维护异常处理程序、调度优先级和线程上下文。（线程上下文，当前执行的线程在其时间片结束时被挂起，而另一个线程继续运行。当系统从一个线程切换到另一个线程时，它将保存被抢先的线程的线程上下文，并重新加载线程队列中下一个线程的已保存线程上下文）
3. 关系 操作系统使用进程将它们正在执行的不同应用程序分开，.NET Framework 将操作系统进程进一步细分为System.AppDomain （应用程序域）的轻量托管子进程。
线程是CPU的调度单元，是进程中的执行单位，一个进程中可以有多个线程同时执行代码。
比如，你现在要有一批数据要大数据要入库，你又不想一边入库一边等待返回结果，你可以用异步，将大数据推入一个队列，然后另外一个线程来操作这个队列里面的数据入库，入完了，就通知一下主线程。这段时间你的主线程可以做任何事。
当我们处理一些长线的调用时，经常会导致界面停止响应或者IIS线程占用过多等问题，这个时候我们需要更多的是用异步编程来修正这些问题，但是通常都是说起来容易做起来难，诚然异步编程相对于同步编程来说，它是一种完全不同的编程思想，对于习惯了同步编程的开发者来说，在开发过程中难度更大，可控性不强是它的特点。
在.NET Framework5.0种，微软为我们系统了新的语言特性，让我们使用异步编程就像使用同步编程一样相近和简单，本文中将会解释以前版本的Framework中基于回调道德异步编程模型的一些限制以及新型的API如果让我们简单的做到同样的开发任务。
为什么要异步
一直以来，使用远程资源的编程都是一个容易造成困惑的问题，不同于“本地资源”，远程资源的访问总会有很多意外的情况，网络环境的不稳定机器服务端的故障，会造成很多程序员完全不可控的问题，所以这也就要求程序员需要更多的去保护远程资源的调用，管理调用的取消、超市、线程的等待以及处理线程长时间没响应的情况等。而在.NET中我们通常忽略了这些挑战，事实上我们会有多种不用的模式来处理异步编程，比如在处理IO密集型操作或者高延迟的操作时候不组测线程，多数情况我们拥有同步和异步两个方法来做这件事。可是问题在于当前的这些模式非常容易引起混乱和代码错误，或者开发人员会放弃然后使用阻塞的方式去开发。
而在如今的.NET中，提供了非常接近于同步编程的编程体验，不需要开发人员再去处理只会在异步编程中出现的很多情况，异步调用将会是清晰的且不透明的，而且易于和同步的代码进行组合使用。
过去糟糕的体验
最好的理解这种问题的方式是我们最常见的一种情况：用户界面只拥有一个线程所有的工作都运行在这个线程上，客户端程序不能对用户的鼠标时间做出反应，这很可能是因为应用程序正在被一个耗时的操作所阻塞，这可能是因为线程在等待一个网络ID或者在做一个CPU密集型的计算，此时用户界面不能获得运行时间，程序一直处于繁忙的状态，这是一个非常差的用户体验。
很多年来，解决这种问题的方法都是做异步花的调用，不要等待响应，尽快的返回请求，让其他事件可以同时执行，只是当请求有了最终反馈的时候通知应用程序让客户代码可以执行指定的代码。
而问题在于：异步代码完全毁掉了代码流程，回调代理解释了之后如何工作，但是怎么在一个while循环里等待？一个if语句？一个try块或者一个using块？怎么去解释“接下来做什么”？
看下面的一个例子：
public int SumPageSizes(IList<Uri> uris)
{
int total = 0;
foreach (var uri in uris)
{
txtStatus.Text = string.Format("Found {0} bytes...", total);
var data = new WebClient().DownloadData(uri);
total += data.Length;
}
txtStatus.Text = string.Format("Found {0} bytes total", total);
return total;
}
这个方法从一个uri列表里下载文件，统计他们的大小并且同时更新状态信息，很明显这个方法不属于UI线程因为它需要花费非常长的时间来完成，这样它会完全的挂起UI，但是我们又希望UI能被持续的更新，怎么做呢？
我们可以创建一个后台编程，让它持续的给UI线程发送数据来让UI来更新自身，这个看起来是很浪费的，因为这个线程把大多时间花在等下和下载上，但是有的时候，这正是我们需要做的。在这个例子中，WebClient提供了一个异步版本的DownloadData方法—DownloadDataAsync，它会立即返回，然后在DownloadDataCompleted后触发一个事件，这允许用户写一个异步版本的方法分割所要做的事，调用立即返回并完成接下来的UI线程上的调用，从而不再阻塞UI线程。下面是第一次尝试：
public void SumpageSizesAsync(IList<Uri> uris)
{
SumPageSizesAsyncHelper(uris.GetEnumerator(), 0);
}
public void SumPageSizesAsyncHelper(IEnumerator<Uri> enumerator, int total)
{
if (enumerator.MoveNext())
{
txtStatus.Text = string.Format("Found {0} bytes...", total);
var client = new WebClient();
client.DownloadDataCompleted += (sender,e)=>{
SumPageSizesAsyncHelper(enumerator, total + e.Result.Length);
};
client.DownloadDataAsync(enumerator.Current);
}
else
{
txtStatus.Text = string.Format("Found {0} bytes total", total);
}
}
然后这依然是糟糕的，我们破坏了一个整洁的foreach循环并且手动获得了一个enumerator，每一个调用都创建了一个事件回调。代码用递归取代了循环，这种代码你应该都不敢直视了吧。不要着急，还没有完 。
原始的代码返回了一个总数并且显示它，新的一步版本在统计还没有完成之前返回给调用者。我们怎么样才可以得到一个结果返回给调用者，答案是：调用者必须支持一个回掉，我们可以在统计完成之后调用它。
然而异常怎么办？原始的代码并没有关注异常，它会一直传递给调用者，在异步版本中，我们必须扩展回掉来让异常来传播，在异常发生时，我们不得不明确的让它传播。
最终，这些需要将会进一步让代码混乱：
public void SumpageSizesAsync(IList<Uri> uris,Action<int,Exception> callback)
{
SumPageSizesAsyncHelper(uris.GetEnumerator(), 0, callback);
}
public void SumPageSizesAsyncHelper(IEnumerator<Uri> enumerator, int total,Action<int,Exception> callback)
{
try
{
if (enumerator.MoveNext())
{
txtStatus.Text = string.Format("Found {0} bytes...", total);
var client = new WebClient();
client.DownloadDataCompleted += (sender, e) =>
{
SumPageSizesAsyncHelper(enumerator, total + e.Result.Length,callback);
};
client.DownloadDataAsync(enumerator.Current);
}
else
{
txtStatus.Text = string.Format("Found {0} bytes total", total);
enumerator.Dispose();
callback(total, null);
}
}
catch (Exception ex)
{
enumerator.Dispose();
callback(0, ex);
}
}
当你再看这些代码的时候，你还能立马清楚的说出这是什么JB玩意吗？
恐怕不能，我们开始只是想和同步方法那样只是用一个异步的调用来替换阻塞的调用，让它包装在一个foreach循环中，想想一下试图去组合更多的异步调用或者有更复杂的控制结构，这不是一个SubPageSizesAsync的规模能解决的。
我们的真正问题在于我们不再可以解释这些方法里的逻辑，我们的代码已经完全无章可循。异步代码中很多的工作让整件事情看起来难以阅读并且似乎充满了BUG。
一个新的方式
如今，我们拥有了一个新的功能来解决上述的问题，异步版本的代码将会如下文所示：
public async Task<int> SumPageSizesAsync(IList<Uri> uris)
{
int total = 0;
foreach (var uri in uris)
{
txtStatus.Text = string.Format("Found {0} bytes...", total);
var data = await new WebClient().DownloadDataTaskAsync(uri);
total += data.Length;
}
txtStatus.Text = string.Format("Found {0} bytes total", total);
return total;
}
除了添加的高亮的部分，上文中的代码与同步版本的代码非常相似,代码的流程也从未改变，我们也没有看到任何的回调，但是这并不代表实际上没有回调操作，编译器会搞定这些工作，不再需要您去关心。
异步的方法是用了Task<int>替代了原来返回的Int类型，Task和Task<T>是在如今的framework提供的，用来代表一个正在运行的工作。
异步的方法没有额外的方法，依照惯例为了区别同步版本的方法，我们在方法名后添加Async作为新的方法名。上文中的方法也是异步的，这表示方法体会让编译器区别对待，允许其中的一部分将会变成回调，并且自动的创建Task<int>作为返回类型。
关于这个方法的解释：在方法内部，调用另外一个异步方法DownloadDataTaskAsync，它快速的返回一个Task<byte[]>类型的变量，它会在下载数据完成以后被激活，到如前为止，在数据没有完成之前，我们不想做任何事，所以我们使用await来等待操作的完成。
看起来await关键字阻塞了线程直到task完成下载的数据可用，其实不然，相反它标志了任务的回调，并且立即返回，当这个任务完成之后，它会执行回调。
Tasks
Task和Task<T>类型已经存在于.NET Framework 4.0中，一个Task代表一个进行时的活动，它可能是一个运行在单独线程中的一个CPU密集型的工作或者一个IO操作，手动的创建一个不工作在单独线程的任务也是非常容易的：
static Task ReadFileAsync(string filePath,out byte[] buffer)
{
Stream stream = File.Open(filePath, FileMode.Open);
buffer = new byte[stream.Length];
var tcs = new TaskCompletionSource<double>();
stream.BeginRead(buffer, 0, buffer.Length, arr =>
{
var length = stream.EndRead(arr);
tcs.SetResult(stream.Length);
}, null);
return tcs.Task;
}
一旦创建了一个TaskCompletionSource对象，你就可以返回与它关联的Task对象，问相关的工作完成后，客户代码才得到最终的结果，这时Task没有占据自己的线程。
如果实际任务失败，Task从样可以携带异常并且向上传播，如果使用await将触发客户端代码的异常：
static async void ReadAssignedFile()
{
byte[] buffer;
try
{
double length = await ReadFileAsync("SomeFileDoNotExisted.txt", out buffer);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
static Task<double> ReadFileAsync(string filePath,out byte[] buffer)
{
Stream stream = File.Open(filePath, FileMode.Open);
buffer = new byte[stream.Length];
var tcs = new TaskCompletionSource<double>();
stream.BeginRead(buffer, 0, buffer.Length, arr =>
{
try
{
var length = stream.EndRead(arr);
tcs.SetResult(stream.Length);
}
catch (IOException ex)
{
tcs.SetException(ex);
}
}, null);
return tcs.Task;
}
基于任务的异步编程模型
上文中解释了异步方法应该是的样子-Task-based asynchronous Pattern(TAP)，上文中异步的体现只需要一个调用方法和异步异步方法，后者返回一个Task或者Task<T>。
下文中将介绍一些TAP中的约定，包括怎么处理“取消”和“进行中”，我们将进一步讲解基于任务的编程模型。
Async和await
理解async方法不运行在自己的线程是非常重要的，事实上，编写一个async方法但是没有任何await的话，它就将会是一个不折不扣的同步方法：
static async Task<int> TenToSevenAsync()
{
Thread.Sleep(10000);
return 7;
}
假如你调用这个方法，将会阻塞线程10秒后返回7，这也许不是你期望的，在VS中也将得到一个警告，因为这可能永远不是想要的结果。
只有一个async方法运行到一个await语句时，它才立即把控制权返回给调用方，然而只有当等待的任务完成之后，它才会真正的返回结果，这意味着你需要确保async方法中的代码不会做过多的任务或者阻塞性能的调用。下面的实例才是你所期望的效果
static async Task<int> TenToSevenAsync()
{
await Task.Delay(3000);
return 7;
}
Task.Delay实际上是异步版本的Tread,Sleep，它返回一个Task,这个Task将会在指定的时间内完成。
时间处理程序和无返回值的异步方法
异步方法可以从其他异步方法使用await创建，但是异步在哪里结束？
在客户端程序中，通常的回答是异步方法由事件发起，用户点击一个按钮，一个异步方法被激活，直到它完成，事件本身并不关系方法何时执行完成。这就是通常所说的“发后既忘”
为了适应这种模式，异步方法通常明确的被设计为“发后既忘”-使用void作为返回值替代Task<TResult>类型，这就让方法可以直接作为一个事件处理程序。当一个void saync的方法执行时，没有Task被返回，调用者也无法追踪调用是否完成。
private async void someButton_Click(object sender, RoutedEventArgs e)
{
someButton.IsEnabled = false;
await SumPageSizesAsync(GetUrls()));
someButton.IsEnabled = true;
}
本教程结束