.NET池IAsyncResult对象

Question

通过阅读SendAsync，BeginAsync方法的Socket示例，我意识到有人建议汇集SocketAsyncEventArgs实例，因为每个调用都创建了一个IAsyncResult实例，因此它比BeginXX、EndXX异步方法更好。

我认为这并不是一个很好的实践，可以很容易地将可以实例化的对象(如SocketAsyncEventArgs)汇集在一起。对象分配非常快，并且对GC进行了优化，以有效地处理短活动对象。我试着实现一种池机制，看看它是如何执行的，实际上，在简单的对象上分配更快，这些对象除了将一些数据封装在ctor中之外什么也不做。(这就像通过发送数十亿条SELECT 1语句来分析DBMS，这就是我来这里的原因。)

我并不是问哪个更好，我相信分析实际应用程序会给出答案，但我只是好奇汇集简单的短活对象的好处。更好的GC性能？低内存碎片？在设计过程中值得考虑吗？

来自MSDN

这些增强的主要特性是避免在大容量异步套接字I/O期间重复分配和同步对象。System.Net.Sockets.Socket类当前实现的开始/结束设计模式要求为每个异步套接字操作分配一个System.IAsyncResult对象。 在新的System.Net.Sockets.Socket类增强中，异步套接字操作由应用程序分配和维护的可重用SocketAsyncEventArgs对象描述。高性能套接字应用程序最了解必须持续的重叠套接字操作的数量。应用程序可以创建它需要的许多SocketAsyncEventArgs对象。例如，如果服务器应用程序需要在任何时候都有15个套接字接受操作未完成以支持传入客户端连接速率，它可以为此目的分配15个可重用的SocketAsyncEventArgs对象。

谢谢。

Answer 1

IAsyncResult接口包含一个类型为WaitHandle的AsyncWaitHandle属性。WaitHandle消耗操作系统资源。

实际上，WaitHandle实现了IDisposable接口，所以实现IAsyncResult的类本身应该实现IDisposable。

这一切都是说，躺在周围的数百个IAsyncResult实例不是内存问题，而是资源问题。新的套接字调用消除了对周围数百个IDisposable对象的需求。

Answer 2

没有过期策略的缓存是内存泄漏。你的问题中没有任何东西表明你考虑过一个好的政策。如果没有缓存，那么就不要使用缓存。如果你这样做了，然后测试它，看看你是否能衡量实际的改进。