http://blog.chinaunix.net/uid-10386087-id-2959221.html
今天遇到一個內存泄露的問題。是師兄檢測出來的。Variant類型在使用后要Clear否則會造成內存泄露，為什么呢？
Google一下找到下面一篇文章，主要介紹了Com的內存泄露，中間有對Variant的一些解釋吧。
1. 引用計數泄漏
由于C++的一些對象生命周期難以管理，在COM中加入了引用計數，用來解決這個問題，引用計數是COM最重要的特性 之一。但諷刺的是，雖然很多COM組件是用C++寫的，但是在所有編程語言中，C++使用COM是最麻煩的，而且最容易產生引用計數的泄漏，從而最終造成 內存泄漏。
引用計數泄漏一旦產生，比new了之后忘了delete還難以定位，因為一個對象可能被很多地方使用，根本就不知道到底是那個使用的地方在 AddRef之后沒有Release，只能知道對象泄漏了，但不知道是哪里導致泄漏。
因此在使用COM的時候，盡量使用智能指針，而且最好是所有使用COM的地方全部使用智能指針，這樣能在很大成都上防止產生COM對象的引用計數泄 漏。
然而使用了智能指針一定能解決問題嗎？也不一定，至少有以下兩種情況，使用了智能指針仍然會產生引用計數泄漏，而且比上面的情況更加難以找到原因：
對象循環引用導致引用計數泄漏
如果有兩個對象A和B，在A中使用了B，同時在B中使用了A，B對象中有一個智能指針指向A，A對象中有一 個智能指針指向B，這時候就會產生循環引用導致。因為A對象能被析構的前提是B對象先析構，而B對象析構的前提同樣是A對象先析構，這就成了一個死局，兩 個對象都無法析構，A和B都產生了內存泄漏。
要想解決這種問題，一種方法是把這個循環的鏈打斷，在某個合適的地方把某一個對象中的智能指針顯示地把智能指針賦值為NULL，這樣循環的條件被打 破，兩個對象就都可以析構了。另一種方法是使用弱引用，自動完成。但弱引用相對有點復雜，在本文中不作介紹，讀者可以自行在網上搜索相關資料。
不正確的智能指針使用方法導致引用計數泄漏
有時候使用了智能指針，并且也沒有循環引用，但是對象仍然有引用計數泄漏，是不是很困惑？對于 這種情況，有可能是因為使用智能指針不正確引起的。
我們有時候會這樣使用智能指針：
pUnknown->QueryInterface(__uuidof(IMyInterface), & spMyInterface);
spMyInterface變量是一個智能指針，在大多數情況下這樣使用不會有任何問題，尤其是使用了微軟的_com_ptr_t或CComPtr 等。但如果我們使用一些第三方的智能指針，例如Boost里的intrusive_ptr。我們知道，在_com_ptr_t和CComPtr中，重載 了&操作符，在&操作符中，會先釋放目前的引用計數，然后返回一個指向指針的指針。這樣帶來的好處是使用&操作符的時候，都會先 釋放當前的對象，不會造成內存泄漏，壞處是這個智能指針可能無法放到一些STL的容器中，因為有一些STL的容器，在移動容器中的數據單元時，會用 到&操作符，這樣的結果是一旦移動，對象就被釋放了。Boost的智能指針，例如intrusive_ptr是沒有重載&操作符的，因此 可以放心地在STL容器中使用，但如果寫類似于QueryInterface(__uuidof(IMyInterface), & spMyInterface)就要特別小心了，例如像下面的連續兩次QueryInterface用法，就會產生引用計數泄漏：
boost::intrusive_ptr??? spMyInterface;
pUnknown->QueryInterface(__uuidof(IMyInterface), & spMyInterface);
pUnknown2->QueryInterface(__uuidof(IMyInterface), & spMyInterface);
因為第二次調用QueryInterface之前，spMyInterface并沒有Release，因此就有引用計數泄漏了。如果在某個循環中這 樣使用，則問題會更加嚴重。
要解決這類問題，有兩種方法。第一是同一個變量永遠不要多次使用，在變量聲明周期中類似的操作只使用一次，如果有多次使用的需求，用別的變量來實 現。另一種方法是每次使用之前，都先顯示地把變量清空，釋放引用計數，例如先spMyInterface，再調用QueryInterface。
2. 字符串（BSTR）泄漏
字符串泄漏容易被忽視，而且COM中使用的BSTR字符串，并不是用new或者malloc等來分配的，而 是用類似于::SysAllocString等API來分配的，要檢測是否有泄漏更加困難。
我們一般在調用某個類似于這樣的函數GetString([out] BSTR * str)的返回BSTR的指針的函數后，需要調用::SysFreeString把字符串釋放掉，和new/delete、malloc/free、 AddRef/Release類似。如果忘記調用::SysFreeString，就會產生內存泄漏。
一般我們使用字符串類來自動釋放，例如使用CComBSTR，就可以這樣寫：
CComBSTR str;
GetString(&str);
str在析構的時候會自動調用::SysFreeString把字符串釋放掉。
但如果看一下CComBSTR類的實現，我們會發現，這個類和Boost的intrusive_ptr類似，是沒有重載&操作符的，這就帶 來和intrusive_ptr一樣的問題，如果連續兩次以上使用這個字符串，就會產生內存泄漏，例如字符串類我們有時候會這樣用：
CComBSTR str;
for(int I = 0;I < 100;I ++)
{
pInterface->GetString(&str);
// do something
}
這樣的后果是每調用一次，就會 產生一個內存泄漏。因此一定要保證在字符串對象的生命周期中，只被使用一次，代碼改為這樣就不會有問題：
for(int I = 0;I < 100;I ++)
{
CComBSTR str;
pInterface->GetString(&str);
// do something
}
另外還有一種方法是使用_bstr_t的GetAddress函數，這個函數返回的是 BSTR *，每次調用里面都會先釋放當前的字符串，因此使用 _bstr_t屬于比較保險并且方便的選擇。不過遺憾的是在VC6中這個類并沒有實現GetAddress函數，用起來可能會影響代碼的移植性。
3. VARIANT泄漏
這個情況和字符串泄漏類似，變量不再使用之后，應該調用::VariantClear來釋放內存，否則就可能會 產生內存泄漏。
解決方法也和字符串類似，可以使用VARIANT的CComVariant，但這個類和CComBSTR也有一樣的問題，因此使用的時候也一樣要注 意，必須保證每個變量的生命周期中只使用一次。
另外有一個和_bstr_t類似的類：_variant_t，里面有一個GetAddress函數可以比較方便和安全的使用。具體的細節請參考這幾 個類的實現代碼，這里不多做介紹。
4. 總結
對于本文中提到的幾種內存泄漏的原因，根源在于使用一個第三方的類的時候，其實并沒有真正理解這些類的實現原理，我們以為正確 地使用了，但其實用法并不對。因此在使用一個不是自己寫的第三方類的時候，不能直接拿過來就用，而是應該花一點時間去仔細了解一下這個類，知道怎樣使用是 合理的，而怎樣使用是不正確的，把所有的隱患在編碼之前就解決掉，整個項目開發過程就會更加順利，產品質量就會更高。
關于第三方類庫的使用，在本人另一篇博文《編碼原則十日談》中有提及，這里給出地址，供讀者參考。
