QBox/Golang/CERL/StdExt/TPL/WinxGui - 许式伟的专栏

许式伟的技术博客,介绍与我相关的技术:包括QBox、云存储、Go语言、CERL、StdExt、TPL、WinxGui 等等。...

C++内存管理变革(4):boost::object_pool与gc allocator

本文已经迁移到: http://cpp.winxgui.com/cn:gc-allocator-and-boost-object-pool

C++内存管理变革(4): boost::object_pool

许式伟 (版权声明)
2007-4-21

这篇文章拖的有点久了。NeutralEvil 在3个月之前就在催促我继续写了。只是出于WinxGui完整性的考虑,我一直在刻意优先去补充其它方面的文章,而不是让人去误会WinxGui是一个内存管理库了。:)

言归正传。我们在内存池(MemPool)技术详解已经介绍了boost::pool组件。从内存管理观念的变革来看,这是是一个传统的MemPool组件,尽管也有一定的改进(但只是性能上的改进)。但boost::object_pool不同,它与我在C++内存管理变革强调的观念非常吻合。可以认为,boost::object_pool是一种不通用的gc allocator组件。

我已经多次提出gc allocator的概念。这里仍然需要强调一下,所谓gc allocator,是指具垃圾回收能力的allocatorC++内存管理变革(1) 中我们引入了这个概念,但是没有明确gc allocator一词。

boost::object_pool内存管理观念

boost::object_pool的了不起之处在于,这是C++从库的层次上头一次承认,程序员在内存管理上是会犯错误的,由程序员来确保内存不泄漏是困难的。boost::object_pool允许你忘记释放内存。我们来看一个例子:

    class X { … };
 
    
void func()
    {
        boost::object_pool
<X> alloc;
 

        X* obj1 = alloc.construct();
        X
* obj2 = alloc.construct();
        alloc.destroy(obj2);
    }

如果boost::object_pool只是一个普通的allocator,那么这段代码显然存在问题,因为obj1的析构函数没有执行,申请的内存也没有释放。

但是这段代码是完全正常的。是的,obj1的析构确实执行了,所申请内存也被释放了。这就是说,boost::object_pool既支持你手工释放内存(通过主动调用object_pool::destroy),也支持内存的自动回收(通过object_pool::~object_pool析构的执行)。这正符合gc allocator的规格。

注:内存管理更好的说法是对象管理。内存的申请和释放更确切的说是对象的创建和销毁。但是这里我们不刻意区分这两者的差异。

boost::object_pool与AutoFreeAlloc

我们知道,AutoFreeAlloc不支持手工释放,而只能等到AutoFreeAlloc对象析构的时候一次性全部释放内存。那么,是否可以认为boost::object_pool是否比AutoFreeAlloc更加完备呢?

其实不然。boost::object_pool与AutoFreeAlloc都不是完整意义上的gc allocator。AutoFreeAlloc因为它只能一次性释放,故此仅仅适用特定的用况。然而尽管AutoFreeAlloc不是普适的,但它是通用型的gc allocator。而boost::object_pool只能管理一种对象,并不是通用型的allocator,局限性其实更强。

boost::object_pool的实现细节

大家对boost::object_pool应该已经有了一个总体的把握。现在,让我们深入到object_pool的实现细节中去。

内存池(MemPool)技术详解中,我们介绍boost::pool组件时,特意提醒大家留意pool::ordered_malloc/ordered_free函数。事实上,boost::object_poolmalloc/construct, free/destroy函数调用了pool::ordered_malloc, ordered_free函数,而不是pool::malloc, free函数。

让我们解释下为什么。

其实这其中的关键,在于object_pool要支持手工释放内存和自动回收内存(并自动执行析构函数)两种模式。如果没有自动析构,那么普通的MemPool就足够了,也就不需要ordered_free。既然有自动回收,同时又存在手工释放,那么就需要区分内存块(MemBlock)中哪些结点(Node)是自由内存结点(FreeNode),哪些结点是已经使用的。对于哪些已经是自由内存的结点,显然不能再调用对象的析构函数。

我们来看看object_pool::~object_pool函数的实现:

template <typename T, typename UserAllocator>
object_pool
<T, UserAllocator>::~object_pool()
{
  
// handle trivial case
  if (!this->list.valid())
    
return;
 
  details::PODptr
<size_type> iter = this->list;
  details::PODptr
<size_type> next = iter;
 
  
// Start ’freed_iter’ at beginning of free list
  void * freed_iter = this->first;
 
  
const size_type partition_size = this->alloc_size();
 
  
do
  {
    
// increment next
    next = next.next();
  
    
// delete all contained objects that aren’t freed
  
    
// Iterate ’i' through all chunks in the memory block
    for (char * i = iter.begin(); i != iter.end(); i += partition_size)
    {
      
// If this chunk is free
      if (i == freed_iter)
      {
        
// Increment freed_iter to point to next in free list
        freed_iter = nextof(freed_iter);
 
        
// Continue searching chunks in the memory block
        continue;
      }
  
      
// This chunk is not free (allocated), so call its destructor
      static_cast<*>(static_cast<void *>(i))->~T();
      
// and continue searching chunks in the memory block
    }
  
    
// free storage
    UserAllocator::free(iter.begin());
  
    
// increment iter
    iter = next;
  } 
while (iter.valid());
  
  
// Make the block list empty so that the inherited destructor doesn’t try to
  
//  free it again.
  this->list.invalidate();
}

这段代码不难理解,object_pool遍历所有申请的内存块(MemBlock),并遍历其中所有结点(Node),如果该结点不出现在自由内存结点(FreeNode)的列表(FreeNodeList)中,那么,它就是用户未主动释放的结点,需要进行相应的析构操作。

现在你明白了,ordered_malloc是为了让MemBlockList中的MemBlock有序,ordered_free是为了让FreeNodeList中的所有FreeNode有序。而MemBlockList, FreeNodeList有序,是为了更快地检测Node是自由的还是被使用的(这实际上是一个集合求交的流程,建议你看看std::set_intersection,它定义在STL的<algorithm>中)。

C++内存管理变革-系列文章 

点击这里查看更多内存管理相关文章

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