Tridion发布和垃圾收集

我提到了之前的一篇文章，其中我解释说，我们的系统在大规模出版过程中显然是随机崩溃的

我们使用的是XSLTMediator&我们所有的模板都基于TemplateBase解决方案

有人告诉我，这个错误可能与垃圾收集/COM+有关-我认为这有点过分，TemplateBase解决方案显式实现了IDisposable，它应该解决所有GC/COM+的问题？与VBScript中的设置不同，设置obj=没有任何东西可以避免内存泄漏

---

谢谢。

听起来您需要进行一些深入的调试。有关此主题的高质量信息来源之一是这里的一些注意事项

1使用Marshal.ReleaseComObject释放Tridion COM对象，但在引用计数器达到0之前，不能只调用一次

while (Marshal.ReleaseComObject(component) > 0);

2不要将COM对象作为参数传递到函数中

3不要声明或尽量避免将COM对象声明为类中的字段

---

4考虑使用弱引用。弱引用将立即将对象标记为准备好进行GC。由于.Net GC在后台线程中运行，我们不知道它将在何时执行，因此在使用它之前，始终在所有弱引用中添加null检查，以确保对象仍然处于活动状态，如果已经收集到弱引用，则需要再次实例化弱引用。

能否从事件查看器日志中提供错误消息？另外，您的问题是Tridion publishing如何进行垃圾收集，或者每个模板如何处理？声明IDisposable不会自动修复任何问题。您的模板/中介代码必须正确实现Dispose并关闭它可能保留的任何资源。你可以考虑调用。关闭现代相当于将一个对象设置为零。但所有这些都只是语句，您的问题是什么？中介代码实际上是XsltMediator，它本身并不直接实现IDisposable。在任何情况下，都不需要担心非托管资源，因此GC应该正确地执行其工作？TemplateBase实现了它，这应该足够了吗？我不确定我的问题是什么，因为我不相信这个问题是因为没有实现IDisposableI当然有兴趣知道实现GC的最佳实践是什么，以及Tridion本身是如何处理模板的，如果有人能够很好地描述它的话！XSLTMediator与模块化模板一起使用，因此将使用的API是TOM.NET，它不会给您一个RCW。即使是这样，使用Marshal.FinalReleaseComObject也可以避免您自己编写循环代码。在这种情况下，弱引用不会对您有多大帮助。如果您再次需要该对象，只需在模板的生命周期中使用强引用来保持它。真正地如果要将对象推送到某种长寿命缓存中，弱引用可能是有意义的，但为什么呢？TOM.NET对象（如Engine、Session）仍然在后台使用互操作，因此将它们作为扩展对象的一部分传递给XSLT中介可能会导致内存泄漏。根据我的经验，在一种技术与另一种技术（如.Net和COM MSXML解析器）之间传递对象可能会导致内存泄漏，这就是为什么弱引用会出现在图片中，迫使发布它。但弱引用不会强制发布任何内容。如果您的强引用超出了范围，则具有相同的效果。弱引用只有在您有意让对象保持可访问性，但准备让其被处置并处理后果时才有意义。这可能不是模板中的场景。