【项目设计】高并发内存池(七)[性能测试和提升]

&＃x1f387;C&＃43;&＃43;学习历程&＃xff1a;入门

---

• 博客主页&＃xff1a;一起去看日落吗
• 持续分享博主的C&＃43;&＃43;学习历程
• 博主的能力有限&＃xff0c;出现错误希望大家不吝赐教
• 分享给大家一句我很喜欢的话&＃xff1a; 也许你现在做的事情&＃xff0c;暂时看不到成果&＃xff0c;但不要忘记&＃xff0c;树&＃x1f33f;成长之前也要扎根&＃xff0c;也要在漫长的时光&＃x1f31e;中沉淀养分。静下来想一想&＃xff0c;哪有这么多的天赋异禀&＃xff0c;那些让你羡慕的优秀的人也都曾默默地翻山越岭&＃x1f43e;。

---

&＃x1f341; &＃x1f343; &＃x1f342; &＃x1f33f;

经过前面的测试可以看到&＃xff0c;我们的代码此时与malloc之间还是有差距的&＃xff0c;此时我们就应该分析分析我们当前项目的瓶颈在哪里&＃xff0c;但这不能简单的凭感觉&＃xff0c;我们应该用性能分析的工具来进行分析。

• VS编译器下性能分析的操作步骤

VS编译器中就带有性能分析的工具的&＃xff0c;我们可以依次点击“调试→性能和诊断”进行性能分析&＃xff0c;注意该操作要在Debug模式下进行。

同时我们将代码中n的值由10000调成了1000&＃xff0c;否则该分析过程可能会花费较多时间&＃xff0c;并且将malloc的测试代码进行了屏蔽&＃xff0c;因为我们要分析的是我们实现的高并发内存池。

在点击了“调试→性能和诊断”后会弹出一个提示框&＃xff0c;我们直接点击“开始”进行了。

然后会弹出一个选项框&＃xff0c;这里我们选择的是第二个&＃xff0c;因为我们要分析的是各个函数的用时时间&＃xff0c;然后点击下一步。

出现以下选项框继续点击下一步。

最后点击完成&＃xff0c;就可以等待分析结果了。

• 分析性能瓶颈

通过分析结果可以看到&＃xff0c;光是Deallocate和MapObjectToSpan这两个函数就占用了一半多的时间。

而在Deallocate函数中&＃xff0c;调用ListTooLong函数时消耗的时间是最多的。

在ListTooLong函数中&＃xff0c;调用ReleaseListToSpans函数时消耗的时间是最多的。

在ReleaseListToSpans函数中&＃xff0c;调用MapObjectToSpan函数时消耗的时间是最多的。

也就是说&＃xff0c;最终消耗时间最多的实际就是MapObjectToSpan函数&＃xff0c;我们这时再来看看为什么调用MapObjectToSpan函数会消耗这么多时间。通过观察我们最终发现&＃xff0c;调用该函数时会消耗这么多时间就是因为锁的原因。

因此当前项目的瓶颈点就在锁竞争上面&＃xff0c;需要解决调用MapObjectToSpan函数访问映射关系时的加锁问题。tcmalloc当中针对这一点使用了基数树进行优化&＃xff0c;使得在读取这个映射关系时可以做到不加锁。

基数树实际上就是一个分层的哈希表&＃xff0c;根据所分层数不同可分为单层基数树、二层基数树、三层基数树等。

• 单层基数树

单层基数树实际采用的就是直接定址法&＃xff0c;每一个页号对应span的地址就存储数组中在以该页号为下标的位置。

最坏的情况下我们需要建立所有页号与其span之间的映射关系&＃xff0c;因此这个数组中元素个数应该与页号的数目相同&＃xff0c;数组中每个位置存储的就是对应span的指针。

