ＣＯＭ计用计数：如何理解AddRed()、Release()返回的计数值是不精确的，不可信的？

Question

“AddRef和Release的返回值没有什么意义，只是在程序调试中可能会用上，客户不应该将此值当成是组件或其接口的精确可靠值。”《COM技术内幕》中有以上这段话，但如果是不精确的，又知道何时删除这个对象呢？最近遇到ＣＯＭ接口的内存泄漏问题，所以在此请教！

Answer 1

不准确是 不 可能的，抱歉我没看过技术内幕，但是我能理解COM基础原理。书中这么说可能是出于多个线程共享一个组件的考虑，也可能是翻译不准确。只是在一个复杂一些的系统里，一个COM组件实例的引用计数，可能发生修改的地方往往比你想象的要多的多。换句话说，程序运行到某处，依你分析，此时的计数值应该是N，但十之八九你会猜错呵呵。DirectShow Filter就是一个很好的例子。正确的说，客户应该把那个值看作：精确但不可靠。但是有一点说得没错，确实是“只是在程序调试中用上”。是啊，实际作为产品的程序中怎么用呢？没法用。例如以前我在开发程序时就犯过这样一个可笑的错误。在那个程序中，我的几个DirectShow Filter组件，在程序要结束，DirectShow链路都已经解散、释放掉之后，在调用那几个Filters的Release时，返回值都是1或2，换句话说这意味着系统没有释放这些组件，将来它们必定是泄漏掉了。怎么办呢？我就自己做了如下一个可怕的宏：#define RELEASE_ALL(p)\
    if(p)\
        while(p->Release());\
    p = NULL;哦你看，这么疯狂的Release，组件经过这个宏后，倒是的确释放的干干净净。但是后来在继续运行时，在程序其他地方又出现了新的内存访问违例。高手一看便知这是为什么。总之，遇到组件的Release返回值该为0却不为0，以至于造成内存泄漏时，你应该做的是横下一条心仔细看Code，看看到底是哪里AddRef之后忘记Release了。Release返回值不为0，只有这一个原因。尤其要仔细检查有Advise Sink的地方，一般要有相应的Unadvise才行。两个组件之间互相抓住引用计数的话，你就要做好走钢丝的准备……

Answer 2

Release返回值为0的时候是准确的，表示对象已经无用了，其他值都是参考值

Answer 3

多谢回复!AgedBOY(禁欲的情种):我也是在做DirectShow程序啊!就是遇到播放WMV格式的内存泄漏,放一首歌要消耗2、3M内存，太夸张了！巧的是，我也用过你上面那个宏来释放，发现播放停止时，有的Video Renderer Release()返回的引用计数竟然达到了十几，其它Filter从几到十几都有，看来Graph内部作了很多处理，用这个宏自然在后面出错。
因为我我们程序原因，需要按照指定的Filter链路来连接，其中还要连两三个自己写的Filter,所以不得不一个Filter一个Fitler地连，这样就保留了所有的Filter的接口，也容易造成问题。我也不想保留这么多指针，但好像只得这样,就像你说的，走钢丝啊。原来都用智能指针，但发现不是不行，于是还是自己来做吧。我现在觉得比较好的一种习惯就是：CoCreateInstance(&pGB);//得到IGraphBuilder
CoCreateInstance(&pFilter);//得到pFilter
pGB->AddFilter(pFilter);//加入Graph
pFilter->Release();//如果后面不再用这个Filter，就马上释放
...
pGB->RemoveFilter(pFilter);
pFilter->Release();//如果前面没有释放，在这里Release
...
pGB->Release();我觉得按道理应该这样啊，一个Filter测试可以通过，但Filter多了就不行了频频出错。另外单独测试，发现pGB->AddFilter()使Filter引用计数加1，pGB->RemoveFilter()减1。不晓得是否这样。连接WMV格式要用DMO，这段代码是从Tutorial上得来的，检查过应该没问题，后来又用ffdshow decoder代替DMO Doceoder还是有此问题。所以应该不是DMO的原因。而且播放其它格式，如MPG，RM，MPEG2都没有内存泄漏啊。谢谢你的回复，看了你的回复，虽然问题还是这样，但好像知道了该怎么做。

Answer 4

现在的进展是：我只能保持一种似乎泄漏最少的方法了。有时，在我觉得合理的地方给加上Release()，程序也能正常运行，但泄漏又更严重了，真是搞不懂，所以只能保持一种似乎泄漏最少的方法了。还有一个问题就是，不够稳定，在多次打开媒体文件后，程序可能当掉！