一、什么是RAII
Resource Acquisition Is Initialization,资源获取即初始化。C/C++的开发者都知道,在这类语言的开发中,内存需要手动来控制。也就是说,释放和回收内存得开发者亲历亲为。从某种角度看,能够把控内存的细节,当然是更灵活,可如果把控的不好,却是一场灾难。
根据二八定律,对于绝大多数的开发者来说,都被划分到了灾难的一个方向(即使经验丰富技术高超的开发者也难免会出问题)。那么,尤如医学上所讲,预防大于治疗。在C++中,哪些对象的生命周期是不需要自己控制而由系统自动控制呢?很容易想到类的局部对象。c++之父Bjarne Stroustrup因此提出了上面的RAII,
二、作用
RAII的作用非常明显,就是管理资源。通过临时的对象自动调用析构函数来处理资源。既然这样,初始化资源就可以放到构造函数中,由开发者来进行控制并交由系统自动创建。而此处的资源很容易想到的就是内存。但其实不仅有内存还有相关的句柄、IO等等都可以。RAII其实可以显著的降低因为经验或者疏忽导致的资源泄露。
常见的RAII应用的场景有以下几种情况:
1、内存管理
2、锁管理
3、句柄管理
4、IO管理
5、其它
建议初学者一定要掌握这个技巧,则可以大幅的提高在开发过程中资源管理的安全性。RAII当然也有一些不足之处,最典型的缺点就是其的优势。假如一个资源只使用一下便可以回收。那么封装进入一个对象后,则其生命周期则升级到了这个对象的作用域生命周期。而且有可能无意间的循环引用和对象与资源生命周期的不同情况下,都可能会有一些细节的问题需要完善。
三、与三五原则的关系
在RAII中有一个比较典型的错误应用,它一般类似于下面的样子:
class Lock
{
public:Lock(){//相关锁初始化 }~Lock(){//相关锁回收}private://Lock(const Lock &);//Lock operator =(const Lock &);
};void UseLock(Lock l)//注意此处
{
//此处使用Lock来控制锁
}
unsigned ThreadFun(){Lock l;UseLock(l);
}
RAII如果类似上面的方法使用,即在RAII应用时再增加一层控制,发现锁就不好使了。难道RAII不能再封装?并不是,而是锁没有被深拷贝导致的UseLock函数中的复制的l并没有被拷贝出一个相同的副本,值传递导致在UseLock后其内部的l副本和ThreadFun中使用l共用一个锁资源。而前者在函数退出后会调用析构函数释放掉锁。这样在后面的Lock对象再使用形同虚设。在前面分析过三五原则,这个错误其实就是没有正确处理这个原则的非常典型的应用。
四、应用和例程
RAII的应用非常简单,就是以下几个步骤:
1、设计并开发一个类来封装相关的资源
2、在类构造函数中创建资源
3、在类的析构函数中释放资源
4、在实际的作用域空间内创建此类的临时对象
下面就看一个简单的锁的例子:
template <typename Mutex_> class lock_guard final {
public:lock_guard(Mutex_ *m_rwMt) : m_mt(m_rwMt) { pthread_mutex_lock(m_mt); }~lock_guard() { pthread_mutex_unlock(m_mt); }public:lock_guard(const lock_guard &) = delete;lock_guard(lock_guard &&) = delete;lock_guard &operator=(const lock_guard &) = delete;lock_guard &operator=(lock_guard &&) = delete;private:Mutex_ *m_mt;
};
其实内存控制也和这个差不多,只要把相关的内存创建和回收控制好即可。
在STL的标准库中,很多实现都应用到了RAII,比如常见的lock_guard,智能指针和stream等,所以还是建议大家把这个技巧弄清楚明白。
五、总结
记得以前总结过RAII相关的资料,可最近回头一看,没有找到 。于是,就只好将其再总结一篇,如果找到,就算重复总结吧。其实RAII更像是一种无奈之举,总得有一种安全的处理资源的方式啊。恰好,在C++中有这种变通的实现方式。其实上面还是有一些细节没有提到,比如创建和释放资源如果出现异常怎么办(即构造函数或析构函数如何处理异常)?这个在相关的知识中有过说明就不再详细阐述了。
或许这就是古人常说的,天无绝人之路!所以,对网上说的什么C++/c要被清退的说法,淡然处之即好。该来的一定会来,该走的也一定会走,不是谁说让谁走谁就会走。