【项目设计】--- 高并发内存池设计（二）-CSDN博客

本文链接：https://blog.csdn.net/weixin_75128035/article/details/147384921

【项目设计】--- 高并发内存池设计（二）

一、高并发内存池整体框架设计
二、threadcache
三、centralcache
四、pagecache
- 1、pagecache整体设计
- 2、pagecache中获取Span
五、申请内存过程联调

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

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

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

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

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

在这里插入图片描述

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

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申请内存时是不需要加锁的（TLS无锁访问），而一次性申请大于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

1、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实际就是一个数组，数组中存储的就是一个个的自由链表，至于这个数组中到底存储了多少个自由链表，就需要看我们在进行字节数对齐时具体用的是什么映射对齐规则了。

2、threadcache哈希桶映射对齐规则

如何进行对齐？

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

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

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

空间浪费率

虽然对齐产生的内碎片会引起一定程度的空间浪费，但按照上面的对齐规则，我们可以将浪费率控制到百分之十左右。需要说明的是，1~128这个区间我们不做讨论，因为1字节就算是对齐到2字节也有百分之五十的浪费率，这里我们就从第二个区间开始进行计算。

浪费率= 对齐后的字节数/浪费的字节数

对齐和映射相关函数的编写

此时有了字节数的对齐规则后，我们就需要提供两个对应的函数，分别用于获取某一字节数对齐后的字节数，以及该字节数对应的哈希桶下标。关于“处理对齐”和“映射的函数”，我们可以将其封装到一个类当中。

//管理对齐和映射等关系
class SizeClass
{
public:
	//获取向上对齐后的字节数
	static inline size_t RoundUp(size_t bytes);
	//获取对应哈希桶的下标
	static inline size_t Index(size_t bytes);
};

需要注意的是，SizeClass类当中的成员函数最好设置为静态成员函数，否则我们在调用这些函数时就需要通过对象去调用，并且对于这些可能会频繁调用的函数，可以考虑将其设置为内联函数。

在获取某一字节数向上对齐后的字节数时，可以先判断该字节数属于哪一个区间，然后再通过调用一个子函数进行进一步处理。

// 这个函数的作用：获取向上对齐后的字节数
static inline size_t RoundUp(size_t size)
{
	if(size<=128)
	{
		return _RoundUp(size, 8);
	}
	else if (size <= 1024)
	{
		return _RoundUp(size, 16);
	}
	else if (size <= 8 * 1024)
	{
		return _RoundUp(size, 128);
	}
	else if (size <= 64 * 1024)
	{
		return _RoundUp(size, 1024);
	}
	else if (size <= 256 * 1024)
	{
		return _RoundUp(size,8 * 1024);
	}
	else
	{
		assert(false);
		return -1;
	}
}

此时我们就需要编写一个子函数，该子函数需要通过对齐数计算出某一字节数对齐后的字节数，最容易想到的就是下面这种写法。

 // 正常人都会这样想
size_t _RoundUp(size_t size, size_t AlignNum)
{
	size_t AlignSize;
	if (size % AlignNum != 0)
	{
		AlignSize = (size / AlignNum + 1) * AlignNum;
	}
	else
	{
		AlignSize = size;// 如果正好能对齐，那就用他自己的size
	}
	return AlignSize;
}

除了上述写法，我们还可以通过位运算的方式来进行计算，虽然位运算可能并没有上面的写法容易理解，但计算机执行位运算的速度是比执行乘法和除法更快的。

// 高手写的代码：利用位运算 一定 比实际的/ 和 % 运算更加快速！
static inline size_t _RoundUp(size_t bytes, size_t AlignNum)
{
	return (bytes + AlignNum - 1) & ~(AlignNum - 1);
}

在获取某一字节数对应的哈希桶下标时，也是先判断该字节数属于哪一个区间，然后再通过调用一个子函数进行进一步处理

static inline size_t Index(size_t bytes)
{
	assert(bytes <= MAX_TYPES);

	// 这里的数组是从第二个区间对齐数所对应的桶开始的，第1个是8个桶，然后依次在后面加即可
	static int group_arr[4] = { 16,56,56,56 };

	if (bytes <= 128)
	{
		return _Index(bytes, 3);
	}
	else if (bytes <= 1024)
	{
		return _Index(bytes-128, 4)+group_arr[0];
	}
	else if (bytes <= 8 * 1024)
	{
		return _Index(bytes - 1024, 7) + group_arr[0]+ group_arr[1];
	}
	else if (bytes <= 64 * 1024)
	{
		return _Index(bytes - 8 * 1024, 10) + group_arr[0] + group_arr[1]+ group_arr[2];
	}
	else if (bytes <= 256 * 1024)
	{
		return _Index(bytes - 64 * 1024, 13) + group_arr[0] + group_arr[1] + group_arr[2] + group_arr[3];
	}
	else
	{
		assert(false);
		return -1;
	}
}

此时我们需要编写一个子函数来继续进行处理，容易想到的就是根据对齐数来计算某一字节数对应的下标。
一般写法：

// 正常人思维：
size_t _Index(size_t bytes, size_t alignNum)
{
	if (bytes % alignNum == 0)
	{
		return bytes / alignNum - 1;
	}
	else
	{
		return bytes / alignNum;
	}
}

当然，为了提高效率下面也提供了一个用位运算来解决的方法，需要注意的是，此时我们并不是传入该字节数的对齐数，而是将对齐数写成2的n次方的形式后，将这个n值进行传入。比如对齐数是8，传入的就是3。

// 高手写的代码：找到size在哪个哈希桶
static inline size_t _Index(size_t bytes, size_t align_shift)
{
	return (bytes + (1 << align_shift) - 1 >> align_shift) - 1;
}

ThreadCache类

按照上述的对齐规则，thread cache中桶的个数，也就是自由链表的个数是208，以及thread cache允许申请的最大内存大小256KB，我们可以将这些数据按照如下方式进行定义。

//小于等于MAX_BYTES，就找thread cache申请
//大于MAX_BYTES，就直接找page cache或者系统堆申请
static const size_t MAX_BYTES = 256 * 1024;
//thread cache和central cache自由链表哈希桶的表大小
static const size_t NFREELISTS = 208;

