IUnknown::QueryInterface() 是否会增加引用计数？

Question

如果我有一个 IUnknown *ptr，我是否需要在通过 ptr->QueryInterface() 获取的每个接口上调用 Release() ，此外当我完成ptr时调用ptr->Release()？

我曾经认为答案是“是”，但是这段来自MSDN的引用 让我困惑：

有时候你可能需要获取一个对象的弱引用（也就是说，你可能希望获取一个指向其接口之一的指针而不增加引用计数），但是通过以下方式做到这一点是不可接受的调用QueryInterface，然后调用Release。

我不明白为什么这是有问题的 - 如果我调用 ptr->QueryInterface() 然后对结果指针调用 Release，引用计数不应该对象仍然是积极的吗？这如何导致无效指针？

Answer 1

文档是正确的。并且您需要遵循引用计数规则 - 除了在创建对象之后之外，还包括在从 QueryInterface 获取的接口上调用 Release 。

为了弄清楚为什么不能使用 Release 执行弱指针 - 在调用 QueryInterface 和之后立即调用 Release 时存在竞争条件。

• 线程 1 创建对象 - 引用计数 1
• 线程 2 调用 QueryInterface 进行弱引用 - 引用计数 2
• 线程 1 释放对象 - 引用计数 1
• 线程 2 调用 Release 进行弱引用 - 引用计数 0。被摧毁了。
• Thread2 尝试使用对象 - 错误。

警告是为了防止上述情况 - 大概有些程序员认为他们可以“调用 ptr->QueryInterface() 然后在结果指针上调用 Release”并且然后使用该对象...

Answer 2

IUnknown::QueryInterface方法

检索指向对象上支持的接口的指针。

此方法在其返回的指针上调用 IUnknown::AddRef。

直接来自 IUnknown::QueryInterface 参考
http://msdn.microsoft.com/ en-us/library/ms682521%28v=vs.85%29.aspx

Answer 3

主题并不是唯一的情况。我什至可以说线程实际上根本不是主要场景：这些 COM 规则可以追溯到 Win16，然后抢占式多线程首先被添加到 Windows。

关键问题是，就 COM 而言，引用计数是针对每个接口的，而不是针对每个对象的。 COM 实现可以通过按对象实现引用计数来实际实现引用计数 - 这可能是在 C++ 中执行此操作的最简单方法，特别是当 COM 对象映射到单个 C++ 对象时 - 但这只不过是实现细节， COM 客户端代码不能依赖这种情况。

有许多 COM 对象可以根据需要动态生成接口，然后在不再需要时立即销毁它们。在这些情况下，如果您调用 QI 来获取这些接口之一，一旦您调用 Release，该接口的内存就会被释放，因此使用它可能会导致故障/崩溃等。

一般来说，您必须将对 ->Release() 的任何调用视为可能释放指针后面的内存。

（另外，请注意，COM 实际上并没有弱引用的概念：有计数的（强）引用，仅此而已。）

Answer 4

避免弱引用的建议并不能解决竞争问题。

T1 operator new, create object, references: 1
T1     passes interface object reference to T2, thinking it can "share" ownership
T1     suspends
T2     resumes
T2 QueryInterface
T2     suspends before InterlockedIncrement, references: 1
T1     resumes
T1 Calls Release
T1     suspends between InterlockedDecrement and operator delete, references: 0
T2     resumes, InterlockedIncrement occurs, references 1
T2     suspends
T1     resumes, operator delete executes, references 1 !!!
T1     suspends
T2     resumes
T2 Any reference to the interface is now invalid since it has been deleted with reference count 1.

这可以在 COM 服务器中解决。然而，COM 客户端不应该依赖于服务器来阻止这种竞争条件。因此，COM 客户端不得在线程之间共享接口对象。应该允许访问接口对象的唯一线程是当前“拥有”接口对象的一个​​线程。

T1 不应该调用 Release。是的，它可以在将接口对象传递给 T2 之前调用 AddRef。但这可能无法解决比赛问题，只能将其转移到其他地方。最佳实践是始终保持一接口对象、一所有者的概念。

如果 COM 服务器希望支持两个（或更多）接口可以引用某些共享服务器内部状态的概念，则 COM 服务器应通过提供 CreateCopyOfInstance 方法来通告契约并在内部管理争用。当然，有处理这种“扇出”的服务器的例子。看一下 Microsoft 的持久存储接口。在那里，接口不会“扇出”。每个接口应该由单个用户（线程/进程/其他）拥有，并且“扇出”由服务器在内部管理，并提供给服务器的方法COM 客户端控制某些方面的争用问题。因此，Microsoft 的 COM 服务器必须将竞争条件作为与客户签订的合同的一部分来解决。