项目设计高并发内存池

Posted 2022-03-30 2021dragon

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了项目设计高并发内存池相关的知识，希望对你有一定的参考价值。

文章目录

项目介绍
内存池介绍
定长内存池的实现
高并发内存池整体框架设计
threadcache
- threadcache整体设计
- threadcache哈希桶映射对齐规则
- threadcacheTLS无锁访问
centralcache
- centralcache整体设计
- centralcache结构设计
- centralcache核心实现
pagecache
- pagecache整体设计
- pagecache中获取Span
申请内存过程联调
threadcache回收内存
centralcache回收内存
pagecache回收内存
释放内存过程联调
大于256KB的大块内存申请问题
使用定长内存池配合脱离使用new
释放对象时优化为不传对象大小
多线程环境下对比malloc测试
复杂问题的调试技巧
性能瓶颈分析
针对性能瓶颈使用基数树进行优化
使用基数树进行优化代码实现
项目源码

项目介绍

本项目实现的是一个高并发的内存池，它的原型是Google的一个开源项目tcmalloc，tcmalloc全称Thread-Caching Malloc，即线程缓存的malloc，实现了高效的多线程内存管理，用于替换系统的内存分配相关函数malloc和free。

tcmalloc的知名度也是非常高的，不少公司都在用它，比如Go语言就直接用它做了自己的内存分配器。

该项目就是把tcmalloc中最核心的框架简化后拿出来，模拟实现出一个mini版的高并发内存池，目的就是学习tcmalloc的精华。

该项目主要涉及C/C++、数据结构（链表、哈希桶）、操作系统内存管理、单例模式、多线程、互斥锁等方面的技术。

内存池介绍

池化技术

在说内存池之前，我们得先了解一下“池化技术”。所谓“池化技术”，就是程序先向系统申请过量的资源，然后自己进行管理，以备不时之需。

之所以要申请过量的资源，是因为申请和释放资源都有较大的开销，不如提前申请一些资源放入“池”中，当需要资源时直接从“池”中获取，不需要时就将该资源重新放回“池”中即可。这样使用时就会变得非常快捷，可以大大提高程序的运行效率。

在计算机中，有很多使用“池”这种技术的地方，除了内存池之外，还有连接池、线程池、对象池等。以服务器上的线程池为例，它的主要思想就是：先启动若干数量的线程，让它们处于睡眠状态，当接收到客户端的请求时，唤醒池中某个睡眠的线程，让它来处理客户端的请求，当处理完这个请求后，线程又进入睡眠状态。

内存池

内存池是指程序预先向操作系统申请一块足够大的内存，此后，当程序中需要申请内存的时候，不是直接向操作系统申请，而是直接从内存池中获取；同理，当释放内存的时候，并不是真正将内存返回给操作系统，而是将内存返回给内存池。当程序退出时（或某个特定时间），内存池才将之前申请的内存真正释放。

内存池主要解决的问题

内存池主要解决的就是效率的问题，它能够避免让程序频繁的向系统申请和释放内存。其次，内存池作为系统的内存分配器，还需要尝试解决内存碎片的问题。

内存碎片分为内部碎片和外部碎片：

外部碎片是一些空闲的小块内存区域，由于这些内存空间不连续，以至于合计的内存足够，但是不能满足一些内存分配申请需求。
内部碎片是由于一些对齐的需求，导致分配出去的空间中一些内存无法被利用。

注意： 内存池尝试解决的是外部碎片的问题，同时也尽可能的减少内部碎片的产生。

malloc

C/C++中我们要动态申请内存并不是直接去堆申请的，而是通过malloc函数去申请的，包括C++中的new实际上也是封装了malloc函数的。

我们申请内存块时是先调用malloc，malloc再去向操作系统申请内存。malloc实际就是一个内存池，malloc相当于向操作系统“批发”了一块较大的内存空间，然后“零售”给程序用，当全部“售完”或程序有大量的内存需求时，再根据实际需求向操作系统“进货”。

malloc的实现方式有很多种，一般不同编译器平台用的都是不同的。比如Windows的VS系列中的malloc就是微软自行实现的，而Linux下的gcc用的是glibc中的ptmalloc。

定长内存池的实现

