2

我知道现代 Windows 版本会在程序终止后回收以前使用 等获取的内存malloc，new但是 COM 对象呢？我应该obj->Release()在程序退出时调用它们，还是系统会为我这样做？

我猜它：这取决于. 对于进程外 COM，我可能应该总是调用Release()，但对于进程内 COM，我认为这并不重要，因为 COM 对象在程序终止后无论如何都会死掉。

4

3 回答 3

4

如果您处于进程本身，那么是的，您应该这样做，因为您可能不知道服务器在哪里，并且服务器可能不在 proc 中。如果您在 DLL 中，它会变得更加复杂。

在 DLL中，除非您收到DLL_PROCESS_DETACH通知，否则您应该什么都不做，只让应用程序关闭。这是因为在进程拆卸期间会调用此通知。因此，此时清理为时已晚。内核可能已经回收了您调用的块release。

请记住，作为 DLL 编写者，如果进程不正常退出，您将无能为力，您只能在合理的范围内做您能做的事情，以便在正常退出后进行清理。

一种简单的解决方案是在任何地方都使用智能 COM 指针，ATL和WRL的实现可以很好地工作，因此您大部分时间都不必担心它。即使这些是静态存储的，它们的析构函数也会在进程拆除或 DLL 卸载之前被调用，从而在安全的时候安全地释放。

所以简短的回答是如果可以release的话，例如，如果这样做是安全的，你应该总是打电话。但是，有时情况并非如此，您绝对不应该做任何事情。

于 2013-12-16T16:03:05.127 回答
3

根据底层对象的实现，可能会有也可能没有惩罚。该对象可能具有在进程关闭之后仍然存在的状态。本地数据库中的持久锁是最简单的例子。

考虑到这一点，我说最好调用 Release 以防万一。

于 2013-12-16T16:07:06.370 回答
2
  • 进程内 COM 对象将随进程而死
  • 进程外引用将在超时时释放
    • 设计不佳的服务器和客户端可能会保持不良状态，持有指向对象（通常是代理）的指针，这些对象不再可用，无法看到它们已经死亡。无法摆脱它们
    • 优雅地释放指针总是一个好主意

如果您没有正确释放 COM 指针，并且 COM 活动包括封送处理，您很可能会遇到CoUninitialze既烦人又/或最终向用户显示进程崩溃消息的异常。

于 2013-12-16T16:08:07.080 回答