EffectiveC++2eItem10(2)
delete pa; // 内存块再次空,
// 释放
... // 你有了想法...
return 0;
}
这个糟糕的小程序会比用缺省的operator new和operator delete写的程序运行得还慢,占用还要多的内存,更不要和用内存池写的程序比了。
当然有办法处理这种不合理的情况,但考虑的特殊情况越多,就越有可能要重新实现内存管理函数,而最后你又会得到什么呢?内存池不能解决所有的内存管理问题,在很多情况下是很适合的。
实际开发中,你会经常要给许多不同的类实现基于内存池的功能。你会想,“一定有什么办法把这种固定大小内存的分配器封装起来,从而可以方便地使用”。是的,有办法。虽然我在这个条款已经唠叨这么长时间了,但还是要简单介绍一下,具体实现留给读者做练习。
下面简单给出了一个Pool类的最小接口(见条款18),Pool类的每个对象是某类对象(其大小在Pool的构造函数里指定)的内存分配器。
class Pool {
public:
Pool(size_t n); // 为大小为n的对象创建
// 一个分配器
void * alloc(size_t n) ; // 为一个对象分配足够内存
// 遵循条款8的operator new常规
void free( void *p, size_t n); // 将p所指的内存返回到内存池;
// 遵循条款8的operator delete常规
~Pool(); // 释放内存池中全部内存
};
这个类支持Pool对象的创建,执行分配和释放操作,以及被摧毁。Pool对象被摧毁时,会释放它分配的所有内存。这就是说,现在有办法避免Airplane的函数里所表现的内存泄漏似的行为了。然而这也意味着,如果Pool的析构函数调用太快(使用内存池的对象没有全部被摧毁),一些对象就会发现它正在使用的内存猛然间没了。这造成的结果通常是不可预测的。
有了这个Pool类,即使Java程序员也可以不费吹灰之力地在Airplane类里增加自己的内存管理功能:
class Airplane {
public:
... // 普通Airplane功能
static void * operator new(size_t size);
static void operator delete(void *p, size_t size);
private:
AirplaneRep *rep; // 指向实际描述的指针
static Pool memPool; // Airplanes的内存池
};
inline void * Airplane::operator new(size_t size)
{ return memPool.alloc(size); }
inline void Airplane::operator delete(void *p,
size_t size)
{ memPool.free(p, size); }
// 为Airplane对象创建一个内存池,
// 在类的实现文件里实现
Pool Airplane::memPool(sizeof(Airplane));
这个设计比前面的要清楚、干净得多,因为Airplane类不再和非Airplane的代码混在一起。union,自由链表头指针,定义原始内存块大小的常量都不见了,它们都隐藏在它们应该呆的地方——Pool类里。让写Pool的程序员去操心内存管理的细节吧,你的工作只是让Airplane类正常工作。
现在应该明白了,自定义的内存管理程序可以很好地改善程序的性能,而且它们可以封装在象Pool这样的类里。但请不要忘记主要的一点,operator new和operator delete需要同时工作,那么你写了operator new,就也一定要写operator delete。
- 最新评论
