副标题#e#
C++号称是多范式的通用编程语言，可是RAII实际上已在C++编程技能中酿成 不行或缺的焦点技能。RAII险些无处不在的身影不只仅来自于C++之父的大力大举提 倡，更来自于这一技能自己的简朴，高效和险些无所不能的适应面。
如 果您还没有传闻过RAII的话，那么我在这里再从头论述一遍，RAII是下列英文短 语的首字母缩写：
Resource Acquisition Is Initialisation
这 句话直译为中文的意思是： 资源得到即初始化。这只是一个短语，不能指望靠 望文生义来相识字面背后的完整寄义，可是短语自己简直反应了重要的论点： 资源是其一，初始化是其二。
RAII 是有关资源的。资源是一切需要分派 的数量有限的资料。好比，存储器，文件句柄，网络套接字端口，数据库毗连， 以及线程池等。根基上，由于物理的限制，所有的资料都是有限的。在某些非凡 的环境下，资料由于局部的极大富厚而丧失了资源的意义，好比沙子，氛围等。 可是在大大都环境下，资料都是有限的，需要我们善加打点。
资源打点 的最根基形式就是善始善终。申请了资源，用完了，就要偿还。在C++措施员生 活里最常见的就是内存资源，资源打点就是内存打点： 申请了内存，不管什么 时候逻辑上完成了对这片内存的利用，内存就要被正确地释放。留意这里的用词 是"不管什么时候". 在实际应用中，内存的利用逻辑是如此巨大，使 得逻辑上界定某块内存的生命周期会成为很是繁琐很是巨大的任务，而内存资源 就会在人类智力的疏漏中泄漏出去。而纵然是简朴环境，内存也会在菜鸟措施员 惊慌失措的拙劣中溜走。所以资源打点固然可以简化为一句"有始有终 "，在实际傍边很难获得担保。
有 一类语言，好比Java，把内存资 源经受了，提供了所谓的自动内存打点，利用内存分派算法的方法为措施员模仿 了一个取之不尽用之不竭的准无穷内存模式。背后的思想是，在普通应用中，内 存的利用在空间和时间上都是相对会合的，这就答允用较少的内存来应付时间积 累上无限的内存请求。措施员利用这类语言就不消再思量内存的释放问题。承担 就大大减轻了。
自动内存打点从道理上把内存资源倍增而发生一种资料 （准）无限的虚拟情况，从而把措施员从沉重的内存资源打点上解放出来，化更 多的精神思量实际的事务代码，提高了出产率。可是它也有本身的范围。一，自 动内存打点算法较量巨大，自己的措施就要占必然内存，同时自动内存打点用时 间换空间，还要求实际物理内存至少为应用最大瞬时所需内存的两倍才气较好地 发挥浸染，这一要求说明，自动内存打点其实已经不是在打点短缺意义上的 "资源"，而是为不那么挥霍地利用富厚的资料提供一种说得已往的代 用方案。其次，由于自动内存打点是与详细的应用疏散的，无法知道最符合的切 入点，所以自动内存打点的参与根基是不行预测的。这限制了自动内存打点在那 些对时间响应要求较量严格的措施中的应用。最后，自动内存打点仅是对内存资 源的打点，它无法打点其它的资源。除了内存，措施员往往要和其它的资源打交 道。自动内存打点模式无法应用到其它范例的资源打点。
C++提供了RAII 作为一个真正意义上的资源打点实用方案。这也是C++语言在资源打点这一意义 越发遍及的问题上作出的孝敬。固然其实用意义如此重大，可是其做法却很简朴 ，就是用类来暗示资源，在类的结构函数里分派资源，在类的析构函数里释放资 源。好比，
class Resource {
public：
Resource（const char *name） ： _resource（alloc_resource（name）） {……}
~Resource（） { release_resource （_resource）； }
}；
资源类的利用也很简朴，按 泛围利用。好比，有一个事务处理惩罚，利用到了某种资源。假如这一事务可以用一 个函数来暗示，那么，可以简朴地用一个在函数进口处分派的资源变量来暗示资 源分派。譬喻：
void transaction1（const char *res_name）
{
Resource res（res_name）；
// 后头 是利用资源res
}
#p#副标题#e#
不 管措施体内资源res的利用逻辑 如何巨大，退出路径如何繁多，C++语言担保了在退出函数范畴的时候，资源对 象肯定获得析构，资源肯定获得释放。这一担保甚至包罗底层函数抛出异常的情 况。所有这些都是免费的，措施员要做的，就是用一个RAII语义的类来表达一类 资源，然后用一对标识代码范畴的大括号来构勒资源的每一个生命周期范畴。如 果该事务逻辑过于巨大，无法有效地在单一函数里表达，那么可以用一个类来表 达该事务，这个类可以简朴地把用到的RAII资源作为成员包括，在表达逻辑上达 到了资源和事务逻辑共存亡的境地。
#p#分页标题#e#
你会说，这太不足用了，资源的生 命周期大概是动态的，无法静态抉择。有时候甚至是外部用户抉择的。赶上这种 环境，智能指针类（其自己就有RAII语义）的引用计数根基上可以办理百分之九 十以上的问题。
譬喻在一个很实际的应用中，一个事务大概由用户通过 界面提倡执行，提倡后大概由于外部资源失败而中止，大概由于用户呼吁而中止 ，也有大概是自然执行完毕而中止。
一 个较量自然的表达是线程池和事 务函数。接到用户呼吁，主措施选择可用的闲置线程，载入该事务函数运行，一 旦事务函数因为妨碍可能自然原因返回，线程从头回到闲置状态。事务函数和主 措施用数据同步通讯的方法来实现事务运行状态的节制。在这种方法中，资源成 为函数的一部门，其存亡已根基不是我们体贴的问题，我们只要体贴，何时挪用 事务函数。这已经是较量大较量靠近事务逻辑的问题了。
假如不能利用 线程，可能认为多线程打点要比资源打点还要微妙还要邪恶，那么就要写所谓的 异步进程。整个的逻辑就是要在一个线程里通过轮询和行动切割的方法来实现事 务和事件的多道并行处理惩罚，这仍然可以通过写一个异步事务类来表达，资源将作 为成员附着在该事务类上，而所有的异步事务类将作为资源被轮询轮回地址的函 数自动打点（这是一定的，主轮回需要轮番执行当前正在执行的事务）。
可见，通过RAII措施员乐成地把资源打点问题弱化，转为如何表达事务 逻辑上。而这正是措施员的主要任务。也就是说，一旦资源被用RAII的形式封装 起来，措施员就不再思量资源泄漏问题，而思量如何表达事务逻辑的问题，这个 价钱并不算大。虽然，措施员要僵持只用资源类的工具形式而不是显式动态分派 的形式（也就是函数里的普通变量可能事务类里的普通成员，而不是任何new出 来的工具形式），不然所有的尽力都白搭了。这算是一点点代码要求。并不难做 到。
和自动内存打点较量起来，RAII仅需少量的打点代码（对类差池对 象），能普遍合用于各类资源工具的利用，时间上可以节制和预测。能为资源管 理提供一个统一的模式。RAII是自由的，它更多是靠措施员对类型的简朴遵守（ 僵持利用工具而不是指针）来到达目标。我认为，措施员是需要遵守规律的，特 别是那些好的规律。
利用RAII应该成为C++措施员的根基习惯，这正如书 写无错高效代码应该成为每个C++措施员的追求。
