这事儿我太熟了——你遇到的情况其实是Valgrind的检测范围和OpenGL资源的存储方式导致的，和“后台垃圾回收”关系不大，具体来说有这几个核心原因：

1. Valgrind跟踪的是CPU侧标准内存，管不到GPU/驱动层面的资源 #

Valgrind的核心是监测C/C++程序在CPU堆、栈上的内存分配（比如malloc/free、new/delete），但OpenGL对象（着色器、纹理、缓冲区这些）的实际内存是存储在GPU显存或者显卡驱动内部维护的内存池里的。你调用glCreateShader拿到的只是一个句柄（整数ID），不是指向CPU内存的指针，Valgrind根本没法识别这个句柄对应的驱动侧内存分配，自然也就检测不到泄漏。

2. 程序退出时驱动会自动清理OpenGL资源 #

绝大多数OpenGL驱动都会在进程终止时自动回收该进程创建的所有OpenGL资源——毕竟操作系统会回收进程的所有关联资源，驱动也会跟着清理自己为这个进程管理的GPU内存。所以哪怕你完全不调用glDeleteShader，程序一结束，那些没释放的着色器资源就被驱动自动清掉了，Valgrind在进程退出后检查内存时，看不到残留的堆内存泄漏，也就不会报错。

怎么才能检测到这类OpenGL资源泄漏？ #

如果想排查OpenGL资源的泄漏，得用专门的工具：

• 启用OpenGL调试上下文，配合glDebugMessageCallback来跟踪每个对象的创建与销毁，能精准定位没释放的资源；
• 使用RenderDoc、APITrace这类工具，它们能记录完整的OpenGL调用流程，事后可以分析哪些对象创建后没被删除；
• 显卡厂商的调试工具，比如NVIDIA Nsight、AMD Radeon GPU Profiler，也能直接检测资源泄漏问题。

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