Question

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

我怀疑组分激活剂的生活方式（What is the expected LifeStyle of a Castle Windsor component activator?）。 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

作为旁注，能否明确声明组件激活器生活方式是否有用？就我而言，没有理由说它不能成为Singleton，这会节省一些内存和处理。

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

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

希望这有帮助

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

1 个答案: