两种C++引用计数实现方法的效果对比及优劣分析

一、正确性完全等价 #

这两种实现都能安全、正确地完成线程环境下的引用计数管理，最终的内存同步效果完全一致。

引用计数的核心安全需求有两个：一是引用数的增减必须是原子操作，二是最后一个线程销毁对象时，必须能看到其他线程对该对象的所有修改——这两点两种方案都完美覆盖：

• 原子性：不管是relaxed还是acq_rel内存序，std::atomic_int的fetch_add/fetch_sub都能保证操作原子性，不会出现计数混乱的情况。
• 内存可见性：
  • 方案1中，fetch_sub用acq_rel语义：release保证当前线程之前对对象的所有写入都能被其他线程感知；acquire保证执行delete this时，能完整看到其他线程对该对象的所有修改。当返回值为1时，说明当前是最后一个引用，此时同步语义已经确保对象状态完整，销毁操作安全。
  • 方案2中，先执行无同步开销的relaxed递减，只有确认是最后一个引用（refcnt==0）时，才插入acquire栅栏。这个栅栏的作用和方案1中fetch_sub的acquire语义完全一致：确保后续销毁对象时，能看到其他线程的所有修改。而release语义的需求，因为只有当所有其他引用都释放完毕后才会触发销毁，此时其他线程的所有操作已经完成，栅栏足以保证同步，和方案1的效果等价。

二、优劣差异 #

1. 性能：方案2更优（多数场景） #

• 方案1的fetch_sub用acq_rel内存序，会限制CPU的指令重排序，在ARM、PowerPC这类弱内存模型架构下会产生额外的内存屏障开销；即使是x86这种强内存模型架构，也可能存在轻微的性能损耗。
• 方案2把同步开销延迟到了真正需要销毁对象的时候。大多数业务场景中，引用计数递减后不会触发销毁（refcnt>0），此时只需要一个无同步开销的relaxed操作；只有最后一次释放时才会执行栅栏，而这种场景占比极低，整体性能表现更优。

2. 可读性：方案1更直观 #

• 方案1的逻辑紧凑，同步语义直接绑定在原子操作上，一眼就能明白这个递减操作同时承担了同步职责，对不熟悉内存模型的开发者更友好。
• 方案2把原子操作和同步逻辑拆分，需要理解内存栅栏的作用才能理清整个同步流程，上手门槛相对更高。

3. 兼容性：二者无差异 #

两种实现都是标准C的合规写法，在所有支持C11及以上的编译器和硬件架构下都能正常工作，不存在兼容性问题。

内容的提问来源于stack exchange，提问作者Afshin