std::shared_ptr不能直接复刻，因其引用计数依赖独立分配的控制块（含ref_count、weak_count、删除器等），多个实例必须共享同一控制块；手写若仅用局部int会导致重复释放，且控制块需动态分配、生命周期独立于对象本身。
为什么 std::shared_ptr 不能直接复刻？
因为它的引用计数不是裸存的整数，而是和对象内存布局强耦合：控制块（control block）通常单独分配，同时管理引用计数、弱引用计数、删除器和自定义分配器。自己手写时若只在指针类里放一个 int，会立刻踩坑——多个 shared_ptr 指向同一对象但各自维护计数，析构时重复释放。
- 真正共享的必须是同一块控制内存，不是同一变量
- 控制块需支持多线程安全递增/递减（
std::atomic_int是底线） - 构造时若传入原始指针，控制块要和对象内存分离；若用
make_shared风格，则控制块和对象可合并分配（但实现更复杂）
最简可用版：单线程 + 分离控制块
先抛开线程安全和优化，聚焦引用计数逻辑本身。核心是让所有指向同一对象的智能指针，共享同一个控制块实例。
template<typename T>
class my_shared_ptr {
T* ptr_;
struct control_block {
int ref_count;
int weak_count;
T* obj;
control_block(T* p) : ref_count(1), weak_count(1), obj(p) {}
~control_block() { delete obj; }
};
control_block* cb_;
<p>public:
explicit my_shared<em>ptr(T* p = nullptr) : ptr</em>(p), cb_(p ? new control_block(p) : nullptr) {}</p><pre class='brush:php;toolbar:false;'>my_shared_ptr(const my_shared_ptr& other) : ptr_(other.ptr_), cb_(other.cb_) {
if (cb_) ++cb_->ref_count;
}
my_shared_ptr& operator=(const my_shared_ptr& other) {
if (this != &other) {
release();
ptr_ = other.ptr_;
cb_ = other.cb_;
if (cb_) ++cb_->ref_count;
}
return *this;
}
~my_shared_ptr() { release(); }private: void release() { if (cb && --cb->refcount == 0) { delete cb; } ptr = nullptr; cb = nullptr; } };
注意：control_block 必须动态分配，且生命周期独立于 T 对象本身；release() 中判空和原子操作缺失，仅适用于单线程场景。
reset() 和 swap() 容易漏掉控制块管理
这两个成员函数看似简单，但实际是引用计数逻辑的“压力测试点”。漏处理控制块，轻则内存泄漏，重则 double-delete。
立即学习“C++免费学习笔记（深入）”；
-
reset(T* p)必须先释放当前资源，再为新指针新建控制块（或复用已有） -
swap(my_shared_ptr& other)只交换ptr_和cb_，不碰计数——否则会破坏共享语义 - 尤其当
reset(nullptr)时，cb_的weak_count还可能非零（有weak_ptr存在），此时不能删控制块，只能减ref_count
为什么别急着加线程安全？
加 std::atomic_int 不等于线程安全。引用计数的原子性只是基础，真正难的是控制块生命周期与指针访问的竞态：比如一个线程刚读完 ptr_，另一个线程就执行了 reset() 并销毁了对象，前者后续解引用就 UB。
-
std::shared_ptr的线程安全模型很明确：多个shared_ptr实例可并发读/写，但对同一对象的非原子访问（如*ptr）仍需用户自己同步 - 手写时若盲目加
atomic却忽略load-acquire/store-release语义，可能在弱内存序平台（ARM、RISC-V）上出错 - 多数真实项目用
std::shared_ptr就够了；真要自研，优先保证正确性，再考虑性能和并发
控制块的内存布局、弱引用计数的触发时机、自定义删除器的存储方式——这些细节一旦选错，后面改起来比重写还疼。
