1.12 替代方案

除了使用shared_ptr/weak_ptr，要想在C++(www.cppentry.com) 里做到线程安全的对象回调与析构，可能的办法有以下一些。

1. 用一个全局的fa.ade 来代理Foo 类型对象访问，所有的Foo 对象回调和析构都通过这个fa.ade 来做，也就是把指针替换为objId/handle，每次要调用对象的成员函数的时候先check-out，用完之后再check-in 16。这样理论上能避免racecondition，但是代价很大。因为要想把这个fa.ade 做成线程安全的，那么必然要用互斥锁。这样一来，从两个线程访问两个不同的Foo 对象也会用到同一个锁，让本来能够并行执行的函数变成了串行执行，没能发挥多核的优势。当然，可以像Java 的ConcurrentHashMap 那样用多个buckets，每个bucket 分别加锁，以降低contention。

2. §1.4 提到的“只创建不销毁”手法，实属无奈之举。

3. 自己编写引用计数的智能指针17。本质上是重新发明轮子，把shared_ptr 实现一遍。正确实现线程安全的引用计数智能指针不是一件容易的事情，而高效的实现就更加困难。既然shared_ptr 已经提供了完整的解决方案，那么似乎没有理由抗拒它。

4. 将来在C++(www.cppentry.com)11 里有unique_ptr，能避免引用计数的开销，或许能在某些场合替换shared_ptr。

其他语言怎么办

有垃圾回收就好办。Google 的Go 语言教程明确指出，没有垃圾回收的并发编程(www.cppentry.com)是困难的（Concurrency is hard without garbage collection）。但是由于指针算术的存在，在C/C++(www.cppentry.com) 里实现全自动垃圾回收更加困难。而那些天生具备垃圾回收的语言在并发编程(www.cppentry.com)方面具有明显的优势，Java 是目前支持并发编程(www.cppentry.com)最好的主流语言，它的util.concurrent 库和内存模型是C++(www.cppentry.com)11 效仿的对象。