来自 COM 经验的八个教训

核心提示： 其实答案非常简单，应用程序的开发人员其他都做得很对，来自 COM 经验的八个教训(2)，只有一点例外，而这点又非常重要：他们没有在所有的客户端线程中调用 CoInitialize 或 CoInitializeEx，要么在没有明显原因的情况下失败，他们给我演示的最惊人的症状是：当一个调用无法

其实答案非常简单。应用程序的开发人员其他都做得很对，只有一点例外，而这点又非常重要：他们没有在所有的客户端线程中调用 CoInitialize 或 CoInitializeEx。现代 COM 的基本原则之一，就是每个使用 COM 的线程都应该先调用 CoInitialize 或 CoInitializeEx 来初始化 COM。这条原则是无法免除的。除了其他事情以外，CoInitialize(Ex) 应将线程放入单元中，并初始化重要的每线程状态信息（这对于 COM 的正确操作是必需的）。调用 CoInitialize(Ex) 失败通常会在应用程序生命期早期以失败的 COM API 函数的形式表现出来，最常见的是激活请求。但有时问题很隐蔽，直到一切都太晚了（例如对 Release 的调用一去不复返了）才表现出来。当开发小组将 CoInitialize(Ex) 调用添加到所有接触 COM 的线程之后，他们的问题就迎刃而解了。

具有讽刺意义的是，Microsoft 竟是 COM 程序员有时不调用 CoInitialize(Ex) 的原因之一。Microsoft 知识库中包含的一些文档中说，调用 CoInitialize(Ex) 对基于 MTA 的线程来说不是必需的（有关示例，请参阅文章 Q150777）。是的，在很多情况下，我们可以跳过 CoInitialize(Ex) 而不会出现问题。但是，这样是不应该的，除非您知道自己在干什么，并且可以绝对肯定自己不会受到负面影响。调用 CoInitialize(Ex) 是没有害处的，因此我建议 COM 程序员始终从某个与 COM 相关的线程中调用它。 

不要在线程之间传递原始接口指针

我咨询的首批 COM 项目之一就涉及到一个包含 100,000 行代码的分布式应用程序，该程序是由美国西海岸的一个大型软件公司编写的。该应用程序在多个机器上创建了数十个 COM 对象，并从客户端进程启动的背景线程中调用这些对象。开发小组遇到问题了，调用要么消失得无影无踪，要么在没有明显原因的情况下失败。他们给我演示的最惊人的症状是：当一个调用无法返回时，在同一台机器上启动其他支持 COM 的应用程序（包括 Microsoft Paint 等）会频繁导致这些应用程序被锁定。