STL 源码剖析allocator 深入（五）

此时感悟：在夜深人静的时候，感谢自己可以思考，可以成长。

今天在学校，看到了即将要来的招聘会，我知道，现在的自己必须面对现实，因为只有你得到了，才会留下来！

声明：参考书籍<STL 源码剖析>侯杰

stl 源码剖析 第二章，比较详细的简述了allocator，我在上面一篇也有简单的介绍！由于今天在看源码有很多 不解，所以特此来总结和学习。

allocator 概述

标准allocator需要实现rebind，allocate，deallocate，max_size和构造及析构函数一共六个函数

我就对不常见的加以介绍吧！

1 rebind

VC源码 

template<class _Ty,class _Alloc>class _Vector_val

有些VC源码 包含一个基类

template<class _Ty,class _Alloc>class _Vector_val: public _Container_base

再看看下面的代码

template<class _Ty,class _Alloc>class _Vector_val: public _Container_base{// base class for vector to hold datapublic:typedef typename _Alloc::template rebind<_Ty>::other _Alty;

可以看出是一个模板类，那么rebind 有什么作用呢？

typedef typename _Alloc::template rebind<_Ty>::other _Alty; 

整体来看是类型定义，假设现在我们这样使用vector<int>， 那么_Ty 即 int, _Ax 即 allocator<int>，由vector 类传递给 基类_Vector_val，则_Alloc 即allocator<int> ；

可以看到 allocator<void> 是allocator 模板类的特化， rebind<_Ty> 是成员模板类，other是成员模板类

中自定义类型，_Ty 即是int ， 那么other 类型也就是allocator<int>， 也就是说_Alty 是类型 allocator<int> 。

_Alty _Alval; 即 基类定义了一个allocator<int> 类型的成员，被vector 继承后以后用于为vector 里面元素分配内存等操作。

Alocator 是内存分配器，STL在这个层面上进行开放是为了让用户/程序员有权选择不同的内存分配器。举例来说，Allocator_A和Allocator_B在内存分配方式上可能是不一样的,也就是说Allocator_A<int>和Allocator_B<int>所分配的内存很有可能是不一样的。 

假如有一个容器类MyVector, 它用的是Allocator_A<int>内存分配器，这个容器类很有可能需要double类型的分配器，而且要求对int和double类型的内存分配策略是一样的，这是rebind的意义就体现出来了。

总之一句话，rebind实现了对不同类型使用同一种内存分配策略的要求。

2 allocate

SGI的allocator首先接受用户所需要的size_t,然后 调用allocate(其实是客户端这么写objalloc.allocate(n);),allocate向 freelist(__defalut_malloc_template的一个数据成员,型别为一个obj* volalite freelist[16],既是存储这16个列表的那个家伙),如果freelist没有内存(或者说它是空的,为初始化)那么调用 refill,refill从真正的SIG memory pool中取内存,取出做多20个客户端所需要的size_t大小的内存块,通过chunk_alloc,取出来后将其妆扮好(就是想这20块内存连接为 一个链表),上交给allocate享用

template 　　char* 　　__default_alloc_template<__threads, __inst>::_S_chunk_alloc(size_t __size, 　　int& __nobjs)

默 认情况下__nobjs实参为20,而且是一个地址传递(引用传递).他做的工作可是相当相当的伟大.原始社会的时候,一切资源都相当的丰富(原始人从来 不担心石油危机),chunk_alloc从内存里面取出20块size_t大小的内存上交给refill,refill将其装配后,上交 freelist,allocate从freelist中取出一块上交给我(^_^),其实是我想allocate要内存,结果没有,allocate想 refill要内存,refill马上把chunk_alloc找来,于是内存有了.
　　当然内存要节约使用,第一次我想要一个32字节的内 存,chunk_alloc找来了2*20*32个字节的内存,其中的20块上交给了refill,refill填充 freelist,freelist[3]存储其中19个,上交给客户端(我)一个.下一次我要一个8字节的内存,chunk_alloc又要找内存了, 不过上次找来的内存还没有用完(上次交了20*24,剩余20*24,也就是剩余480字节),而且足够上交refill的了(需要8*20=160), 他们我上交给他所需要的内存,不从系统堆(heap)里面取用内存(只有chunk_alloc这样的劳动人民知道花钱小心翼翼).这样美好的日子一直持 续着,突然有一天,chunk_alloc发现系统内存重要用完了,怎么办?怎么向refill交差?refill一再压迫 chunk_alloc.chunk_alloc于是去找freelist,freelist内部存储上尚未陪客户端(client)取走的内存,比如 freelist[3],中还有10块没有用完,也就是说有160个字节的内存,那么chunk_alloc看看内不能满足refill的最小需求(1块 size_t),然后毫无保留的上交上去.如果连freelist都没有内存了,chunk_alloc于是向同门兄弟 __malloc_default_alloc求助(调用它的allocate),再那里有内存不足的处理情况,或许就要std::bad_alloc 了!
　　诚实的讲SGI的策略已经是异常的完美了,但是作为一个STL,只能是最完美的,其中还是存在一些不足,因为一个完美的memory_pool实在是很有难度的!!