malloc其实就是一个通用的内存池，在什么场景下都可以使用，但这也意味着malloc在什么场景下都不会有很高的性能，因为malloc并不是针对某种场景专门设计的。

定长内存池就是针对固定大小内存块的申请和释放的内存池，由于定长内存池只需要支持固定大小内存块的申请和释放，因此我们可以将其性能做到极致，并且在实现定长内存池时不需要考虑内存碎片等问题，因为我们申请/释放的都是固定大小的内存块。

我们可以通过实现定长内存池来熟悉一下对简单内存池的控制，其次，这个定长内存池后面会作为高并发内存池的一个基础组件。

如何实现定长？

在实现定长内存池时要做到“定长”有很多种方法，比如我们可以使用非类型模板参数，使得在该内存池中申请到的对象的大小都是N。

template<size_t N>
class ObjectPool
;

此外，定长内存池也叫做对象池，在创建对象池时，对象池可以根据传入的对象类型的大小来实现“定长”，因此我们可以通过使用模板参数来实现“定长”，比如创建定长内存池时传入的对象类型是int，那么该内存池就只支持4字节大小内存的申请和释放。

template<class T>
class ObjectPool
;

如何直接向堆申请空间？

既然是内存池，那么我们首先得向系统申请一块内存空间，然后对其进行管理。要想直接向堆申请内存空间，在Windows下，可以调用VirtualAlloc函数；在Linux下，可以调用brk或mmap函数。

#ifdef _WIN32
	#include <Windows.h>
#else
	//...
#endif

//直接去堆上申请按页申请空间
inline static void* SystemAlloc(size_t kpage)

