0

阅读 s 的SendAsync方法BeginAsync说明Socket，我意识到有人建议将SocketAsyncEventArgs实例池化，说它比 BeginXX、EndXX 异步方法更好，因为每个调用都会创建一个IAsyncResult实例。

我认为汇集可以轻松实例化的对象（例如SocketAsyncEventArgs）并不是一个好习惯。对象分配非常快，并且 GC 被优化以有效地处理短期对象。我尝试实现一个池化机制来看看它是如何执行的，实际上在简单对象上分配更快，这些对象除了将一些数据封装在 ctor 中之外什么都不做。（嗯，这就像通过发送数十亿条SELECT 1语句来分析 DBMS，这就是我在这里的原因。）

我不是在问哪个更好，我相信分析实际应用程序会产生答案，但只是对汇集简单的短期对象的好处感到好奇。更好的 GC 性能？内存碎片少？在设计时是否值得考虑？

来自MSDN

这些增强的主要特点是避免在大容量异步套接字 I/O 期间重复分配和同步对象。目前由 System.Net.Sockets.Socket 类实现的 Begin/End 设计模式要求为每个异步套接字操作分配一个 System.IAsyncResult 对象。

在新的 System.Net.Sockets.Socket 类增强中，异步套接字操作由应用程序分配和维护的可重用 SocketAsyncEventArgs 对象描述。高性能套接字应用程序最清楚必须维持的重叠套接字操作的数量。应用程序可以创建所需的任意数量的 SocketAsyncEventArgs 对象。例如，如果服务器应用程序需要始终有 15 个未完成的套接字接受操作以支持传入的客户端连接速率，则它可以为此目的分配 15 个可重用的 SocketAsyncEventArgs 对象。

谢谢。

4

2 回答 2

2

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

事实上，WaitHandle实现了IDisposable接口，所以实现的类 IAsyncResult应该自己实现IDisposable。

这就是说，IAsyncResult周围存在数百个实例不是内存问题 - 这是资源问题。新的套接字调用摆脱了对IDisposable周围数百个对象的需求。

于 2010-02-27T16:59:55.677 回答
1

没有过期策略的缓存是内存泄漏。您的问题中没有任何内容表明您考虑了一项好的政策。如果您没有，请不要使用缓存。如果你这样做了，那么测试它，看看你是否可以衡量实际的改进。

于 2010-02-27T16:25:08.023 回答