★ FEATURED ARTICLE 排查内存增长这件事说穿了是一场围绕“怀疑”的持久战怀疑自己代码写得有问题怀疑Qt框架哪块缓存没清甚至怀疑Windows调度器在捣鬼。而“QT MinGW编译器下的内存异常持续增长检查”这个主题正是我在某跨平台桌面客户端项目里被折磨过最久的一类问题。应用在Windows上跑着跑着任务管理器里的内存占用就开始匀速爬坡业务端同事隔几天来催一次重启。听起来像典型内存泄漏可真要在MinGW这套工具链下动起手来你会发现一个尴尬事实MSVC那句顺手的_CrtDumpMemoryLeaks在MinGW下完全不存在Valgrind在Windows上又不能直接用Qt Creator自带的分析器在WindowsMinGW这个组合下对原生C堆内存的检查能力又相当有限。这篇文章就围绕这个场景把我验证过的工具选型、完整排查流程和实际踩过的坑整理出来给同样在用QtMinGW做Windows桌面应用、又被内存曲线折磨的人一个可落地的参考。1. 内存异常增长的本质与排查思路拆解1.1 先搞清楚“内存增长”到底涨的是哪个指标很多人看到任务管理器里“内存”那一列往上走就下结论说程序内存泄漏其实这个结论经常下早了。任务管理器默认显示的是工作集Working Set这个数值不仅包含进程真正持有的物理内存还包含Windows为了效率主动映射进来的缓存页面系统完全可以在不违反任何内存管理规则的前提下让这个数字上下跳动。排查内存异常增长最该盯的其实是私有字节Private Bytes和提交大小Commit Size这两个计数器它们反映的是进程真正申请并持有、没有归还给操作系统的虚拟内存量。我自己的习惯是先用Windows自带的性能监视器perfmon把进程的Private Bytes加进去然后固定跑一段业务操作观察曲线整体趋势。如果Private Bytes是单边持续上涨几乎不回落那基本可以断定程序内部有对象在被累积持有也就是真正需要排查的异常增长如果只是工作集涨、Private Bytes平稳那大概率只是页面缓存波动不用太紧张。这个判断是整个排查工作的起点方向错了后面所有工具跑出来的结果都会让你困惑。1.2 内存增长并不等于内存泄漏先分类再动手把“内存增长”笼统归因为“内存泄漏”会漏掉很多同样让内存曲线飙升的情况。我一般会在动手前先给现象分类粗粒度来看大概有五种类型典型特征常见场景工具能不能直接发现真泄漏分配后失去引用永远无法释放new之后没有delete、父对象没设置Dr. Memory、ASan都能直接报伪泄漏/缓存膨胀对象仍被引用但持有数量只增不减单例里的列表越攒越长、QPixmapCache无限写入工具只会报“still reachable”需要人工判断生命周期过长对象功能上不需要了却还被某个长生命周期对象持有窗口关闭但未delete、信号槽连接未断开工具难直接定性需要审查对象关系隐式共享造成的假象单个元素很小但背后共享着大缓冲区QString/QByteArray拷贝切片、QImage局部引用工具看不出逻辑需要熟悉容器语义碎片化膨胀总分配量没涨但堆碎片让空闲内存难以复用频繁申请释放不同大小对象工具基本无能为力你看真正能靠泄漏检测工具一步到位的只有第一类剩下的还得靠代码理解。所以我的排查原则是先把现象归类再决定上什么工具。如果Private Bytes涨得很规律每次固定操作涨固定幅度那基本都是对象持续new出来没释放工具会非常给力如果增长节奏不规律、幅度忽大忽小就要多考虑缓存和生命周期问题。1.3 为什么MinGW环境下这个问题格外麻烦这套问题放在MinGW下难度会翻倍。原因很现实MSVC生态里那套调试接口——_CrtSetBreakAlloc、_CrtDumpMemoryLeaks、Visual Studio自带的诊断工具——在Windows上确实是好东西可MinGW用的是GCC运行时这套CRT调试接口根本没有连想靠Visual Studio的诊断窗口分析一个MinGW编译出来的exe都做不到。Valgrind的Memcheck在设计上高度依赖Linux的ptrace机制Windows下跑不起来有人尝试在WSL里跑Valgrind但那只能分析Linux版本的程序对你的Windows Qt应用毫无帮助。好在MinGW-w64这条路线这些年一直在发展两个主力替代方案可用一个是动态插桩工具Dr. Memory不需要重新编译源码另一个是编译期插桩的AddressSanitizer配合LeakSanitizer在较新的GCC版本上已经能工作。只是它们各有各的脾气用得不对会让你白折腾大半天后面我会把关键坑都点出来。2. 工具选型解析Windows下MinGW能用的三套内存检查方案2.1 Dr. MemoryWindows上最接近Valgrind的选择Dr. Memory是我在MinGW环境下最先尝试的工具它在思路上和Valgrind很像都是动态二进制插桩不需要你重新编译程序它直接拦截目标进程的内存分配和释放调用在程序运行时收集所有堆操作。它最大的优势是兼容性好只要是带调试符号的Debug构建管你是MinGW编译的还是MSVC编译的它都能分析。使用上有一个前提必须满足程序必须是Debug构建而且要带-g调试符号。Release构建或者优化等级开太高比如-O2会让很多分配点的行号信息消失报告里的调用栈会变得没法看。启动方式很简单命令行下这样执行drmemory.exe -- your_qt_app.exe程序退出后Dr. Memory会自动生成报告重点看LEAK条目。它会告诉你泄漏的内存大小、分配次数以及分配时的调用栈。我这里有一个真实场景的简化报告片段Error #1: LEAK 64 bytes in 1 allocation(s) allocation site: mainwindow.cpp:45 in MainWindow::openConfigDialog 0x0000000140012FAB in operator new(unsigned long)如果报告里出现了很多指向Qt库内部的分配点先别慌那多半是Qt的全局缓存和线程池在退出时没有被完全清理属于需要过滤的杂音。我的做法是把报告中的调用栈筛选一遍只留下指向自己源码文件的部分那才是真正需要查的地方。2.2 AddressSanitizer与LeakSanitizer编译期插桩方案第二个方案是AddressSanitizer通常配合LeakSanitizer一起用。它的原理是在编译阶段往代码里插入大量检查逻辑运行时拦截堆操作并记录每次分配的调用栈。相比Dr. MemoryASan的速度快很多跑起来不那么煎熬而且报告的调用栈质量非常高直接对应源码行号。在MinGW下启用ASan首先确认你的编译器够新。我建议使用GCC 10以上的MinGW-w64工具链老版本离线安装包里带的编译器可能压根不支持-fsanitizeaddress。CMake构建时这样配置cmake_minimum_required(VERSION 3.16) project(memory_demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(memory_demo main.cpp) if(WIN32) target_compile_options(memory_demo PRIVATE -fsanitizeaddress -g -O1) target_link_options(memory_demo PRIVATE -fsanitizeaddress -static-libasan) endif()加了-static-libasan是想把ASan运行时静态链接进程序减少动态库加载顺序带来的问题。这是我在实际项目中踩出来的经验如果不静态链接经常会遇到程序一启动就弹出ASan runtime does not come first的报错原因是可执行文件启动时ASan运行时没有被最先加载某些预编译的Qt库抢先加载了依赖库导致运行时地址错乱。遇到这种报错先检查是不是忘了静态链接如果加上了还是报错那就别再死磕直接切回Dr. Memory工具是服务目标的不是用来跟它较劲的。2.3 不依赖外部工具的最小方案私有字节打点日志不管用哪个检测工具我都会先给自己留一条“后路”在程序里埋一个内存打点日志。这条后路的好处是零依赖、零侵入式调试而且能长期保留。具体做法是用Windows API读取当前进程的内存计数器然后用定时器每隔一秒输出一次重定向到日志文件。#include windows.h #include QDebug #include QTimer #include QDateTime double currentPrivateMb() { PROCESS_MEMORY_COUNTERS pmc; pmc.cb sizeof(pmc); if (GetProcessMemoryInfo(GetCurrentProcess(), pmc, sizeof(pmc))) { return static_castdouble(pmc.PrivateUsage) / (1024.0 * 1024.0); } return -1.0; } void startMemoryLog(QObject *parent) { QTimer *timer new QTimer(parent); QObject::connect(timer, QTimer::timeout, []() { qInfo().noquote() QDateTime::currentDateTime().toString(Qt::ISODate) currentPrivateMb() MB; }); timer-start(1000); }这段代码在MinGW下编译时需要链接psapi库CMake里加一行target_link_libraries(memory_demo psapi)就行。平时它就是个隐藏得很深的小日志开关只在排查时打开。它可以帮你回答两个关键问题内存增长是不是稳定的复现条件是什么这两个问题不搞清楚后面跑任何工具都像无头苍蝇。3. 完整排查实操从复现到定位再到回归验证3.1 搭建可复现的基线场景任何内存问题的排查第一步都是把“现场”固定下来。你要是直接在正式环境里开着几十个窗口、让用户随机操作那跑什么工具都白搭报告里全是杂音。我的做法是把业务操作拆成一个固定动作序列比如启动程序-打开配置对话框-填入数据-关闭对话框-等两秒-再打开。然后循环这个序列两百次用内存打点日志记录整个过程的Private Bytes变化。我当时在某个模拟项目X里就复现得特别规律每打开关闭一次配置对话框内存Private Bytes稳定增加0.2MB左右。这个现象本身就强烈指向一个结论——对话框对象每次打开都new了一个新实例关闭时并没有释放。有了这个稳定的基线后面所有工具的验证都有了参照物。如果你连最小场景都无法稳定复现那说明问题藏在更复杂的业务分支里这时候不要硬来先去缩小复现路径把无关代码注释掉一步一步逼近问题点。3.2 用Dr. Memory跑第一轮把可疑分配点逼出来基线确定之后我先把程序切到Debug构建确保带-g -O0然后用Dr. Memory启动程序按固定动作序列操作一遍最后正常退出程序。这里有个细节一定要让程序正常退出不要从任务管理器里强杀进程。Dr. Memory是在进程退出时做泄漏汇总的强杀会导致报告缺失或格式混乱。跑出来的报告质量取决于你的基础环境。我当时的报告核心内容是ERRORS FOUND: -------------- Error #1: LEAK 260 bytes in 1 allocation(s) 0x0000000002F1A040 allocation location: configdialog.cpp:78 in ConfigDialog::ConfigDialog mainwindow.cpp:45 in MainWindow::openConfigDialog调用栈很清楚分配点在ConfigDialog构造函数的第78行调用者是主窗口的openConfigDialog。也就是说每次打开配置对话框都会new一个对话框对象而关闭对话框时这个对象没有被释放。报告里这个LEAK的含义是“进程退出时仍然存在且没有有效引用的内存”它的可信度很高。拿到这个结论后我不急着改代码而是先去源码里验证这个分配点是否真的具备泄漏条件。打开openConfigDialog看了一眼果然void MainWindow::openConfigDialog() { auto *dlg new ConfigDialog(); // 没有传入父对象也没有保存指针 dlg-setAttribute(Qt::WA_DeleteOnClose); // 没设置关闭即删除 dlg-show(); }new出来的对象没给父对象、没存成员指针、也没设置WA_DeleteOnClose那么对话框关闭时默认只是hide()对象本身一直挂在堆上直到进程退出才被Dr. Memory抓个正着。这就是最典型的Qt内存泄漏写法。3.3 用ASan再做二次确认拿到更完整的调用栈Dr. Memory给出了方向但我习惯再用ASan确认一次因为它的报告格式更适合交叉验证。我把CMake配置切到上一节那个带AddressSanitizer的版本重新构建跑同样的动作序列程序正常退出时LeakSanitizer会在控制台输出泄漏摘要大致长这样ERROR: LeakSanitizer: detected memory leaks Direct leak of 260 byte(s) in 1 object(s) allocated from: #0 0x7ff68a54a9b2 in operator new(unsigned long) #1 0x7ff68a3f1a10 in ConfigDialog::ConfigDialog configdialog.cpp:78 #2 0x7ff68a3f1d05 in MainWindow::openConfigDialog mainwindow.cpp:45 #3 0x7ff68a3f1e8f in MainWindow::openConfigButtonClicked mainwindow.cpp:31两个工具指向同一行号到这个程度基本可以下结论了。注意跑ASan时同样要保证程序走完整个场景并且正常退出因为LeakSanitizer是在退出阶段做最终扫描的。如果你用某种方式强杀进程或者程序本身因为其他错误崩溃退出报告可能就出不来了。3.4 修复与回归验证内存曲线拉平才算完定位到根因之后修复并不复杂。针对上面那个泄漏最简单的办法是给对话框设置父对象或者设置WA_DeleteOnClose属性二者选一个就好。我自己更推荐设置父对象因为这同时解决了生命周期管理和父子窗口的层级关系void MainWindow::openConfigDialog() { auto *dlg new ConfigDialog(this); dlg-setWindowModality(Qt::WindowModal); dlg-show(); }有了父对象主窗口析构时对话框会跟着释放对话框关闭默认只是隐藏但父对象在不会泄漏。改完后重新构建再跑一遍同样的固定动作序列这次用内存日志对比修复前每循环一次涨0.2MB循环两百次后Private Bytes涨了40MB修复后同样两百次循环Private Bytes几乎是一条直线稳定在某个平台值附近。到这一步这个问题的排查才算真正划上句号。4. 常见问题与排查技巧实录4.1 高频踩坑速查表跑了很多轮之后我把自己遇到过的坑整理成了一个速查表每次排查前先扫一眼能省下不少时间现象常见原因解决方案Dr. Memory启动即崩溃杀毒软件拦截插桩进程或程序路径含中文把exe和日志目录放到纯英文路径给Dr. Memory加白名单ASan报“ASan runtime does not come first”运行时加载顺序冲突CMake里加-static-libasan不行就换Dr. Memory任务管理器内存高但Private Bytes平稳工作集缓存波动用perfmon或打点日志看Private Bytes别盯工作集Debug能复现Release复现不了优化改变了对象的生命周期和调用时机先以Debug构建为主排查Release问题单独看业务逻辑Dr. Memory报一大堆Qt库内部泄漏Qt全局缓存、线程池退出时未清理只看调用栈指向自己源码的条目其余过滤改完一处泄漏内存还是涨内存增长往往是多个泄漏点叠加一次只修一个点修完立刻回归验证4.2 那些“看着像泄漏”但不是泄漏的隐蔽场景排查多了你会发现不是所有内存增长都能归咎于new了没delete。有一种情况特别迷惑就是Qt容器的隐式共享机制。看这段代码QByteArray fullData readLargeFile(); // 假设50MB QListQByteArray chunks; for (int i 0; i 1000; i) { chunks.append(fullData.left(100)); // left返回的只是“引用”背后共享fullData }你以为存了1000个100字节的切片总共才100KB可实际上每个切片都共享着底层那50MB的大缓冲区引用计数涨到了1001内存占用直接飙升50MB。这种增长很难被泄漏检测工具定性因为对象引用关系完全合法工具只会认为它们是“仍然可达”的内存。要发现这类问题靠的是对Qt容器语义的熟悉而不是单纯跑工具。还有一类是信号槽连接累积。往同一个信号上反复挂lambda槽每次连接都会造成闭包对象累积如果连接发生在循环或者高频刷新函数里内存和调用开销会同时上涨。这类问题靠工具也难定位代码审查时多留个心眼。4.3 用Git二分缩小引入范围当工具报告里什么都查不出来或者你怀疑是多处改动共同导致问题时Git二分是一个非常可靠的兜底手段。思路很简单先确认一个内存稳定、一个内存异常的两个历史版本然后用git bisect在中间翻找每次checkout一个中间版本重新构建跑固定动作序列读取内存日志里Private Bytes的峰值或增长斜率判定当前版本是“好”还是“坏”。我实际用的判定脚本思路不复杂就是启动程序循环跑固定动作N次结束后把日志里最后几个时间点的Private Bytes读出来如果比基线版本高过一定阈值就判为坏。每一步判定都自动化二分大概六七轮就能定位到具体某次提交。找到问题提交之后再结合提交信息里的改动文件往往很快就能锁定根源这比漫无目的地读代码高效得多。5. 经验沉淀一条更省时的排查路线这几轮排查下来我对工具和代码的关系有了更深的体会。工具只负责告诉你“内存是在哪里分配的”它不会告诉你“这个分配是不是多余的”。Dr. Memory和ASan能精确到文件行号但真正判断“该不该释放、该在什么时候释放”的还是你对对象生命周期的理解。所以我现在的排查路线是固定的先埋内存打点日志确认现象和复现条件再用Dr. Memory跑一轮粗定位随后用ASan做精细确认最后回到代码层面做生命周期审查修复后靠日志回归验证。如果是隐蔽的缓存膨胀或信号槽连接累积工具给不出结论时就切到代码审查加Git二分。最后再分享一个小技巧内存日志功能别等出问题再临时加平时就可以做成一个隐藏菜单项或环境变量开关线上版本也保留这个能力。出问题的时候你让现场同事开一下开关跑一段时间把日志发回来你就可以在家复现、定位、验证整个流程会顺畅非常多。这个习惯帮我省过不止一次远程救火的麻烦。
阅读完成 · 觉得有帮助？
