EWS 托管 API 1.1 - 拉取订阅内存泄漏
是否有其他人在 Exchange 托管 Web 服务 API？调用 PullSubscription.GetEvents() 时，几乎每次轮询调用时内存利用率都会攀升 4K。我能够降低内存利用率的唯一方法是在每次调用后强制进行垃圾回收（通过 GC.Collect()） - 这是一条不必要的路径。
我很惊讶地发现 API 已经快一年没有改变了。
Has anyone else discovered a memory leak issue with Pull Subscriptions (ExchangeService.SubscribeToPullNotifications()) in Exchange Managed Web Services API? When calling PullSubscription.GetEvents() the memory utilization climbs 4K with nearly every polling call. The only way I've been able to keep the memory utilization down is by forcing garbage collection (via GC.Collect()) after every call - an unnecessary path.
I am surprised to see the API hasn't changed for almost a year.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
此问题已由另一篇文章解决。本质上，EWS 与另一个无法释放 NetworkStream 的组件发生冲突（由于
SqlException）。使用ANTS内存分析器来查明原因以及问题发生的时间。如果没有这个分析工具，我们永远不会发现这个问题。This issue was resolved by another post. Essentially EWS was conflicting with another component that failed to release a
NetworkStream(due to aSqlException). ANTS memory profiler was used to pinpoint the cause and timing of the issue. Without this profiling tool we would have never discovered the problem.我想说的是，如果 GC.Collect 回收内存，就不存在内存泄漏。 GC 没有执行 GC 收集的压力，因为有足够的可用内存。
I would say that if a GC.Collect reclaims the memory, there is no memory leak. There is just not pressure on the GC to perform a GC collection, since enough memory is available.