国外案例网站,青岛网页设计学校,企业网站建设服务,wordpress免费主题传送门#xff1a;异步编程系列目录…… 摘要#xff1a;本博文解释在.NET 4.X中的Task使用完后为什么不应该调用Dispose()。并且说明.NET4.5对.NET4.0的Task对象进行的部分改进#xff1a;减轻Task对WaitHandle对象的依赖#xff0c;并且增强在释放了Task后对其成员的可访… 传送门异步编程系列目录…… 摘要本博文解释在.NET 4.X中的Task使用完后为什么不应该调用Dispose()。并且说明.NET4.5对.NET4.0的Task对象进行的部分改进减轻Task对WaitHandle对象的依赖并且增强在释放了Task后对其成员的可访问性。 我多次获得这样一个问题 “Task实现了IDisposable接口并且公开Dispose()方法这是否意味着我们要对所有的任务进行释放吗” 概述 1. 这是我对该问题的简要回答 “不是不用释放你持有的Task。” 2. 这是我对该问题的中篇回答 “不是不用释放你持有的Task除非性能报告或可伸缩性测试报告显示你需要释放Task以满足你的性能目标。如果你发现一个需要被释放的Task必须100%确保在你的释放点处该Task已经完成并且没有被其他地方在使用。” 3. 下面你可以找一个休闲的阅读时间这是我对该问题的长回答 为什么要调用Task的Dispose() .NET Framework设计指南中指出一个类型如果持有其它实现过IDisposable接口的资源时其自身也应该实现IDisposable接口。在Task内部可能会分配一个WaitHandle对象用于等待任务完成。WaitHandle实现IDisposable接口因为它持有SafeWaitHandle内核等待句柄所以Task实现了IDisposable接口。如果不主动释放SafeWaitHandle句柄最终终结器也会将其清理但是不能对此资源立即清理并且还将此清理工作负荷遗留给系统。通过给Task实现IDisposable接口我们可以让开发人员能主动及时的对资源进行释放。 问题 如果为每一个Task都分配一个WaitHandle那么释放Task将是一个好措施因为这样能提高性能。但是事实并非如此现实中为Task分配WaitHandle的情况是非常少出现的。在.NET 4.0中WaitHandle在以下几种情况会延迟初始化访问 ((IAsyncResult)task).AsyncWaitHandle成员或者调用Task的WaitAll()/WaitAny()方法这两个方法在.NET4.0版本中内部是基于Task的WaitHandle对象实现的。这使得回答“是否应该释放Task”问题更加困难了因为如果Task都使用了WaitAll()/WaitAny()那么释放Task就是一个好选择。 1 2 3 4 5 6 7 public interface IAsyncResult { object AsyncState { get; } WaitHandle AsyncWaitHandle { get; } bool CompletedSynchronously { get; } bool IsCompleted { get; } } 在.NET 4.0中一个Task一旦被释放它的大多数成员访问都会抛出ObjectDisposedExceptions异常。这使得完成的任务很难被安全的缓存因为一个消费者释放Task后另一个消费者无法再访问Task的一些重要成员如ContinueWith()方法或Result属性。 这里还有另外一个问题Task是基础同步基元。如果Task被用于并行化如在一个fork/join模式”分支/合并”模式中那么它就很容易知道什么时候完成它们和什么时候没有人再使用它们比如 1 2 3 4 5 6 var tasks new Task[3]; tasks[0] Compute1Async(); tasks[1] Compute2Async(); tasks[2] Compute3Async(); Task.WaitAll(tasks); foreach(var task in tasks) task.Dispose(); 然而当使用Task的延续任务时就很难判断它什么时候完成它们和什么时候没有人再使用它们比如 1 2 3 4 5 Compute1Async().ContinueWith(t1 { t1.Dispose(); … }); 示例成功的释放掉Compute1Async()返回的Task但是它忽略了如何释放ContinueWith()返回的Task。当然我们能使用同样的方法释放这个Task。 1 2 3 4 5 Compute1Async().ContinueWith(t1 { t1.Dispose(); … }).ContinueWith(t2 t2.Dispose()); 但是我们不能释放第二个ContinueWith()返回的Task。即使使用C#5.0中新的async/await异步方法也不能解决。例如 1 2 3 string s1 await Compute1Async(); string s2 await Compute2Async(s1); string s3 await Compute3Async(s2); 如果想释放这些Task我需要进行像下面这样的重写 1 2 3 4 5 6 7 string s1 null, s2 null, s3 null; using(var t1 Compute1Async()) s1 await t1; using(var t2 Compute2Async(s1)) s2 await t2; using(var t3 Compute3Async(s2)) s3 await t3; 解决方案 由于像上面这样进行释放大多数Task显得很繁琐所以在.NET4.5中已经对Task的Dispose()做过一些改进 1. 我们使得你更少机会为Task创建WaitHandle对象。在.NET4.5中我们已经重写了Task的WaitAll()和WaitAny()以致这两个方法不再依赖与WaitHandle对象这样WaitAll()、WaitAny()、Wait()就都基于自旋等待避免在Task的内部实现中使用WaitHandle对象并且提供async/await相关异步功能。因此只有当你显示访问Task的IAsyncResult.AsyncWaitHandle成员才会为Task分配WaitHandle对象但这种需求非常少见。这意味着除了这种非常少见的情况外释放一个任务是不需要的。 2. 我们使得Task在释放后依然可用。你能使用Task的所有公开成员即使Task已经被释放访问这些成员的表现就和释放Task之前一样。只有IAsyncResult.AsyncWaitHandle成员你不能使用因为这是你释放Task时真真所释放的对象当你尝试在释放Task后访问这个属性时依然会抛出ObjectDisposedException。此外更进一步的说现在我们推荐使用async/await异步方法以及基于任务的异步编程模式降低对IAsyncResult的使用即使你继续使用((IAsyncResult)task)调用其AsyncWaitHandle成员也是十分罕见的。 3. Task.Dispose()方法在“.NET Metro风格应用程序”框架所引用的程序集中甚至并不存在即此框架中Task没有实现IDisposable接口。 指南 所以这又让我们回到了简要的回答“不是不用释放你的Task。”通常很难找到一个合适的释放点目前几乎没有一个理由需要去主动释放Task因为调用((IAsyncResult)task).AsyncWaitHandle成员的需求是十分罕见的并且在“.NET Metro风格应用程序”框架所引用的程序集中你甚至不能调用Task的Dispose()方法。 更多资源来源博文关于Async与Await的FAQ 原文http://blogs.msdn.com/b/pfxteam/archive/2012/03/25/10287435.aspx 作者Stephen Toub - MSFT 作者滴答的雨 出处http://www.cnblogs.com/heyuquan/ 本文版权归作者和博客园共有欢迎转载但未经作者同意必须保留此段声明且在文章页面明显位置给出原文连接否则保留追究法律责任的权利。
