c++oding="utf-8" ?>
shared_ptr::use_count() 返回当前强引用计数，类型为ptrdiff_t（c++17起），非线程安全，仅反映调用瞬时值；不包含weak_ptr计数，返回0表示该shared_ptr为空而非对象已销毁。
shared_ptr::use_count() 返回当前引用计数
直接调用 use_count() 成员函数即可拿到当前 shared_ptr 管理对象的强引用数量。它返回 long 类型（C++17 起为 ptrdiff_t），不是线程安全的快照，仅反映调用瞬间的值。
常见错误是误以为它能反映“总持有者数”——其实只统计强引用；弱引用（weak_ptr）不计入 use_count()，但会体现在 weak_ptr::use_count() 中（注意：这是 weak_ptr 自己的弱引用计数，不是所指对象的强引用数）。
- 多线程环境下，
use_count()的结果可能在返回后立即失效，不能用于同步逻辑 - 调试时打印
ptr.use_count()是排查循环引用或提前释放的常用手段 - 若返回 0，说明该
shared_ptr本身已为空（ptr.get() == nullptr），不代表对象已被销毁
为什么不能用 get() + 自定义控制块访问计数
有人试图通过 get() 拿到原始指针，再反向查找控制块——这不可行。控制块内存布局未标准化，且与 shared_ptr 实例绑定，无法从裸指针安全推导。标准库明确禁止用户直接操作控制块。
典型翻车场景：在自定义删除器里读 use_count() 判断是否最后一个引用，结果因多线程竞争导致判断失准，引发重复释放或悬空访问。
- 控制块地址和结构随实现而异（libstdc++、libc++、MSVC 各不相同）
- 即使通过
shared_ptr的私有成员（如_M_ptr、_M_refcount）强行访问，属于未定义行为，编译器优化可能破坏其有效性 - 真正需要“最后一个引用”语义时，应改用
weak_ptr配合lock()+ 空检查，或设计无状态资源管理
use_count() 在循环引用检测中的实际用法
当怀疑两个 shared_ptr 相互持有导致内存泄漏时，use_count() 是最轻量的验证工具。关键看“预期为 1 却长期大于 1”的对象。
struct Node {
std::shared_ptr<node> next;
std::shared_ptr<node> parent; // 可能造成循环引用
};
auto a = std::make_shared<node>();
auto b = std::make_shared<node>();
a->next = b;
b->parent = a; // 此时 a.use_count() == 2, b.use_count() == 2
</node></node></node></node>
- 运行中定期检查关键对象的
use_count()，若脱离业务逻辑后仍不降为 1，高度提示循环引用 - 配合 AddressSanitizer 或 Valgrind 使用，比单纯看计数更可靠
- 注意：临时作用域内的拷贝（如传参、赋值）也会短暂抬高计数，需排除瞬时干扰
替代方案：用 weak_ptr 观察生命周期而非依赖计数
硬依赖 use_count() 往往暴露设计问题。更健壮的做法是把“谁还活着”这个判断交给 weak_ptr：
- 将可能形成环的一方改为
std::weak_ptr<t></t>，打破强引用链 - 使用前调用
lock()获取临时shared_ptr，失败即表示对象已销毁 -
weak_ptr::expired()等价于lock().get() == nullptr，开销略低但语义相同
真正难处理的是跨模块、隐式持有的场景——比如某个全局容器悄悄存了 shared_ptr，此时 use_count() 仍是唯一能快速定位“谁还拿着”的线索，只是别把它当成同步原语用。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
