Castle Windsor组件激活器中是否有内存泄漏？

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

我对构件激活剂的生活方式有怀疑（What is the expected LifeStyle of a Castle Windsor component activator?）。 Krzysztof Kozmic善意地回答说：“Windsor中的每个组件都将获得它自己的激活器实例”。

在我的应用程序中的大内存泄漏面对我来发现，在这个类的析构函数明确的是从来没有所谓的（在我的情况下，至少）。城堡是否适当地释放了催化剂，也就是说，何时处置了这种类型的工厂？

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

作为一个方面说明，是否有能力显式声明组件激活器的生活方式？在我的情况下，没有理由为什么它不能成为一个Singleton，这会节省一些内存和处理。

来源

2013-11-14 Luis Ferreira

在温莎城堡内存泄漏的感知最常见的原因是如何处理那些没有一个系统定义的一生中，最值得注意的是，短暂的组件的任何组件的误解。

城堡的设计师决定创建和销毁的责任是容器的问题。情况就是这样，默认行为是跟踪容器创建的所有对象。这意味着，如果你不释放它们，你会看到什么看起来像内存泄漏。

如果你读这一点，并想“我知道，我知道，我放开了我所有的东西”，你可能想证明给自己你是通过更改默认发布政策“不跟踪”。如果你的内存泄漏消失了，你可能不会在某处发布任何东西。

我认为这是改变释放的政策代码：

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

希望这有助于

来源

2013-11-15 05:08:42 greyalien007

其实，我的怀疑并没有涉及被激活的组件的生活方式，而是组件*激活者*的生活方式。所以你的答案本身就是有价值的信息，并不是专门针对我的问题。其实我已经放弃了对这个问题的调查，因为我有理由相信这只会影响我执行NUnit测试，当初始化持续发生时，但线程永远不会结束（因此不会清理）。 –

如果我没有记错，每个组件都有它自己的激活器，激活器的生命周期与组件的生命周期有关。 – greyalien007

Castle Windsor组件激活器中是否有内存泄漏？

回答

相关问题