温莎城堡组件激活器中是否存在内存泄漏

Question

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

我对组件激活

器的生活方式有疑问（温莎城堡组件激活器的预期生活方式是什么？Krzysztof Kozmic 和蔼地回答说："温莎中的每个组件都将获得自己的激活器实例"。

面对我的应用程序中的大量内存泄漏，我发现此类中的显式析构函数从未被调用（至少在我的情况下）。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

作为旁注，能够显式声明组件激活器生活方式不是很有用吗？就我而言，没有理由不能成为单例，这将节省一些内存和处理。

Answer 1

在温莎城堡中感知内存泄漏的最常见原因是对如何处理任何没有系统可定义生命周期的组件（最值得注意的是瞬态组件）的误解。

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

如果您阅读本文并认为"我知道，我知道，我正在发布我所有的东西"，您可能希望通过将默认发布策略更改为"不跟踪"来证明自己是。 如果你的内存泄漏消失了，你可能没有在某个地方发布一些东西。

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

 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.")]

这里有一个关于释放对象的有用链接，如果你不知道它是如何工作的

希望这有帮助