高并发内存池（四）Page Cache的框架及内存申请实现

[一、Page Cache的框架梳理](#一、Page Cache的框架梳理)

[二、Page Cache的实现](#二、Page Cache的实现)

2.1PageCache.h

2.2VirtualAlloc

[2.3std::unordered_map _idSpanMap,>](#2.3std::unordered_map _idSpanMap,>)

[2.4Page Cache.cpp](#2.4Page Cache.cpp)

一、Page Cache的框架梳理

申请内存：

**1.**当central cache向page cache申请内存时，page cache先检查对应位置有没有span，如果没有则向更大页寻找一个span，如果找到则分裂成两个。比如：申请的是4页page，4页page后面没有挂span，则向后面寻找更大的span，假设在10页page位置找到一个span，则将10页page span分裂为一个4页page span和一个6页page span。

2. 如果找到_spanList[128]都没有合适的span，则向系统使用mmap、brk或者是VirtualAlloc等方式申请128页page span挂在自由链表中，再重复1中的过程。

**3.**需要注意的是central cache和page cache 的核心结构都是spanlist的哈希桶，但是他们是有本质区别的，central cache中哈希桶，是按跟thread cache一样的大小对齐关系映射的，他的spanlist 中挂的span中的内存都被按映射关系切好链接成小块内存的自由链表。而page cache 中的 spanlist则是按下标桶号映射的，也就是说第i号桶中挂的span都是i页内存。

二、Page Cache的实现

2.1PageCache.h

PageCache中也同样采用了单例模式，和互斥锁。但PageCache不同于centralcache，只有一个全局锁，thread和central哈希桶中挂的链表结构都是彼此单独管理不会相互影响，而PageCache中的桶是根据页数来直接映射的 ，从1-128大小的页（一页是8kb），刚开始page向进程地址空间中的堆进行申请时，直接申请的就是一大页，所以内存池刚跑起来时，整个SpanList中只有最大的那个桶中有一个128*8kb的大页，而小页都是由大页切出来的，将大页切小以后放到对应页所在的桶里，所以整个pagecache桶都是动态进行变化 的。
当线程顺着Central找到Pagecache后会根据用户申请的内存大小计算出要去Page Cache的哪个桶去切那个桶的Span中的页，如果目标桶没有就从当前桶往下去一层一层查找大页桶里是否有内存，如果有就切出自己想要的小页内存，然后将剩下的放到另一个桶中。如果此时有桶锁，多个线程同时去查找切分再放回去，就会导致频繁的加锁解锁，反而降低了效率。所以在PageCache中直接挂一把整个单例的大锁，每次只允许一个线程访问。

cpp 复制代码

class PageCache
{
public:
	static PageCache* GetInstance()
	{
		return &_sInst;
	}

	//获取当前地址到span的映射
	Span* MapObjectToSpan(void* obj);

	// 释放空闲span回到Pagecache，并合并相邻的span
	void ReleaseSpanToPageCache(Span* span);


	Span* NewSpan(size_t k);//获取一个新的span并返回给CentralCache

	std::mutex _pageMtx;

private:
	SpanList _spanList[NPAGES];//按一个span的页数来存放span，从1页到128页，下标从1-128，带上0号下标不存数据一共129个桶

	std::unordered_map<PAGE_ID, Span*> _idSpanMap;

	PageCache()
	{}
	PageCache(const PageCache&) = delete;

	static PageCache _sInst;//创建单例模式，因为PageCache也是全局共享的
};

2.2VirtualAlloc

VirtualAlloc是一个Windows API 函数，该函数的功能是在调用进程的虚地址空间,预定或者提交一部分页。当Page Cache内存不够时，就可以调用该函数来直接向堆申请内存。

简单点的意思就是申请内存空间。VirtualAlloc这个函数保证申请的大页内存都是页框大小的整数倍。也就是说起始地址就是8kb的整数倍开始的。所以我们在代码中直接将分配来的地址/8kb来计算页号时，也就不用担心移位操作导致地址低位丢失的问题。

cpp 复制代码

//直接去堆上申请空间
inline static void* SystemAlloc(size_t kpage)
{
#ifdef _WIN32
	void* ptr = VirtualAlloc(0, kpage << 13, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
#else
	//linux 下调用其他
#endif
	if (ptr == nullptr)
		throw std::bad_alloc();

	return ptr;
}

2.3std::unordered_map<PAGE_ID, Span*> _idSpanMap

与Central Cache和Thread Cache有所不同的是，Page Cache中的成员变量管理内存块的SpanList _spanList[NPAGES]，还有另一个哈希结构，unordered_map<PAGE_ID, Span*> _idSpanMap;

其作用是为了将页号固定映射到对应的span，和freelist的内存对齐一样，页号也存在对齐，VirtualAlloc申请的内存全是页框大小的整数倍。而因为central cache在向thread cache分配切好的小块span时，这个线程需要就从头部区内存块给这个线程，而另一个线程来了就要分给另一个线程。

所以多线程环境下，线程中每个freelist中的小块内存可能并不是连续的，而在回收内存时无论是在central cache层还是page cache层，其内存块中的地址都是连续的，所以Thread Cache释放的小块内存都需要将其回归到Central Cache中原本它所在的Span当中，当Span中的数据都回来时，就可以合成一个（多个）完整的页，而要想让小块内存回到原本的Span，就需要找到这个给小块内存的页号是和哪个Span所对应的，而为了方便寻找，直接在切分时就对每一页的页号做映射，将页号直接与span地址进行映射方便回收时查找span，直接通过推算得出小块内存页号后直接找到对应Span地址。

所以在Page Cache中有一个哈希表，专门记录分配下去的Span中所存储的起始页号和该Span的映射关系。为之后我们的回收逻辑的实现做铺垫。

2.4Page Cache.cpp

首先要实现的是NewSpan，用于处理Central Cache发来的内存申请请求，并返回一个Span，根据Central Cache所要申请的页的个数，去对应的桶中拿取，如果桶里有就直接返回给Central Cache，如果没有就去存放更大的页的桶里切对应的小页，并且建立切走的页的起始页号以及根据切走了多少页，将每一页都和要返回给Central Cache的Span建立映射关系。然后将切出来的Span返回给Central Cache，将切剩下的页根据存放其Span中剩余页的总数头插到对应的桶中。

cpp 复制代码

#include "PageCache.h"

PageCache PageCache::_sInst;

Span* PageCache::NewSpan(size_t k)//需要找到span为k页的那个桶
{
	assert(k > 0 && k < NPAGES);
	if (!_spanList[k].Empty())
	{
		return _spanList[k].PopFront();//如果该桶下不为空，就将第一个span返回给central cache
	}
	for (size_t i = k + 1; i < NPAGES; i++)
	{
		//假设找到的桶内有n页，将其切分成一个k页的span和一个n-k页的span
		//k页的span返回给central cache
		//n-k页的span挂到第n-k个桶
		if (!_spanList[i].Empty())
		{
			Span* nSpan = _spanList[i].PopFront();//程序第一次刚运行走到这里时，此时i对应的一定是127，也就是第128个桶
			Span* kSpan = new Span; 

			//在nSpan头部切一个k页下来
			kSpan->_pageId = nSpan->_pageId;
			kSpan->_n = k;//将新创建的Span中的页设置成我们需要的页的大小
			
			nSpan->_pageId += k;//取走k页是从当前Span头部切出k页，然后原本nSpan所指向的页号就要往后走k页,这样在之后对页号进行转换时就可以直接转换出切走k页后的页号
			nSpan->_n -= k;//nSpan中页的数量减少k
			//注意：这里只是抽象的说从nspan头部且一块下来，实际上切的不是nspan，
			//而是nsapn中的页号（由地址/8k所得到的页号），切实际上就是将页号往后移，从而改变Span中保存的地址

			//而这里存储nspan中的首位页号映射到nspan也是为了更好的方便page cache回收内存时进行的合并查找
			_idSpanMap[nSpan->_pageId] = nSpan;
			_idSpanMap[nSpan->_pageId + nSpan->_n - 1] = nSpan;

			//将每页id和当前所持有该页的span建立映射，方便central cache回收小块内存时，查找对应的Span
			for (size_t i = 0; i < kSpan->_n; ++i)
			{
				_idSpanMap[kSpan->_pageId + i] = kSpan;
			}
			_spanList[nSpan->_n].PushFront(nSpan);

			return kSpan;
		}
	}

	//走到这个位置就说明后面没有大页的span
	//这时就去找堆要一个128页的span,然后再根据centralcache的需求将其切成不同的小页span，然后分别放入对应的桶中
	Span* bigSpan = new Span; 
	void* ptr = SystemAlloc(NPAGES - 1); 

	bigSpan->_pageId = (PAGE_ID)ptr >> PAGE_SHIFT;
	bigSpan->_n = NPAGES - 1;//此时当前Span中的页数是128页

	_spanList[bigSpan->_n].PushFront(bigSpan);//根据当前span所持有的页数，将当前span插入到对应的桶中

	return NewSpan(k);//这下128页所对应的桶中已经有内存了，再走一遍递归逻辑去128页对应的桶中切k页
}

//说明在PageCache.h
//直接拿着地址换算出页号(直接就是对齐)
//virtualalloc申请的内存起始就是8k的整数被
//比如起始内存除8k=1
//那么从起始地址往后的8k-1个地址除8K得出的也都是1.xxx，除完还是1
Span* PageCache::MapObjectToSpan(void* obj)
{
	PAGE_ID id = ((PAGE_ID)obj >> PAGE_SHIFT);
	auto ret = _idSpanMap.find(id);
	if (ret != _idSpanMap.end())
	{
		return ret->second;
	}
	else
	{
		assert(false);
		return nullptr;
	}
}