std::shared_ptr默认删除器不能直接传文件句柄，因其用delete释放而HANDLE/int fd需CloseHandle()/close()关闭；直接使用会导致句柄泄露、崩溃或未定义行为。
为什么 std::shared_ptr 默认删除器不能直接传文件句柄
因为 Windows 的 HANDLE（或 Unix 的 int fd）不是普通内存指针，std::shared_ptr 默认用 delete 释放，而 CloseHandle() / close() 才是正确释放方式。直接塞进去会导致句柄泄露，甚至程序崩溃。
常见错误现象：
– 程序运行一段时间后报错 ERROR_TOO_MANY_OPEN_FILES
– 跨线程访问时 INVALID_HANDLE_VALUE 或 EBADF
– ASan/Valgrind 报告“use after free”（其实是未定义行为）
- Windows 下必须用
CloseHandle()；Unix/Linux/macOS 必须用close() - 不能把
HANDLE当作裸指针传给std::shared_ptr<void>—— 它不持有资源语义，只管“析构时调用 delete” - 自定义删除器必须是可复制、无状态的函数对象（推荐 lambda 捕获空，或独立函数）
怎么写一个线程安全的句柄包装类
核心是：用 std::shared_ptr 持有句柄值本身（如 HANDLE），并绑定对应平台的关闭逻辑。注意句柄值是 POD 类型，不能直接 new，得用 std::make_shared 包一层，或用原始指针 + 自定义分配。
推荐做法（Windows 示例）：
立即学习“C++免费学习笔记（深入）”；
auto handle = CreateFile(L"test.txt", GENERIC_READ, 0, nullptr, OPEN_EXISTING, 0, nullptr);
if (handle == INVALID_HANDLE_VALUE) { /* ... */ }
<p>auto sp = std::shared_ptr<void>(
static_cast<void<em>>(handle), // 强转为 void</em> 避免类型擦除问题
[](void* h) { CloseHandle(static_cast<HANDLE>(h)); }
);
- Unix 版只需把
CloseHandle换成close，HANDLE换成int - 不要用
std::shared_ptr<HANDLE>—— 析构时会尝试delete一个栈变量地址 - 如果多个线程同时读取/复制
sp，没问题；但不要在多线程中并发调用CloseHandle同一个句柄 ——shared_ptr的引用计数是原子的，但句柄本身不是线程安全的“可重入关闭”
跨线程传递时容易漏掉的兼容性细节
句柄本身在 Windows 上默认不可继承，且多数句柄（如文件、事件）跨线程使用是 OK 的，但跨进程不行；Unix fd 默认是进程内共享的，线程间天然可用 —— 但要注意 fork() 后子进程是否需要保留。
- Windows 下若需跨进程传递，得用
DuplicateHandle()并设bInheritHandle=TRUE，再包装进shared_ptr - Linux 下若用了
O_CLOEXEC，fork()+exec后 fd 会自动关闭 —— 但shared_ptr不感知这个标志，别误以为“没关就是还活着” - 避免把句柄包装成
std::shared_ptr<std::FILE*>——fclose()是 C FILE* 的关闭方式，和底层 fd/HANDLE 不是一层，混用必出问题
性能与 RAII 边界在哪
每次复制 shared_ptr 都有原子引用计数开销，对高频短生命周期句柄（比如每毫秒开闭一次日志文件）不划算。此时应考虑局部作用域 RAII 类（如 ScopedHandle），而非共享语义。
- 真正需要“跨线程共享所有权”的场景其实不多：比如一个后台线程负责读，另一个负责写，且双方都可能触发关闭
- 若只是“主线程创建，子线程使用完即关”，用
std::move传unique_ptr更轻量 - 调试时可用
sp.use_count()观察是否意外延长了句柄生命周期 —— 值 >1 说明还有其他线程持有着
最常被忽略的是：句柄关闭后，shared_ptr 对象本身还能存在，但内部值已失效。别在析构器外再拿它去调 GetLastError() 或做条件判断。