#ifdef _WIN32
	void* ptr = VirtualAlloc(0, kpage<<13, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
#else
	// linux下brk mmap等
#endif
	if (ptr == nullptr)
		throw std::bad_alloc();
	return ptr;

这里我们可以通过条件编译将对应平台下向堆申请内存的函数进行封装，此后我们就不必再关心当前所在平台，当我们需要直接向堆申请内存时直接调用我们封装后的SystemAlloc函数即可。

定长内存池中应该包含哪些成员变量？

对于向堆申请到的大块内存，我们可以用一个指针来对其进行管理，但仅用一个指针肯定是不够的，我们还需要用一个变量来记录这块内存的长度。

由于此后我们需要将这块内存进行切分，为了方便切分操作，指向这块内存的指针最好是字符指针，因为指针的类型决定了指针向前或向后走一步有多大距离，对于字符指针来说，当我们需要向后移动n个字节时，直接对字符指针进行加n操作即可。

其次，释放回来的定长内存块也需要被管理，我们可以将这些释放回来的定长内存块链接成一个链表，这里我们将管理释放回来的内存块的链表叫做自由链表，为了能找到这个自由链表，我们还需要一个指向自由链表的指针。

因此，定长内存池当中包含三个成员变量：

_memory：指向大块内存的指针。
_remainBytes：大块内存切分过程中剩余字节数。
_freeList：还回来过程中链接的自由链表的头指针。

内存池如何管理释放的对象？

对于还回来的定长内存块，我们可以用自由链表将其链接起来，但我们并不需要为其专门定义链式结构，我们可以让内存块的前4个字节（32位平台）或8个字节（64位平台）作为指针，存储后面内存块的起始地址即可。

因此在向自由链表插入被释放的内存块时，先让该内存块的前4个字节或8个字节存储自由链表中第一个内存块的地址，然后再让_freeList指向该内存块即可，也就是一个简单的链表头插操作。

这里有一个有趣问题：如何让一个指针在32位平台下解引用后能向后访问4个字节，在64位平台下解引用后能向后访问8个字节？

首先我们得知道，32位平台下指针的大小是4个字节，64位平台下指针的大小是8个字节。而指针指向数据的类型，决定了指针解引用后能向后访问的空间大小，因此我们这里需要的是一个指向指针的指针，这里使用二级指针就行了。

当我们需要访问一个内存块的前4/8个字节时，我们就可以先该内存块的地址先强转为二级指针，由于二级指针存储的是一级指针的地址，二级指针解引用能向后访问一个指针的大小，因此在32位平台下访问的就是4个字节，在64位平台下访问的就是8个字节，此时我们访问到了该内存块的前4/8个字节。

void*& NextObj(void* ptr)

	return (*(void**)ptr);

需要注意的是，在释放对象时，我们应该显示调用该对象的析构函数清理该对象，因为该对象可能还管理着其他某些资源，如果不对其进行清理那么这些资源将无法被释放，就会导致内存泄漏。

//释放对象
void Delete(T* obj)

	//显示调用T的析构函数清理对象
	obj->~T();

	//将释放的对象头插到自由链表
	NextObj(obj) = _freeList;
	_freeList = obj;

内存池如何为我们申请对象？

当我们申请对象时，内存池应该优先把还回来的内存块对象再次重复利用，因此如果自由链表当中有内存块的话，就直接从自由链表头删一个内存块进行返回即可。

如果自由链表当中没有内存块，那么我们就在大块内存中切出定长的内存块进行返回，当内存块切出后及时更新_memory指针的指向，以及_remainBytes的值即可。

需要特别注意的是，由于当内存块释放时我们需要将内存块链接到自由链表当中，因此我们必须保证切出来的对象至少能够存储得下一个地址，所以当对象的大小小于当前所在平台指针的大小时，需要按指针的大小进行内存块的切分。

此外，当大块内存已经不足以切分出一个对象时，我们就应该调用我们封装的SystemAlloc函数，再次向堆申请一块内存空间，此时也要注意及时更新_memory指针的指向，以及_remainBytes的值。

//申请对象
T* New()

	T* obj = nullptr;

	//优先把还回来的内存块对象，再次重复利用
	if (_freeList != nullptr)
	
		//从自由链表头删一个对象
		obj = (T*)_freeList;
		_freeList = NextObj(_freeList);
	
	else
	
		//保证对象能够存储得下地址
		size_t objSize = sizeof(T) < sizeof(void*) ? sizeof(void*) : sizeof(T);
		//剩余内存不够一个对象大小时，则重新开大块空间
		if (_remainBytes < objSize)
		
			_remainBytes = 128 * 1024;
			_memory = (char*)SystemAlloc(_remainBytes >> 13);
			if (_memory == nullptr)
			
				throw std::bad_alloc();
			
		
		//从大块内存中切出objSize字节的内存
		obj = (T*)_memory;
		_memory += objSize;
		_remainBytes -= objSize;
	
	//定位new，显示调用T的构造函数初始化
	new(obj)T;

	return obj;

需要注意的是，与释放对象时需要显示调用该对象的析构函数一样，当内存块切分出来后，我们也应该使用定位new，显示调用该对象的构造函数对其进行初始化。

定长内存池整体代码如下：

//定长内存池
template<class T>
class ObjectPool

public:
	//申请对象
	T* New()
	
		T* obj = nullptr;

		//优先把还回来的内存块对象，再次重复利用
		if (_freeList != nullptr)
		
			//从自由链表头删一个对象
			obj = (T*)_freeList;
			_freeList = NextObj(_freeList);
		
		else
		
			//保证对象能够存储得下地址
			size_t objSize = sizeof(T) < sizeof(void*) ? sizeof(void*) : sizeof(T);
			//剩余内存不够一个对象大小时，则重新开大块空间
			if (_remainBytes < objSize)
			
				_remainBytes = 128 * 1024;
				//_memory = (char*)malloc(_remainBytes);
				_memory = (char*)SystemAlloc(_remainBytes >> 13);
				if (_memory == nullptr)
				
					throw std::bad_alloc();
				
			
			//从大块内存中切出objSize字节的内存
			obj = (T*)_memory;
			_memory += objSize;
			_remainBytes -= objSize;
		
		//定位new，显示调用T的构造函数初始化
		new(obj)T;

		return obj;
	
	//释放对象
	void Delete(T* obj)
	
		//显示调用T的析构函数清理对象
		obj->~T();

		//将释放的对象头插到自由链表
		NextObj(obj) = _freeList;
		_freeList = obj;
	
private:
	char* _memory = nullptr;     //指向大块内存的指针
	size_t _remainBytes = 0;     //大块内存在切分过程中剩余字节数

	void* _freeList = nullptr;   //还回来过程中链接的自由链表的头指针
;

性能对比

下面我们将实现的定长内存池和malloc/free进行性能对比，测试代码如下：

struct TreeNode

	int _val;
	TreeNode* _left;
	TreeNode* _right;
	TreeNode()
		:_val(0)
		, _left(nullptr)
		, _right(nullptr)
	
;

void TestObjectPool()

	// 申请释放的轮次
	const size_t Rounds = 3;
	// 每轮申请释放多少次
	const size_t N = 1000000;
	std::vector<TreeNode*> v1;
	v1.reserve(N);

	//malloc和free
	size_t begin1 = clock();
	for (size_t j = 0; j < Rounds; ++j)
	
		for (int i = 0; i < N; ++i)
		
			v1.push_back(new TreeNode);
		
		for (int i = 0; i < N; ++i)
		
			delete v1[i];
		
		v1.clear();
	
	size_t end1 = clock();

	//定长内存池
	ObjectPool<TreeNode> TNPool;
	std::vector<TreeNode*> v2;
	v2.reserve(N);
	size_t begin2 = clock();
	for (size_t j = 0; j < Rounds; ++j)
	
		for (int i = 0; i < N; ++i)
		
			v2.push_back(TNPool.New());
		
		for (int i = 0; i < N; ++i)
		
			TNPool.Delete(v2[i]);
		
		v2.clear();
	
	size_t end2 = clock();

	cout << "new cost time:" << end1 - begin1 << endl;
	cout << "object pool cost time:" << end2 - begin2 << endl;

在代码中，我们先用new申请若干个TreeNode对象，然后再用delete将这些对象再释放，通过clock函数得到整个过程消耗的时间。（new和delete底层就是封装的malloc和free）

然后再重复该过程，只不过将其中的new和delete替换为定长内存池当中的New和Delete，此时再通过clock函数得到该过程消耗的时间。

可以看到在这个过程中，定长内存池消耗的时间比malloc/free消耗的时间要短。这就是因为malloc是一个通用的内存池，而定长内存池是专门针对申请定长对象而设计的，因此在这种特殊场景下定长内存池的效率更高，正所谓“尺有所短，寸有所长”。

高并发内存池整体框架设计

该项目解决的是什么问题？

现代很多的开发环境都是多核多线程，因此在申请内存的时，必然存在激烈的锁竞争问题。malloc本身其实已经很优秀了，但是在并发场景下可能会因为频繁的加锁和解锁导致效率有所降低，而该项目的原型tcmalloc实现的就是一种在多线程高并发场景下更胜一筹的内存池。

在实现内存池时我们一般需要考虑到效率问题和内存碎片的问题，但对于高并发内存池来说，我们还需要考虑在多线程环境下的锁竞争问题。

高并发内存池整体框架设计

高并发内存池主要由以下三个部分构成：

thread cache： 线程缓存是每个线程独有的，用于小于等于256KB的内存分配，每个线程独享一个thread cache。
central cache： 中心缓存是所有线程所共享的，当thread cache需要内存时会按需从central cache中获取内存，而当thread cache中的内存满足一定条件时，central cache也会在合适的时机对其进行回收。
page cache： 页缓存中存储的内存是以页为单位进行存储及分配的，当central cache需要内存时，page cache会分配出一定数量的页分配给central cache，而当central cache中的内存满足一定条件时，page cache也会在合适的时机对其进行回收，并将回收的内存尽可能的进行合并，组成更大的连续内存块，缓解内存碎片的问题。

进一步说明：

每个线程都有一个属于自己的thread cache，也就意味着线程在thread cache申请内存时是不需要加锁的，而一次性申请大于256KB内存的情况是很少的，因此大部分情况下申请内存时都是无锁的，这也就是这个高并发内存池高效的地方。

每个线程的thread cache会根据自己的情况向central cache申请或归还内存，这就避免了出现单个线程的thread cache占用太多内存，而其余thread cache出现内存吃紧的问题。

多线程的thread cache可能会同时找central cache申请内存，此时就会涉及线程安全的问题，因此在访问central cache时是需要加锁的，但central cache实际上是一个哈希桶的结构，只有当多个线程同时访问同一个桶时才需要加锁，所以这里的锁竞争也不会很激烈。

各个部分的主要作用

thread cache主要解决锁竞争的问题，每个线程独享自己的thread cache，当自己的thread cache中有内存时该线程不会去和其他线程进行竞争，每个线程只要在自己的thread cache申请内存就行了。

central cache主要起到一个居中调度的作用，每个线程的thread cache需要内存时从central cache获取，而当thread cache的内存多了就会将内存还给central cache，其作用类似于一个中枢，因此取名为中心缓存。

page cache就负责提供以页为单位的大块内存，当central cache需要内存时就会去向page cache申请，而当page cache没有内存了就会直接去找系统，也就是直接去堆上按页申请内存块。

threadcache

threadcache整体设计

定长内存池只支持固定大小内存块的申请释放，因此定长内存池中只需要一个自由链表管理释放回来的内存块。现在我们要支持申请和释放不同大小的内存块，那么我们就需要多个自由链表来管理释放回来的内存块，因此thread cache实际上一个哈希桶结构，每个桶中存放的都是一个自由链表。

thread cache支持小于等于256KB内存的申请，如果我们将每种字节数的内存块都用一个自由链表进行管理的话，那么此时我们就需要20多万个自由链表，光是存储这些自由链表的头指针就需要消耗大量内存，这显然是得不偿失的。

这时我们可以选择做一些平衡的牺牲，让这些字节数按照某种规则进行对齐，例如我们让这些字节数都按照8字节进行向上对齐，那么thread cache的结构就是下面这样的，此时当线程申请1~8字节的内存时会直接给出8字节，而当线程申请9~16字节的内存时会直接给出16字节，以此类推。

因此当线程要申请某一大小的内存块时，就需要经过某种计算得到对齐后的字节数，进而找到对应的哈希桶，如果该哈希桶中的自由链表中有内存块，那就从自由链表中头删一个内存块进行返回；如果该自由链表已经为空了，那么就需要向下一层的central cache进行获取了。

但此时由于对齐的原因，就可能会产生一些碎片化的内存无法被利用，比如线程只申请了6字节的内存，而thread cache却直接给了8字节的内存，这多给出的2字节就无法被利用，导致了一定程度的空间浪费，这些因为某些对齐原因导致无法被利用的内存，就是内存碎片中的内部碎片。

鉴于当前项目比较复杂，我们最好对自由链表这个结构进行封装，目前我们就提供Push和Pop两个成员函数，对应的操作分别是将对象插入到自由链表（头插）和从自由链表获取一个对象（头删），后面在需要时还会添加对应的成员函数。

//管理切分好的小对象的自由链表
class FreeList

public:
	//将释放的对象头插到自由链表
	void Push(void* obj)
	
		assert(obj);

		//头插
		NextObj(obj) = _freeList;
		_freeList = obj;
	

	//从自由链表头部获取一个对象
	void* Pop()
	
		assert(_freeList);

		//头删
		void* obj = _freeList;
		_freeList = NextObj(_freeList);
		return obj;
	

private:
	void* _freeList = nullptr; //自由链表
;

因此thread cache实际就是一个数组，数组中存储的就是一个个的自由链表，至于这个数组中到底存储了多少个自由链表，就需要看我们在进行字节数对齐时具体用的是什么映射对齐规则了。

threadcache哈希桶映射对齐规则

如何进行对齐？

上面已经说了，不是每个字节数都对应一个自由链表，这样开销太大了，因此我们需要制定一个合适的映射对齐规则。

首先，这些内存块是会被链接到自由链表上的，因此一开始肯定是按8字节进行对齐是最合适的，因为我们必须保证这些内存块，无论是在32位平台下还是64位平台下，都至少能够存储得下一个指针。

但如果所有的字节数都按照8字节进行对齐的话，那么我们就需要建立 $256\\times1024\\div8=32768$ 个桶，这个数量还是比较多的，实际上我们可以让不同范围的字节数按照不同的对齐数进行对齐，具体对齐方式如下：

字节数	对齐数	哈希桶下标
$[$ $1 ， 128$ $]$	$8$	$[$ $0 ， 16)$
$[$ $128 + 1 ， 1024$ $]$	$16$	$[$ $16 ， 72)$
$[$ $1024+1，8\\times1024$ $]$	$128$	$[$