现在就可以对ThreadCache类进行定义了，thread cache就是一个存储208个自由链表的数组，目前thread cache就先提供一个Allocate函数用于申请对象就行了，后面需要时再进行增加。

class ThreadCache
{
public:
	//申请内存对象
	void* Allocate(size_t size);

private:
	FreeList _freeLists[NFREELISTS]; //哈希桶
};

在thread cache获取（申请）对象时，通过所给字节数计算出对应的哈希桶下标，如果桶中自由链表不为空，则从该自由链表中取出一个对象进行返回即可；但如果此时自由链表为空，那么我们就需要从central cache进行获取了，这里的FetchFromCentralCache函数也是thread cache类中的一个成员函数，在后面再进行具体实现。

//申请内存对象
void* ThreadCache::Allocate(size_t size)
{
	assert(size <= MAX_BYTES);
	size_t alignSize = SizeClass::RoundUp(size);
	size_t index = SizeClass::Index(size);
	if (!_freeLists[index].Empty())
	{
		return _freeLists[index].Pop();
	}
	else
	{
		return FetchFromCentralCache(index, alignSize);
	}
}

3、threadcacheTLS无锁访问

每个线程都有一个自己独享的thread cache，那应该如何创建这个thread cache呢？我们不能将这个thread cache创建为全局的，因为全局变量是所有线程共享的，这样就不可避免的需要锁来控制，增加了控制成本和代码复杂度。

要实现每个线程无锁的访问属于自己的thread cache，我们需要用到线程局部存储TLS(Thread Local Storage)，这是一种变量的存储方法，使用该存储方法的变量在它所在的线程是全局可访问的，但是不能被其他线程访问到，这样就保持了数据的线程独立性。

//TLS - Thread Local Storage
static _declspec(thread) ThreadCache* pTLSThreadCache = nullptr;

但不是每个线程被创建时就立马有了属于自己的thread cache，而是当该线程调用相关申请内存的接口时才会创建自己的thread cache，因此在申请内存的函数中会包含以下逻辑。

//通过TLS，每个线程无锁的获取自己专属的ThreadCache对象
if (pTLSThreadCache == nullptr)
{
	pTLSThreadCache = new ThreadCache;
}

三、centralcache

1、centralcache整体设计

当线程申请某一大小的内存时，如果thread cache中对应的自由链表不为空，那么直接取出一个内存块进行返回即可，但如果此时该自由链表为空，那么这时thread cache就需要向central cache申请内存了。

central cache的结构与thread cache是一样的，它们都是哈希桶的结构，并且它们遵循的对齐映射规则都是一样的。这样做的好处就是，当thread cache的某个桶中没有内存了，就可以直接到central cache中对应的哈希桶里去取内存就行了。

central cache与thread cache的不同之处

central cache与thread cache有两个明显不同的地方，首先，thread cache是每个线程独享的，而central cache是所有线程共享的，因为每个线程的thread cache没有内存了都会去找central cache，因此在访问central cache时是需要加锁的。

但central cache在加锁时并不是将整个central cache全部锁上了，central cache在加锁时用的是桶锁，也就是说每个桶都有一个锁。此时只有当多个线程同时访问central cache的同一个桶时才会存在锁竞争，如果是多个线程同时访问central cache的不同桶就不会存在锁竞争

central cache与thread cache的第二个不同之处就是，thread cache的每个桶中挂的是一个个切好的内存块，而central cache的每个桶中挂的是一个个的span。（span就是一整个内存页）

在这里插入图片描述

每个span管理的都是一个以页为单位的大块内存，每个桶里面的若干span是按照双向带头循环链表的形式链接起来的，并且每个span里面还有一个自由链表，这个自由链表里面挂的就是一个个切好了的内存块，根据其所在的哈希桶这些内存块被切成了对应的大小。

2、centralcache结构设计

页号的类型？

在这里插入图片描述

// 通过条件编译，PAGE_ID 在32位下是4字节，64位下是8字节
#ifdef _WIN64
	typedef unsigned long long PAGE_ID;

#elif _WIN32
	typedef size_t PAGE_ID;// 在X64位时，是不会走到这个的 直接就是隐形了
#endif

需要注意的是，在32位下，_WIN32有定义，_WIN64没有定义；而在64位下，_WIN32和_WIN64都有定义。因此在条件编译时，我们应该先判断_WIN64是否有定义，再判断_WIN32是否有定义。

span的结构

central cache的每个桶里挂的是一个个的span，span是一个管理以页为单位的大块内存，span的结构如下：

// 管理多个连续页大块内存跨度结构(是一个双向带头循环的链表)
struct Span
{
	PAGE_ID _page_id = 0;// 大块内存起始页的页号 (Span的id顺序)
	size_t _n = 0;// span的数量

	Span* prev = nullptr;// 带头双向循环链表的 前和后
	Span* next = nullptr;

	size_t _useCount = 0;// 连接在span下面的被切好的小内存块，分配给ThreadCache的计数
	void* _freeList = nullptr;// 切好的小内存块的自由链表

	// 都给一些缺省值 再调用默认构造的时候直接使用缺省值

	size_t _objSize = 0;// 优化：在释放对象的函数里面不传大小！(切好小块对象的大小)

	bool _isUse = false;// 在pageCache合并的时候，需要判断即将要合并的Span有没有正在被上一层使用，(默认false就是没有被使用！)
};

对于span管理的以页为单位的大块内存，我们需要知道这块内存具体在哪一个位置，便于之后page cache进行前后页的合并，因此span结构当中会记录所管理大块内存起始页的页号。
至于每一个span管理的到底是多少个页，这并不是固定的，需要根据多方面的因素来控制，因此span结构当中有一个_n成员，该成员就代表着该span管理的页的数量。
此外，每个span管理的大块内存，都会被切成相应大小的内存块挂到当前span的自由链表中，比如8Byte哈希桶中的span，会被切成一个个8Byte大小的内存块挂到当前span的自由链表中，因此span结构中需要存储切好的小块内存的自由链表。
span结构当中的_useCount成员记录的就是，当前span中切好的小块内存，被分配给thread cache的计数，当某个span的_useCount计数变为0时，代表当前span切出去的内存块对象全部还回来了，此时central cache就可以将这个span再还给page cache。
每个桶当中的span是以双链表的形式组织起来的，当我们需要将某个span归还给page cache时，就可以很方便的将该span从双链表结构中移出。如果用单链表结构的话就比较麻烦了，因为单链表在删除时，需要知道当前结点的前一个结点。

