Outlook Addin：如何按照 Microsoft 文档的建议主动释放内存？答案

【问题标题】：Outlook Addin: How to actively release memory as suggested by Microsoft documentation?Outlook Addin：如何按照 Microsoft 文档的建议主动释放内存？
【发布时间】：2020-08-09 17:42:34
【问题描述】：

Outlook 插件尝试正确检索 Outlook.Exceptions。我找到了以下文档：

https://docs.microsoft.com/de-de/office/client-developer/outlook/pia/how-to-find-a-specific-appointment-in-a-recurring-appointment-series

上面写着： [...] 当您使用定期约会项目时，您应该释放任何先前的引用，在访问或修改项目之前获取对定期约会项目的新引用，并在完成后立即释放这些引用，并且已保存更改。这种做法适用于重复的 AppointmentItem 对象，以及任何 Exception 或 RecurrencePattern 对象。若要在 Visual Basic 中释放引用，请将现有对象设置为 Nothing。 在 C# 中，显式释放该对象的内存。 [...]

现在我的问题是我该怎么做？引用页面上的例子没有显式释放内存？

将 appt 设置为 null 就足够了吗？

【问题讨论】：

标签： c# outlook-addin

【解决方案1】：

设置为 null 绝对是不够的。在这种情况下，您还必须强制垃圾收集器尽快清理堆。您可以通过调用GC.Collect() 和GC.WaitForPendingFinalizers() 正确执行此操作。调用两次是安全的，end 确保循环也被清理干净。

但我建议您在使用完 Outlook 对象后使用System.Runtime.InteropServices.Marshal.ReleaseComObject 来释放它。然后在 Visual Basic 中将变量设置为 Nothing（在 C# 中为 null）以释放对对象的引用。如果您的加载项尝试枚举存储在 Microsoft Exchange Server 上的集合中超过 256 个 Outlook 项目，这一点尤其重要（此数字在最新版本中有所增加）。如果您不及时释放这些对象，您可能会达到 Exchange 对任何一次打开的最大项目数量的限制。

ReleaseComObject 方法用于显式控制托管代码中使用的 COM 对象的生命周期。您应该使用此方法及时释放包含资源引用的底层 COM 对象，或者在必须按特定顺序释放对象时。

每次 COM 接口指针进入公共语言运行库 (CLR) 时，都会将其包装在 RCW 中。

RCW 有一个引用计数，每次 COM 接口指针映射到它时都会递增。 ReleaseComObject 方法减少 RCW 的引用计数。当引用计数达到零时，运行时会释放其对非托管 COM 对象的所有引用，如果您尝试进一步使用该对象，则会引发 System.NullReferenceException。如果同一个 COM 接口从非托管代码传递到托管代码不止一次，则包装器上的引用计数每次递增，调用 ReleaseComObject 返回剩余引用的数量。

ReleaseComObject 方法使您能够强制释放 RCW 引用计数，以便它在您想要的时候准确地发生。但是，不当使用ReleaseComObject 可能会导致您的应用程序失败，或者可能导致访问冲突。

【讨论】：

在方法局部变量引用 AppointmentItem 的每个方法结束时，必须主动调用 System.Runtime.InteropServices.Marshal.ReleaseComObject 是否正确？
不，实际上并非如此……这取决于谁检索或创建了 COM 对象的实例。它作为参数传递，你不应该释放它。

【解决方案2】：

C#（CLR 运行时）中的内存管理是自动的，并采用垃圾收集器。

垃圾收集器定期检查要回收的无法访问的对象。这个过程不是确定性的，除非你强制它（但通常你不应该）。

要释放对象的内存，您只需使其无法访问：这可能发生在设置为 null 对有问题对象的所有引用的各种组合中，或者让所有引用超出范围（前提是您没有将其分配给属性字段）。

【讨论】：