//单层基数树
template <int BITS>
class TCMalloc_PageMap1
{
public:typedef uintptr_t Number;explicit TCMalloc_PageMap1(){size_t size &＃61; sizeof(void*) << BITS; //需要开辟数组的大小size_t alignSize &＃61; SizeClass::_RoundUp(size, 1 << PAGE_SHIFT); //按页对齐后的大小array_ &＃61; (void**)SystemAlloc(alignSize >> PAGE_SHIFT); //向堆申请空间memset(array_, 0, size); //对申请到的内存进行清理}void* get(Number k) const{if ((k >> BITS) > 0) //k的范围不在[0, 2^BITS-1]{return NULL;}return array_[k]; //返回该页号对应的span}void set(Number k, void* v){assert((k >> BITS) &＃61;&＃61; 0); //k的范围必须在[0, 2^BITS-1]array_[k] &＃61; v; //建立映射}
private:void** array_; //存储映射关系的数组static const int LENGTH &＃61; 1 << BITS; //页的数目
};


此时当我们需要建立映射时就调用set函数&＃xff0c;需要读取映射关系时&＃xff0c;就调用get函数就行了。

代码中的非类型模板参数BITS表示存储页号最多需要比特位的个数。在32位下我们传入的是32-PAGE_SHIFT&＃xff0c;在64位下传入的是64-PAGE_SHIFT。而其中的LENGTH成员代表的就是页号的数目&＃xff0c;即 22^BITS

比如32位平台下&＃xff0c;以一页大小为8K为例&＃xff0c;此时页的数目就是2³² / 2¹³ &＃61; 2 ¹⁹ , 因此存储页号最多需要19个比特位&＃xff0c;此时传入非类型模板参数的值就是 32 − 13 &＃61; 19。由于32位平台下指针的大小是4字节&＃xff0c;因此该数组的大小就是2¹⁹ x 4 &＃61; 2M ,内存消耗不大&＃xff0c;是可行的。但如果是在64位平台下&＃xff0c;此时该数组的大小是2⁵¹ x 8 &＃61; 2²⁴G,这显然是不可行的&＃xff0c;实际上对于64位的平台&＃xff0c;我们需要使用三层基数树。

• 二层基数树

这里还是以32位平台下&＃xff0c;一页的大小为8K为例来说明&＃xff0c;此时存储页号最多需要19个比特位。而二层基数树实际上就是把这19个比特位分为两次进行映射。

比如用前5个比特位在基数树的第一层进行映射&＃xff0c;映射后得到对应的第二层&＃xff0c;然后用剩下的比特位在基数树的第二层进行映射&＃xff0c;映射后最终得到该页号对应的span指针。

在二层基数树中&＃xff0c;第一层的数组占用2⁵ x &＃61; 2⁷ Byte 空间&＃xff0c;第二层的数组最多占用2⁵ x 2¹⁴ x 4 &＃61; 2²¹ &＃61; 2M。二层基数树相比一层基数树的好处就是&＃xff0c;一层基数树必须一开始就把 2M 的数组开辟出来&＃xff0c;而二层基数树一开始时只需将第一层的数组开辟出来&＃xff0c;当需要进行某一页号映射时再开辟对应的第二层的数组就行了。

//二层基数树
template <int BITS>
class TCMalloc_PageMap2
{
private:static const int ROOT_BITS &＃61; 5; //第一层对应页号的前5个比特位static const int ROOT_LENGTH &＃61; 1 << ROOT_BITS; //第一层存储元素的个数static const int LEAF_BITS &＃61; BITS - ROOT_BITS; //第二层对应页号的其余比特位static const int LEAF_LENGTH &＃61; 1 << LEAF_BITS; //第二层存储元素的个数//第一层数组中存储的元素类型struct Leaf{void* values[LEAF_LENGTH];};Leaf* root_[ROOT_LENGTH]; //第一层数组
public:typedef uintptr_t Number;explicit TCMalloc_PageMap2(){memset(root_, 0, sizeof(root_)); //将第一层的空间进行清理PreallocateMoreMemory(); //直接将第二层全部开辟}void* get(Number k) const{const Number i1 &＃61; k >> LEAF_BITS; //第一层对应的下标const Number i2 &＃61; k & (LEAF_LENGTH - 1); //第二层对应的下标if ((k >> BITS) > 0 || root_[i1] &＃61;&＃61; NULL) //页号值不在范围或没有建立过映射{return NULL;}return root_[i1]->values[i2]; //返回该页号对应span的指针}void set(Number k, void* v){const Number i1 &＃61; k >> LEAF_BITS; //第一层对应的下标const Number i2 &＃61; k & (LEAF_LENGTH - 1); //第二层对应的下标assert(i1 < ROOT_LENGTH);root_[i1]->values[i2] &＃61; v; //建立该页号与对应span的映射}//确保映射[start,start_n-1]页号的空间是开辟好了的bool Ensure(Number start, size_t n){for (Number key &＃61; start; key <&＃61; start &＃43; n - 1;){const Number i1 &＃61; key >> LEAF_BITS;if (i1 >&＃61; ROOT_LENGTH) //页号超出范围return false;if (root_[i1] &＃61;&＃61; NULL) //第一层i1下标指向的空间未开辟{//开辟对应空间static ObjectPool<Leaf> leafPool;Leaf* leaf &＃61; (Leaf*)leafPool.New();memset(leaf, 0, sizeof(*leaf));root_[i1] &＃61; leaf;}key &＃61; ((key >> LEAF_BITS) &＃43; 1) << LEAF_BITS; //继续后续检查}return true;}void PreallocateMoreMemory(){Ensure(0, 1 << BITS); //将第二层的空间全部开辟好}
};


因此在二层基数树中有一个Ensure函数&＃xff0c;当需要建立某一页号与其span之间的映射关系时&＃xff0c;需要先调用该Ensure函数确保用于映射该页号的空间是开辟了的&＃xff0c;如果没有开辟则会立即开辟。

而在32位平台下&＃xff0c;就算将二层基数树第二层的数组全部开辟出来也就消耗了 2 M 2M 2M的空间&＃xff0c;内存消耗也不算太多&＃xff0c;因此我们可以在构造二层基数树时就把第二层的数组全部开辟出来。

• 三层基数树

上面一层基数树和二层基数树都适用于32位平台&＃xff0c;而对于64位的平台就需要用三层基数树了。三层基数树与二层基数树类似&＃xff0c;三层基数树实际上就是把存储页号的若干比特位分为三次进行映射。

此时只有当要建立某一页号的映射关系时&＃xff0c;再开辟对应的数组空间&＃xff0c;而没有建立映射的页号就可以不用开辟其对应的数组空间&＃xff0c;此时就能在一定程度上节省内存空间。

//三层基数树
template <int BITS>
class TCMalloc_PageMap3
{
private:static const int INTERIOR_BITS &＃61; (BITS &＃43; 2) / 3; //第一、二层对应页号的比特位个数static const int INTERIOR_LENGTH &＃61; 1 << INTERIOR_BITS; //第一、二层存储元素的个数static const int LEAF_BITS &＃61; BITS - 2 * INTERIOR_BITS; //第三层对应页号的比特位个数static const int LEAF_LENGTH &＃61; 1 << LEAF_BITS; //第三层存储元素的个数struct Node{Node* ptrs[INTERIOR_LENGTH];};struct Leaf{void* values[LEAF_LENGTH];};Node* NewNode(){static ObjectPool<Node> nodePool;Node* result &＃61; nodePool.New();if (result !&＃61; NULL){memset(result, 0, sizeof(*result));}return result;}Node* root_;
public:typedef uintptr_t Number;explicit TCMalloc_PageMap3(){root_ &＃61; NewNode();}void* get(Number k) const{const Number i1 &＃61; k >> (LEAF_BITS &＃43; INTERIOR_BITS); //第一层对应的下标const Number i2 &＃61; (k >> LEAF_BITS) & (INTERIOR_LENGTH - 1); //第二层对应的下标const Number i3 &＃61; k & (LEAF_LENGTH - 1); //第三层对应的下标//页号超出范围&＃xff0c;或映射该页号的空间未开辟if ((k >> BITS) > 0 || root_->ptrs[i1] &＃61;&＃61; NULL || root_->ptrs[i1]->ptrs[i2] &＃61;&＃61; NULL){return NULL;}return reinterpret_cast<Leaf*>(root_->ptrs[i1]->ptrs[i2])->values[i3]; //返回该页号对应span的指针}void set(Number k, void* v){assert(k >> BITS &＃61;&＃61; 0);const Number i1 &＃61; k >> (LEAF_BITS &＃43; INTERIOR_BITS); //第一层对应的下标const Number i2 &＃61; (k >> LEAF_BITS) & (INTERIOR_LENGTH - 1); //第二层对应的下标const Number i3 &＃61; k & (LEAF_LENGTH - 1); //第三层对应的下标Ensure(k, 1); //确保映射第k页页号的空间是开辟好了的reinterpret_cast<Leaf*>(root_->ptrs[i1]->ptrs[i2])->values[i3] &＃61; v; //建立该页号与对应span的映射}//确保映射[start,start&＃43;n-1]页号的空间是开辟好了的bool Ensure(Number start, size_t n){for (Number key &＃61; start; key <&＃61; start &＃43; n - 1;){const Number i1 &＃61; key >> (LEAF_BITS &＃43; INTERIOR_BITS); //第一层对应的下标const Number i2 &＃61; (key >> LEAF_BITS) & (INTERIOR_LENGTH - 1); //第二层对应的下标if (i1 >&＃61; INTERIOR_LENGTH || i2 >&＃61; INTERIOR_LENGTH) //下标值超出范围return false;if (root_->ptrs[i1] &＃61;&＃61; NULL) //第一层i1下标指向的空间未开辟{//开辟对应空间Node* n &＃61; NewNode();if (n &＃61;&＃61; NULL) return false;root_->ptrs[i1] &＃61; n;}if (root_->ptrs[i1]->ptrs[i2] &＃61;&＃61; NULL) //第二层i2下标指向的空间未开辟{//开辟对应空间static ObjectPool<Leaf> leafPool;Leaf* leaf &＃61; leafPool.New();if (leaf &＃61;&＃61; NULL) return false;memset(leaf, 0, sizeof(*leaf));root_->ptrs[i1]->ptrs[i2] &＃61; reinterpret_cast<Node*>(leaf);}key &＃61; ((key >> LEAF_BITS) &＃43; 1) << LEAF_BITS; //继续后续检查}return true;}void PreallocateMoreMemory(){}
};


因此当我们要建立某一页号的映射关系时&＃xff0c;需要先确保存储该页映射的数组空间是开辟好了的&＃xff0c;也就是调用代码中的Ensure函数&＃xff0c;如果对应数组空间未开辟则会立马开辟对应的空间。

• 代码更改

现在我们用基数树对代码进行优化&＃xff0c;此时将PageCache类当中的unorder_map用基数树进行替换即可&＃xff0c;由于当前是32位平台&＃xff0c;因此这里随便用几层基数树都可以。

//单例模式
class PageCache
{
public://...
private://std::unordered_map _idSpanMap;TCMalloc_PageMap1<32 - PAGE_SHIFT> _idSpanMap;
};


此时当我们需要建立页号与span的映射时&＃xff0c;就调用基数树当中的set函数。

_idSpanMap.set(span->_pageId, span);


而当我们需要读取某一页号对应的span时&＃xff0c;就调用基数树当中的get函数。

Span* ret &＃61; (Span*)_idSpanMap.get(id);


并且现在PageCache类向外提供的&＃xff0c;用于读取映射关系的MapObjectToSpan函数内部就不需要加锁了。

//获取从对象到span的映射
Span* PageCache::MapObjectToSpan(void* obj)
{PAGE_ID id &＃61; (PAGE_ID)obj >> PAGE_SHIFT; //页号Span* ret &＃61; (Span*)_idSpanMap.get(id);assert(ret !&＃61; nullptr);return ret;
}


• 为什么读取基数树映射关系时不需要加锁&＃xff1f;

当某个线程在读取映射关系时&＃xff0c;可能另外一个线程正在建立其他页号的映射关系&＃xff0c;而此时无论我们用的是C&＃43;&＃43;当中的map还是unordered_map&＃xff0c;在读取映射关系时都是需要加锁的。

因为C&＃43;&＃43;中map的底层数据结构是红黑树&＃xff0c;unordered_map的底层数据结构是哈希表&＃xff0c;而无论是红黑树还是哈希表&＃xff0c;当我们在插入数据时其底层的结构都有可能会发生变化。比如红黑树在插入数据时可能会引起树的旋转&＃xff0c;而哈希表在插入数据时可能会引起哈希表扩容。此时要避免出现数据不一致的问题&＃xff0c;就不能让插入操作和读取操作同时进行&＃xff0c;因此我们在读取映射关系的时候是需要加锁的。

而对于基数树来说就不一样了&＃xff0c;基数树的空间一旦开辟好了就不会发生变化&＃xff0c;因此无论什么时候去读取某个页的映射&＃xff0c;都是对应在一个固定的位置进行读取的。并且我们不会同时对同一个页进行读取映射和建立映射的操作&＃xff0c;因为我们只有在释放对象时才需要读取映射&＃xff0c;而建立映射的操作都是在page cache进行的。也就是说&＃xff0c;读取映射时读取的都是对应span的_useCount不等于0的页&＃xff0c;而建立映射时建立的都是对应span的_useCount等于0的页&＃xff0c;所以说我们不会同时对同一个页进行读取映射和建立映射的操作。

• 再次对比malloc进行测试

还是同样的代码&＃xff0c;只不过我们用基数树对代码进行了优化&＃xff0c;这时测试固定大小内存的申请和释放的结果如下&＃xff1a;

可以看到&＃xff0c;这时就算申请释放的是固定大小的对象&＃xff0c;其效率都是malloc的两倍。下面在申请释放不同大小的对象时&＃xff0c;由于central cache的桶锁起作用了&＃xff0c;其效率更是变成了malloc的好几倍。