双链表结构

根据上面的描述，central cache的每个哈希桶里面存储的都是一个双链表结构，对于该双链表结构我们可以对其进行封装。

// 管理多个span，把他们以：带头双向 循环链表的形式连接起来
class SpanList
{
public:
	SpanList()
	{
		_head = new Span;
		_head->prev = _head;
		_head->next = _head;
	}

	Span* Begin()
	{
		return _head->next;
	}
	Span* End()
	{
		return _head;
	}

	bool Empty()
	{
		return _head == _head->next;
	}


	void PushFront(Span* span)// 头插
	{
		Insert(Begin(), span);
	}

	Span* PopFront()
	{
		Span* front = _head->next;// 记录一下头
		Erase(front);// 解除
		return front;// 弹出
	}

	void Insert(Span* pos, Span* newSpan)// 在pos位置之前插入一个newspan
	{
		assert(pos);
		assert(newSpan);


		Span* prev = pos->prev;

		prev->next = newSpan;
		newSpan->prev = prev;

		newSpan->next = pos;
		pos->prev = newSpan;
	}

	void Erase(Span* pos)
	{
		assert(pos);
		assert(pos != _head);//不能删除哨兵位的头结点

		Span* prev = pos->prev;
		Span* next = pos->next;

		prev->next = next;
		next->prev = prev;
	}

private:
	Span* _head;
public:
	std::mutex _mtx;// 桶锁
};

需要注意的是，从双链表删除（Erase）的span会还给下一层的page cache，相当于只是把这个span从双链表中移除，因此不需要对删除的span进行delete操作。

central cache的结构

central cache的映射规则和thread cache是一样的，因此central cache里面哈希桶的个数也是208，但central cache每个哈希桶中存储就是我们上面定义的双链表结构。

class CentralCache
{
public:
	//...
private:
	SpanList _spanLists[NFREELISTS];
};

central cache和thread cache的映射规则一样，有一个好处就是，当thread cache的某个桶没有内存了，就可以直接去central cache对应的哈希桶进行申请就行了。

3、centralcache核心实现

central cache的实现方式

每个线程都有一个属于自己的thread cache，我们是用TLS来实现每个线程无锁的访问属于自己的thread cache的。而central cache和page cache在整个进程中只有一个，对于这种只能创建一个对象的类，我们可以将其设置为单例模式。

单例模式可以保证系统中该类只有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。单例模式又分为饿汉模式和懒汉模式，懒汉模式相对较复杂，我们这里使用饿汉模式就足够了。

//单例模式
class CentralCache
{
public:
	//提供一个全局访问点
	static CentralCache* GetInstance()
	{
		return &_sInst;
	}
private:
	SpanList _spanLists[NFREELISTS];
private:
	CentralCache() //构造函数私有
	{}
	CentralCache(const CentralCache&) = delete; //防拷贝

	static CentralCache _sInst;
};

为了保证CentralCache类只能创建一个对象，我们需要将central cache的构造函数和拷贝构造函数设置为私有，或者在C++11中也可以在函数声明的后面加上=delete进行修饰。

CentralCache类当中还需要有一个CentralCache类型的静态的成员变量，当程序运行起来后我们就立马创建该对象，在此后的程序中就只有这一个单例了。

CentralCache CentralCache::_sInst;

最后central cache还需要提供一个公有的成员函数，用于获取该对象，此时在整个进程中就只会有一个central cache对象了。

慢开始反馈调节算法

当thread cache向central cache申请内存时，central cache应该给出多少个对象呢？这是一个值得思考的问题，如果central cache给的太少，那么thread cache在短时间内用完了又会来申请；但如果一次性给的太多了，可能thread cache用不完也就浪费了。

鉴于此，我们这里采用了一个慢开始反馈调节算法。当thread cache向central cache申请内存时，如果申请的是较小的对象，那么可以多给一点，但如果申请的是较大的对象，就可以少给一点。

通过下面这个函数，我们就可以根据所需申请的对象的大小计算出具体给出的对象个数，并且可以将给出的对象个数控制到2~512个之间。也就是说，就算thread cache要申请的对象再小，我最多一次性给出512个对象；就算thread cache要申请的对象再大，我至少一次性给出2个对象。

//管理对齐和映射等关系
class SizeClass
{
public:
	//thread cache一次从central cache获取对象的上限
	static size_t NumMoveSize(size_t size)
	{
		assert(size > 0);
	
		//对象越小，计算出的上限越高
		//对象越大，计算出的上限越低
		int num = MAX_BYTES / size;
		if (num < 2)
			num = 2;
		if (num > 512)
			num = 512;
	
		return num;
	}
};

但就算申请的是小对象，一次性给出512个也是比较多的，基于这个原因，我们可以在FreeList结构中增加一个叫做_maxSize的成员变量，该变量的初始值设置为1，并且提供一个公有成员函数用于获取这个变量。也就是说，现在thread cache中的每个自由链表都会有一个自己的_maxSize。

//管理切分好的小对象的自由链表
class FreeList
{
public:
	size_t& MaxSize()
	{
		return _maxSize;
	}

private:
	void* _freeList = nullptr; //自由链表
	size_t _maxSize = 1;
};

此时当thread cache申请对象时，我们会比较_maxSize和计算得出的值，取出其中的较小值作为本次申请对象的个数。此外，如果本次采用的是_maxSize的值，那么还会将thread cache中该自由链表的_maxSize的值进行加一。

因此，thread cache第一次向central cache申请某大小的对象时，申请到的都是一个，但下一次thread cache再向central cache申请同样大小的对象时，因为该自由链表中的_maxSize增加了，最终就会申请到两个。直到该自由链表中_maxSize的值，增长到超过计算出的值后就不会继续增长了，此后申请到的对象个数就是计算出的个数。（这有点像网络中拥塞控制的机制）

从CentralCache获取对象

每次thread cache向central cache申请对象时，我们先通过慢开始反馈调节算法计算出本次应该申请的对象的个数，然后再向central cache进行申请。

