本章中，将实现一种在C++中不常见、但在许多其他语言(特别是带有集成垃圾收集器的语言)中普遍采用的做法：编写能够在程序执行的选定时刻，延迟销毁动态分配对象的机制。
我们不会编写一个真正的垃圾回收器(garbage collector)，那样会涉及对编译器内部机制的深度介入，并会改变 C++ 如此强大的编程模型。但会构建一些延迟回收(deferred reclamation)机制：在选定的时刻，有意识地将一些对象统一销毁，并释放它们所占用的内存空间，尽管不一定保证这些对象的销毁顺序。也不会详尽地介绍所有实现这类机制的技术，但希望为你(亲爱的读者)提供足够的启发和思路，使你在需要时能够构建自己的延迟回收机制。
本章介绍的技术可以与第 10 章中的技术结合使用，以提升程序性能并减少内存碎片。但为了使讨论更清晰，我们仍将延迟回收作为一个独立主题来讲解。在阅读完本章之后，你将能够：
理解延迟回收所涉及的权衡：确实能带来一些好处，但也伴随着一定的代价(绝不是银弹！)；
实现一个几乎透明的外部包装器(external wrapper)，用于追踪需要回收的内存；
实现一个几乎透明的外部包装器，用于帮助对延迟回收的对象进行最终销毁；
实现一个计数指针，类似于 std::shared_ptr 的引用计数机制，以便识别在某个选定作用域结束时可以被回收的对象。
我们迈出的第一步是尝试理解，一些延迟回收可以派上用场的问题领域，其中包括它与(虽不同但相似的)垃圾回收问题之间的关系。
在本章中，我们经常会使用“终结(finalization)”这个词，而不是“销毁(destruction)”，是想强调这样一个事实：在一个对象生命周期结束时执行的代码(也就是它的析构函数)与其底层内存的释放是两个不同的阶段。此外，“终结”这一术语在带有垃圾回收机制的语言中更为常见，而本章所讨论的技术与这些语言中的垃圾回收机制，在某种程度上是相关的。可以将“终结”(不涉及回收)理解为仅调用对象的析构函数，而不释放其底层内存。
正如本章前面所提到的那样，我们用“回收(reclamation)”来表示这样一个行为：在程序执行的某些特定时刻(例如作用域结束或程序结束时)，统一释放一个或多个对象所占用的内存。这个术语在 C++ 中并不常见，但在垃圾回收语言中使用频繁。由于本章所讨论的主题在某些方面与这些语言的做法相似，因此使用类似的术语，会有助于我们更好地理解其中涉及的技术和思想。