怎样从灾难性故障中，恢复一个长期运行、系统级的后台守护进程或服务，在如今的软件设计过程中，已成为了一个重要的考虑因素。当这些软件是由C 语言编成，并使用了引用计数的智能指针时，那么，智能指针的有效回收，对系统是否具备可伸缩级的恢复能力、甚至正确地继续未完成的操作来说，都显得至关重要。
在本文中，描述了一种方法，可从关机之后的软件恢复中，有效地回收引用计数指针，而且此方法在内存占用方面也很高效，这种方法的关键在于避免对象复制，而对象复制通常是由C 中指针引用的串行化和反串行化这种传统技术产生的。当从存档文档中反串行化时，本方法使用了标记(tag)来唯一地识别指针对象，且在系统恢复时由一个对象缓存来保存指针引用。
本文以一个基于事件的商业实时作业调度系统来进行演示，其通常由大型市场咨询公司使用，每天都会在集群工作站上处理数不胜数的计算任务。
为什么许多C 软件项目会使用自动内存管理技术呢，因为他有以下好处：
² 代码安全性。避免了太早释放一个对象所带来的风险。
² 代码正确性。避免了忘记释放未使用内存所带来的风险。
² 代码模块性。代码中不再需要点缀着和程式无关的簿记代码。
² 编程简单性。现在可假定一种无限内存的计算模式。
² 编程高效性。程式员不再担心内存管理问题。
引用计数智能指针，有时也称为“计数体术语”，是一种生命期受管的对象，其对引用他的数量，有一个内部的计数器。当内部引用计数为零时，这些对象会自动销毁自身，这是一种很有用的技术，已运用在许多C 软件产品项目中，因为简单易行，且无需对语言或编译器进行任何扩展。
引用计数智能指针能进一步定义为一体式或分离式，一体式智能指针把引用计数放在自身内，而分离式智能指针则把引用计数放在对象之外。在本文中，使用的是分离式智能指针方案，这需要在访问实际对象指针之前，在智能指针模板对象中重载 -> 或 * 操作符，从本质上来说，这也是代理(Proxy)设计模式的一个特例。
就现在来说，还没有一种方案以高效利用内存的方式描述了怎样恢复智能指针，而传统的C 对象串行和反串行化方法，会导致内存低效，因为当一个反串行化的对象碰到一个对他的引用时，总是会创建一个新对象，在最坏的情况下，这会把一个恢复后的守护进程的内存消耗量，推到一个无法接受的高度，致使他无法继续运行下去。
问题的引出
传统对象的串行和反串行化方案，也能实现智能指针，只但是在内存上比较低效而已。在这些传统方案中，当一个对象串行化时，对象内的成员指针被解引用，他的内容和对象一起“串行”进存档文档中。这种方法的问题在于，当反串行化时，成员指针会再次构造，且是每个恢复的对象都会这样。
下面以基于事件的作业调度系统来进行讲解，作业定义在CJobDef对象中，其包含了作业的静态属性，如他执行的命令、工作目录、及作业执行时的用户ID。而作业定义的运行实例则包装在CJobInst对象中，其包含了一些和实例有关的属性，如他的进程ID、执行参数、及运行历史记录。在类层次上，每个CJobInst对象都包含了一个成员，其引用到触发这次作业实例的原始CJobDef对象。
图1是软件停止运行之前的系统，运行时CJobInst对象的多个实例可能会引用至同一个CJobDef对象。在软件停止及恢复后，传统串行化对象恢复方法，会导致为每个运行的CJobInst对象，都创建一个CJobDef对象，如图2中所示。
图1：恢复之前的对象图
图2：内存低效恢复之后的对象图
引用计数指针是否能有效地回收，对系统意外关机之后数据的恢复来说至关重要，关键是要避免对象复制。
怎样从灾难性故障中，恢复一个长期运行、系统级的后台守护进程或服务，在如今的软件设计过程中，已成为了一个重要的考虑因素。当这些软件是由C 语言编成，并使用了引用计数的智能指针时，那么，智能指针的有效回收，对系统是否具备可伸缩级的恢复能力、甚至正确地继续未完成的操作来说，都显得至关重要。
[1] [2] [3] [4]
