不能直接继承 std::enable_shared_from_this，因为它要求对象必须已由std::shared_ptr管理，否则调用shared_from_this()会抛std::bad_weak_ptr；它不支持裸指针构造时初始化引用计数，也不适用于栈对象或自定义分配器场景。
为什么不能直接继承 std::enable_shared_from_this
因为 std::enable_shared_from_this 要求对象必须已由 std::shared_ptr 管理，否则调用 shared_from_this() 会抛 std::bad_weak_ptr。它不提供裸指针构造时的引用计数初始化能力，也不支持栈对象或自定义分配器场景。侵入式基类要解决的正是“对象诞生即自带计数、不依赖外部智能指针构造”这一前提。
intrusive_ref_counter 的最小可行实现要点
核心是把引用计数内嵌为成员变量，并提供线程安全的原子增减（除非明确单线程场景）。不要用 int 或 std::atomic 简单累加——需保证释放时最后一次 release() 真正触发 delete this，且禁止拷贝构造/赋值。
- 继承必须为
public，否则派生类无法访问基类的add_ref()/release() - 析构函数必须为
protected：防止用户直接delete p，强制走release()路径 -
add_ref()和release()应声明为noexcept，避免异常中断计数逻辑 - 推荐用
std::atomic<:int32_t>，初值设为0；首次add_ref()设为1，而非构造时就 +1 —— 避免“构造完未被引用却已计数”的歧义
class intrusive_ref_counter {
protected:
mutable std::atomic<:int32_t> ref_count_{0};
<p>public:
intrusive_ref_counter() = default;
intrusive_ref_counter(const intrusive_ref_counter&) = delete;
intrusive_ref_counter& operator=(const intrusive_ref_counter&) = delete;</p>
<pre class="brush:php;toolbar:false;">void add_ref() const noexcept {
ref_count_.fetch_add(1, std::memory_order_relaxed);
}
void release() const noexcept {
if (ref_count_.fetch_sub(1, std::memory_order_acq_rel) == 1) {
delete this;
}
}
};
如何与裸指针配合实现类似 shared_ptr 的语义
关键不在基类本身，而在封装一层轻量指针包装器（非必须，但实用）。这个包装器只存裸指针 + 转发调用 add_ref()/release()，不管理内存布局、不带控制块，体积等于一个指针大小。
- 构造时调用
p->add_ref()，而非在构造函数里隐式增加——避免用户误用栈对象继承该基类 - 移动构造/赋值需置空原指针，否则可能 double
release() - 不要重载
operator==比较指针值：两个包装器指向同一对象时，它们的get()相等，但不应默认认为逻辑相等（除非业务明确需要） - 若需支持
dynamic_cast，基类必须有虚函数（哪怕仅一个虚析构），否则多态转换失败
示例包装器片段：
template <typename t>
class intrusive_ptr {
T* ptr_ = nullptr;
public:
explicit intrusive_ptr(T* p = nullptr) noexcept : ptr_(p) {
if (ptr_) ptr_->add_ref();
}
~intrusive_ptr() { if (ptr_) ptr_->release(); }
<pre class="brush:php;toolbar:false;">intrusive_ptr(const intrusive_ptr& rhs) noexcept : ptr_(rhs.ptr_) {
if (ptr_) ptr_->add_ref();
}
intrusive_ptr& operator=(const intrusive_ptr& rhs) noexcept {
if (ptr_ != rhs.ptr_) {
if (ptr_) ptr_->release();
ptr_ = rhs.ptr_;
if (ptr_) ptr_->add_ref();
}
return *this;
}
// ... 其余接口（get, operator-, reset 等）
};
容易被忽略的生命周期陷阱
侵入式计数最大的风险不是线程安全，而是“谁负责第一次 add_ref()”。如果对象通过 new 分配但没人调用 add_ref()，后续任意一次 release() 都会导致 ref_count_ == 0 时 delete this，而此时计数本应是 1。
- 永远不要让继承
intrusive_ref_counter的类被栈分配（除非你 100% 确保永不传给任何intrusive_ptr） - 工厂函数（如
create()）应返回intrusive_ptr，并在内部完成new T+add_ref()，而不是返回裸指针 - 回调中保存
intrusive_ptr时，注意循环引用：A 持有 B 的intrusive_ptr，B 又持有 A 的，两者将永不释放。此时需引入弱引用（如额外维护一个std::weak_ptr-like 计数，或改用非侵入式方案） - 多重继承下，若多个基类都含
intrusive_ref_counter，delete this会只析构最派生类，其余基类析构函数不执行——必须确保只有一个计数基类，且继承链清晰
真正难的从来不是写对那几行原子操作，而是让所有协作代码都遵守“裸指针诞生即绑定计数”的契约。一旦有人绕过包装器直接 delete，整个机制就失效了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
