std::shared_ptr比裸指针更安全，因其原子引用计数确保仅最后一个副本析构时释放内存，避免双重释放和悬空指针；但对象本身不自动线程安全，需避免多线程竞争同一shared_ptr实例。
std::shared_ptr 为什么比裸指针 + delete 更安全
裸指针在多线程中释放，最容易踩的坑是“双重释放”和“悬空指针访问”。比如两个线程同时判断 ptr != nullptr 后进入 delete ptr，结果第二次 delete 触发未定义行为。而 std::shared_ptr 用原子引用计数保证释放时机：只有最后一个副本析构时才调用 delete，且该操作本身是原子的。
注意三点：
-
std::shared_ptr的引用计数操作默认是线程安全的（C++11 起强制要求），但指向的对象本身不自动线程安全 - 避免从不同线程对同一个
std::shared_ptr实例做拷贝或赋值——这会竞争内部控制块；应确保每个线程持有独立副本 - 若对象构造/析构涉及复杂逻辑，仍需在析构函数内加锁保护共享资源，
std::shared_ptr不替你管这个
std::unique_ptr 在多线程里能直接 move 吗
可以，但必须满足一个前提：不能跨线程共享同一 std::unique_ptr 对象。它的所有权是排他的，move 操作本身不是原子的，所以如果你试图在两个线程里对同一个 std::unique_ptr 变量调用 std::move，就是数据竞争。
正确做法是：
- 在线程 A 中完成
std::move(ptr)后，立刻置为nullptr或不再访问 - 把 moved 出去的
std::unique_ptr通过线程安全方式（如std::queue+std::mutex）传递给线程 B - 线程 B 接收后拥有唯一所有权，析构时自动调用
delete—— 这个过程无需额外同步
内存池里的 free() 为什么不能直接调用 ::free
内存池的 free() 不是归还给操作系统，而是把内存块插回空闲链表供复用。如果误调 ::free(ptr)，会导致：
- 后续从池中分配出这块内存时，实际指向已释放区域，引发段错误或静默数据损坏
- 池管理器维护的元数据（如块头、前后指针）被系统回收逻辑破坏
- 整个池的空闲链表断裂，部分内存永久不可用
典型错误写法：pool.free(ptr); ::free(ptr); —— 第二行绝对多余且危险。正确释放只走池内逻辑，比如 free_list.push(ptr)。
异常发生时，锁没释放怎么办
最常见场景：持有 std::mutex 期间抛出异常，导致锁未释放，其他线程永久阻塞。根本解法不是 try-catch，而是 RAII：用 std::lock_guard 或 std::unique_lock，它们在栈展开时自动析构并解锁。
别这么写：
mtx.lock(); do_something_that_might_throw(); // 异常了，mtx.unlock() 永远不执行 mtx.unlock();
要这么写：
{ // 作用域开始
std::lock_guard<:mutex> lock(mtx);
do_something_that_might_throw(); // 异常？lock 析构自动 unlock
} // 作用域结束，lock 自动销毁</:mutex>
这点容易被忽略：即使函数里有多个 return 或提前退出路径，std::lock_guard 也始终可靠。手动 lock/unlock 是多线程里最隐蔽的死锁源头之一。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