如果thread cache最终申请到对象的个数就是一个，那么直接将该对象返回即可。为什么需要返回一个申请到的对象呢？因为thread cache要向central cache申请对象，其实由于某个线程向thread cache申请对象但thread cache当中没有，这才导致thread cache要向central cache申请对象。因此central cache将对象返回给thread cache后，thread cache会再将该对象返回给申请对象的线程。

但如果thread cache最终申请到的是多个对象，那么除了将第一个对象返回之外，还需要将剩下的对象挂到thread cache对应的哈希桶当中。

//从中心缓存获取对象
void* ThreadCache::FetchFromCentralCache(size_t index, size_t size)
{
	//慢开始反馈调节算法
	//1、最开始不会一次向central cache一次批量要太多，因为要太多了可能用不完
	//2、如果你不断有size大小的内存需求，那么batchNum就会不断增长，直到上限
	size_t batchNum = std::min(_freeLists[index].MaxSize(), SizeClass::NumMoveSize(size));
	if (batchNum == _freeLists[index].MaxSize())
	{
		_freeLists[index].MaxSize() += 1;
	}
	void* start = nullptr;
	void* end = nullptr;
	size_t actualNum = CentralCache::GetInstance()->FetchRangeObj(start, end, batchNum, size);
	assert(actualNum >= 1); //至少有一个

	if (actualNum == 1) //申请到对象的个数是一个，则直接将这一个对象返回即可
	{
		assert(start == end);
		return start;
	}
	else //申请到对象的个数是多个，还需要将剩下的对象挂到thread cache中对应的哈希桶中
	{
		_freeLists[index].PushRange(NextObj(start), end);
		return start;
	}
}

从中心缓存获取一定数量的对象

这里我们要从central cache获取n个指定大小的对象，这些对象肯定都是从central cache对应哈希桶的某个span中取出来的，因此取出来的这n个对象是链接在一起的，我们只需要得到这段链表的头和尾即可，这里可以采用输出型参数进行获取。

// 从CentralCache 获取一定数量的对象给ThreadCache
size_t CentralCache::FetchRangeObj(void*& start, void*& end, size_t batchNum, size_t size)
{
	// 那么此时线程就进CentralCache来拿内存，在ThreadCache不同位置的哈希桶，对应相应的在CentralCache里面的哈希桶
	// 所以你得先找到对应的位置

	size_t index = SizeClass::Index(size);

	// 上锁才能操作！
	_spanLists[index]._mtx.lock();

	Span* span = GetOneSpan(_spanLists[index], size);// 通过GetOneSpan函数来获取一个span

	// 获取到之后 先断言，获取到的span为非空&&span下面挂有内存块
	assert(span);
	assert(span->_freeList);

	// 如何从非空的span里面获取batchNum个内存块？
	// 1、start指向span的第一个位置
	// 2、end往后走batchNum-1步
	// 3、span的next指向end的next
	// 4、end的next指向nullptr
	start = span->_freeList;
	end = start;

	size_t actualNum = 1;// 把actualNum赋值为1的原因：因为已经断言span为非空了，肯定至少能分配出去一个，而且刚开始end就指向start
	// 用这个来标记实际上到底有多少个内存块分配出去（因为span下面连接的可能不到batch个，所以有多少拿多少）
	size_t i = 0;
	while (i < batchNum-1 && NextObj(end) != nullptr)// 如果end的next==nullptr那么在使用end的next的时候就会出现野指针，所以一定要避免让end的next指向nullptr
	{
		end = NextObj(end);
		++i;
		++actualNum;
	}
	span->_freeList = NextObj(end);
	NextObj(end) = nullptr;

	span->_useCount += actualNum;

	_spanLists[index]._mtx.unlock();



	return actualNum;
}

在这里插入图片描述
对代码进行解释说明：

由于central cache是所有线程共享的，所以我们在访问central cache中的哈希桶时，需要先给对应的哈希桶加上桶锁，在获取到对象后再将桶锁解掉。
在向central cache获取对象时，先是在central cache对应的哈希桶中获取到一个非空的span，然后从这个span的自由链表中取出n个对象即可，但可能这个非空的span的自由链表当中对象的个数不足n个，这时该自由链表当中有多少个对象就给多少就行了
也就是说，thread cache实际从central cache获得的对象的个数可能与我们传入的n值是不一样的，因此我们需要统计本次申请过程中，实际thread cache获取到的对象个数，然后根据该值及时更新这个span中的小对象被分配给thread cache的计数。（actualNum存在的意义）
需要注意的是，虽然我们实际申请到对象的个数可能比n要小，但这并不会产生任何影响。因为thread cache的本意就是向central cache申请一个对象，我们之所以要一次多申请一些对象，是因为这样一来下次线程再申请相同大小的对象时就可以直接在thread cache里面获取了，而不用再向central cache申请对象。

插入一段范围的对象到自由链表

此外，如果thread cache最终从central cache获取到的对象个数是大于一的，那么我们还需要将剩下的对象插入到thread cache中对应的哈希桶中，为了能让自由链表支持插入一段范围的对象，我们还需要在FreeList类中增加一个对应的成员函数。

//管理切分好的小对象的自由链表
class FreeList
{
public:
	//插入一段范围的对象到自由链表
	void PushRange(void* start, void* end)
	{
		assert(start);
		assert(end);
		
		// 因为从CentralCache中取到的是一段小内存块，头是start，尾是end
// 我们将这块连续的内存块“头插”到treadCache里面，要保证：小内存块的顺序正确性，小内存块end的next指向那个freelist
		//头插
		NextObj(end) = _freeList;
		_freeList = start;
	}
private:
	void* _freeList = nullptr; //自由链表
	size_t _maxSize = 1;
};

四、pagecache

1、pagecache整体设计

page cache与central cache结构的相同之处

page cache与central cache一样，它们都是哈希桶的结构，并且page cache的每个哈希桶中里挂的也是一个个的span，这些span也是按照双链表的结构链接起来的。

page cache与central cache结构的不同之处

