Win10下C++程序Memory Commit Size持续增长的原因与排查方案

核心现象 #

• 程序属性：C++开发，运行于Windows 10系统，基于MFC实现多窗口、OpenGL完成渲染逻辑，属于图形与内存密集型应用，运行时需处理多路相机图像，存在大量实时数据拷贝操作
• 内存表现：任务管理器监测显示*Memory Commit Size（内存提交大小）随运行时间快速升高，但Working Set（工作集）*大小始终保持稳定；监测峰值下程序提交大小约37GB，位列进程列表首行
• 触发故障：程序连续运行10-15天左右，提交大小会耗尽系统包含分页文件在内的总可用提交内存，触发两类异常：
  • 程序直接崩溃退回桌面
  • 显示驱动与GPU断开连接，屏幕显示黑屏
• 已尝试方案：代码级内存泄漏排查、更新显卡驱动、升级Windows 10系统版本，均未解决问题

仅触发提交大小增长的泄漏类型 #

首先明确Windows内存统计逻辑：提交大小统计进程所有已向系统申请、系统承诺预留存储空间的内存总和，不管内存当前驻留在物理RAM还是被换出到分页文件；工作集仅统计当前驻留在物理RAM、可直接访问的内存部分。只要申请的内存长期不被访问，系统会自动将其换出到分页文件，从工作集统计中移除，就会出现“提交涨、工作集稳”的现象。
常规内存泄漏排查仅覆盖CRT堆上new/malloc分配的内存，结合程序技术栈与故障表现（会触发GPU驱动断连），查不到的泄漏基本属于以下几类常规工具无法覆盖的场景：

• GPU/驱动层资源泄漏
  这是OpenGL工业应用最高发的问题，所有用户态堆检测工具都无法扫描到驱动层维护的内存：
  • 未正确释放的OpenGL对象：包括纹理、VBO/PBO顶点/像素缓冲、FBO帧缓冲、渲染缓冲、着色器程序、显示列表等，每创建一个未释放的对象，驱动就会在进程提交内存中占用对应空间。这类资源如果创建后仅初始化写入一次，后续因逻辑bug未参与渲染，就会被系统换出到分页文件，完全不占用工作集。程序存在大量实时图像拷贝操作，PBO对象泄漏是最高发的诱因。
  • 相机SDK缓冲区泄漏：多数工业相机SDK取流时返回的帧缓冲区在内核/驱动层分配，必须调用SDK提供的专用接口释放，如果仅拷贝帧数据不释放缓冲区，这部分内存不会被常规堆检测工具识别，长期闲置就会被换出。
  • MFC GDI对象泄漏：创建的HBITMAP、HDC、兼容位图等GDI资源由内核态维护，若未调用DeleteObject/ReleaseDC释放，同样不会被用户态堆检测捕获，长期闲置会被换出到分页文件。
• 直接虚拟内存分配泄漏
  很多图像处理逻辑会直接调用VirtualAlloc提交大段内存做帧缓存，如果逻辑分支漏写VirtualFree、或指针被覆盖导致无法释放，这类内存不属于CRT堆管理范围，常规排查会漏。如果这类内存写入一次后再无访问，会被快速换出到分页文件，不会体现在工作集统计中。
• 内存映射对象泄漏
  为了实现大图像快速拷贝创建的内存映射文件（CreateFileMapping+MapViewOfFile），如果用完仅取消视图映射、未关闭文件映射句柄，或完全未做释放操作，这部分提交内存长期不访问也会被换出，同样不在常规堆检测范围内。
• 线程栈泄漏
  如果逻辑中反复动态创建工作线程（例如每路相机每帧创建一个处理线程），但未正确关闭线程句柄、也未保证线程正常退出，每个线程默认会提交初始栈空间，僵死线程的栈内存长期不访问会被换出，积少成多十几天累积到几十GB非常常见。

排查与防范方案 #

• 换用正确的排查工具，不要死磕用户态堆检测
  • 用微软Sysinternals套件中的VMMap定期抓取进程内存分布，直接定位持续增长的内存类型：是私有数据、堆、栈、映射文件还是驱动分配内存，快速缩小排查范围。
  • 开启OpenGL调试上下文，注册glDebugMessageCallback回调，全量日志记录所有GL对象的创建、销毁操作，统计每类对象的创建/释放数量是否匹配，重点核查PBO、纹理两类高频创建的对象。
  • 用GDIView定期统计进程GDI对象数量，确认是否随运行时间持续线性上涨，排查GDI资源泄漏。
  • 用Process Explorer监测进程句柄数、线程数变化，如果线程数持续上涨，优先排查线程创建/销毁逻辑。
• 从编码层面做强制防护，避免漏释放
  • 所有OpenGL资源、SDK资源、GDI资源、系统句柄全部用RAII类封装，构造时调用创建接口，析构时强制调用对应释放接口，禁止用裸变量持有资源ID/句柄，从语法层面避免逻辑分支漏释放。
  • 所有直接调用VirtualAlloc、CreateFileMapping等系统接口分配的内存，配套实现对应的释放逻辑，用智能指针自定义删除器封装，保证离开作用域必然释放。
  • 图像处理工作线程统一用固定大小的线程池调度，禁止动态反复创建/销毁线程；所有线程句柄用RAII包装，退出时确保线程正常终止再释放资源。
  • 增加内部埋点统计：每24小时打印一次当前持有的GL对象数量、GDI对象数量、线程数、帧缓存池大小，一旦某类指标持续线性上涨直接触发告警，不用等十几天内存耗尽崩了再排查。
• 增加兜底防护逻辑
  • 增加进程内存水位监测，当提交大小超过预设业务阈值时，主动触发闲置资源清理，释放所有缓存的历史帧、闲置PBO、临时纹理等资源。
  • 不要依赖驱动自动回收资源，程序退出前显式遍历所有已创建的GPU资源做释放，避免驱动残留引用导致的内存泄漏。

内容的提问来源于stack exchange，提问作者Chris