PFS_PAGE_SIZE//每个pag的大小,global_thrad_containr中默认为56PFS_PAGE_COUNT//pag的最大个数，global_thrad_containr中默认为56classPFS_buffr_scalabl_containr{PFS_cachlin_atomic_siz_tm_monotonic;//单调递增的原子变量，用于无锁选择pagPFS_cachlin_atomic_siz_tm_max_pag_indx;//当前已分配的最大pagindxsiz_tm_max_pag_count;//最大pag个数，超过后将不再分配新pagstd::atomicarray_typ*m_pags[PFS_PAGE_COUNT];//pag数组nativ_mutx_tm_critical_sction;//创建新pag时需要的一把锁}首先m_pags是一个数组，每个pag都可能有fr的rcords，也有可能整个pag都是busy的，Mysql采用了比较简单的策略，轮训挨个尝试每个pag是否有空闲，直到分配成功。如果轮训所有pags依然没有分配成功，这个时候就会创建新的pag来扩充，直到达到pag数的上限。轮训并不是每次都是从第个pag开始寻找，而是使用原子变量m_monotonic记录的位置开始查找，m_monotonic在每次在pag中分配失败是加。核心简化代码如下：
valu_typ*allocat(pfs_dirty_stat*dirty_stat){currnt_pag_count=m_max_pag_indx.m_siz_t.load();monotonic=m_monotonic.m_siz_t.load();monotonic_max=monotonic+currnt_pag_count;whil(monotonicmonotonic_max){indx=monotonic%currnt_pag_count;array=m_pags[indx].load();pfs=array-allocat(dirty_stat);if(pfs){//分配成功返回rturnpfs;}ls{//分配失败，尝试下一个pag，//因为m_monotonic是并发累加的，这里有可能本地monotonic变量并不是线性递增的，有可能是从直接变为3或更大，//所以当前whil循环并不是严格轮训所有pag，很大可能是跳着尝试，换者说这里并发访问下大家一起轮训所有的pag。//这个算法其实是有些问题的，会导致某些pag被跳过忽略，从而加剧扩容新pag的几率，后面会详细分析。monotonic=m_monotonic.m_siz_t++;}}//轮训所有Pag后没有分配成功，如果没有达到上限的话，开始扩容pagwhil(currnt_pag_countm_max_pag_count){//因为是并发访问，为了避免同时去创建新pag，这里有一个把同步锁，也是整个PFS内存分配唯一的锁nativ_mutx_lock(m_critical_sction);//拿锁成功，如果array已经不为null，说明已经被其它线程创建成功array=m_pags[currnt_pag_count].load();if(array==nullptr){//抢到了创建pag的责任m_allocator-alloc_array(array);m_pags[currnt_pag_count].stor(array);++m_max_pag_indx.m_siz_t;}nativ_mutx_unlock(m_critical_sction);//在新的pag中再次尝试分配pfs=array-allocat(dirty_stat);if(pfs){//分配成功并返回rturnpfs;}//分配失败，继续尝试创建新的pag直到上限}}我们再详细分析下轮训pag策略的问题，因为m_momotonic原子变量的累加是并发的，会导致一些pag被跳过轮训它，从而加剧了扩容新pag的几率。举一个极端一些的例子，比较容易说明问题，假设当前一共有4个pag，第、4个pag已满无可用rcord，第、3个pag有可用rcord。当同时来了4个线程并发Allocat请求，同时拿到了的m_monotonic=0.monotonic=m_monotonic.m_siz_t.load();这个时候所有线程尝试从第个pag分配rcord都会失败(因为第个pag是无可用rcord)，然后累加去尝试下一个pagmonotonic=m_monotonic.m_siz_t++;这个时候问题就来了，因为原子变量++是返回最新的值，4个线程++成功是有先后顺序的，第个++的线程后monotonic值为，第个++的线程为3，以次类推。这样就看到第3、4个线程跳过了pag和pag3，导致3、4线程会轮训结束失败进入到创建新pag的流程里，但这个时候pag和pag3里是有空闲rcord可以使用的。虽然上述例子比较极端，但在Mysql并发访问中，同时申请PFS内存导致跳过一部分pag的情况应该还是非常容易出现的。3Pag内Rcord选择策略PFS_buffr_dfault_array是每个Pag维护一组rcords的管理类。关键数据结构如下：
classPFS_buffr_dfault_array{PFS_cachlin_atomic_siz_tm_monotonic;//单调递增原子变量，用来选择fr的rcordsiz_tm_max;//rcord的最大个数T*m_ptr;//rcord对应的PFS对象，比如PFS_thrad}每个Pag其实就是一个定长的数组，每个rcord对象有3个状态FREE，DIRTY,ALLOCATED，FREE表示空闲rcord可以使用，ALLOCATED是已分配成功的，DIRTY是一个中间状态，表示已被占用但还没分配成功。Rcord的选择本质就是轮训查找并抢占状态为fr的rcord的过程。核心简化代码如下：
valu_typ*allocat(pfs_dirty_stat*dirty_stat){//从m_monotonic记录的位置开始尝试轮序查找monotonic=m_monotonic.m_siz_t++;monotonic_max=monotonic+m_max;whil(monotonicmonotonic_max){indx=monotonic%m_max;pfs=m_ptr+indx;//m_lock是pfs_lock结构，fr/dirty/allocatd三状态是由这个数据结构来维护的//后面会详细介绍它如何实现原子状态迁移的if(pfs-m_lock.fr_to_dirty(dirty_stat)){rturnpfs;}//当前rcord不为fr,原子变量++尝试下一个monotonic=m_monotonic.m_siz_t++;}}选择rcord的主体主体流程和选择pag基本相似，不同的是pag内rcord数量是固定不变的，所以没有扩容的逻辑。当然选择策略相同，也会有同样的问题，这里的m_monotonic原子变量++是多线程并发的，同样如果并发大的场景下会有rcord被跳过选择了，这样导致pag内部即便有fr的rcord也可能没有被选中。所以也就是pag选择即便是没有被跳过，pag内的rcord也有几率被跳过而选不中，雪上加霜，更加加剧了内存的增长。4pfs_lock每个rcord都有一个pfs_lock，来维护它在pag中的分配状态(fr/dirty/allocatd)，以及vrsion信息。关键数据结构：structpfs_lock{std::atomicm_vrsion_stat;}pfs_lock使用个3位无符号整型来保存vrsion+stat信息，格式如下：stat低位字节表示分配状态。statPFS_LOCK_FREE=0x00statPFS_LOCK_DIRTY=0x0statPFS_LOCK_ALLOCATED=0xvrsion初始vrsion为0，每分配成功一次加，vrsion就能表示该rcord被分配成功的次数主要看一下状态迁移代码：
//下面3个宏主要就是用来位操作的，方便操作stat或vrsion#dfinVERSION_MASK0xFFFFFFFC#dfinSTATE_MASK0x#dfinVERSION_INC4boolfr_to_dirty(pfs_dirty_stat*copy_ptr){uint3old_val=m_vrsion_stat.load();//判断当前stat是否为FREE，如果不是，直接返回失败if((old_valSTATE_MASK)!=PFS_LOCK_FREE){rturnfals;}uint3nw_val=(old_valVERSION_MASK)+PFS_LOCK_DIRTY;//当前stat为fr，尝试将stat修改为dirty，atomic_