WCF / Castle 中的内存泄漏问题

Question

我们的MVC3 Web应用程序和WCF数据层服务之间存在内存泄漏问题。我相信问题来自于WCF端，但无法找到原因。我已经在网络上和这些论坛中搜索过，但没有找到原因。非常感谢您的任何帮助！

所以，最初的症状是与后端相关的w3wp进程大小不断增加。我们可以看到，每次从调用服务的Web应用程序进行简单调用时，它会按可变量（数量级100kb）增长。

运行Jetbrains内存分析工具对应用程序进行分析，我们可以看到：

System.ServiceModel.Channels.TransmissionStrategy.SlidingWindow 

远远地，罪魁祸首是内存泄漏。在应用程序启动时，有4个对象实例化，占用极少的内存（总量的6.4%），经过轻微使用后，它上升到>200个对象，约占总量的50%。持续使用将使其接近100%。我以前从未听说过这种情况，但一些搜索表明它被用于数据与WCF层之间的传输等方面。

我目前的思路是进程正在被创建，但没有正确释放。我们的服务是由Castle创建并从Web端注册的：

public static IWindsorContainer RegisterWcfService<TS, TI>(this IWindsorContainer container)
 where TI : TS
 where TS : class
{
 container.Register(Component.For<TS>().ImplementedBy<TI>().Named(typeof(TI).Name)
     .Interceptors<LoggingInterceptor>()
     .Interceptors<ExceptionHandlerInterceptor>()
     .LifeStyle.Transient
     .AsWcfService(
        GetServiceModel<TS, TI>()
        ));

 return container;
}

正如其他帖子中建议的那样，我们正在使用

container.Kernel.ReleasePolicy = new NoTrackingReleasePolicy();

为确保组件正确释放，尽管我相信上述方法已足够，但我们没有显式地处理任何服务引用。请问有人对我们的内存泄漏可能来自哪里有任何建议或建议吗？

- Chris

---

你确定内存无法被回收吗？机器总内存是否承受压力？可能是因为有足够的内存，所以它不会回收吗？ - Sam Holder

完全确定，它没有被回收。 - Chris

Answer 1

很遗憾，手动管理WCF代理的释放是确保垃圾回收和网络资源释放最可靠的方法。这篇简短的博客文章解释了一些导致WCF代理泄漏内存和网络资源的问题。既然您已经配置容器创建临时代理实例，应该使用类似于文章中展示的模式包装服务调用逻辑。

如果这不能解决您的问题，则需要使用WinDbg浏览内存转储，以查找实际的GC根持有对SlidingWindow实例引用链的引用。

顺便说一句：不要试图使用更长寿命的作用域（请求或单例）来尝试解决此问题。解决方案是正确处理代理实例。我曾经吃过苦头……;-)

- Sixto Saez

---

谢谢，我担心可能是这种情况。 - Chris