第1章 线程安全的对象生命期管理
编写线程安全的类不是难事，用同步原语(synchronization primitives)保护内部状态即可。但是对象的生与死不能由对象自身拥有的mutex（互斥器）来保护。如何避免对象析构时可能存在的race condition（竞态条件）是C++多线程编程面临的基本问题，可以借助Boost库中的shared_ptr和weak_ptr [注：在cpp11中这两个类已是标准库的一部分]完美解决。这也是实现线程安全的Observer模式的必备技术。
本章源自2009年12月我在上海祝成科技举办的C++技术大会的一场演讲《当析构函数遇到多线程》，读者应具有C++多线程编程经验，熟悉互斥器、竞态条件等概念，了解智能指针，知道Observer设计模式。
1.1 当析构函数遇到多线程
与其他面向对象语言不同，C++要求程序员自己管理对象的生命期，这在多线程环境下显得尤为困难。当一个对象能被多个线程同时看到时，那么对象的销毁时机就会变得模糊不清，可能出现多种竞态条件(race condition)：
● 在即将析构一个对象时，从何而知此刻是否有别的线程正在执行该对象的成员函数？
● 如何保证在执行成员函数期间，对象不会在另一个线程被析构？
● 在调用某个对象的成员函数之前，如何得知这个对象还活着？它的析构函数会不会碰巧执行到一半？
解决这些race condition是C++多线程编程面临的基本问题。本文试图以shared_ptr一劳永逸地解决这些问题，减轻C++多线程编程的精神负担。
1.1.1 线程安全的定义
依据[JCP]，一个线程安全的class应当满足以下三个条件：
● 多个线程同时访问时，其表现出正确的行为。
● 无论操作系统如何调度这些线程，无论这些线程的执行顺序如何交织(interleaving)。
● 调用端代码无须额外的同步或其他协调动作。
依据这个定义，C++标准库里的大多数class都不是线程安全的，包括std::string、std::vector、std::map等，因为这些class通常需要在外部加锁才能供多个线程同时访问。
1.1.2 MutexLock与MutexLockGuard
为了便于后文讨论，先约定两个工具类。我相信每个写C++多线程程序的人都实现过或使用过类似功能的类，代码见§ 2.4。
MutexLock封装临界区(critical section)，这是一个简单的资源类，用RAII手法[CCS，条款13]封装互斥器的创建与销毁。临界区在Windows上是struct CRITI-CAL_SECTION，是可重入的；在Linux下是pthread_mutex_t，默认是不可重入的[注：可重入与不可重入的讨论见§ 2.1.1]。MutexLock一般是别的class的数据成员。
MutexLockGuard封装临界区的进入和退出，即加锁和解锁。MutexLockGuard一般是个栈上对象，它的作用域刚好等于临界区域。
这两个class都不允许拷贝构造和赋值，它们的使用原则见§ 2.1。
1.1.3 一个线程安全的Counter示例
编写单个的线程安全的class不算太难，只需用同步原语保护其内部状态。例如下面这个简单的计数器类Counter：
// A thread-safe counter
class Counter : boost::noncopyable
{
// copy-ctor and assignment should be private by default for a class.
public:
Counter() : value_(0) {}
int64_t value() const;
int64_t getAndIncrease();private:
int64_t value_;
mutable MutexLock mutex_;
};int64_t Counter::value() const
{MutexLockGuard lock(mutex_); //lock 的析构会晚于返回对象的构造，return value_; //因此有效地保护了这个共享数据。
}int64_t Counter::getAndIncrease()
{MutexLockGuard lock(mutex_);int64_t ret = value_++;return ret;
}
// In a read word, atomic operations are preferred.
// 当然在实际项目中，这个class用原子操作更合理，这里用锁仅仅为了举例。这个class很直白，一看就明白，也容易验证它是线程安全的。每个Counter对象有自己的mutex_，因此不同对象之间不构成锁争用(lock contention)。即两个线程有可能同时执行L24，前提是它们访问的不是同一个Counter对象。注意到其mutex_成员是mutable的，意味着const成员函数如Counter::value()也能直接使用non-const的mutex_。思考：如果mutex_是static，是否影响正确性和/或性能？
尽管这个Counter本身毫无疑问是线程安全的，但如果Counter是动态创建的并通过指针来访问，前面提到的对象销毁的race condition(竞态条件)仍然存在。==>【1.1里提示的竞态条件】
--------------------------------------------分隔线-----------------------------------------------------
笔记：
静态成员性于类，并不属于对象
严重影响正确性，原因如下：
1. 锁的范围问题
cpp
// 如果mutex_是static，所有Counter实例共享同一个锁
Counter c1, c2, c3; // c1、c2、c3使用同一个mutex_2. 不必要的竞争
cpp
// 这些操作本应可以并行执行，现在却要串行执行
std::thread t1([&]() { c1.getAndIncrease(); }); // 锁住所有Counter
std::thread t2([&]() { c2.getAndIncrease(); }); // 被阻塞，等待同一个锁
std::thread t3([&]() { c3.getAndIncrease(); }); // 被阻塞，等待同一个锁3. 数据保护失效
静态mutex无法保护不同实例的value_成员，因为：
- 每个Counter实例有自己的
value_ - 但所有实例共享同一个锁
- 这违反了"一个锁保护一个数据"的原则
性能影响
⚠️ 严重的性能下降
- 虚假竞争：不同实例的操作本可并行，现在必须串行
- 锁竞争加剧：所有线程竞争同一个锁，而不是分散到不同实例的锁
- 可扩展性差：随着Counter实例增多，性能不会提升
正确的设计选择
实例级锁（当前设计）✅
cpp
class Counter : boost::noncopyable {
private:int64_t value_;mutable MutexLock mutex_; // 每个实例有自己的锁
};- 优点：不同实例操作可以并行
- 适用场景：多个Counter实例需要独立操作
静态锁的适用场景
cpp
class GlobalCounter {
private:static int64_t value_;static MutexLock mutex_; // 静态数据需要静态锁
};- 适用场景：保护真正的全局/静态共享数据
总结
不要将mutex_改为static，因为：
- 正确性：静态锁无法正确保护实例数据，违反了封装原则
- 性能：引入不必要的串行化，破坏并发性能
- 设计：混淆了实例数据保护和全局数据保护的界限
当前的非静态mutex设计是正确的，它为每个Counter实例提供了独立的同步机制。
--------------------------------------------分隔线------------------------------------------------------
1.2 对象的创建很简单
对象构造要做到线程安全，唯一的要求是在构造期间不要泄露this指针，即
● 不要在构造函数中注册任何回调；
● 也不要在构造函数中把this传给跨线程的对象；
● 即便在构造函数的最后一行也不行。
之所以这样规定，是因为在构造函数执行期间对象还没有完成初始化，如果this被泄露(escape)给了其他对象（其自身创建的子对象除外），那么别的线程有可能访问这个半成品对象，这会造成难以预料的后果。
//不要这么做(Don't do this.)
class Foo: public Observer //Observer的定义见第10页
{
public:Foo(Observable *s){s->register_(this); //错误，非线程安全}virtual void update();
};对象构造的正确方法：
//要这么做(Do this.)
class Foo: public Observer //Observer的定义见第10页
{
public:Foo()virtual void update();//另外定义一个函数，在构造之后执行回调函数的注册工作void observe(Observable *s){s->register_(this); }
};
Foo *pFoo = new Foo;
Observable *s = getSubject();
pFoo->observe(s); //二段式构造，或者直接写s->register_(pFoo);这也说明，二段式构造——即构造函数+initialize()——有时会是好办法，这虽然不符合C++教条，但是多线程下别无选择。另外，既然允许二段式构造，那么构造函数不必主动抛异常，调用方靠initialize()的返回值来判断对象是否构造成功，这能简化错误处理。
即使构造函数的最后一行也不要泄露this，因为Foo有可能是个基类，基类先于派生类构造，执行完Foo::Foo()的最后一行代码还会继续执行派生类的构造函数，这时most-derived class的对象还处于构造中，仍然不安全。
相对来说，对象的构造做到线程安全还是比较容易的，毕竟曝光少，回头率为零。而析构的线程安全就不那么简单，这也是本章关注的焦点。
1.3 销毁太难
对象析构，这在单线程里不构成问题，最多需要注意避免空悬指针和野指针[注：空悬指针(dangjling pointer)指向已经销毁的对象或已经回收的地址，野指针(wild pointer)指的是未经初始化的指针(http://en.wikipedia.or/wiki/Dangling_pointer)。]。而在多线程程序中，存在了太多的竞态条件。对一般成员函数而言，做到线程安全的办法是让它们顺次执行，而不要并发执行（关键是不要同时读写共享状态），也就是让每个成员函数的临界区不重叠。这是显而易见的，不过有一个隐含条件或许不是每个人都能立刻想到：成员函数用来保护临界区的互斥器本身必须是有效的。而析构函数破坏了这一假设，它会把mutex成员变量销毁掉。悲剧啊！
1.3.1 mutex不是办法
mutex只能保证函数一个接一个地执行，考虑下面的代码，它试图用互斥锁来保护析构函数：（注意代码中的(1)和(2)两处标记。）
Foo::~Foo()
{MutexLockGuard lock(mutex_);//free internal state (1)
}void Foo::update()
{MutexLockGuard lock(mutex_); // (2)//make use of internal state 使用内部状态
}
此时，有A、B两个线程都能看到Foo对象x，线程A即将销毁x，而线程B正准备调用x->update()。
尽管线程A在销毁对象之后把指针置为了NULL，尽管线程B在调用x的成员函数之前检查了指针x的值，但还是无法避免一种race condition：
1.线程A执行到了析构函数的(1)处，已经持有了互斥锁，即将继续往下执行。
2.线程B通过了if(x)检测，阻塞在(2)处。
接下来会发生什么，只有天晓得。因为析构函数会把mutex_销毁，那么(2)处有可能永远阻塞下去，有可能进入“临界区”，然后core dump，或者发生其他更糟糕的情况。
这个例子至少说明delete对象之后把指针置为NULL根本没用，如果一个程序要靠这个来防止二次释放，说明代码逻辑出了问题。
1.3.2 作为数据成员的mutex不能保护析构
前面的例子说明，作为class数据成员的MutexLock只能用于同步本class的其他数据成员的读和写，它不能保护安全地析构。因为MutexLock成员的生命期最多与对象一样长，而析构动作可说是发生在对象身故之后（或者身亡之时）。另外，对于基类对象，那么调用到基类析构函数的时候，派生类对象的那部分已经析构了，那么基类对象拥有的MutexLock不能保护整个析构过程。再说，析构过程本来也不需要保护，因为只有别的线程都访问不到这个对象时，析构才是安全的，否则会有§ 1.1谈到的竞态条件发生。
另外如果要同时读写一个class的两个对象，有潜在的死锁可能。比方说有swap()这个函数：
void swap(Counter& a, Counter& b)
{MutexLockGuard aLock(a.mutex_); //potential dead lock 潜在的死锁MutexLockGuard bLock(b.mutex_);int64_t value = a.value_;a.value_ = b.value_;b.value_ = value;如果线程A执行swap(a，b)；而同时线程B执行swap(b，a)；，就有可能死锁。operator=()也是类似的道理。
Counter& Counter::operator=(const Counter& rhs)
{if(this == &rhs)return *this;MutexLockGuard myLock(mutex_); //potential dead lock 潜在的死锁MutexLockGuard itsLock(rhs.mutex_);value_ = rhs.value_; //改成value_ = rhs.value()会死锁return *this;
}一个函数如果要锁住相同类型的多个对象，为了保证始终按相同的顺序加锁，我们可以比较mutex对象的地址，始终先加锁地址较小的mutex。
1.4 线程安全的Observer有多难
一个动态创建的对象是否还活着，光看指针是看不出来的（引用也一样看不出来）。指针就是指向了一块内存，这块内存上的对象如果已经销毁，那么就根本不能访问[CCS，条款99]（就像free(3)之后的地址不能访问一样），既然不能访问又如何知道对象的状态呢？换句话说，判断一个指针是不是合法指针没有高效的办法，这是C/C++指针问题的根源[注：在Java 中，一个reference 只要不为 null，它一定指向有效的对象]。（万一原址又创建了一个新的对象呢？再万一这个新的对象的类型异于老的对象呢？）
在面向对象程序设计中，对象的关系主要有三种：composition、aggregation、association。composition（组合/复合）关系在多线程里不会遇到什么麻烦，因为对象x的生命期由其唯一的拥有者owner控制，owner析构的时候会把x也析构掉。从形式上看，x是owner的直接数据成员，或者scoped_ptr成员，抑或owner持有的容器的元素。
后两种关系在C++里比较难办，处理不好就会造成内存泄漏或重复释放。association（关联/联系）是一种很宽泛的关系，它表示一个对象a用到了另一个对象b，调用了后者的成员函数。从代码形式上看，a持有b的指针（或引用），但是b的生命期不由a单独控制。aggregation（聚合）关系从形式上看与association相同，除了a和b有逻辑上的整体与部分关系。如果b是动态创建的并在整个程序结束前有可能被释放，那么就会出现§1.1谈到的竞态条件。
那么似乎一个简单的解决办法是：只创建不销毁。程序使用一个对象池来暂存用过的对象，下次申请新对象时，如果对象池里有存货，就重复利用现有的对象，否则就新建一个。对象用完了，不是直接释放掉，而是放回池子里。这个办法当然有其自身的很多缺点，但至少能避免访问失效对象的情况发生。
这种山寨办法的问题有：
● 对象池的线程安全，如何安全地、完整地把对象放回池子里，防止出现“部分放回”的竞态？（线程A认为对象x已经放回了，线程B认为对象x还活着。）
● 全局共享数据引发的lock contention，这个集中化的对象池会不会把多线程并发的操作串行化？
● 如果共享对象的类型不止一种，那么是重复实现对象池还是使用类模板？
● 会不会造成内存泄漏与分片？因为对象池占用的内存只增不减，而且多个对象池不能共享内存（想想为何）。
回到正题上来，如果对象x注册了任何非静态成员函数回调，那么必然在某处持有了指向x的指针，这就暴露在了race condition之下。
一个典型的场景是Observer模式（代码见recipes/thread/test/Observer.cc）。
class Observer // :boost::noncopyable
{
public:
virtual ~Observer();
virtual void update() = 0;
// ...
};class Observable
{
public:
void register_(Observer* x);
void unregister(Observer* x);void notifyObservers() {for (Observer* x : observers_) { //这行是c++x->update(); //(3)}
}
private:
std::vector<Observer*> observers_;
};当Observable通知每一个Observer时(L17)，它从何得知Observer对象x还活着？要不试试在Observer的析构函数里调用unregister()来解注册？恐难奏效。
23 class Observer
24 {
25 //同前
26 void observe(Observable *s) {
27 s->register_(this);
28 subject_ = s;
29 }
30
31 virtual ~Observer() {
32 subject_->unregister(this);
33 }
34
35 Observable *subject_;
36 };
我们试着让Observer的析构函数去调用unregister(this)，这里有两个race conditions。其一：L32如何得知subject_还活着？其二：就算subject_指向某个永久存在的对象，那么还是险象环生：
1.线程A执行到L32之前，还没有来得及unregister本对象。
2.线程B执行到L17，x正好指向是L32正在析构的对象。
这时悲剧又发生了，既然x所指的Observer对象正在析构，调用它的任何非静态成员函数都是不安全的，何况是虚函数[注：C++标准对在构造函数和析构函数中调用虚函数的行为有明确规定，但是没有考虑开发调用的情况]。更糟糕的是，Observer是个基类，执行到L32时，派生类对象已经析构掉了，这时候整个对象处于将死未死的状态，core dump恐怕是最幸运的结果。
这些race condition似乎可以通过加锁来解决，但在哪儿加锁，谁持有这些互斥锁，又似乎不是那么显而易见的。要是有什么活着的对象能帮帮我们就好了，它提供一个isAlive()之类的程序函数，告诉我们那个对象还在不在。可惜指针和引用都不是对象，它们是内建类型。
-------------------------------分隔线--------------------------------
笔记：
// recipes/thread/test/Observer.cpp #include <algorithm>
#include <vector>
#include <stdio.h>class Observable;class Observer
{
public:virtual ~Observer();virtual void update() = 0;void observe(Observable* s);
protected:Observable* subject_;
};class Observable
{
public:void register_(Observer* x);void unregister(Observer* x);void notifyObservers(){printf("notifyObservers========%d\n", observers_.size());for (Observer* x : observers_) { //这行是c++x->update(); //(3)}}
private:std::vector<Observer*> observers_;
};Observer::~Observer()
{subject_->unregister(this);
}void Observer::observe(Observable* s)
{s->register_(this);subject_ = s;
}void Observable::register_(Observer* x)
{observers_.push_back(x);
}void Observable::unregister(Observer* x)
{std::vector<Observer*>::iterator it = std::find(observers_.begin(), observers_.end(), x);if (it != observers_.end()){std::swap(*it, observers_.back());observers_.pop_back();}
}class Foo : public Observer
{virtual void update(){printf("Foo::update() %p\n", this);}
};
int main()
{Foo* p = new Foo;Observable subject;p->observe(&subject);subject.notifyObservers();delete p;subject.notifyObservers();return 0;
}
编译运行：
---------------------------------分险线-------------------------------
1.5 原始指针有何不妥
指向对象的原始指针(raw pointer)是坏的，尤其当暴露给别的线程时。Observable应当保存的不是原始的Observer＊，而是别的什么东西，能分辨Observer对象是否存活。类似地，如果Observer要在析构函数里解注册（这虽然不能解决前面提到的race condition，但是在析构函数里打扫战场还是应该的），那么subject_的类型也不能是原始的Observable＊。
有经验的C++程序员或许会想到用智能指针。没错，这是正道，但也没那么简单，有些关窍需要注意。这两处直接使用shared_ptr是不行的，会形成循环引用，直接造成资源泄漏。别着急，后文会一一讲到。
空悬指针
有两个指针p1和p2，指向堆上的同一个对象Object，p1和p2位于不同的线程中（图1-1的左图）。假设线程A通过p1指针将对象销毁了（尽管把p1置为了NULL），那p2就成了空悬指针（图1-1的右图）。这是一种典型的C/C++内存错误。
图1-1
要想安全地销毁对象，最好在别人（线程）都看不到的情况下，偷偷地做。（这正是垃圾回收的原理，所有人都用不到的东西一定是垃圾。）
一个“解决办法”
一个解决空悬指针的办法是，引入一层间接性，让p1和p2所指的对象永久有效。比如图1-2中的proxy对象，这个对象，持有一个指向Object的指针。（从C语言的角度，p1和p2都是二级指针。）
图1-2
当销毁Object之后，proxy对象继续存在，其值变为0（见图1-3）。而p2也没有变成空悬指针，它可以通过查看proxy的内容来判断Object是否还活着。
图1-3
要线程安全地释放Object也不是那么容易，race condition依旧存在。比如p2看第一眼的时候proxy不是零，正准备去调用Object的成员函数，期间对象已经被p1给销毁了。
问题在于，何时释放proxy指针呢？
一个更好的解决办法
为了安全地释放proxy，我们可以引入引用计数(reference counting)，再把p1和p2都从指针变成对象sp1和sp2。proxy现在有两个成员，指针和计数器。
1.一开始，有两个引用，计数值为2（见图1-4）。
图1-4
2.sp1析构了，引用计数的值减为1（见图1-5）。
图1-5
3.sp2也析构了，引用计数降为0，可以安全地销毁proxy和Object了（见图1-6）。
图1-6
慢着！这不正是引用计数型智能指针吗？
一个万能的解决方案
引入另外一层间接性(another layer of indirection)[注：https://en.wikipedia.org/wiki/Abstraction_layer]，用对象来管理共享资源（如果把Object看作资源的话），亦即handle/body惯用技法(idiom)。当然，编写线程安全、高效的引用计数handle的难度非凡，作为一名谦卑的程序员[注：参见Edsger W. Dijkstra 的著名演讲《The Humble Programmer 》https://www.cs.utexasedu/-EWD/transcriptions/EWD03xx/EWD340.html).]，用现成的库就行。万幸，C++的TR1标准库里提供了一对“神兵利器”，可助我们完美解决这个头疼的问题。
1.6 神器shared_ptr/weak_ptr
shared_ptr是引用计数型智能指针，在Boost和std::tr1里均提供，也被纳入C++11标准库，现代主流的C++编译器都能很好地支持。shared_ptr<T>是一个类模板(class template)，它只有一个类型参数，使用起来很方便。引用计数是自动化资源管理的常用手法，当引用计数降为0时，对象（资源）即被销毁。weak_ptr也是一个引用计数型智能指针，但是它不增加对象的引用次数，即弱(weak)引用。
shared_ptr的基本用法和语意请参考手册或教程，本书从略。谈几个关键点。
● shared_ptr控制对象的生命期。shared_ptr是强引用（想象成用铁丝绑住堆上的对象），只要有一个指向x对象的shared_ptr存在，该x对象就不会析构。当指向对象x的最后一个shared_ptr析构或reset()的时候，x保证会被销毁。
● weak_ptr不控制对象的生命期，但是它知道对象是否还活着（想象成用棉线轻轻拴住堆上的对象）。如果对象还活着，那么它可以提升(promote)为有效的shared_ptr；如果对象已经死了，提升会失败，返回一个空的shared_ptr。“提升/lock()”行为是线程安全的。
● shared_ptr/weak_ptr的“计数”在主流平台上是原子操作，没有用锁，性能不俗。
● shared_ptr/weak_ptr的线程安全级别与std：：string和STL容器一样，后面还会讲。
孟岩在《垃圾收集机制批判》[注:https://blog.csdn.net/myan/article/details/1906]中一针见血地点出智能指针的优势：“C++利用智能指针达成的效果是：一旦某对象不再被引用，系统刻不容缓，立刻回收内存。这通常发生在关键任务完成后的清理(clean up)时期，不会影响关键任务的实时性，同时，内存里所有的对象都是有用的，绝对没有垃圾空占内存。”
1.7 插曲：系统地避免各种指针错误
我同意孟岩说的[注:《Java替代C语言的可能性》（https://blog.csdn.net/myan/article/details/1482614）]“大部分用C写的上规模的软件都存在一些内存方面的错误，需要花费大量的精力和时间把产品稳定下来。”举例来说，就像Nginx这样成熟且广泛使用的C语言产品都会不时暴露出低级的内存错误[注:http://tracnginx.org/nginx/ticket/{134,135,162}]。内存方面的问题在C++里很容易解决，我第一次也是最后一次见到别人的代码里有内存泄漏是在2004年实习那会儿，我自己写的C++程序从来没有出现过内存方面的问题。C++里可能出现的内存问题大致有这么几个方面：
1.缓冲区溢出(buffer overrun)。
2.空悬指针/野指针。
3.重复释放(double delete)。
4.内存泄漏(memory leak)。
5.不配对的new[]/delete。
6.内存碎片(memory fragmentation)。
正确使用智能指针能很轻易地解决前面5个问题，解决第6个问题需要别的思路，我会在§ 9.2.1和§ A.1.8探讨。
1.缓冲区溢出：用std：：vector<char>/std：：string或自己编写Buffer class来管理缓冲区，自动记住可用缓冲区的长度，并通过成员函数而不是裸指针来修改缓冲区。
2.空悬指针/野指针：用shared_ptr/weak_ptr，这正是本章的主题。
3.重复释放：用scoped_ptr，只在对象析构的时候释放一次。
4.内存泄漏：用scoped_ptr，对象析构的时候自动释放内存。
5.不配对的new[]/delete：把new[]统统替换为std：：vector/scoped_array。
正确使用上面提到的这几种智能指针并不难，其难度大概比学习使用std::vector/std::list这些标准库组件还要小，与std::string差不多，只要花一周的时间去适应它，就能信手拈来。我认为，在现代的C++程序中一般不会出现delete语句，资源（包括复杂对象本身）都是通过对象（智能指针或容器）来管理的，不需要程序员还为此操心。
在这几种错误里边，内存泄漏相对危害性较小，因为它只是借了东西不归还，程序功能在一段时间内还算正常。其他如缓冲区溢出或重复释放等致命错误可能会造成安全性（security和data safety）方面的严重后果。
需要注意一点：scoped_ptr/shared_ptr/weak_ptr都是值语义，要么是栈上对象，或是其他对象的直接数据成员，或是标准库容器里的元素。几乎不会有下面这种用法：
shared_ptr<Foo>＊pFoo=new shared_ptr<Foo>(new Foo)；//WRONG semantic
还要注意，如果这几种智能指针是对象x的数据成员，而它的模板参数T是个incomplete类型，那么x的析构函数不能是默认的或内联的，必须在.cpp文件里边显式定义，否则会有编译错或运行错（原因见§ 10.3.2）。
1.8 应用到Observer上
既然通过weak_ptr能探查对象的生死，那么Observer模式的竞态条件就很容易解决，只要让Observable保存weak_ptr<Observer>即可：
39 class Observable //not 100% thread safe!
40 {
41 public:
42 void register_(weak_ptr<Observer> x); //参数类型可用const weak_ptr<Observer>&
43 //void unregister(weak_ptr<Observer> x); //不需要它
44 void notifyObservers();
45
46 private:
47 mutable MutexLock mutex_;
48 std::vector<weak_ptr<Observer>> observers_;
49 typedef std::vector<weak_ptr<Observer>>::iterator Iterator;
50 };
51
52 void Observable::notifyObservers()
53 {
54 MutexLockGuard lock(mutex_);
55 Iterator it = observers_.begin(); //Iterator 的定义见第49行
56 while(it != observers_.end())
57 {
58 shared_ptr<Observer> obj(it->lock()); //尝试提升，这一步是线程安全的
59 if(obj)
60 {
61 //提升成功，现在引用计数值几乎总是大于等于（想想为什么？）
62 obj->update(); //没有况态条件，因为obj在栈上，对象不可能在本作用域内销毁
63 ++it;
64 }
65 else
66 {
67 //对象已经销毁，从容器中拿掉weak_ptr
68 it = observers_.erase(it);
69 }
70 }
71 }就这么简单。前文代码(3)处（p.10的L17）的竞态条件已经弥补了。思考：如果把L48改为vector<shared_ptr<Observer>>observers_；，会有什么后果？
解决了吗
把Observer＊替换为weak_ptr<Observer>部分解决了Observer模式的线程安全，但还有以下几个疑点。这些问题留到本章§ 1.14中去探讨，每个都是能解决的。
侵入性 强制要求Observer必须以shared_ptr来管理。
不是完全线程安全 Observer的析构函数会调用subject_->unregister(this)，万一subject_已经不复存在了呢？为了解决它，又要求Observable本身是用shared_ptr管理的，并且subject_多半是个weak_ptr<Observable>。
锁争用(lock contention) 即Observable的三个成员函数都用了互斥器来同步，这会造成register_()和unregister()等待notifyObservers()，而后者的执行时间是无上限的，因为它同步回调了用户提供的update()函数。我们希望register_()和unregister()的执行时间不会超过某个固定的上限，以免殃及无辜群众。
死锁 万一L62的update()虚函数中调用了(un)register呢？如果mutex_是不可重入的，那么会死锁；如果mutex_是可重入的，程序会面临迭代器失效（core dump是最好的结果），因为vector observers_在遍历期间被意外地修改了。这个问题乍看起来似乎没有解决办法，除非在文档里做要求。（一种办法是：用可重入的mutex_，把容器换为std::list，并把++it往前挪一行。）
我个人倾向于使用不可重入的mutex，例如Pthreads默认提供的那个，因为“要求mutex可重入”本身往往意味着设计上出了问题(§ 2.1.1)。Java的intrinsic lock是可重入的，因为要允许synchronized方法相互调用（派生类调用基类的同名synchronized方法），我觉得这也是无奈之举。
---------------------------分隔线----------------------------
笔记：
#include <algorithm>
#include <vector>
#include <stdio.h>
#include <mutex>
#include <boost/enable_shared_from_this.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/weak_ptr.hpp>using namespace std;class Observable;class Observer : public boost::enable_shared_from_this<Observer>
{public:virtual ~Observer();virtual void update() = 0;void observe(Observable* s);protected:Observable* subject_;
};class Observable
{public:void register_(boost::weak_ptr<Observer> x);// void unregister(boost::weak_ptr<Observer> x);void notifyObservers(){printf("notifyObservers------1----------%p\n", this);std::lock_guard<std::mutex> lock(mutex_);Iterator it = observers_.begin();printf("notifyObservers------2----------%p\n", this);while (it != observers_.end()){printf("notifyObservers------3----------%p\n", this);boost::shared_ptr<Observer> obj(it->lock());printf("notifyObservers------4------obj----%d\n", obj.get());if (obj){obj->update();++it;}else{printf("notifyObservers() erase\n");it = observers_.erase(it);}}}private:mutable std::mutex mutex_;std::vector<boost::weak_ptr<Observer> > observers_;typedef std::vector<boost::weak_ptr<Observer> >::iterator Iterator;
};Observer::~Observer()
{// subject_->unregister(this);
}void Observer::observe(Observable* s)
{s->register_(shared_from_this());subject_ = s;
}void Observable::register_(boost::weak_ptr<Observer> x)
{observers_.push_back(x);
}//void Observable::unregister(boost::weak_ptr<Observer> x)
//{
// Iterator it = std::find(observers_.begin(), observers_.end(), x);
// observers_.erase(it);
//}// ---------------------class Foo : public Observer
{virtual void update(){printf("Foo::update() %p\n", this);}
};int main()
{Observable subject;{boost::shared_ptr<Foo> p(new Foo);p->observe(&subject);subject.notifyObservers();}subject.notifyObservers();
}编译运行：
--------------------------------------分隔线--------------------------------
1.9 再论shared_ptr的线程安全
虽然我们借shared_ptr来实现线程安全的对象释放，但是shared_ptr本身不是100%线程安全的。它的引用计数本身是安全且无锁的，但对象的读写则不是，因为shared_ptr有两个数据成员，读写操作不能原子化。根据文档[注:https://www.boost.org/doc/libs/latest/libs/smart_ptr/doc/html/smart_ptr.html#shared_ptr_thread_safety]，shared_ptr的线程安全级别和内建类型、标准库容器、std::string一样，即：
● 一个shared_ptr对象实体可被多个线程同时读取；
● 两个shared_ptr对象实体可以被两个线程同时写入，“析构”算写操作；
● 如果要从多个线程读写同一个shared_ptr对象，那么需要加锁。
请注意，以上是shared_ptr对象本身的线程安全级别，不是它管理的对象的线程安全级别。
要在多个线程中同时访问同一个shared_ptr，正确的做法是用mutex保护：
MutexLock mutex; //No need for ReaderWriterLock
shared_ptr<Foo> globalPtr;//我们的任务是把globalPtr安全地传给doit()
void doit(const shared_ptr<Foo> &pFoo);globalPtr能被多个线程看到，那么它的读写需要加锁。注意我们不必用读写锁，而只用最简单的互斥锁，这是为了性能考虑。因为临界区非常小，用互斥锁也不会阻塞并发读。
为了拷贝globalPtr，需要在读取它的时候加锁，即：
void read()
{shared_ptr<Foo> localPtr;{MutexLockGuard lock(mutex);localPtr = globalPtr; //read globalPtr }// use localPtr since here, 读写localPtr也无须加锁doit(localPtr);
}写入的时候也要加锁：
void write()
{shared_ptr<Foo> newPtr(new Foo); //注意，对象的创建在临界区之外{MutexLockGuard lock(mutex);globalPtr = newPtr; // write to globalPtr}//use newPtr since here,. newPtr 无须加锁doit(newPtr);
}注意到上面的read()和write()在临界区之外都没有再访问globalPtr，而是用了一个指向同一Foo对象的栈上shared_ptr local copy。下面会谈到，只要有这样的local copy存在，shared_ptr作为函数参数传递时不必复制，用reference to const作为参数类型即可。另外注意到上面的new Foo是在临界区之外执行的，这种写法通常比在临界区内写globalPtr.reset(new Foo)要好，因为缩短了临界区长度。如果要销毁对象，我们固然可以在临界区内执行globalPtr.reset()，但是这样往往会让对象析构发生在临界区以内，增加了临界区的长度。一种改进办法是像上面一样定义一个localPtr，用它在临界区内与globalPtr交换（swap()），这样能保证把对象的销毁推迟到临界区之外。练习：在write()函数中，globalPtr=newPtr；这一句有可能会在临界区内销毁原来globalPtr指向的Foo对象，设法将销毁行为移出临界区。
1.10 shared_ptr技术与陷阱
意外延长对象的生命期 shared_ptr是强引用（“铁丝”绑的），只要有一个指向x对象的shared_ptr存在，该对象就不会析构。而shared_ptr又是允许拷贝构造和赋值的（否则引用计数就无意义了），如果不小心遗留了一个拷贝，那么对象就永世长存了。例如前面提到如果把p.16中L48 observers_的类型改为vector<shared_ptr<Observer>>，那么除非手动调用unregister()，否则Observer对象永远不会析构。即便它的析构函数会调用unregister()，但是不去unregister()就不会调用Observer的析构函数，这变成了鸡与蛋的问题。这也是Java内存泄漏的常见原因。
另外一个出错的可能是boost::bind，因为boost::bind会把实参拷贝一份，如果参数是个shared_ptr，那么对象的生命期就不会短于boost::function对象：
class Foo
{void doit();
};
shared_ptr<Foo> pFoo(new Foo);
boost::function<void()> func = boost::bind(&Foo::doit, pFoo); long life foo这里func对象持有了shared_ptr<Foo>的一份拷贝，有可能会在不经意间延长倒数第二行创建的Foo对象的生命期。
函数参数 因为要修改引用计数（而且拷贝的时候通常要加锁），shared_ptr的拷贝开销比拷贝原始指针要高，但是需要拷贝的时候并不多。多数情况下它可以以const reference方式传递，一个线程只需要在最外层函数有一个实体对象，之后都可以用const reference来使用这个shared_ptr。例如有几个函数都要用到Foo对象：
void save(const shared_ptr<Foo>& pFoo); //pass by const reference
void validateAccount(const Foo& foo);bool validate(const shared_ptr<Foo>& pFoo) //pass by const reference
{validateAccount(*pFoo);// ...
}那么在通常情况下，我们可以传常引用(pass by const reference)：
void onMessage(const string &msg)
{shared_ptr<Foo> pFoo(new Foo(msg)); //只要在最外层持有一个实体，安全不成问题if(validate(pFoo)) { //没有拷贝pFoosave(pFoo); //没有拷贝pFoo}
}遵照这个规则，基本上不会遇到反复拷贝shared_ptr导致的性能问题。另外由于pFoo是栈上对象，不可能被别的线程看到，那么读取始终是线程安全的。
析构动作在创建时被捕获 这是一个非常有用的特性，这意味着：
● 虚析构不再是必需的。
● shared_ptr<void>可以持有任何对象，而且能安全地释放。
● shared_ptr对象可以安全地跨越模块边界，比如从DLL里返回，而不会造成从模块A分配的内存在模块B里被释放这种错误。
● 二进制兼容性，即便Foo对象的大小变了，那么旧的客户代码仍然可以使用新的动态库，而无须重新编译。前提是Foo的头文件中不出现访问对象的成员的inline函数，并且Foo对象由动态库中的Factory构造，返回其shared_ptr。
● 析构动作可以定制。
最后这个特性的实现比较巧妙，因为shared_ptr<T>只有一个模板参数，而“析构行为”可以是函数指针、仿函数(functor)或者其他什么东西。这是泛型编程和面向对象编程的一次完美结合。有兴趣的读者可以参考Scott Meyers的文章[注:https://www.artima.com/articles/my-most-important-c-aha-momentsemeverem]。这个技术在后面的对象池中还会用到。
析构所在的线程 对象的析构是同步的，当最后一个指向x的shared_ptr离开其作用域的时候，x会同时在同一个线程析构。这个线程不一定是对象诞生的线程。这个特性是把双刃剑：如果对象的析构比较耗时，那么可能会拖慢关键线程的速度（如果最后一个shared_ptr引发的析构发生在关键线程）；同时，我们可以用一个单独的线程来专门做析构，通过一个BlockingQueue<shared_ptr<void>>把对象的析构都转移到那个专用线程，从而解放关键线程。
现成的RAII handle 我认为RAII（资源获取即初始化）是C++语言区别于其他所有编程语言的最重要的特性，一个不懂RAII的C++程序员不是一个合格的C++程序员。初学C++的教条是“new和delete要配对，new了之后要记着delete”；如果使用RAII [CCS，条款13]，要改成“每一个明确的资源配置动作（例如new）都应该在单一语句中执行，并在该语句中立刻将配置获得的资源交给handle对象（如shared_ptr），程序中一般不出现delete”。shared_ptr是管理共享资源的利器，需要注意避免循环引用，通常的做法是owner持有指向child的shared_ptr，child持有指向owner的weak_ptr。
1.11 对象池
假设有Stock类，代表一只股票的价格。每一只股票有一个唯一的字符串标识，比如Google的key是"NASDAQ：GOOG"，IBM是"NYSE：IBM"。Stock对象是个主动对象，它能不断获取新价格。为了节省系统资源，同一个程序里边每一只出现的股票只有一个Stock对象，如果多处用到同一只股票，那么Stock对象应该被共享。如果某一只股票没有再在任何地方用到，其对应的Stock对象应该析构，以释放资源，这隐含了“引用计数”。
为了达到上述要求，我们可以设计一个对象池StockFactory [注：recipes/thread/test/Factory.cc包含这里提到的各个版本]。它的接口很简单，根据key返回Stock对象。我们已经知道，在多线程程序中，既然对象可能被销毁，那么返回shared_ptr是合理的。自然地，我们写出如下代码（可惜是错的）。
// version 1: questionable code
class StockFactory: boost::noncopyable
{
public:shared_ptr<Stock> get(const string & key);
private:mutable MutexLock mutex_;std::map<string, shared_ptr<Stock>> stocks_;
};get()的逻辑很简单，如果在stocks_里找到了key，就返回stocks_[key]；否则新建一个Stock，并存入stocks_[key]。
细心的读者或许已经发现这里有一个问题，Stock对象永远不会被销毁，因为map里存的是shared_ptr，始终有“铁丝”绑着。那么或许应该仿照前面Observable那样存一个weak_ptr?比如
// // version 2: 数据成员修改为 std::map<string, weak_ptr<Stock>> stocks_;
shared_ptr<Stock> StockFactory::get(const string& key)
{shared_ptr<Stock> pStock;MutexLockGuard lock(mutex_);weak_ptr<Stock> &wkStock = stocks_[key]; //如果key不存在，会默认构造一个pStock = wkStock.lock(); //尝试把“棉线”提升为“铁丝”if(!pStock) {pStock.reset(new Stock(key));wkStock = pStock; //这里更新了stocks_[key],注意wkStock是个引用}return pStock;
}这么做固然Stock对象是销毁了，但是程序却出现了轻微的内存泄漏，为什么？
因为stocks_的大小只增不减，stocks_.size()是曾经存活过的Stock对象的总数，即便活的Stock对象数目降为0。或许有人认为这不算泄漏，因为内存并不是彻底遗失不能访问了，而是被某个标准库容器占用了。我认为这也算内存泄漏，毕竟是“战场”没有打扫干净。
其实，考虑到世界上的股票数目是有限的，这个内存不会一直泄漏下去，大不了把每只股票的对象都创建一遍，估计泄漏的内存也只有几兆字节。如果这是一个其他类型的对象池，对象的key的集合不是封闭的，内存就会一直泄漏下去。
解决的办法是，利用shared_ptr的定制析构功能。shared_ptr的构造函数可以有一个额外的模板类型参数，传入一个函数指针或仿函数d，在析构对象时执行d(ptr)，其中ptr是shared_ptr保存的对象指针。shared_ptr这么设计并不是多余的，因为反正要在创建对象时捕获释放动作，始终需要一个bridge。
template<class Y, class D> shared_ptr::shared_ptr(Y * p, D d);
template<class Y, class D> void shared_ptr::reset(Y * p, D d);那么我们可以利用这一点，在析构Stock对象的同时清理stocks_。
// version 3
class StockFactory: boost::noncopyable
{// 在get()中，将pStock.reset(new Stock(key)); 改为：// pStock.reset(new Stock(key), // boost::bind(&StockFactory::deleteStock, this, _1)); // ***
private:void deleteStock(Stock* stock){if(stock) {MutexLockGuard lock(mutex_);stocks_erase(stock->key());}delete stock; // sorry, I lied }// assuming StockFactory lives longer than all Stock's ...// ...这里我们向pStock.reset()传递了第二个参数，一个boost::function，让它在析构Stock＊p时调用本StockFactory对象的deleteStock成员函数。
警惕的读者可能已经发现问题，那就是我们把一个原始的StockFactory this指针保存在了boost::function里（＊＊＊处），这会有线程安全问题。如果这个StockFactory先于Stock对象析构，那么会core dump。正如Observer在析构函数里去调用Observable::unregister()，而那时Observable对象可能已经不存在了。当然这也是能解决的，要用到§ 1.11.2介绍的弱回调技术。
1.11.1 enable_shared_from_this
StockFactory::get()把原始指针this保存到了boost::function中（＊＊＊处），如果StockFactory的生命期比Stock短，那么Stock析构时去回调StockFactory::deleteStock就会core dump。似乎我们应该祭出惯用的shared_ptr大法来解决对象生命期问题，但是StockFactory::get()本身是个成员函数，如何获得一个指向当前对象的shared_ptr<StockFactory>对象呢？
有办法，用enable_shared_from_this。这是一个以其派生类为模板类型实参的基类模板[注:https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern]，继承它，this指针就能变身为shared_ptr。
class StockFactory: public boost::enable_shared_from_this<StockFactory>,boost::noncopyable
{ /* ... */ };为了使用shared_from_this()，StockFactory不能是stack object，必须是heap object且由shared_ptr管理其生命期，即：
shared_ptr<StockFactory> stockFactory(new StockFactory)；
万事俱备，可以让this摇身一变，化为shared_ptr<StockFactory>了。
// version 4
shared_ptr<Stock> StockFactory::get(const string& key)
{// change // pStock.reset(new Stock(key),// boost::bind(&StockFactory::deleteStock, this, _1));// to pStock.reset(new Stock(key),boost::bind(&StockFactory::deleteStock, shared_from_this(),_1));// ...这样一来，boost::function里保存了一份shared_ptr<StockFactory>，可以保证调用StockFactory::deleteStock的时候那个StockFactory对象还活着。
注意一点，shared_from_this()不能在构造函数里调用，因为在构造StockFac-tory的时候，它还没有被交给shared_ptr接管。
最后一个问题，StockFactory的生命期似乎被意外延长了。
1.11.2 弱回调
把shared_ptr绑(boost::bind)到boost: function里，那么回调的时候StockFactory对象始终存在，是安全的。这同时也延长了对象的生命期，使之不短于绑得的boost：function对象。
有时候我们需要“如果对象还活着，就调用它的成员函数，否则忽略之”的语意，就像Observable::notifyObservers()那样，我称之为“弱回调”。这也是可以实现的，利用weak_ptr，我们可以把weak_ptr绑到boost::function里，这样对象的生命期就不会被延长。然后在回调的时候先尝试提升为shared_ptr，如果提升成功，说明接受回调的对象还健在，那么就执行回调；如果提升失败，就不必劳神了。
使用这一技术的完整StockFactory代码如下：
class StockFactory: public boost::enable_shared_from_this<StockFactory>,boost::noncopyable
{
public:shared_ptr<Stock> get(const string& key){shared_ptr<Stock> pStock;MutexLockGuard lock(mutex_);weak_ptr<Stock>& wkStock = stocks_[key]; // 注意wkStock是引用pStock = wkStock.lock();if(!pStock){pStock.reset(new Stock(key),boost::bind(@StockFactory::weakDeleteCallback,boost::weak_ptr<StockFactory>(shared_from_this()),_1));// 上面必须强制把shared_from_this()转型为weak_ptr,才不会延长生命期，// 因为boost::bind拷贝的是实参类型，不是形参类型wkStock = pStock;}return pStock;}
private:static void weakDeleteCallback(const boost::weak_ptr<StockFactory>& wkFactory,Stock* stock){shared_ptr<StockFactory> factory(wkFactory.lock()); //尝试提升if(factory) //如果factory还在，那就清理stocks_{factory->removeStock(stock);}delete stock; //sorry, I lied;}void removeStock(Stock* stock){if(stock){MutexLockGuard lock(mutex_);stocks_.erase(stock->key());}}
private:mutable MutexLock mutex_;std::map<string, weak_ptr<Stock>> stocks_;两个简单的测试：
void testLongLifeFactory()
{shared_ptr<StockFactory> factory(new StockFactory);{shared_ptr<Stock> stock = factory->get("NYSE:IBM");shared_ptr<Stock> stock2 = factory->get("NYSE:IBM");assert(stock == stock2);// stock destructs here}// factory destructs here
}void testShortLifeFactory()
{shared_ptr<Stock> stock;{shared_ptr<StockFactory> factory(new StockFactory);stock = factory->get("NYSE:IBM");shared_ptr<Stock> stock2 = factory->get("NYSE:IBM");assert(stock == stock2);// factory destructs here}// stock destructs here
} 这下完美了，无论Stock和StockFactory谁先挂掉都不会影响程序的正确运行。这里我们借助shared_ptr和weak_ptr完美地解决了两个对象相互引用的问题。
当然，通常Factory对象是个singleton，在程序正常运行期间不会销毁，这里只是为了展示弱回调技术[[注:通用的弱回调封装见recipe/thread/WeakCallback.h，用到了c++11的variadlic template和rvalue reference.]]，这个技术在事件通知中非常有用。
本节的StockFactory只有针对单个Stock对象的操作，如果程序需要遍历整个stocks_，稍不注意就会造成死锁或数据损坏(§ 2.1)，请参考§ 2.8的解决办法。
---------------------------分隔线----------------------------
笔记：
#include <map>#include <boost/bind.hpp>
#include <boost/enable_shared_from_this.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/weak_ptr.hpp>
#include <boost/noncopyable.hpp>
#include <assert.h>
#include <stdio.h>#include <mutex>using std::string;class Stock : boost::noncopyable
{public:Stock(const string& name): name_(name){printf(" Stock[%p] %s\n", this, name_.c_str());}~Stock(){printf("~Stock[%p] %s\n", this, name_.c_str());}const string& key() const { return name_; }private:string name_;
};namespace version1
{// questionable code
class StockFactory : boost::noncopyable
{public:boost::shared_ptr<Stock> get(const string& key){std::lock_guard<std::mutex> lock(mutex_);//muduo::MutexLockGuard lock(mutex_);boost::shared_ptr<Stock>& pStock = stocks_[key];if (!pStock){pStock.reset(new Stock(key));}return pStock;}private:mutable std::mutex mutex_;std::map<string, boost::shared_ptr<Stock> > stocks_;
};}namespace version2
{class StockFactory : boost::noncopyable
{public:boost::shared_ptr<Stock> get(const string& key){boost::shared_ptr<Stock> pStock;std::lock_guard<std::mutex> lock(mutex_);boost::weak_ptr<Stock>& wkStock = stocks_[key];pStock = wkStock.lock();if (!pStock){pStock.reset(new Stock(key));wkStock = pStock;}return pStock;}private:mutable std::mutex mutex_;std::map<string, boost::weak_ptr<Stock> > stocks_;
};}namespace version3
{class StockFactory : boost::noncopyable
{public:boost::shared_ptr<Stock> get(const string& key){boost::shared_ptr<Stock> pStock;std::lock_guard<std::mutex> lock(mutex_);boost::weak_ptr<Stock>& wkStock = stocks_[key];pStock = wkStock.lock();if (!pStock){pStock.reset(new Stock(key),boost::bind(&StockFactory::deleteStock, this, _1));wkStock = pStock;}return pStock;}private:void deleteStock(Stock* stock){printf("deleteStock[%p]\n", stock);if (stock){std::lock_guard<std::mutex> lock(mutex_);stocks_.erase(stock->key()); // This is wrong, see removeStock below for correct implementation.}delete stock; // sorry, I lied}mutable std::mutex mutex_;std::map<string, boost::weak_ptr<Stock> > stocks_;
};}namespace version4
{class StockFactory : public boost::enable_shared_from_this<StockFactory>,boost::noncopyable
{public:boost::shared_ptr<Stock> get(const string& key){boost::shared_ptr<Stock> pStock;std::lock_guard<std::mutex> lock(mutex_);boost::weak_ptr<Stock>& wkStock = stocks_[key];pStock = wkStock.lock();if (!pStock){pStock.reset(new Stock(key),boost::bind(&StockFactory::deleteStock,shared_from_this(),_1));wkStock = pStock;}return pStock;}private:void deleteStock(Stock* stock){printf("deleteStock[%p]\n", stock);if (stock){std::lock_guard<std::mutex> lock(mutex_);stocks_.erase(stock->key()); // This is wrong, see removeStock below for correct implementation.}delete stock; // sorry, I lied}mutable std::mutex mutex_;std::map<string, boost::weak_ptr<Stock> > stocks_;
};}class StockFactory : public boost::enable_shared_from_this<StockFactory>,boost::noncopyable
{public:boost::shared_ptr<Stock> get(const string& key){boost::shared_ptr<Stock> pStock;std::lock_guard<std::mutex> lock(mutex_);boost::weak_ptr<Stock>& wkStock = stocks_[key];pStock = wkStock.lock();if (!pStock){pStock.reset(new Stock(key),boost::bind(&StockFactory::weakDeleteCallback,boost::weak_ptr<StockFactory>(shared_from_this()),_1));wkStock = pStock;}return pStock;}private:static void weakDeleteCallback(const boost::weak_ptr<StockFactory>& wkFactory,Stock* stock){printf("weakDeleteStock[%p]\n", stock);boost::shared_ptr<StockFactory> factory(wkFactory.lock());if (factory){factory->removeStock(stock);}else{printf("factory died.\n");}delete stock; // sorry, I lied}void removeStock(Stock* stock){if (stock){std::lock_guard<std::mutex> lock(mutex_);auto it = stocks_.find(stock->key());if (it != stocks_.end() && it->second.expired()){stocks_.erase(stock->key());}}}private:mutable std::mutex mutex_;std::map<string, boost::weak_ptr<Stock> > stocks_;
};void testLongLifeFactory()
{boost::shared_ptr<StockFactory> factory(new StockFactory);{boost::shared_ptr<Stock> stock = factory->get("NYSE:IBM");boost::shared_ptr<Stock> stock2 = factory->get("NYSE:IBM");assert(stock == stock2);// stock destructs here}// factory destructs here
}void testShortLifeFactory()
{boost::shared_ptr<Stock> stock;{boost::shared_ptr<StockFactory> factory(new StockFactory);stock = factory->get("NYSE:IBM");boost::shared_ptr<Stock> stock2 = factory->get("NYSE:IBM");assert(stock == stock2);// factory destructs here}// stock destructs here
}int main()
{version1::StockFactory sf1;version2::StockFactory sf2;version3::StockFactory sf3;boost::shared_ptr<version3::StockFactory> sf4(new version3::StockFactory);boost::shared_ptr<StockFactory> sf5(new StockFactory);{boost::shared_ptr<Stock> s1 = sf1.get("stock1");}{boost::shared_ptr<Stock> s2 = sf2.get("stock2");}{boost::shared_ptr<Stock> s3 = sf3.get("stock3");}{boost::shared_ptr<Stock> s4 = sf4->get("stock4");}{boost::shared_ptr<Stock> s5 = sf5->get("stock5");}testLongLifeFactory();testShortLifeFactory();
}
编译运行：
---------------------------分险线----------------------------------
1.12 替代方案
除了使用shared_ptr/weak_ptr，要想在C++里做到线程安全的对象回调与析构，可能的办法有以下一些。
- 用一个全局的façade来代理Foo类型对象访问，所有的Foo对象回调和析构都通过这个façade来做，也就是把指针替换为objId/handle，每次要调用对象的成员函数的时候先check-out，用完之后再check-in [注:这是 Jeff Grossman 在《A technique for safe deletion with object locking》一文中提出的办法 [Gr00]]。这样理论上能避免race condition，但是代价很大。因为要想把这个façade做成线程安全的，那么必然要用互斥锁。这样一来，从两个线程访问两个不同的Foo对象也会用到同一个锁，让本来能够并行执行的函数变成了串行执行，没能发挥多核的优势。当然，可以像Java的ConcurrentHashMap那样用多个buckets，每个bucket分别加锁，以降低contention。
- § 1.4提到的“只创建不销毁”手法，实属无奈之举。
- 自己编写引用计数的智能指针[注：见http://blog.csdn.net/solstice/article/details/5238671#comments后面的评论。]。本质上是重新发明轮子，把shared_ptr实现一遍。正确实现线程安全的引用计数智能指针不是一件容易的事情，而高效的实现就更加困难。既然shared_ptr已经提供了完整的解决方案，那么似乎没有理由抗拒它。
- 将来在C++11里有unique_ptr，能避免引用计数的开销，或许能在某些场合替换shared_ptr。
其他语言怎么办
有垃圾回收就好办。Google的Go语言教程明确指出，没有垃圾回收的并发编程是困难的(Concurrency is hard without garbage collection)。但是由于指针算术的存在，在C/C++里实现全自动垃圾回收更加困难。而那些天生具备垃圾回收的语言在并发编程方面具有明显的优势，Java是目前支持并发编程最好的主流语言，它的util.concurrent库和内存模型是C++11效仿的对象。
1.13 心得与小结
学习多线程程序设计远远不是看看教程了解API怎么用那么简单，这最多“主要是为了读懂别人的代码，如果自己要写这类代码，必须专门花时间严肃、认真、系统地学习，严禁半桶水上阵”（孟岩）[注:孟岩《快速掌握一个语言最常用的50%》博客,这篇博客(https://blog.csdn.net/myan/article/details/3144661)的其他文字也很有趣味:“粗粗看看语法，就撸起袖子开干，边查Google 边学习”这种路子也有问题，在对于这种语言的脾气乘性还没有了解的情况下大刀阔斧地拼凑代码，写出来的东西肯定不入流。说穿新鞋走老路，新瓶装旧酒，那都是小问题，真正严重的是这样的程序员可以在短时间内堆积大量充满缺陷的垃圾代码。由于通常开发阶段的测试究备程度有限，这些垃圾代码往往能通过这个阶段，从而潜下来，在后期成为整个项目的“毒瘤”，反反复复让后来的维护者陷入西西弗斯困境。……其实真正写程序不怕究全不会，最怕一知半解地去攒解决方案。因为你完全不会，就自然会去认真查书学习，如果学习能力好的话,写出来的代码质量不会差。而一知半解，自己动手“土法炼钢”，那搞出来的基本上都是“废铜烂铁”。]。一般的多线程教程上都会提到要让加锁的区域足够小，这没错，问题是如何找出这样的区域并加锁，本章§ 1.9举的安全读写shared_ptr可算是一个例子。
据我所知，目前C++没有特别好的多线程领域专著，但C语言有，Java语言也有。《Java Concurrency in Practice》[JCP]是我读过的写得最好的书，内容足够新，可读性和可操作性俱佳。C++程序员反过来要向Java学习，多少有些讽刺。除了编程书，操作系统教材也是必读的，至少要完整地学习一本经典教材的相关章节，可从《操作系统设计与实现》、《现代操作系统》、《操作系统概念》任选一本，了解各种同步原语、临界区、竞态条件、死锁、典型的IPC问题等等，防止闭门造车。
分析可能出现的race condition不仅是多线程编程的基本功，也是设计分布式系统的基本功，需要反复历练，形成一定的思考范式，并积累一些经验教训，才能少犯错误。这是一个快速发展的领域，要不断吸收新知识，才不会落伍。单CPU时代的多线程编程经验到了多CPU时代不一定有效，因为多CPU能做到真正的并行执行，每个CPU看到的事件发生顺序不一定完全相同。正如狭义相对论所说的每个观察者都有自己的时钟，在不违反因果律的前提下，可能发生十分违反直觉的事情。
尽管本章通篇在讲如何安全地使用（包括析构）跨线程的对象，但我建议尽量减少使用跨线程的对象，我赞同水木网友ilovecpp说的：“用流水线，生产者消费者，任务队列这些有规律的机制，最低限度地共享数据。这是我所知最好的多线程编程的建议了。”
不用跨线程的对象，自然不会遇到本章描述的各种险态。如果迫不得已要用，希望本章内容能对你有帮助。
小结
● 原始指针暴露给多个线程往往会造成race condition或额外的簿记负担。
● 统一用shared_ptr/scoped_ptr来管理对象的生命期，在多线程中尤其重要。
● shared_ptr是值语意，当心意外延长对象的生命期。例如boost::bind和容器都可能拷贝shared_ptr。
● weak_ptr是shared_ptr的好搭档，可以用作弱回调、对象池等。
● 认真阅读一遍boost：：shared_ptr的文档，能学到很多东西：http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm
● 保持开放心态，留意更好的解决办法，比如C++11引入的unique_ptr。忘掉已被废弃的auto_ptr。
hared_ptr是TR1的一部分，即C++标准库的一部分，值得花一点时间去学习掌握[注：孟岩在《垃圾收集机制批判》中说:在C++中，new出来的对象没有 delete，这就导致了 memory leak。但是C++早就有了克股这一问题的办法-smart pointer。通过使用标准库里设计精致的各种 STL,容器还有例如 Boost库(差不多是个准标准库了)中的4个smart pointers，C++ 程序员只要花上一个星期的时间学习最新的资料，就可以拍着胸脯说:“我写的程序没有memory leak!”。]，对编写现代的C++程序有莫大的帮助。我个人的经验是，一周左右就能基本掌握各种用法与常见陷阱，比学STL还快。网络上有一些对shared_ptr的批评，那可以算作故意误用的例子，就好比故意访问失效的迭代器来证明std::vector不安全一样。
正确使用标准库（含shared_ptr）作为自动化的内存/资源管理器，解放大脑，从此告别内存错误。
1.14 Observer之谬
本章§ 1.8把shared_ptr/weak_ptr应用到Observer模式中，部分解决了其线程安全问题。我用Observer举例，因为这是一个广为人知的设计模式，但是它有本质的问题。
Observer模式的本质问题在于其面向对象的设计。换句话说，我认为正是面向对象(OO)本身造成了Observer的缺点。Observer是基类，这带来了非常强的耦合，强度仅次于友元(friend)。这种耦合不仅限制了成员函数的名字、参数、返回值，还限制了成员函数所属的类型（必须是Observer的派生类）。
Observer class是基类，这意味着如果Foo想要观察两个类型的事件（比如时钟和温度），需要使用多继承。这还不是最糟糕的，如果要重复观察同一类型的事件（比如1秒一次的心跳和30秒一次的自检），就要用到一些伎俩来work around，因为不能从一个Base class继承两次。
现在的语言一般可以绕过Observer模式的限制，比如Java可以用匿名内部类，Java 8用Closure，C＃用delegate，C++用boost::function/boost::bind [注:见S11.5“以 boost::function和 boost::bind取代虛丽数”,还有孟岩的《function/bind的救赎(上)》
https://blog.csdn.net/myan/article/details/5928531)。]。
在C++里为了替换Observer，可以用Signal/Slots，我指的不是QT那种靠语言扩展的实现，而是完全靠标准库实现的thread safe、race condition free、thread contention free的Signal/Slots，并且不强制要求shared_ptr来管理对象，也就是说完全解决了§ 1.8列出的Observer遗留问题。这会用到§ 2.8介绍的“借shared_ptr实现copy-on-write”技术。
在C++11中，借助variadic template，实现最简单(trivial)的一对多回调可谓不费吹灰之力，代码如下。
template<typename Signature>
class SignalTrivial;// NOT thread safe !!!
template <typename RET, typename... ARGS>
class SignalTrivial<RET(ARGS...)>
{
public:typedef std::function<void (ARGS...)> Functor;void connect(Functor&& func){functors_.push_back(std::forward<Functor>(func));}void call(ARGS&&... args){for(const Functor& f:functors_){f(args...);}}
private:std::vector<Functor> functors_;
};我们不难把以上基本实现扩展为线程安全的Signal/Slots，并且在Slot析构时自动unregister。有兴趣的读者可仔细阅读完整实现的代码(recipes/thread/SignalSlot.h)。
结语
《C++沉思录》（Ruminations on C++中文版）的附录是王曦和孟岩对作者夫妇二人的采访，在被问到“请给我们三个你们认为最重要的建议”时，Koenig和Moo的第一个建议是“避免使用指针”。我2003年读到这段时，理解不深，觉得固然使用指针容易造成内存方面的问题，但是完全不用也是做不到的，毕竟C++的多态要通过指针或引用来起效。6年之后重新拾起来，发现大师的观点何其深刻，不免掩卷长叹。
这本书详细地介绍了handle/body idiom，这是编写大型C++程序的必备技术，也是实现物理隔离的“法宝”，值得细读。目前来看，用shared_ptr来管理资源在国内C++界似乎并不是一种主流做法，很多人排斥智能指针，视其为“洪水猛兽”（这或许受了auto_ptr的垃圾设计的影响）。据我所知，很多C++项目还是手动管理内存和资源，因此我觉得有必要把我认为好的做法分享出来，让更多的人尝试并采纳。我觉得shared_ptr对于编写线程安全的C++程序是至关重要的，不然就得“土法炼钢”，自己“重新发明轮子[注:http://en.wikipedia.orgwiki/Reinventing_the_wheel]”。这让我想起了2001年前后STL刚刚传入国内，大家也是很犹豫，觉得它性能不高，使用不便，还不如自己造的容器类。10年过去了，现在STL已经是主流，大家也适应了迭代器、容器、算法、适配器、仿函数这些“新”名词、“新”技术，开始在项目中普遍使用（至少用vector代替数组嘛）。我希望，几年之后人们回头看本章内容，觉得“怎么讲的都是常识”，那我的写作目的也就达到了。