Castle Windsor 组件激活器中是否存在内存泄漏？答案

【问题标题】：Is there a memory leak in Castle Windsor component activator?Castle Windsor 组件激活器中是否存在内存泄漏？
【发布时间】：2013-11-27 20:33:24
【问题描述】：

我正在使用 Castle Windsor 和 DynamicProxy 从头开始实现持久性延迟加载（我知道 NHibernate 可能是一个选项等）我已经实现了一个自定义组件激活器来始终将我的业务类实例化为代理。

我对组件激活器的生活方式有疑问 (What is the expected LifeStyle of a Castle Windsor component activator?)。 Krzysztof Kozmic 友好地回答说“Windsor 中的每个组件都会有自己的激活器实例”。

面对我的应用程序中的大内存泄漏，我发现永远不会调用此类中的显式析构函数（至少在我的情况下）。 Castle 是否适当地释放了激活器，即在类型工厂被处置时？

Classes
    .FromAssemblyContaining(typeof(QuantityType))
    .InNamespace(typeof(QuantityType).Namespace)
    .WithService.DefaultInterfaces()
    .Configure(reg => { reg.Activator<ColMsProxyComponentActivator>(); })
    .LifestyleTransient() // We really want new entities every time a new one is requested

顺便说一句，能够显式声明组件激活器的生活方式不是很有用吗？在我的情况下，它没有理由不能是单例，这样可以节省一些内存和处理。

【问题讨论】：

标签： components castle-windsor memory-leaks castle activator

【解决方案1】：

在 Castle Windsor 中感知内存泄漏的最常见原因是误解了如何处理任何没有系统可定义生命周期的组件，尤其是瞬态组件。

城堡的设计者认为创造和破坏的责任都是容器的关注点。在这种情况下，默认行为是跟踪容器创建的所有对象。这意味着，如果您不释放它们，您将看到看起来像内存泄漏的情况。

如果您阅读本文并想“我知道，我知道，我要发布我所有的东西”，您可能想通过将默认发布政策更改为“不跟踪”来向自己证明您是。如果你的内存泄漏消失了，你可能没有在某处释放一些东西。

我认为这是更改发布策略的代码：

 container.Kernel.ReleasePolicy = new NoTrackingReleasePolicy();

如果您正在考虑，我将保留 NoTrackingReleasePolicy，因为它解决了我的问题，这是代码中作者的注释：

 [Obsolete("This class is a hack, will be removed in the future release and should be avoided. Please implement proper lifecycle management instead.")]

Here's a useful link about releasing objects if you're unaware how it all works

希望对你有帮助

【讨论】：

其实我的疑惑不在于被激活组件的生活方式，而是组件activator的生活方式。因此，您的答案实际上本身就是有价值的信息，而不是专门针对我的问题。实际上我已经放弃了对这个问题的调查，因为我有理由相信这只会影响我在执行 NUnit 测试时，当初始化不断发生但线程永远不会完成（因此不会清理）。
如果我没记错的话，每个组件都有自己的激活器，激活器的生命周期与组件的生命周期相关。