首先，central cache的映射规则与thread cache保持一致，而page cache的映射规则与它们都不相同。page cache的哈希桶映射规则采用的是直接定址法，比如1号桶挂的都是1页的span，2号桶挂的都是2页的span，以此类推。
其次，central cache每个桶中的span被切成了一个个对应大小的对象，以供thread cache申请。而page cache当中的span是没有被进一步切小的，因为page cache服务的是central cache，当central cache没有span时，向page cache申请的是某一固定页数的span，而如何切分申请到的这个span就应该由central cache自己来决定。

至于page cache当中究竟有多少个桶，这就要看你最大想挂几页的span了，这里我们就最大挂128页的span，为了让桶号与页号对应起来，我们可以将第0号桶空出来不用，因此我们需要将哈希桶的个数设置为129。

//page cache中哈希桶的个数
static const size_t NPAGES = 129;

为什么这里最大挂128页的span呢？因为线程申请单个对象最大是256KB，而128页可以被切成4个256KB的对象，因此是足够的。当然，如果你想在page cache中挂更大的span也是可以的，根据具体的需求进行设置就行了

在page cache获取一个n页的span的过程

如果central cache要获取一个n页的span，那我们就可以在page cache的第n号桶中取出一个span返回给central cache即可，但如果第n号桶中没有span了，这时我们并不是直接转而向堆申请一个n页的span，而是要继续在后面的桶当中寻找span。
直接向堆申请以页为单位的内存时，我们应该尽量申请大块一点的内存块，因为此时申请到的内存是连续的，当线程需要内存时我们可以将其切小后分配给线程，而当线程将内存释放后我们又可以将其合并成大块的连续内存。如果我们向堆申请内存时是小块小块的申请的，那么我们申请到的内存就不一定是连续的了。
因此，当第n号桶中没有span时，我们可以继续找第n+1号桶，因为我们可以将n+1页的span切分成一个n页的span和一个1页的span，这时我们就可以将n页的span返回，而将切分后1页的span挂到1号桶中。但如果后面的桶当中都没有span，这时我们就只能向堆申请一个128页的内存块，并将其用一个span结构管理起来，然后将128页的span切分成n页的span和128-n页的span，其中n页的span返回给central cache，而128-n页的span就挂到第128-n号桶中。
也就是说，我们每次向堆申请的都是128页大小的内存块，central cache要的这些span实际都是由128页的span切分出来的。

page cache的实现方式

当每个线程的thread cache没有内存时都会向central cache申请，此时多个线程的thread cache如果访问的不是central cache的同一个桶，那么这些线程是可以同时进行访问的。这时central cache的多个桶就可能同时向page cache申请内存的，所以page cache也是存在线程安全问题的，因此在访问page cache时也必须要加锁。
但是在page cache这里我们不能使用桶锁，因为当central cache向page cache申请内存时，page cache可能会将其他桶当中大页的span切小后再给central cache。此外，当central cache将某个span归还给page cache时，page cache也会尝试将该span与其他桶当中的span进行合并。
也就是说，在访问page cache时，我们可能需要访问page cache中的多个桶，如果page cache用桶锁就会出现大量频繁的加锁和解锁，导致程序的效率低下。因此我们在访问page cache时使用没有使用桶锁，而是用一个大锁将整个page cache给锁住。
而thread cache在访问central cache时，只需要访问central cache中对应的哈希桶就行了，因为central cache的每个哈希桶中的span都被切分成了对应大小，thread cache只需要根据自己所需对象的大小访问central cache中对应的哈希桶即可，不会访问其他哈希桶，因此central cache可以用桶锁

此外，page cache在整个进程中也是只能存在一个的，因此我们也需要将其设置为单例模式。

//单例模式
class PageCache
{
public:
	//提供一个全局访问点
	static PageCache* GetInstance()
	{
		return &_sInst;
	}
private:
	SpanList _spanLists[NPAGES];
	std::mutex _pageMtx; //大锁
private:
	PageCache() //构造函数私有
	{}
	PageCache(const PageCache&) = delete; //防拷贝

	static PageCache _sInst;
};

当程序运行起来后我们就立马创建该对象即可。

PageCache PageCache::_sInst;

2、pagecache中获取Span

获取一个非空的span

thread cache向central cache申请对象时，central cache需要先从对应的哈希桶中获取到一个非空的span，然后从这个非空的span中取出若干对象返回给thread cache。那central cache到底是如何从对应的哈希桶中，获取到一个非空的span的呢？

首先当然是先遍历central cache对应哈希桶当中的双链表，如果该双链表中有非空的span，那么直接将该span进行返回即可。为了方便遍历这个双链表，我们可以模拟迭代器的方式，给SpanList类提供Begin和End成员函数，分别用于获取双链表中的第一个span和最后一个span的下一个位置，也就是头结点。

//带头双向循环链表
class SpanList
{
public:
	Span* Begin()
	{
		return _head->_next;
	}
	Span* End()
	{
		return _head;
	}
private:
	Span* _head;
public:
	std::mutex _mtx; //桶锁
};

但如果遍历双链表后发现双链表中没有span，或该双链表中的span都为空，那么此时central cache就需要向page cache申请内存块了。

那具体是向page cache申请多大的内存块呢？我们可以根据具体所需对象的大小来决定，就像之前我们根据对象的大小计算出，thread cache一次向central cache申请对象的个数上限，现在我们是根据对象的大小计算出，central cache一次应该向page cache申请几页的内存块。

我们可以先根据对象的大小计算出，thread cache一次向central cache申请对象的个数上限，然后将这个上限值乘以单个对象的大小，就算出了具体需要多少字节，最后再将这个算出来的字节数转换为页数，如果转换后不够一页，那么我们就申请一页，否则转换出来是几页就申请几页。也就是说，central cache向page cache申请内存时，要求申请到的内存尽量能够满足thread cache向central cache申请时的上限。

//管理对齐和映射等关系
class SizeClass
{
public:
	//central cache一次向page cache获取多少页
	static size_t NumMovePage(size_t size)
	{
		size_t num = NumMoveSize(size); //计算出thread cache一次向central cache申请对象的个数上限
		size_t nPage = num*size; //num个size大小的对象所需的字节数

		nPage >>= PAGE_SHIFT; //将字节数转换为页数
		if (nPage == 0) //至少给一页
			nPage = 1;

		return nPage;
	}
};

代码中的PAGE_SHIFT代表页大小转换偏移，我们这里以页的大小为8K为例，PAGE_SHIFT的值就是13

