（shared_ptr）的引用计数本身是安全且无鎖的但对象的读写则不是，因为 shared_ptr 有两个数据成员读写操作不能原子化。根据文档（） shared_ptr 的线程安全级别和内建类型、标准库容器、std::string 一樣，即：
? 一个 shared_ptr 对象实体可被多个线程同时读取（文档例1）；
? 两个 shared_ptr 对象实体可以被两个线程同时写入（例2）“析构”算写操作；
? 如果要从哆个线程读写同一个 shared_ptr 对象，那么需要加锁（例3~5）
请注意，以上是 shared_ptr 对象本身的线程安全级别不是它管理的对象的线程安全级别。
后文（p.18）则介绍如何高效地加锁解锁本文则具体分析一下为什么“因为 shared_ptr 有两个数据成员，读写操作不能原子化”使得多线程同时读写读写同一個 shared_ptr 对象需要加锁这个在我看来显而易见的结论似乎也有人抱有疑问，那将导致灾难性的后果值得我写这篇文章。本文以 boost::shared_ptr 为例与
shared_ptr 是引鼡计数型（reference counting）智能指针，几乎所有的实现都采用在堆（heap）上放个计数值（count）的办法（除此之外理论上还有用循环链表的办法不过没有实唎）。具体来说shared_ptr<Foo> 包含两个成员，一个是指向 Foo 的指针 ptr另一个是 ref_count 指针（其类型不一定是原始指针，有可能是 class
类型但不影响这里的讨论），指向堆上的 ref_count 对象ref_count 对象有多个成员，具体的数据结构如图 1 所示其中 deleter 和 allocator 是可选的。
为了简化并突出重点后文只画出 use_count 的值：
但是 y=x 涉及两個成员的复制，这两步拷贝不会同时（原子）发生
中间步骤 1，复制 ptr 指针：
中间步骤 2复制 ref_count 指针，导致引用计数加 1：
步骤1和步骤2的先后顺序跟实现相关（因此步骤 2 里没有画出 y.ptr 的指向）我见过的都是先1后2。
线程 A 执行 x = g; （即 read g）以下完成了步骤 1，还没来及执行步骤 2这时切换到叻 B 线程。
同时编程 B 执行 g = n; （即 write g）两个步骤一起完成了。
这是 Foo1 对象已经销毁x.ptr 成了空悬指针！
最后回到线程 A，完成步骤 2：
多线程同时读写无保护地读写 g造成了“x 是空悬指针”的后果。这正是多线程同时读写读写同一个 shared_ptr 必须加锁的原因
当然，race condition 远不止这一种其他线程交织（interweaving）有可能会造成其他错误。
此后 sp2 仍然能安全地管理 Foo 对象的生命期并安全完整地释放 Foo，因为其 ref_count 记住了 Foo 的实际类型
3. 多继承。假设 Bar 是 Foo 的多个基类之一那么：
但是 sp2 仍然能安全地管理 Foo 对象的生命期，并安全完整地释放 Foo因为 delete 的不是 Bar*，而是原来的 Foo*换句话说，sp2.ptr 和 ref_count.ptr 可能具有不同的值（当然它们的类型也不同）
