前言
这本书这几年零零散散读过两三遍了，作为经典书籍，应该重复读反复读，既然我现在开始写博了，我也准备把以前觉得经典的好书重读细读一遍，并且将笔记整理到博客中，好记性不如烂笔头，同时也在写的过程中也可以加深自己理解的深度，当然同时也和技术社区的朋友们共享
同步IO执行过程，拿Read举例
- 托管代码转变为本地用户模式代码，Read在内部调用Win32的ReadFile函数
- ReadFile分配IRP（IO Request Packet）
- IRP包括：一个文件句柄、文件偏移量、Byte[]数组
- IO请求进入Windows内核模式，传递IRP，调用内核，根据设备句柄，内核将IRP分发给设备驱动的IRP队列
- 线程在IRP队列里阻塞，硬件执行IO，不涉及到任何线程
- 线程虽然变成睡眠，节省了CPU时间，但是依然浪费了空间（用户模式栈、内核模式栈、TEB等）
- 硬件设备完成IO，Windows唤醒线程，把它调度给一个CPU
- 线程从内核模式返回用户模式，再返回托管代码
同步IO的危害
- 降低服务器响应能力和吞吐量
- 浪费过多的系统资源（线程和内存）
- 频繁的上下文切换
- 线程池频繁创建更多的新线程、阻塞线程醒来时又是上下文切换
异步IO
异步IO的过程的区别在于，IRP请求在内核模式添加到硬盘驱动程序的IRP队列之后，线程不再阻塞，而是允许返回代码，线程立即返回。对回调方法调用的委托实际会在IRP中一路传递道设备驱动程序。硬件处理好IRP后，将IRP的委托放到CLR的线程池队列中。线程池线程提取完成的IRP，并调用回调方法。调用BeginXXX方法时，它构造一个对象来唯一标识IO请求，将请求加入Windows设备驱动程序队列，然后返回对IAsyncResult的引用。在内部CLR线程池使用IOCP来完成异步请求的绑定和发送
异步IO的好处
- 降低资源使用率
- 减少上下文切换
- 提升GC性能和调试性能
- 提高并发量和吞吐量
APM
某一些提供Begin和End方法接口的类，但不与硬件设备通信，这些方法的代码仅仅执行计算限制的操作。不能执行IO限制的操作，因此需要一个线程来执行这些操作
FLC中还有其他：文件流类、网络流类、数据库类、Webservice、WCF
基于传统的begin...,end...模式的异步实现，如果该实现是基于IOCP的话，那么它并不会阻塞在IO线程上。它的实现原理是将IO请求转换成IRP(IO Request Package)然后传递到硬件设备驱动的IRP Queue中，调用begin..方法的线程会立马返回，然后硬件驱动会去它的IRP Queue取出工作项执行，真正执行的时候也不会用到任何线程。当实现完之后会把irp逐层向上抛直到IOCP，然后会将其扔给threadpool,threadpool会选用一个IO线程执行begin...方法中传递的回调方法
委托的BeginInvoke方法在内部调用ThreadPool.QueueUserWorkItem将计算限制操作添加道CLR的线程池队列。最好将IAsyncResult返回调用者。
如果存在回调，执行完后会线程池线程不会回到池中，会调用回调
不建议：
- 直接调用End，会阻塞
- 要避免使用IAsyncResult的WaitHandle属性，会阻塞线程，可能造成线程池分配另一个线程
- 查询IsCompleted，也不建议，会浪费CPU事件
建议
- 总是调用End，而且只调用一次。（1.释放资源 2. 处理异常）
- 调用End方法时应该和Begin方法相同的对象
异常
调用Begin抛异常时，表示异步操作没有进入队列，所以线程池线程不会调用传给Begin的任何回调方法。设备驱动程序向CLR线程池post已完成的IRP，并会在代表异步操作的IAsyncResult中放入一个错误码。线程池调用回调方法，传递Result，回调方法把Result传给恰当的End方法，End方法发现错误码会把它转换成恰当的Exception异常
一般关心从End方法调用抛出的异常
如果采用委托的方式异步调用某个没有返回值的方法， 那么，当你不调用EndInvoke时，你是不知道是否有异常抛出的
委托异步
委托的异步调用是将任务交给线程池的工作线程来执行的
对于delegate的begininvoke的异步实现是在threadpool里的线程来运行的，但是它是基于remoting的架构实现的。这点明显很费性能，所以最好不要用它
线程上下文切换
Context.Post方法将回调送到GUI线程队列中，允许线程池线程立即返回，Send也将回调送入GUI线程队列，但随后会阻塞线程池线程，但随后会阻塞线程池线程，知道GUI线程完成对回调方法的调用。注意，这些Context都在内部调用BeginInvoke（Post）或Invoke方法。EAP中还是用了AsyncOperationManager
EAP
用起来比较方便，但是它是由wiondows form团队开发的，主要是提供给winForm使用的，能很好地在winform开发中使用，但是它会在每次出发时产生EventArgs对象，会造成很多垃圾。其次，使用时间地方式来通知外面也是有性能损失的，对于delegate的调用比virtual方法地调用性能还要差
EAP的诸多限制，同时实现两个模式。支持EAP的类自动将应用程序模型映射到它的线程处理模型。在内部使用了SynchronizationContext类
backgroundworker这个组件本质还是通过delegate的begininvoke来做的(可以通过reflector来查看)，所以也是不推荐使用的
BackgroundWorker用于执行异步的计算限制的工作。不用于执行IO限制的工作
EAP相较APM的缺点，1：包装损耗 2：实际订阅容易内存释放 3.错误处理不一致
APM与Task的转换
- IAsyncResult APM转换为Task，通过Task.Factory.FromAsync<Response>。ask实现了IAsyncResult接口，可以兼容APM。Task封装了对End方法的调用
- 将EAP转变为Task，在EAP的事件回调中针对TaskCompletionSource进行创建
.NET Framework 的异步编程模型
结语
我知道，Jeffrey Ritchter在线程章节花了很大的心血，但是书写时还是没有很好的归纳清楚，比如他用25章讲线程基础和线程的发展和历史背景，这OK无可厚非，但是26章和27章明显就有点没有章法了，他在26章的标题是计算限制的异步，讲线程池然后直接跳到TPL的部分（顺带讲了一下定时器），27章标题是IO限制的异步，可是实际上在讲APM和EAP。哎，所以导致我看书笔记也写的很凌乱，勿怪，仅仅作为自己的一个记录，罢了！