//页大小转换偏移，即一页定义为2^13，也就是8KB
static const size_t PAGE_SHIFT = 13;

需要注意的是，当central cache申请到若干页的span后，还需要将这个span切成一个个对应大小的对象挂到该span的自由链表当中。
如何找到一个span所管理的内存块呢？首先需要计算出该span的起始地址，我们可以用这个span的起始页号乘以一页的大小即可得到这个span的起始地址，然后用这个span的页数乘以一页的大小就可以得到这个span所管理的内存块的大小，用起始地址加上内存块的大小即可得到这块内存块的结束位置。
明确了这块内存的起始和结束位置后，我们就可以进行切分了。根据所需对象的大小，每次从大块内存切出一块固定大小的内存块尾插到span的自由链表中即可。
为什么是尾插呢？因为我们如果是将切好的对象尾插到自由链表，这些对象看起来是按照链式结构链接起来的，而实际它们在物理上是连续的，这时当我们把这些连续内存分配给某个线程使用时，可以提高该线程的CPU缓存利用率。

//获取一个非空的span
Span* CentralCache::GetOneSpan(SpanList& spanList, size_t size)
{
	//1、先在spanList中寻找非空的span
	Span* it = spanList.Begin();
	while (it != spanList.End())
	{
		if (it->_freeList != nullptr)
		{
			return it;
		}
		else
		{
			it = it->_next;
		}
	}

	//2、spanList中没有非空的span，只能向page cache申请
	Span* span = PageCache::GetInstance()->NewSpan(SizeClass::NumMovePage(size));
	//计算span的大块内存的起始地址和大块内存的大小（字节数）
	char* start = (char*)(span->_pageId << PAGE_SHIFT);
	size_t bytes = span->_n << PAGE_SHIFT;

	//把大块内存切成size大小的对象链接起来
	char* end = start + bytes;
	//先切一块下来去做尾，方便尾插
	span->_freeList = start;
	start += size;
	void* tail = span->_freeList;
	//尾插
	while (start < end)
	{
		NextObj(tail) = start;
		tail = NextObj(tail);
		start += size;
	}
	NextObj(tail) = nullptr; //尾的指向置空
	
	//将切好的span头插到spanList
	spanList.PushFront(span);

	return span;
}

需要注意的是，当我们把span切好后，需要将这个切好的span挂到central cache的对应哈希桶中。因此SpanList类还需要提供一个接口，用于将一个span插入到该双链表中。这里我们选择的是头插，这样当central cache下一次从该双链表中获取非空span时，一来就能找到

由于SpanList类之前实现了Insert和Begin函数，这里实现双链表头插就非常简单，直接在双链表的Begin位置进行Insert即可

//带头双向循环链表
class SpanList
{
public:
	void PushFront(Span* span)// 头插
	{
		Insert(Begin(), span);
	}



	void Insert(Span* pos, Span* newSpan)// 在pos位置之前插入一个newspan
	{
		assert(pos);
		assert(newSpan);


		Span* prev = pos->prev;

		prev->next = newSpan;
		newSpan->prev = prev;

		newSpan->next = pos;
		pos->prev = newSpan;
	}
private:
	Span* _head;
public:
	std::mutex _mtx; //桶锁
};

获取一个k页的span

当我们调用上述的GetOneSpan从central cache的某个哈希桶获取一个非空的span时，如果遍历哈希桶中的双链表后发现双链表中没有span，或该双链表中的span都为空，那么此时central cache就需要向page cache申请若干页的span了，下面我们就来说说如何从page cache获取一个k页的span。
因为page cache是直接按照页数进行映射的，因此我们要从page cache获取一个k页的span，就应该直接先去找page cache的第k号桶，如果第k号桶中有span，那我们直接头删一个span返回给central cache就行了。所以我们这里需要再给SpanList类添加对应的Empty和PopFront函数。

// 管理多个span，把他们以：带头双向 循环链表的形式连接起来
class SpanList
{
public:
	SpanList()
	{
		_head = new Span;
		_head->prev = _head;
		_head->next = _head;
	}

	Span* Begin()
	{
		return _head->next;
	}
	Span* End()
	{
		return _head;
	}

	bool Empty()
	{
		return _head == _head->next;
	}


	void PushFront(Span* span)// 头插
	{
		Insert(Begin(), span);
	}

	Span* PopFront()
	{
		Span* front = _head->next;// 记录一下头
		Erase(front);// 解除
		return front;// 弹出
	}

	void Insert(Span* pos, Span* newSpan)// 在pos位置之前插入一个newspan
	{
		assert(pos);
		assert(newSpan);


		Span* prev = pos->prev;

		prev->next = newSpan;
		newSpan->prev = prev;

		newSpan->next = pos;
		pos->prev = newSpan;
	}

	void Erase(Span* pos)
	{
		assert(pos);
		assert(pos != _head);

		Span* prev = pos->prev;
		Span* next = pos->next;

		prev->next = next;
		next->prev = prev;
	}

private:
	Span* _head;


public:
	std::mutex _mtx;// 桶锁
};

如果page cache的第k号桶中没有span，我们就应该继续找后面的桶，只要后面任意一个桶中有一个n页span，我们就可以将其切分成一个k页的span和一个n-k页的span，然后将切出来k页的span返回给central cache，再将n-k页的span挂到page cache的第n-k号桶即可。
但如果后面的桶中也都没有span，此时我们就需要向堆申请一个128页的span了，在向堆申请内存时，直接调用我们封装的SystemAlloc函数即可。
需要注意的是，向堆申请内存后得到的是这块内存的起始地址，此时我们需要将该地址转换为页号。由于我们向堆申请内存时都是按页进行申请的，因此我们直接将该地址除以一页的大小即可得到对应的页号。

