HANDLE泄漏表现为句柄数持续增长、Process Explorer显示大量未关闭句柄，最终导致API失败；应使用thread_local HandleGuard RAII封装，避免unique_ptr；IOCP中PerHandleData需在析构中CloseHandle；GDI/USER对象须线程内创建释放，禁跨线程传递。
Windows 下 HANDLE 泄漏的典型表现
程序运行时间越长，GetProcessHandleCount() 返回值持续上涨，任务管理器中“句柄数”列明显高于同类进程；用 Process Explorer 查看句柄表，发现大量重复的 Event、Mutex、Thread 或 IoCompletionPort 类型句柄未关闭。这类泄漏不直接表现为内存增长，但最终会触发 ERROR_TOO_MANY_OPEN_FILES 或导致 CreateThread、CreateEvent 等 API 返回 NULL。
thread_local + RAII 封装 HANDLE 的正确姿势
不能只靠 std::thread 析构或 join() 保证资源释放——线程异常退出、std::terminate 或未调用 detach() 前就 return，都会跳过栈上对象析构。必须把 HANDLE 生命周期和 RAII 对象强绑定，并确保它在任何退出路径下都执行 CloseHandle()：
- 用
struct HandleGuard { HANDLE h; ~HandleGuard() { if (h && h != INVALID_HANDLE_VALUE) CloseHandle(h); } };包裹所有裸 HANDLE - 避免
thread_local std::unique_ptr<handleguard></handleguard>——std::unique_ptr的析构函数可能在 TLS 销毁阶段被跳过（尤其 Windows 上 CRT 的 TLS 清理顺序不可靠） - 改用
thread_local HandleGuard原生对象，构造时传入 HANDLE，析构由编译器保证调用（即使线程因异常终止，TLS 对象仍会按逆序析构） - 若需延迟初始化，用
thread_local static std::aligned_storage_t<sizeof alignof> storage;</sizeof>+ placement new，手动控制构造/析构时机
IOCP 场景中 PerHandleData 的泄漏陷阱
封装 IocpServer 类时，常把每个连接的 SOCKET 和关联的 OVERLAPPED、WSABUF 封装进 PerHandleData 结构体。但容易忽略：这些结构体本身是堆分配的，而其内部持有的 hEvent、hIocp 必须随结构体生命周期终结——否则 delete pPerHandleData 后 HANDLE 仍存活。
- 在
PerHandleData析构函数中显式调用CloseHandle(hEvent)、CloseHandle(hIocp)，不要依赖外部清理逻辑 - 避免在
OnAccept中仅new PerHandleData，却在OnDisconnect中只delete而不关 HANDLE - 若使用
std::shared_ptr<perhandledata></perhandledata>，确保其自定义 deleter 包含CloseHandle调用，而非仅delete - 用 Application Verifier 开启
Handle检查项，可捕获CloseHandle被遗漏或重复调用的场景
多线程下 GDI/USER 对象泄漏的定位难点
GDI 句柄（HBITMAP、HDC）和 USER 句柄（HWND、HMENU）不走 CloseHandle，且泄漏后不会立即报错，而是耗尽系统级配额（默认每进程 10000 个 GDI 对象）。更麻烦的是：它们的生命周期常跨线程——比如 UI 线程创建的 HDC 被 Worker 线程持有并忘记释放。
立即学习“C++免费学习笔记（深入）”；
- 禁止跨线程传递 GDI/USER 句柄，除非明确文档说明线程安全（
GetDC返回的HDC仅限调用线程使用） - 对
CWinThread派生类，重写ExitInstance()并遍历线程私有 GDI 资源池做清理（如缓存的CBitmap） - 用
GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS)在关键路径前后打点，快速定位泄漏发生段 - 注意 MFC 的
CClientDC、CPaintDC析构会自动ReleaseDC，但若在非 UI 线程构造它们，析构时调用ReleaseDC会失败且静默丢弃
CloseHandle，而是写了却在错误线程上下文中执行——这种问题在调试器里看不到崩溃，只会在用户连续打开关闭窗口几十次后才暴露。 
