线程安全的对象生命期管理（六）

shared——ptr技术与陷阱

       1、意外延长对象的生命期   

                 shared_ptr是强引用，只要有一个指向x对象的shared_ptr存在，该对象就不会析构。而shared——ptr又是允许拷贝构造和赋值的（否则就不用引用计数了，scope_ptr..），但如果不小心遗留了一个拷贝没有释放，那么对象就会永久存在（内存泄漏）。这也是java内存泄漏的常见原因（这里就体现weak_ptr的作用了，同时可以升级）。

                 例如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);

                  函数参数

                         因为要修改引用计数（而且拷贝的时候需要加锁），shared_ptr的拷贝开销比拷贝原始指针要高，所以多数情况下可以以const reference方式传递，一个线程只需要在最外层函数有一个实体对象，之后都可以用const &来使用这个指针。

void save(const shared_ptr<Foo>& pFoo);
void validateAccount(const Foo& foo)
void onMessaged(const string& msg)
{
	shared_ptr<Foo> pFoo(new Foo(msg));
	if(validate(pFoo))
		save(pFoo);
}

                       由于pFoo是栈上对象，不可能被别的线程看到，那么读取始终是线程安全的。（尽量避免出现跨线程的对象，从根本上解决问题）。

                析构动作在创建时被捕获

                        这意味着：

                                虚析构不再是必需的。

                                shared_ptr<void>可以持有任何对象，而且能安全的释放。

                                shared_ptr对象可以安全地跨越模块边界，比如从DLL里返回，而不会造成从模块A分配地内存在模块B里被释放这种错误（加了中间层管理，几乎无需担心本身的问题，只要中间层管理恰当）。
                                二进制兼容性，即便Foo的对象的大小变了，那么动态库代码无须改变。前提是Foo的头文件中不出现访问对象的成员的inline函数，并且Foo对象由动态库中的Factory构造，返回其shared_ptr。

                               析构动作可以定制

               析构所在的线程

                       析构shared_ptr所管理对象的线程不一定是对象诞生的线程。这个特性是把双刃剑：如果对象的析构比较耗时，那么可能会拖慢关键线程的速度（析构线程就是关键线程）；为了解决这个问题，我们可以把析构分离出来，用一个专门线程做析构。

                现成的RAII handle 

                        RAII（资源获取即初始化）是C++语言一个重要的特性，每一个明确的资源配置动作都应该在单一语句中执行，并在该语句中立刻将配置获得的资源交给handle对象，程序中一般不出现delete。