// 获取一个“具有第k页规格”的Span
Span* PageCache::NewSpan(size_t k)
{
	assert(k > 0 && k < NPAGES);


	// 如果k>128，直接去堆上要
	if (k > NPAGES - 1)
	{
		void* ptr = SystemAlloc(k);

		//Span* span = new Span;
		Span* span = _spanPool.New();

		span->_page_id = (PAGE_ID)ptr >> PAGE_SHIFT;// 更新一下页数和ID
		span->_n = k;

		_idSpanMap[span->_page_id] = span;// 就算是>128的也要映射到哈希表，进行缓存

		return span;
	}




	// 1、先在对应的第k页的桶里面找一下有没有Span
	if (!_spanlists[k].Empty())
		return _spanlists->PopFront();

	// 2、就在后面的桶里面找一找有没有Span
	for (size_t i = k + 1; i < NPAGES; ++i)
	{
		if (!_spanlists[i].Empty())
		{
			Span* nspan = _spanlists[i].PopFront();// 如果当前_spanlists[i]！=empty，那就直接头删弹出一个Span当做nspan

			//Span* kspan = new Span;

			Span* kspan = _spanPool.New();

			// 在nsapn的头部切一个k页下来
			kspan->_page_id = nspan->_page_id;// 这里其实就相当于把nspan的起始地址直接赋值给kspan
			kspan->_n = k;// kspan的个数就是k啊

			nspan->_page_id += k;// nspan对应的起始地址，往后走k步
			nspan->_n -= k;// nspan的数量_n对应-k个

			// 然后把剩余的n-k页的Span挂到对应的位置！
			_spanlists[nspan->_n].PushFront(nspan);


			// 在回收之前，先储存要合并页的首尾页号！
			// 方便pageCache在回收时，进行合并查找！
			_idSpanMap[nspan->_page_id] = nspan;// 首
			_idSpanMap[nspan->_page_id + nspan->_n - 1] = nspan;// 尾

			// 建立id和Span的映射关系，方便CentralCache回收内存块时便于查找对应的Span
			for (PAGE_ID i = 0; i < kspan->_n; i++)// kspan是切割出出去的span，所以你回收肯定要小于你切割出去的!
			{
				_idSpanMap[kspan->_n + i] = kspan;// kspan->_n + i这是<PAGE_ID，Span>的PAGE_ID，kspan是<PAGE_ID，Span>里面的Span！
			}

			return kspan;// 这是返回给CentralCache的
		}
	}

	// 走到这里就说明：整个PageCache都是空空如也！没有一个Span
	// 就不得不向系统直接申请一个128页的Span
	// 
	// 
	// (这里需要注意：第XXX个桶，第XXX页的Span，实际上就是该哈希桶下面挂的每一个Span的规格大小)

	//Span* bigSpan = new Span;
	Span* bigSpan = _spanPool.New();

	void* ptr = SystemAlloc(NPAGES - 1);
	bigSpan->_page_id = (PAGE_ID)ptr >> PAGE_SHIFT;
	bigSpan->_n = NPAGES - 1;

	_spanlists[bigSpan->_n].PushFront(bigSpan);
	// 递归调用
	return NewSpan(k);

}

这里说明一下，当我们向堆申请到128页的span后，需要将其切分成k页的span和128-k页的span，但是为了尽量避免出现重复的代码，我们最好不要再编写对应的切分代码。我们可以先将申请到的128页的span挂到page cache对应的哈希桶中，然后再递归调用该函数就行了，此时在往后找span时就一定会在第128号桶中找到该span，然后进行切分。
这里其实有一个问题：当central cache向page cache申请内存时，central cache对应的哈希桶是处于加锁的状态的，那在访问page cache之前我们应不应该把central cache对应的桶锁解掉呢？
这里建议在访问page cache前，先把central cache对应的桶锁解掉。虽然此时central cache的这个桶当中是没有内存供其他thread cache申请的，但thread cache除了申请内存还会释放内存，如果在访问page cache前将central cache对应的桶锁解掉，那么此时当其他thread cache想要归还内存到central cache的这个桶时就不会被阻塞。
因此在调用NewSpan函数之前，我们需要先将central cache对应的桶锁解掉，然后再将page cache的大锁加上，当申请到k页的span后，我们需要将page cache的大锁解掉，但此时我们不需要立刻获取到central cache中对应的桶锁。因为central cache拿到k页的span后还会对其进行切分操作，因此我们可以在span切好后需要将其挂到central cache对应的桶上时，再获取对应的桶锁。

这里为了让代码清晰一点，只写出了加锁和解锁的逻辑，我们只需要将这些逻辑添加到之前实现的GetOneSpan函数的对应位置即可。

spanList._mtx.unlock(); //解桶锁
PageCache::GetInstance()->_pageMtx.lock(); //加大锁

//从page cache申请k页的span

PageCache::GetInstance()->_pageMtx.unlock(); //解大锁

//进行span的切分...

spanList._mtx.lock(); //加桶锁，(还原为原来的样子)

//将span挂到central cache对应的哈希桶

五、申请内存过程联调

ConcurrentAlloc函数

在将thread cache、central cache以及page cache的申请流程写通了之后，我们就可以向外提供一个ConcurrentAlloc函数，用于申请内存块。每个线程第一次调用该函数时会通过TLS获取到自己专属的thread cache对象，然后每个线程就可以通过自己对应的thread cache申请对象了。

static void* ConcurrentAlloc(size_t size)
{
	//通过TLS，每个线程无锁的获取自己专属的ThreadCache对象
	if (pTLSThreadCache == nullptr)
	{
		pTLSThreadCache = new ThreadCache;
	}
	return pTLSThreadCache->Allocate(size);
}

这里说一下编译时会出现的问题，在C++的algorithm头文件中有一个min函数，这是一个函数模板，而在Windows.h头文件中也有一个min，这是一个宏。由于调用函数模板时需要进行参数类型的推演，因此当我们调用min函数时，编译器会优先匹配Windows.h当中以宏的形式实现的min，此时当我们以std::min的形式调用min函数时就会产生报错，这就是没有用命名空间进行封装的坏处，这时我们只能选择将std::去掉，让编译器调用Windows.h当中的min

申请内存过程联调测试一

由于在多线程场景下调试观察起来非常麻烦，这里就先不考虑多线程场景，看看在单线程场景下代码的执行逻辑是否符合我们的预期，其次，我们这里就只简单观察在一个桶当中的内存申请就行了。

下面该线程进行了三次内存申请，这三次内存申请的字节数最终都对齐到了8，此时当线程申请内存时就只会访问到thread cache的第0号桶。

void* p1 = ConcurrentAlloc(6);
void* p2 = ConcurrentAlloc(8);
void* p3 = ConcurrentAlloc(1);

