【请关注】VC内存泄露的排除及处理
内存泄漏定位和处理
一、定位方法
1. 工具辅助类
- Visual Studio自带工具
- 案例:通过 _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF) 开启调试堆,运行后查看输出窗口泄漏报告,定位 new / delete 不匹配(如 int* p = new int[5]; 未 delete[] p )。
- 案例:利用Memory Usage调试工具,对比前后内存快照,筛选增长模块(如循环内重复 new 对象未释放)。
- 第三方工具
- 案例:使用**Valgrind(Windows版叫MemCheck)**扫描 DLL 文件,检测 malloc / free 不匹配(如 void* ptr = malloc(100); 函数返回前未 free(ptr) )。
- 案例:通过BoundsChecker监控COM对象泄漏,如 CoCreateInstance 创建的接口未 Release 。
2. 代码审查类
- 智能指针误用
- 案例:原始指针与 std::shared_ptr 混用导致泄漏(如 int* p = new int; std::shared_ptr<int> sp(p); delete p; ,双重释放风险)。
- 案例: std::unique_ptr 未正确转移所有权(如函数返回 unique_ptr 时未用 std::move ,导致临时对象释放)。
- 资源句柄泄漏
- 案例: CreateFile 打开文件未 CloseHandle , CreateMutex 未 ReleaseMutex 。
- 案例:GDI对象泄漏(如 CreateBitmap 未 DeleteObject )。
- 容器类泄漏
- 案例: std::vector 存储原始指针,元素删除时未手动释放(如 vec.push_back(new MyClass()); 未遍历 delete )。
- 案例: std::map 使用自定义类型作为键,未正确管理内存(如键为 char* 且未复制导致悬挂指针)。
二、处理方法
1. 基础修复类
- 匹配释放
- 案例: new[] 对应 delete[] (修复 int* arr = new int[10]; delete arr; 为 delete[] arr; )。
- 案例:COM对象 AddRef 后必须 Release (修复 IXMLDOMDocument* pDoc; pDoc->AddRef(); 未释放)。
- 智能指针替代
- 案例:将原始指针 MyClass* obj = new MyClass(); 改为 std::unique_ptr<MyClass> obj(new MyClass()); 。
- 案例:共享所有权场景用 std::shared_ptr (如多线程共享资源时自动管理引用计数)。
2. 资源管理类
- RAII模式
- 案例:封装文件句柄到类中,析构函数调用 CloseHandle (避免 HANDLE hFile = CreateFile(...); 函数异常时未关闭)。
- 案例:GDI对象封装( class GDIObject { ~GDIObject() { DeleteObject(hObj); } }; )。
- 容器清理
- 案例: std::list<MyClass*> 析构前遍历释放( for (auto* p : list) delete p; list.clear(); )。
- 案例:使用 std::vector<std::unique_ptr<Item>> 自动管理元素内存。
3. 框架与库适配
- MFC/ATL泄漏
- 案例: CString 动态分配内存未释放(实际由框架管理,无需手动处理,但需注意临时对象生命周期)。
- 案例: CWinThread 创建的对象未在 ExitInstance 中释放(如自定义 CObject 派生类未 DeleteAllObjects )。
- 第三方库泄漏
- 案例:OpenCV矩阵 Mat 未调用 release() (改用RAII封装的 cv::Ptr<Mat> )。
- 案例:Boost库 boost::shared_ptr 循环引用(添加 weak_ptr 打破循环)。
三、复杂场景案例
- 多线程泄漏
- 案例:线程局部存储( TLS )中分配内存未释放(如 _beginthreadex 创建的线程内 malloc 未 free )。
- 案例:锁竞争导致异常路径未释放( lock_guard<std::mutex> 自动释放锁,但自定义锁需确保 unlock )。
- 动态加载模块泄漏
- 案例: LoadLibrary 加载 DLL 后未 FreeLibrary ,且 DLL 内部有全局对象泄漏。
- 案例: GetProcAddress 获取的函数指针使用后未释放相关资源(如动态创建的窗口未销毁)。
- 模板类泄漏
- 案例:自定义分配器的 std::vector 未正确释放(如 template <class T> class MyAllocator { ... }; 未实现 deallocate )。
- 案例:模板类继承导致析构函数非虚(基类 virtual ~Base() {} 缺失,派生类资源未释放)。
关键原则
1. 优先预防:用智能指针、RAII替代原始指针,减少手动管理。
2. 分层排查:先工具定位模块,再代码审查具体函数。
3. 测试覆盖:单元测试中添加内存泄漏检测(如 _CrtSetBreakAlloc 在指定分配处中断)。