裸指针无法实现强/弱引用计数，因其不携带生命周期信息、不能自动增减计数且无法区分强弱持有；必须通过外置控制块分离对象与计数逻辑，由strong_count决定对象生死、weak_count控制块释放。
为什么不能直接用裸指针实现强/弱引用计数
裸指针 int* 或 T* 本身不携带生命周期信息，无法自动增减引用计数，更无法区分“强持有”和“弱持有”。强行在外部维护一个全局计数器会破坏封装性，且无法解决多线程竞争、对象析构后指针悬挂等问题。真正可行的路径是模拟 std::shared_ptr 和 std::weak_ptr 的协作机制——即共用一个控制块（control block），由强引用数决定对象生死，弱引用数仅影响控制块自身释放。
控制块设计：必须分离对象与计数逻辑
控制块需同时保存：strong_count（当前强引用数）、weak_count（当前弱引用数，含自身）、指向托管对象的 T*，以及可选的自定义删除器。关键点在于：控制块必须动态分配，且其生命周期独立于托管对象——当 strong_count 降为 0 时销毁对象，但控制块要等到 weak_count 也归零才释放。
常见错误是把计数成员放在托管对象内部（intrusive），这要求用户类型必须继承或包含计数字段，丧失通用性；正确做法是让控制块完全外置，通过模板推导 T 并使用 new 分配足够内存容纳对象+控制块（或分开分配）。
示例结构简写：
template<typename t>
struct ControlBlock {
std::atomic<long> strong_count{1};
std::atomic<long> weak_count{1}; // 初始含自身
T* ptr;
void (*deleter)(T*) = [](T* p) { delete p; };
<pre class="brush:php;toolbar:false;">void add_strong() { ++strong_count; }
bool release_strong() { return --strong_count == 0; }
void add_weak() { ++weak_count; }
bool release_weak() { return --weak_count == 0; }
};
强引用指针类：构造/拷贝/赋值必须同步更新 strong_count
MySharedPtr 的每个操作都要保证原子性或临界区安全，尤其在多线程下。拷贝构造、拷贝赋值、移动构造、移动赋值、析构函数是五个核心入口点，必须统一处理计数变更和空指针边界。
- 构造时：分配控制块 → 放入对象指针 →
strong_count初始化为 1 - 拷贝构造/赋值：对源的控制块调用
add_strong()，再更新本地ptr和cb - 析构：若非空，调用
release_strong()；若返回 true，则调用deleter(ptr)，再对控制块调用release_weak() - 重载
operator->和operator*前必须检查ptr != nullptr，否则解引用空指针导致未定义行为
注意：不要在构造函数里抛异常后忘记清理已分配的控制块——建议用 try/catch 或 RAII 封装分配过程。
弱引用指针类：lock() 是唯一安全访问对象的方式
MyWeakPtr 不拥有对象，只持有指向控制块的指针。它的所有操作（构造、拷贝、赋值、析构）只影响 weak_count，绝不碰 strong_count。关键接口是 lock()：它尝试原子地将 strong_count 加 1，仅当加成功时才返回有效的 MySharedPtr；否则返回空 MySharedPtr。
典型陷阱：
- 直接暴露控制块里的
ptr给用户——这是悬挂指针温床，MyWeakPtr不能提供operator-> -
lock()返回的MySharedPtr生命周期未被延长？错：只要strong_count加成功，对象就一定还活着，该MySharedPtr能安全使用 - 没处理控制块为空的情况（如默认构造的
MyWeakPtr），lock()必须先判空再操作
简单 lock() 实现逻辑：
MySharedPtr<t> lock() const {
if (!cb) return MySharedPtr<t>();
long s = cb->strong_count.load();
while (s > 0) {
if (cb->strong_count.compare_exchange_weak(s, s + 1)) {
return MySharedPtr<t>(cb, cb->ptr); // 内部不增 weak_count
}
}
return MySharedPtr<t>(); // 对象已销毁
}
</t></t></t></t>
控制块的内存布局、原子操作粒度、线程安全边界、以及 weak_count 是否包含控制块自身，这几个地方稍有偏差就会引发双重释放或内存泄漏。别指望靠调试器一眼看出问题——得结合 ASan/TSan 验证，尤其是弱引用大量存在又频繁 lock() 的场景。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