当线程第一次申请内存时，该线程需要通过TLS获取到自己专属的thread cache对象，然后通过这个thread cache对象进行内存申请。
在这里插入图片描述

在申请内存时通过计算索引到了thread cache的第0号桶，但此时thread cache的第0号桶中是没有对象的，因此thread cache需要向central cache申请内存块。
在这里插入图片描述
在向central cache申请内存块前，首先通过NumMoveSize函数计算得出，thread cache一次最多可向central cache申请8字节大小对象的个数是512，但由于我们采用的是慢开始算法，因此还需要将上限值与对应自由链表的_maxSize的值进行比较，而此时对应自由链表_maxSize的值是1，所以最终得出本次thread cache向central cache申请8字节对象的个数是1个。

并且在此之后会将该自由链表中_maxSize的值进行自增，下一次thread cache再向central cache申请8字节对象时最终申请对象的个数就会是2个了。

在这里插入图片描述
在thread cache向central cache申请对象之前，需要先将central cache的0号桶的锁加上，然后再从该桶获取一个非空的span。

在这里插入图片描述
在central cache的第0号桶获取非空span时，先遍历对应的span双链表，看看有没有非空的span，但此时肯定是没有的，因此在这个过程中我们无法找到一个非空的span。

那么此时central cache就需要向page cache申请内存了，但在此之前需要先把central cache第0号桶的锁解掉，然后再将page cache的大锁给加上，之后才能向page cache申请内存。

在这里插入图片描述
在向page cache申请内存时，由于central cache一次给thread cache8字节对象的上限是512，对应就需要4096字节，所需字节数不足一页就按一页算，所以这里central cache就需要向page cache申请一页的内存块。

在这里插入图片描述
但此时page cache的第1个桶以及之后的桶当中都是没有span的，因此page cache需要直接向堆申请一个128页的span。

在这里插入图片描述
这里通过监视窗口可以看到，用于管理申请到的128页内存的span信息。

我们可以顺便验证一下，按页向堆申请的内存块的起始地址和页号之间是可以相互转换的。

在这里插入图片描述
现在将申请到的128页的span插入到page cache的第128号桶当中，然后再调用一次NewSpan，在这次调用的时候，虽然在1号桶当中没有span，但是在往后找的过程中就一定会在第128号桶找到一个span。

在这里插入图片描述
此时我们就可以把这个128页的span拿出来，切分成1页的span和127页的span，将1页的span返回给central cache，而把127页的span挂到page cache的第127号桶即可。

在这里插入图片描述
从page cache返回后，就可以把page cache的大锁解掉了，但紧接着还要将获取到的1页的span进行切分，因此这里没有立刻重新加上central cache对应的桶锁。

在进行切分的时候，先通过该span的起始页号得到该span的起始地址，然后通过该span的页数得到该span所管理内存块的总的字节数。
在这里插入图片描述
在确定内存块的开始和结束后，就可以将其切分成一个个8字节大小的对象挂到该span的自由链表中了。在调试过程中通过内存监视窗口可以看到，切分出来的每个8字节大小的对象的前四个字节存储的都是下一个8字节对象的起始地址。
在这里插入图片描述
当切分结束后再获取central cache第0号桶的桶锁，然后将这个切好的span插入到central cache的第0号桶中，最后再将这个非空的span返回，此时就获取到了一个非空的span。

由于thread cache只向central cache申请了一个对象，因此拿到这个非空的span后，直接从这个span里面取出一个对象即可，此时该span的_useCount也由0变成了1。
在这里插入图片描述
由于此时thread cache实际只向central cache申请到了一个对象，因此直接将这个对象返回给线程即可。

当线程第二次申请内存块时就不会再创建thread cache了，因为第一次申请时就已经创建好了，此时该线程直接获取到对应的thread cache进行内存块申请即可。
在这里插入图片描述
当该线程第二次申请8字节大小的对象时，此时thread cache的0号桶中还是没有对象的，因为第一次thread cache只向central cache申请了一个8字节对象，因此这次申请时还需要再向central cache申请对象。

这时thread cache向central cache申请对象时，thread cache第0号桶中自由链表的_maxSize已经慢增长到2了，所以这次在向central cache申请对象时就会申请2个。如果下一次thread cache再向central cache申请8字节大小的对象，那么central cache会一次性给thread cache3个，这就是所谓的慢增长。
在这里插入图片描述
但由于第一次central cache向page cache申请了一页的内存块，并将其切成了1024个8字节大小的对象，因此这次thread cache向central cache申请2两个8字节的对象时，central cache的第0号桶当中是有对象的，直接返回两个给thread cache即可，而不用再向page cache申请内存了。

但线程实际申请的只是一个8字节对象，因此thread cache除了将一个对象返回之外，还需要将剩下的一个对象挂到thread cache的第0号桶当中。

在这里插入图片描述

这样一来，当线程第三次申请1字节的内存时，由于1字节对齐后也是8字节，此时thread cache也就不需要再向central cache申请内存块了，直接将第0号桶当中之前剩下的一个8字节对象返回即可。在这里插入图片描述

申请内存过程联调测试二

为了进一步测试代码的正确性，我们可以做这样一个测试：让线程申请1024次8字节的对象，然后通过调试观察在第1025次申请时，central cache是否会再向page cache申请内存块。

for (size_t i = 0; i < 1024; i++)
{
	void* p1 = ConcurrentAlloc(6);
}
void* p2 = ConcurrentAlloc(6);

因为central cache第一次就是向page cache申请的一页内存，这一页内存被切成了1024个8字节大小的对象，当这1024个对象全部被申请之后，再申请8字节大小的对象时central cache当中就没有对象了，此时就应该向page cache申请内存块。

通过调试我们可以看到，第1025次申请8字节大小的对象时，central cache第0号桶中的这个span的_useCount已经增加到了1024，也就是说这1024个对象都已经被线程申请了，此时central cache就需要再向page cache申请一页的span来进行切分了。
在这里插入图片描述
而这次central cache在向page cache申请一页的内存时，page cache就是将127页span切分成了1页的span和126页的span了，然后central cache拿到这1页的span后，又会将其切分成1024块8字节大小的内存块以供thread cache申请。