揭秘重度MMORPG手游后台性能优化方案

本文节选自《2018腾讯移动游戏技术评审标准与实践案例》手册，由腾讯互娱工程师王杰分享《仙剑奇侠传online》项目中游戏后台的优化经验，深度解析寻路算法、视野管理、内存优化、同步优化等常见问题。

1、服务器CPU性能优化

1.1寻路算法JPS优化

MMORPG游戏中服务器中须要对NPC寻路，然而A*算法及其各类优化并不让人满意，所以寻路算法也成为瓶颈之一。

所以，本文介绍JPS的效率、多线程、内存、路径优化算法。为了测试搜索算法的优化性能，实验中设置游戏场景使得起点和终点差距200个格子，须要寻路104次。结果发现，A*寻路总时间约2.6074x1011纳秒（一秒为109纳秒）；基础版JPS寻路总时间1.7037x1010纳秒；利用位运算优化的JPS（下文称JPS-Bit）寻路总时间3.2364x109纳秒；利用位运算和剪枝优化的JPS（下文称JPS-BitPrune）寻路总时间2.3703x109纳秒；利用位运算和预处理的JPS（下文称JPS-BitPre）寻路总时间2.0043x109纳秒；利用位运算、剪枝和预处理三个优化的JPS（下文称JPS-BitPrunePre）寻路总时间9.5434x108纳秒。

上述结果代表，寻路200个格子的路径，JPS的五个版本，平均消耗时间分别为1.7毫秒、0.32毫秒、0.23毫秒、0.02毫秒、0.095毫秒，寻路速度分别为A*算法的15倍、81倍、110倍、130倍、273倍，大幅度超越A*算法，标志着寻路已经不会成为性能的瓶颈。

事实上，在2012到2014年举办的三届（目前为止只有三届）基于Grid网格寻路的比赛GPPC（The Grid-Based Path Planning Competition）中，JPS已经被证实是基于无权重格子，在没有预处理的状况下寻路最快的算法。

1.1.1 JPS算法介绍

JPS又名跳点搜索算法（Jump Point Search），是由澳大利亚两位教授于2011年提出的基于Grid格子的寻路算法。A*算法总体流程如表1.1.1.1.1所示，JPS算法在保留A*算法的框架的同时，进一步优化了A*算法寻找后继节点的操做。为了说明JPS在A*基础上的具体优化策略，咱们在图1.1.1.1.1中给出A*和JPS的算法流程图对比。由图1.1.1.1.1看出，JPS与A*算法主要区别在后继节点拓展策略上，不一样于A*算法中直接获取当前节点全部非关闭的可达邻居节点来进行拓展的策略，JPS根据当前结点current的方向、并基于跳点的策略来扩展后继节点，遵循“两个定义、三个规则”（见表1.1.1.1.2，两个定义肯定强迫邻居、跳点，三个规则肯定节点的拓展原则），具体流程以下：

一，若current当前方向是直线方向：

（1）若是current左后方不可走且左方可走（即左方是强迫邻居），则沿current左前方和左方寻找不在closedset的跳点；

（2）若是current当前方向可走，则沿current当前方向寻找不在closed集合的跳点；

（3）若是current右后方不可走且右方可走（右方是强迫邻居），则沿current右前方和右方寻找不在closedset的跳点；

二，若current当前方向为对角线方向：

（1）若是current当前方向的水平份量可走（例如current当前为东北方向，则水平份量为东），则沿current当前方向的水平份量寻找不在closedset的跳点；

（2）若是current当前方向可走，则沿current当前方向寻找不在closedset的跳点；

（3）若是current当前方向的垂直份量可走（例如current当前为东北方向，则垂直份量为北），则沿current当前方向的垂直份量寻找不在closedset的跳点。

JPS寻找跳点的过程有三种优化：一，位运算；二；预处理；三；剪枝中间跳点。

<ignore_js_op>

 

图1.1.1.1.1 A*和JPS的算法流程图对比

<ignore_js_op>

 

表1.1.1.1.1 A*算法流程

<ignore_js_op>

 

表1.1.1.1.2 JPS算法的“两个定义、三个规则”

1.1.1.2 JPS算法举例

<ignore_js_op>

 

图1.1.1.2.1 寻路问题示例场景（5*5的网格）

下面举例说明JPS具体的寻路流程。问题示例如图1.1.1.2.1所示，5*5的网格，黑色表明阻挡区，S为起点，E为终点。JPS要寻找从S到E的最短路径，首先初始化将S加入openset。从openset取出F值最小的点S，并从openset删除，加入closedset，S的当前方向为空，则沿八个方向寻找跳点，在该图中只有下、右、右下三个方向可走，但向下遇到边界，向右遇到阻挡，所以都没有找到跳点，而后沿右下方向寻找跳点，在G点，根据上文定义二的第（3）条，parent(G)为S，praent(G)到S为对角线移动，而且G通过垂直方向移动（向下移动）能够到达跳点I，所以G为跳点 ，将G加入openset。从openset取出F值最小的点G，并从openset删除，加入closedset，由于G当前方向为对角线方向（从S到G的方向），所以在右、下、右下三个方向寻找跳点，在该图中只有向下可走，所以向下寻找跳点，根据上文定义二的第（2）条找到跳点I，将I加入openset。从openset取出F值最小的点I，并从openset删除，加入closedset，由于I的当前方向为直线方向（从G到I的方向），在I点时I的左后方不可走且左方可走，所以沿下、左、左下寻找跳点，但向下、左下都遇到边界，只有向左寻找到跳点Q（根据上文定义二的第（2）条）），所以将Q加入openset。从openset取出F值最小的点Q，并从openset删除，加入closedset，由于Q的当前方向为直线方向，Q的左后方不可走且左方可走，所以沿右、左、左上寻找跳点，但向右、左上都遇到边界，只有向左寻找到跳点E（根据上文定义二的第（1）条）），所以将E加入openset。从openset取出F值最小的点E，由于E是目标点，所以寻路结束，路径是S、G、I、Q、E。

注意，本文不考虑从H能走到K的状况，由于对角线有阻挡（这点和论文不一致，但和代码一致，由于若是H到K能直接到达，会走进H右边的阻挡区，大部分的JPS开源代码根据论文都认为H到K能直接到达，因此存在穿越阻挡的状况），若是须要H到K能走，则路径是S、G、H、K、M、P、E，修改跳点的计算方法便可。

上述的JPS寻路效率是明显快于A*的，缘由在于：在从S到A沿垂直方向寻路时，在A点，若是是A*算法，会将F、G、B、H都加入openset，可是在JPS中这四个点都不会加入openset。对F、G、H三点而言，由于从S、A、F的路径长度比S、F长，因此从S到F的最短路径不是S、A、F路径，同理S、A、G也不是最短路径，根据上文规则二的第（1）条，走到A后不会走到F、G，因此F、G不会加入openset，虽然S、A、H是S到H的最短路径，但由于存在S、G、H的最短路径且不通过A，据上文规则二的第（1）条，从S走到A后，下一个走的点不会是H，所以H也不会加入openset；对B点而言，根据上文规则三，B不是跳点，也不会加入openset，直接走到C便可。

表1.1.1.2.1所示为A*和JPS在寻路消耗中的对比，D. Age: Origins、D. Age 二、StarCraft为三个游戏龙腾世纪：起源、、龙腾世纪二、星际争霸的场景图集合，M.Time表示操做openset和closedset的时间，G.Time表示搜索后继节点的时间。可见A*大约有58%的时间在操做openset和closedset，42%时间在搜索后继节点；而JPS大约14%时间在操做openset和closedset，86%时间在搜索后继节点。避免在openset中加入太多点，从而避免过多的维护最小堆是JPS比A*快的缘由（（最小堆插入新元素时间复杂度log(n)，删除最小元素后调整堆，时间复杂度也为log(n)）），实际上在从S到E的寻路过程当中，进入openset的只有S、G、I、Q、E。

<ignore_js_op>

 

表1.1.1.2.1 A*和JPS的寻路消耗对比

1.1.2 JPS五个优化算法

1.1.2.1 JPS优化之一JPS-Bit：位运算优化

利用位运算优化的JPS-Bit的关键优化思路在于利用位运算来优化JPS中节点拓展的效率。下面以图1.1.2.1.1中的场景示例说明如何将位运算融合于JPS算法中，其中黑色部分为阻挡，假设当前位置为I（标蓝位置），当前方向为右，位运算中使用1表明不可走，0表明可走，则I当前行B的八位能够用八个bit：00000100表示，I上一行B-的八位能够用八个bit：00000000表示，I的下一行B+的八位能够用八个bit：00110000表示。在当前行寻找阻挡的位置能够用CPU的指令__builtin_clz(B)（返回前导0的个数），即当前阻挡在第5个位置（从0开始）。寻找当前行的跳点能够用__builtin_clz(((B->>1) && !B-) ||((B+>>1) && !B+)) 寻找，例如本例中(B+>>1) && !B+为：(00110000 >> 1) && 11001111，即00001000，而(B->>1) &&!B为00000000，因此__builtin_clz(((B->>1) && !B-) ||((B+>>1) && !B+))为__builtin_clz(00001000)为4，因此跳点为第4个位置M（从0开始）。注意论文中使用_builtin_ffs(((B-<<1) && !B-) ||((B+<<1) && !B+))，__builtin_ffs(x)返回x的最后一位1是从后向前第几位，好比7368（1110011001000）返回4，由于论文对格子的bit编码采用小端模式，而这里对格子的bit编码采用大端模式。

因为JPS-Bit使用运算效率更高的位运算和CPU指令运算来优化原始JPS节点扩展过程当中的遍历操做，JPS-Bit的算法效率高于原始的JPS，实测中JPS-Bit的寻路时间比JPS缩短5倍左右。

<ignore_js_op>

 

图1.1.2.1.1寻路问题示例场景（3*8的网格）

1.1.2.2 JPS优化之二JPS-BitPrune：位运算与剪枝优化

利用位运算和剪枝优化的JPS-BitPrune在JPS-Bit的基础上进一步进行剪枝优化，剪掉没必要要的中间跳点（见表1.1.1.1.2，定义二第(3)条定义），根据定义二，中间跳点在节点拓展过程当中只具备简单的“承接”做用，不具有拓展价值，将中间跳点放入openset会增大扩展的次数，所以JPS-BitPrune将中间跳点所有删除，将中间跳点后继跳点中的非中间跳点的父跳点改成中间跳点的父跳点，能够有效避免冗余的节点拓展运算。

拐点获取：值得一提的是，JPS-BitPrune因为删除了中间跳点，所以JPS-BitPrune须要在搜索到完整的路径以后以必定的策略在最后寻得的路径中加入中间拐点，使得每两个相邻的路径节点之间都是垂直、水平、对角线方向可达的。对此，JPS-BitPrune采用的具体方法以下：

假设目前搜索到的路径为start(jp1)、jp二、jp3...jpk..end(jpn)，对每两个相邻的跳点jpi、jpi+1，一，若是jpi、jpi+1的x坐标或者y坐标相等，说明这两个跳点在同一个水平方向或垂直方向，能够直线到达，无需在这两个跳点之间加入拐点；二，若是jpi、jpi+1的x坐标和y坐标都不相等，（1）若是x坐标的差dx（即jpi的x坐标减去jpi+1的x坐标）和y坐标的差dy的绝对值相等，说明这两个跳点在对角线方向，也能够直线到达，无需在这两个跳点之间加入拐点；（2）若是x坐标的差dx和y坐标的差dy的绝对值不相等，说明这两个跳点不在对角线方向，而且有可能不能直线到达（由于跳点附近有阻挡），此时jpi、jpi+1之间只须要加入一个从jpi出发离jpi+1最近的对角线上的点便可（jpi、jpi+1不能水平、垂直、对角线到达，说明jpi、jpi+1之间必定存在被剪枝的中间跳点，只须要补上离jpi+1最近的一个中间跳点充当拐点便可，该拐点即为jpi沿对角线方向走min(dx,dy)步到达的点）。

<ignore_js_op>

 

图1.1.2.2.1 JPS-BitPrune的剪枝优化示例

下面以图1.1.2.2.1 的问题场景示例JPS-BitPrune如何在剪枝的同时进行寻路。起点为S（坐标为(1,1)，即S(1,1)），节点一、四、6均为中间跳点：由于节点二、3是知足定义二第(2)条的跳点，因此节点1是为了到达节点二、3的中间跳点，同理节点四、6也为中间跳点。在剪枝中间跳点以前，要将中间跳点的后继节点的父节点调整为该中间跳点的父节点。例如图1.1.2.2.1 中，节点1的后继跳点为节点二、三、4，其中节点4也为中间跳点，删掉中间跳点中的节点1后，节点二、3的父跳点由节点1改成节点S，删除中间跳点中的节点4后，节点4的后继跳点5的父跳点由节点4改成节点S（节点4的父跳点为节点1，但节点1已经被删掉，所以回溯到节点S），删除中间跳点中的节点6后，节点6的后继跳点7的父跳点由节点6改成节点S（节点6的父跳点为节点4，但节点4被删，节点4的父跳点节点1也被删，所以回溯到节点S）。

上述过程是简化的逻辑描述，实际运行中的作法是从节点S寻找跳点，首先找到中间跳点节点1，而后在水平方向和垂直方向寻找到跳点节点二、3，将节点二、3的父跳点设为节点S；继续沿对角线方向寻找跳点，走到节点4后，沿水平方向和垂直方向寻找到跳点节点5，将节点5的父跳点设为节点S；继续沿对角线方向寻找跳点，走到节点6后，沿水平方向和垂直方向寻找到跳点7，将跳点7的父跳点设为节点S。所以JPS-BitPrune得到路径S(1,1) 、节点7(4,6)。

由于路径中S(1,1)没法垂直、水平、对角线方向走到节点7(4,6)，须要加入中间拐点，根据上述的拐点添加策略，有dx为3，dy为5，须要从S沿对角线走3步，即节点6(4,4)可做为中间拐点，所以，在图1.1.2.2.1 的示例中，JPS-BitPrune最后构建的完整路径为S(1,1) 、节点6(4,4) 、节点7(4,6)。

1.1.2.2.1 剪枝的优化效率

下面经过对比剪枝先后的JPS节点拓展的状况来讲明剪枝操做的优化效率：

场景一（无剪枝） 若是不对中间跳点进行剪枝，那么从节点S寻路到节点7将经历以下过程：

从节点S搜索跳点，找到跳点节点1，openset此时只有节点1；

从openset取出F值最小跳点节点1，并搜索节点1的后继跳点，水平方向和垂直方向找到跳点节点二、3，对角线方向找到跳点节点4，此时openset有节点二、三、4；

从openset取出F值最小跳点节点4，并搜索节点4的后继跳点，水平和垂直方向找到跳点节点5，对角线方向找到跳点6，此时openset有节点二、三、五、6；

从openset取出F值最小跳点节点6，垂直方向找到跳点7，此时openset有节点二、三、五、7；

从openset取出F值最小的跳点节点7，为目的点，搜索结束，所以完整路径为节点S(1,1)、节点1(2,2) 、节点4(3,3) 、节点6(4,4) 、节点7(4,6)。JPS在到达目的节点7以前，须要接连拓展中间跳点1，4，6。

场景二（剪枝中间跳点） 在剪枝中间跳点以后，从节点S寻路到节点7的流程获得了明显简化：

从节点S寻找跳点，首先找到中间跳点节点1，而后在水平方向和垂直方向寻找到跳点节点二、3，将节点二、3的父跳点设为节点S；继续沿对角线方向寻找跳点，走到节点4后，沿水平方向和垂直方向寻找到跳点节点5，将节点5的父跳点设为节点S；继续沿对角线方向寻找跳点，走到节点6后，沿水平方向和垂直方向寻找到跳点7，将跳点7的父跳点设为节点S；继续沿对角线方向寻找跳点，遇到阻挡，搜索终止，此时openset有节点二、三、五、7；

从openset取出F值最小的跳点节点7，为目的点，搜索结束，此时得到的路径为S(1,1) 、节点7(4,6)。不一样于无剪枝的JPS须要拓展中间跳点一、四、6，在JPS-BitPrune中，节点一、四、6做为中间跳点均被剪枝，有效避免了冗余的节点拓展，寻路效率获得大大提高。

1.1.2.3 JPS优化之三JPS-BitPre：位运算与预处理

本优化中的预处理在一些文章被称为JPS+。JPS-BitPre和JPS-BitPrunePre都不支持动态阻挡，由于动态阻挡的出现会致使八个方向最多能走的步数发生变化，从而致使预处理的结果再也不准确。利用位运算和预处理的JPS-BitPre依旧采用JPS-Bit中的位运算，而其中的预处理则是对每一个点存储八个方向最多能走的步数step，这个step值将影响JPS中节点的拓展顺序和拓展“跨度”，加快寻路效率。因为预处理版本的JPS须要存储八个方向最多能走多少步，若是地图大小是N*N，每一个方向最多能走的步数用16位数表示，则须要存储空间N*N*8*16bit，若是N为1024，则大概须要存储空间为16M，存储空间占用较大，使用该版本JPS时须要权衡是否以空间换时间，另外预处理的时间对小于1024*1024个格子的图能够在1秒内处理完，但对于2048*2048个格子的图须要一小时左右处理完。

其中，step值由跳点、阻挡、边界等决定，若是遇到跳点，则step为走到跳点的步数；不然step为走到阻挡或边界的步数。

例如对图1.1.2.3.1中的N点，向北最多走到节点8，即2步；
向南最多走到节点4，即4步；
向西最多走到节点6，即3步；
向东最多走到节点2（节点2是知足定义二第（2）条的跳点），即5步；
西北最多走到节点7，即2步；
东北最多走到节点1（节点为1是上文定义二第（3）条定义的跳点），即1步；
西南最多走到节点5，即3步；
东南最多走到节点3（节点3是上文定义二第（3）条定义的跳点），即3步。

<ignore_js_op>

 

图1.1.2.3.1  JPS-BitPre寻路的场景示例

以图1.1.2.3.1中的场景为例，要寻找从节点N到节点T的路径，JPS-BitPre的寻路流程以下：

从openset取出节点N， 从N沿八个方向寻找跳点，根据预处理获得的各方向最远可走的step值，能够快速肯定八个方向最远能到达的节点{1，2，3，4，5，6，7，8}，如图1.1.2.3.1所示，其中，节点一、二、3均为知足定义二的跳点，直接加入openset，对于节点四、五、六、七、8，首先判断终点T位于以N为中心的南、西南、西、西北、北的哪部分，由于T位于西南方向，只有节点5位于西南方向，所以节点四、六、七、8直接略过，在从N到5的方向上，N可走3步，而N和T的x坐标差绝对值dx为1，y坐标差绝对值dy为2，所以将从节点N到节点5方向上走min(dx,dy)步即节点11，加入openset；

从openset取出F值最小节点11，垂直方向找到跳点T，加入openset；三，从openset取出F值最小节点T，为目的点，搜索结束，此时得到的路径为N(4,5)、节点11(3,4) 、节点T(3,3)。

为了说明JPS-BitPre寻路的准确性与高效率，这里给出原始JPS-Bit从N到T的寻路流程做为对比：

从openset取出节点N后，须要沿八个方向寻找跳点，节点一、三、11为上文定义二第（3）条定义的跳点，加入openset，节点2为上文定义二的第（2）条定义的跳点，加入openset；

从openset取出F值最小节点11，垂直方向找到跳点T，加入openset；

从openset取出F值最小跳点T，为目的点，搜索结束，此时得到的路径也为N(4,5)、节点11(3,4) 、节点T(3,3)。

对比发现，通过预处理的JPS-BitPre和只使用位运算的JPS-Bit最后寻得的路径是同样的，然而，因为JPS-BitPre无需在每一步节点拓展过程当中沿各方向寻找跳点，其能够根据预处理获得的step值快速肯定openset的备选节点，从而大大提高寻路效率。

1.1.2.4 JPS优化之四：不可达两点提早判断

如图1.1.2.4.1所示，起点S不可到达终点E，然而寻路算法仍然会花费时间去寻找S、E之间的路径，并且失败状况下寻路花费的时间远大于成功状况下寻路花费的时间，由于失败状况下须要遍历全部的路径，才能肯定两点不可达。所以为了不这种状况，在每次寻路以前，判断起点和终点是否可达：若是起点和终点在同一连通区域，则起点和终点可达，不然不可达。只有起点和终点可达，才须要去寻路。

首先计算Grid网格的连通区域，算法如表1.1.2.4.1所示，算法只能采用宽度优先搜索，深度优先搜索的递归层次太深，会致使栈溢出。按照表1.1.2.4.1的算法，图1.1.2.4.1的点S、一、2的连通区域编号均为1，点三、四、E的连通区域编号均为2，S、E连通区域编号不一样，所以S、E不在同一连通区域，不须要寻找路径。表1.1.2.4.1的算法在程序启动时计算一次便可，算法复杂度为O(N)，N为Grid网格数目，运行时只须要查询两点是否在同一连通区域，算法复杂度为O(1)。

<ignore_js_op>

 

图1.1.2.4.1 不可达的两点S、E

<ignore_js_op>

 

表1.1.2.4.1 计算连通区域

1.1.2.5 JPS优化之五：空间换时间

openset采用最小堆实现，最小堆的底层数据结构是一个数组，从最小堆中插入、删除时间复杂度为O(logn)。除了删除还须要查找操做，每次找到一个跳点，都须要判断在最小堆中是否有，若是有，则判断是否更新G值、F值、父跳点等，若是没有，则加入openset。在最小堆的中查找操做时间复杂度O(n)，所以须要优化。closedset存的是已经从openset中弹出的跳点，实际只须要对每一个跳点加个标记便可，若是跳点打上标记，则表示是closedset中跳点，不然不是。

综合上述需求，针对1km*1km的地图，构建2k*2k的二维数组matrix，数组每一个元素pnode均为一个指针，指针的对象类型包括节点id、是否扩展过expanded(便是否在closedset中)、G值、F值、父跳点指针parent、在最小堆中的索引index等12个byte。若是地图(x,y)处是搜索到的跳点，首先检查在二维数组matrix对应的(x,y)处指针pnode是否为空，若是为空，表示该跳点以前未搜索过，从内存池new出一个跳点，将指针加到最小堆openset中，并在执行shift up、shift down操做以后，记录在最小堆中的索引index；若是不为空，则表示该跳点以前搜索过，首先检查expand标记，若是为真，则表示在closedset中，直接跳过该跳点；不然表示在openset中，经过matrix(x,y)记录的在openset中的索引index找到对应的指针，检查matrix(x,y)和openset(index)的指针是否相等进行二次确认，而后检查判断是否须要更新G值、F值、父跳点等，采用空间换时间的方法能够将openset和closedset中查找操做降为O(1)。游戏中有不少场景，无需为每一个场景构建一个matrix，以最大的场景的大小构建一个matrix便可。

1.1.3 多线程支持

游戏服务器广泛采用单进程多线程架构，多线程下，不能对JPS寻路加锁，不然寻路串行化，失去了多线程的优点，为了支持多线程JPS寻路，须要将一些变量声明为线程独有thread_local，例如上文提到的为了优化openset和closedset的查找速度，构建的二维跳点指针数组matrix。该数组必须为线程独有，不然，不一样线程在寻路时，都修改matrix元素指向的跳点数据，例如A线程在扩展完跳点后，将expanded标记为真，B线程再试图扩展该跳点时，发现已经扩展过，就直接跳过，致使寻路错误。

1.1.4 JPS内存优化算法

1.1.4.1 分层

JPS的地图格子粒度若是采用0.5m*0.5m，每一个格子占1bit，则1km*1km的地图占用内存2k*2k/8个byte，即0.5M；为了向上、向下也能经过取32位数得到向上、向下的32个格子阻挡信息，须要存将地图旋转90度后的阻挡信息；

上文JPS优化之四：不可达两点提早判断，须要存连通讯息，假设连通区数目最多15个，则需内存2k*2k/2个byte，即2m，则内存为：原地图阻挡信息0.5m、旋转地图阻挡信息0.5m、连通区信息2m，即3m。另外，上文提到用空间换时间的方法，为了优化openset和closedset的查找速度，构建二维跳点指针数组matrix。1km*1km的地图，格子粒度为0.5m*0.5m，构建出的matrix指针数组大小为2k*2k*4byte即为8m，为了支持多线程，该matrix数组必须为thread_local，即线程独有，16个线程共需内存16*8m即为128m，内存空间太大，所以须要优化这部份内存。

首先将2k*2k分红100*100的块，即20*20个块，20*20个块为第一层数组firLayerMatrix，100*100为第二层数组secLayerMatrix，firLayerMatrix的400个元素为400个指针，每一个指针初始化为空，当遍历到的跳点属于firLayerMatrix中(x,y)的块时，则从内存池new出100*100*4byte的secLayerMatrix，secLayerMatrix每一个元素也是一个指针，指向一个从内存池new出来的跳点。

例如，搜索2k*2k的地图时，在(231,671)位置找到一个跳点，首先检查firLayerMatrix的(2,6)位置指针是否为空，若是为空，则new出100*100*4byte的secLayerMatrix，继续在secLayerMatrix查找(31,71)位置检查跳点的指针是否为空，若是为空，则从内存池new出来跳点，加入openset，不然检查跳点的expanded标记，若是标记为真，表示在closedset中，直接跳过该点，不然表示在openset中，判断是否更新G值、F值、父节点等。由于游戏中NPC寻路均为短距离寻路，JPS寻路区域最大为80*80，一个secLayerMatrix是100*100，所以只须要一个secLayerMatrix，则两层matrix大小为：20*20*4byte+100*100*4byte即为0.04m。

因此16个线程下，总内存为：原地图阻挡信息0.5m、旋转地图阻挡信息0.5m、连通区信息2m、两层matrix0.04m*16，共3.64M，游戏中场景最多不到20个，全部场景JPS总内存为72.8M。

1.1.4.2 内存池

在JPS搜索过程当中，每次将一个跳点加入openset，都须要new出对应的节点对象，节点对象中存节点id、父节点、寻路消耗等共12个byte，为了减小内存碎片，以及频繁new的时间消耗，须要自行管理内存池，每次new节点对象时，均从内存池中申请，内存池详解请见下文服务器内存优化，为了防止内存池增加过大，须要限制搜索步数。

本文的内存池共有两个：

一，跳点的内存池，初始大小为800个跳点，当new的跳点数目超出800个，即中止寻路，由于服务器用JPS进行NPC的寻路，NPC不会进行长距离寻路，假设NPC寻路上限距离是20m，则寻路区域面积是40m*40m，格子数80*80即6400，经统计跳点数目占全部格子数目的比例不到1/10， 即跳点数目少于640，所以800个跳点足够使用，800个跳点共占内存800byte*12，即为9.6k，忽略不计；

二，secLayerMatrix指向的100*100*4byte的内存池，由于每次寻路都须要至少一个secLayerMatrix，若是每次寻路都从新申请，寻路完后再释放，会形成开销，所以secLayerMatrix指向的100*100*4byte的空间也在内存池中，申请时，从内存池拿出，释放时，放回内存池便可，secLayerMatrix内存池占内存0.04m。

1.1.5 路径优化

如图1.1.4.1所示，绿色格子为起点，红色格子为终点，灰色格子为跳点，蓝线为JPS搜出来的路径，灰色虚线为搜索过程。能够看出，从绿色格子到红色格子能够直线到达，而JPS搜索出来的路径却须要转折一次，在游戏表现上，会显得比较奇怪。所以在JPS搜索出来路径后，须要对路径进行后处理。

好比JPS搜出来的路径有A、B、C、D、E、F、G、H八个点，走到A时，须要采样检查A、C是否直线可达，若是A、C直线可达，再检查A、D是否直线可达，若是A、D直线可达，继续检查A、E，若是A、E直线不可达，则路径优化为A、D、E、F、G、H，走到D时，再检查D、F是否直线可达，若是D、F直线可达，继续检查D、G，若是D、G直线不可达，则路径优化为A、D、F、G、H。依此类推，直到走到H。由于采样检查的速度很快，大约占JPS寻路时间的1/5，并且只有当走到一个路点后，才采样检查该路点以后的路点是否能够合并，将采样的消耗平摊在行走的过程当中，所以采样的消耗能够忽略。

<ignore_js_op>

 

图1.1.4.1

1.2视野管理算法的优化

1.2.1 视野管理算法的背景

1.2.1.1 九宫格

游戏中地图用来承载阻挡、静态建筑、NPC（非玩家控制角色：Non-Player-Controlled Character）、WRAP点等。玩家在地图上移动，其可见的其余玩家即发生变化，若是玩家的每次移动，都更新视野列表，时间成本过高，所以只有当玩家离开某个区域时，才更新视野列表，而在这个区域内的移动，并不更新视野列表。为了划分这个区域，引入九宫格概念，如图1所示，九个格子的总面积大于一个手机屏幕，小于两个手机屏幕。大于一个手机屏幕的缘由是，能够预先计算当前屏幕外的一些玩家，但又没有必要预先计算太多的屏幕外玩家，所以小于两个手机屏幕，玩家可见的范围为以玩家为中心周围九个格子内的其余玩家。

若是玩家Me在格子5内移动，则不主动更新视野列表，玩家可见范围为红色和绿色格子内的玩家（若是玩家Me视野列表内的玩家He从一个格子移动到另外一个格子，致使Me和He不可见，也会致使玩家Me的视野列表发生更新，称为被动更新），若是玩家Me从格子5移动到格子8则主动更新视野列表，玩家可见范围为紫色和绿色格子内的玩家。

<ignore_js_op>

 

图1.2.1.1.1 玩家从九宫格的格子5移动到格子8

1.2.1.2 视野管理的必要性

在大型多人在线游戏MMO（Massively Multiplayer Online）中，多个玩家在同一场景，此时玩家须要能看到其附近的玩家，同时不须要看到与其距离远的玩家。这就是视野管理须要作的事情：为每一个玩家维护一个视野列表，管理每一个玩家可见视野内的其余玩家。

MMO游戏中，视野对服务器形成的压力主要来源于两点：一，玩家频繁移动形成视野列表的频繁更新的压力；二，广播视野列表的带宽压力。由于视野列表中的玩家频繁变化，有的玩家离开当前玩家的视野，有的玩家新进入当前玩家的视野，所以当前玩家的视野列表须要进行频繁的增、删、查操做，所以增、删、查操做的时间复杂度要尽量的低，从而缓解视野列表频繁更新的压力。

若是当前视野列表中有100个玩家，每一个玩家都移动了一段距离，为了让其余玩家看到本身的移动，每一个玩家都须要被通知其余99个玩家的移动，这就须要广播100*99个数据包，随着地图中玩家数目增长，形成广播量急剧增长，对带宽形成极大压力，所以玩家的视野列表须要有规模限制，从而缓解带宽压力。

本文提出一种利用全局内存池、双向链表、位标记进行视野管理的算法，能够将每次增、删、查视野列表的复杂度降为O(1)。

1.2.2 全局内存池

全局内存池中存放的元素如图1.2.1.1所示。ViewLinkNodePair中有两个ViewLinkNode类型元素，ViewLinkNode定义如图1.2.1.2所示，记录ViewLinkNodePair指针类型的m_Parents，以及Obj_User指针类型的m_pUser，m_pUser即为指向玩家的指针。ViewLinkNodePair两个ViewLinkNode元素各自包含一个m_pUser指针，这两个m_pUser指针存放相互可见的两个玩家。采用内存池好处是避免内存碎片、以及频繁分配的消耗。

<ignore_js_op>

 

图1.2.1.1

<ignore_js_op>

 

图1.2.1.2

1.2.3 双向链表

每一个玩家的视野列表是一个双向链表，双向链表中每一个元素包含ViewLinkNodePair中的两个ViewLinkNode之一，ViewLinkNode中记录ViewLinkNodePair和可见的玩家。当玩家A和B相互可见时，申请ViewLinkNodePair，A的ViewLinkNodeA记录ViewLinkNodePair和B，B的ViewLinkNodeB记录ViewLinkNodePair和A。当玩家A和B不相互可见时，在A的双向链表中找到记录B的ViewLinkNodeA，而后从A的双向链表中删除，并在记录B的ViewLinkNodeA中找到ViewLinkNodePair，在ViewLinkNodePair中找到记录A的ViewLinkNodeB，在B的双向链表中删除。

双向链表每一个元素是CChainItem<ViewLinkNode>的指针，类模板CChainItem定义如图1.2.2.1所示，data存的是ViewLinkNode的指针。如图1.2.2.2所示，当两个玩家rObjA、rObjB相互可见时，首先从全局内存池g_ViewLinkPool新建一个对象，对象的指针为pPair，将pPair的m_LinkNodeA的m_pUser指向rObjB的地址，m_LinkNodeB的m_pUser指向rObjA的地址，m_Parents指向pPair。当两个玩家rObjA、rObjB相互不可见时，只须要在rObjA的双向链表中找到对应的CChainItem<ViewLinkNode>的指针，该指针的m_LinkNodeA中的m_pUser指向rObjB的地址，并将对应的双向链表的元素从rObjA的双向链表中删除，而后根据m_LinkNodeA的m_Parents找到对应的pPair，再从pPair中找到m_LinkNodeB，m_LinkNodeB的m_pUser指向rObjA的地址，将m_LinkNodeB从rObjB的双向链表中删除。

<ignore_js_op>

 

图1.2.2.1

<ignore_js_op>

 

图1.2.2.2

1.2.4 位标记

游戏中须要频繁的判断两个玩家是否相互可见，然而采用全局内存池+双向链表的数据结构，最快只能采用遍历双向链表的方法，该时间复杂度为O(n)，所以采用第三个数据结构：位标记辅助完成这项工做。每一个场景中的Obj数量是有限的，咱们游戏每一个场景的Obj数目最大为2048，ObjID编号从0到2047，每一个玩家是否可见用一个bit表示。因此每一个玩家共须要2047个bit表示是否与其余2047个Obj可见，即0.25K，3000个玩家同时在线，位标记占0.75M。假设He的ObjID为10，判断Me是否可见He，只须要查看Me的第10个位标记是否为1便可。

1.2.5 视野管理流程

如图1.2.1.1.1所示，玩家Me从格子5移动到格子8，老视野可见的玩家为红色和绿色格子内的玩家，新视野可见的玩家为紫色和绿色格子内的玩家。首先遍历Me的双向链表，对全部老视野列表的玩家打上标签1，而后遍历紫色和绿色格子内的玩家，若是玩家He已打标签1，则将玩家He打上标签2，说明玩家He在新视野和老视野均可见；若是玩家He没打标签1，则说明玩家He是新进视野的玩家，加入EnterList；从新遍历Me的双向链表，若是玩家He仍然是标签1，说明玩家He只在老视野，没在新视野中，加入LeaveList，同时记录玩家He在玩家Me视野数组中的索引。

例如Me在格子5时老视野列表里的玩家为：User一、User二、User三、User四、User五、User6；Me移动到格子8时，紫色和绿色格子内的玩家有User三、User四、User五、User六、User七、User8。首先对双向链表User1到User6六个玩家打标签1；而后对User3到User8打标签，由于User3到User6已打标签1，因此对这4个玩家打标签2，而User七、User8没打标签1，因此这两个玩家加入EnterList；再遍历双向链表User一、User2由于仍然是标签1，因此将这两个玩家加入LeaveList，同时记录这两个玩家的pPair。

对LeaveList的两个玩家User一、User2，由于已知pPair，因此已知Me和User一、User2三个玩家的双向链表中CChainItem<ViewLinkNode>的指针位置，删除便可。

对EnterList中的玩家，须要按照优先级高低放到不一样的桶里，好比队友的优先级比其余玩家优先级高。而后按照优先级高低的顺序加入视野列表，若是视野列表已满，优先级高的玩家仍然没进入视野列表，须要从视野列表中删除优先级低的玩家，以便腾出空间将优先级高的玩家加入。对EnterList的两个玩家User七、User8，新建ViewLinkNodePair，并将ViewLinkNode插入对应的双向链表便可。

1.3 玩家眷性同步的优化

1.3.1 背景介绍

本文适用于全部脏标记遍历功能，提高性能几十倍，本文以游戏中玩家的属性同步做为例子进行介绍。

MMORPG游戏中玩家有大量属性须要从服务器同步给客户端，例如名字、血量、战力、等级、速度等等。每当某个玩家的某个属性发生变化时，须要将玩家该属性的标志位置脏，在心跳或者其余须要发送的时机，调用同步属性函数，判断置脏的属性并同步给全部客户端。须要注意，不能每次在某个玩家的某个属性发生变化时，均同步给全部客户端，由于开销太大，通常在心跳里（固定时间间隔）同步。为了保证玩家眷性在全部客户端及时更新，心跳间隔通常在500ms左右，如此频繁的调用以及同步属性函数内大量的脏标记判断致使同步属性函数成为性能瓶颈之一，大约占后台性能消耗的10%。

假设玩家有n个属性，k个属性置脏，最直观的作法是遍历全部n个属性，逐个判断是否置脏，置脏的属性同步给客户端，须要判断n次；本文做者以前提过一种优化算法，根据属性置脏的频率，优先判断置脏频率高的属性，当判断出的脏属性数目等于k，则中止，该优化效率显著优于遍历n个属性，但也不是最优的算法。

还有一种优化思路是用set记录置脏的属性，set插入时间复杂度为O(logn)，置脏m个属性，set插入操做总时间复杂度为O(log(1*2*..*m))，再考虑某个属性频繁置脏的状况，好比第m个属性在同步以前置脏p次，则set操做时间复杂度为O(log(1*2..*m*p)，虽然通常状况下m比较小，但不排除某些状况m很大，就会致使出现性能瓶颈，实测中发现采用set，o2编译，如图1.3.1.1所示插入50个脏属性耗时165639微秒，如图1.3.1.2所示置脏50个标记位耗时1522微秒，set效率低108倍，虽然同步的时间间隔内更新的属性数目不多，但某个属性更新的可能很是频繁，因此同步时间间隔内假设插入50个脏属性模拟很合理。

显然，若是算法不管属性更新是否频繁，不管属性数目是可能是少，都能在k的时间判断出哪些属性置脏，则该算法为最优算法。由于置脏的属性很是稀疏，k每每是个位数，因此最优算法能够将效率提高几十倍。

<ignore_js_op>

 

图1.3.1.1

<ignore_js_op>

 

图1.3.1.2

1.3.2 优化算法

为引出本文的优化算法，本文首先介绍一个问题：计算一个整数的二进制表示中有多少个1。基本作法如图1.3.2.1所示。假设该整数n为10001100，则须要右移7次。但计算机里的数字原本就是用二进制存的，因此计算过程也都是二进制计算。利用一些位运算的特性，能够很容易计算1的个数。该例子中n - 1为10001011，n & (n - 1)为10001000，能够看到低3位都变成了0。多验证几个例子，能够看出结论，要消除整数n最低位的1，可使用 n = n & (n-1)。从而计算n的二进制表示有多少个1的算法如图1.3.2.2所示。

<ignore_js_op>

 

图1.3.2.1

<ignore_js_op>

 

图1.3.2.2

本文介绍一个gcc的内置函数，__builtin_ffs(uint32 n)，返回n最后一个为1的位是从后向前的第几位，例如若n为10001100，则__builtin_ffs(n)为3，该函数对应的x86汇编代码，O0编译结果如图1.3.2.3所示，仅有四条汇编指令。该内置函数64位的版本为__builtin_ffsll(uint64 n)。

<ignore_js_op>

 

图1.3.2.3

接下来正式介绍本文的优化算法，假设有64个属性，该64个属性用bit位表示是否置脏，共需64bit，将64bit转成uint64的n，每次用__builtin_ffsll找出最低位的1的位置，便可找出一个置脏的属性，而后用n&(n-1)消除最低位的1，当n为0时算法终止。假设64个属性第2个属性和第9个属性置脏，则该64bit编码为0...0100000010，首先用__builtin_ffsll找出低第2位的置脏属性，而后n=n&(n-1)，即0...0100000000，再用__builtin_ffsll找出低第9位的置脏属性，而后n=n&(n-1)即为0，算法终止，可看出从64个属性里找出置脏的两个属性，只须要两次操做。

找出置脏属性后，使用switch语句而不是if语句处理须要同步的属性。由于随着if语句数目增多，效率会线性下降。而switch语句在case多的状况下（gcc在O0编译，case大于等于5个），翻译的汇编代码会使用查找表，在O(1)时间内找到对应的case，因此switch语句不会在case规模很大的状况降低低效率；在case不多的状况下（gcc在O0编译，case小于5个），仍然会逐个比较。须要注意，为尽量提高性能，脏标记数目最好为64位整数倍，不然假如脏标记数目为120位，取出64位后，须要将剩下的63位拆分红32位、16位、8位，分三次取出，再计算脏标记位置，性能会下降。

1.3.3 性能对比

num类型为uint64，记录全部脏标记，num低第2位、低第64位置脏，即num为100...010。图1.3.3.1所示为遍历全部属性，并逐个判断是否置脏，num & 1不为0时，表示第j个属性被置脏，图1.3.3.2所示为采用本文的优化算法，index为最低位的脏标记的位置。实测中图1.3.3.1耗时2011微秒，图1.3.3.2耗时26微秒，性能提高77倍。本文的优化算法不只适用于属性同步，全部脏标记相关的功能都可采用，例如数据的判断置脏并落地存储。

<ignore_js_op>

 

图1.3.3.1

<ignore_js_op>

 

图1.3.3.2

1.4 跨服战团匹配算法的优化

游戏中存在跨服战等需求，将一些队伍组成固定规模战团，而后战团之间战斗，战团匹配过程应当尽可能高效、快速，同时实现战力均衡。为了实现尽量公平均衡的战团匹配，直观的作法固然是搜索全部队伍组成固定规模的战团，然而其时间复杂度为指数级，以极高的计算代价换取最优匹配显然是不现实的，所以，战团匹配问题也成为制约服务器性能瓶颈问题。

为此，本文利用压桶法实现了快速组成固定规模为K的战团，在尽可能保证匹配战团的战力均衡前提下，将战团匹配的时间复杂度降为O(n)。具体上，当有玩家或队伍（实际中，队伍人数为1到5）申请组成战团时，将其加入队列尾部。而后在游戏的心跳中遍历队列，若是当前遍历的玩家或队伍的人数加上桶里的人数小于等于K，则将当前玩家或队伍加入桶，并从队列中删除；不然新建一个桶，将玩家或队伍加入新桶中。在战团匹配时，找出全部人数为K的桶，将桶里全部玩家的战力值的和设为对应桶的权重值，并以此对全部的满的桶进行排序，每次选择战力值最接近的两个战团进行战力均衡的调整，而后传送到战斗服务器进行战斗。

然而，因为压桶法是为了节省时间而选择的贪心算法，可能会遗漏能组成战团的玩家或队伍，所以在压桶法后，本文采用查表法对剩余的玩家和队伍再次尝试组成固定规模的战团。首先在服务器启动时作些预处理，群举全部能组成两个固定规模战团的组合（队伍人数为一的队伍数目，队伍人数为二的队伍数目，...，队伍人数为五的队伍数目），并存在set里，该步骤是全局惟一的，而且只须要作一次。而后统计剩下的玩家和队伍，计算人数为1、2、...、五的队伍数目。若是剩下的玩家或队伍队伍人数为一到五的队伍数目均大于set中某个元素，则set中该元素表示能组成两个固定规模战团的组合，并从剩下的玩家或队伍中删除。此步骤重复进行，直到剩下的玩家或队伍没法组成两个固定规模的战团。

经过上述方法，本文实现尽量合理的战团组成，在此以后，为了尽量实现两个战团战力均衡，本文进一步设计战团玩家调整方法。当两个固定规模的战团组成后，经过查询预先生成的表，调整两个战团里的玩家，使得两个战团的战力尽量相等，加强战斗刺激性。具体上，首先群举全部的能组成两个固定规模战团的可能，并存在map里，map的key为字符串，key惟一标识战团的构成（队伍人数为一的队伍数目，队伍人数为二的队伍数目，...，队伍人数为五的队伍数目），map的value为一个vector容器，vector中存储当前key拆分红两个固定规模战团的全部可能。当调整两个战团的战力时，经过map查询当前两个战团能重组成的全部两个战团的可能，而后遍历全部的可能，找出两个战团战力最接近的组合。

1.5 发包逻辑拆分

在服务器给客户端发包时，须要将数据包打包成流，在Encode操做中存在大量memcpy操做，而每一个memcpy时间复杂度为O(n)，所以打包过程也成为性能瓶颈之一。所以，本文认为有必要将数据包打包并发包的过程从游戏主线程中拆分，另开一个线程处理。在具体的多线程实现过程当中，在主线程和发包线程之间须要有通讯的数据结构，主线程负责将数据包写进该数据结构，发包线程负责将包从该数据结构中读取、打包、发送，合理的通讯数据结构的使用将对多线程效率影响很大。

简单的实现能够采用c++的queue做为两个线程通讯的数据结构，然而须要对queue加锁，才能保证两个线程读写安全，但锁的开销会下降性能。所以，本文采用基于字节流的无锁循环队列。由于每一个数据包大小不同，小的几个Byte，大的几百K，所以不能采用基于对象的无锁循环队列，不然几个Byte的数据包也会占据几百K的空间。

另外本文采用Tconnd做为网络通讯组件，Tconnd发包须要携带TFRAMEHEAD，该结构体大小为12K，除了TFRAMEHEAD_CMD_START等管理包的该TFRAMEHEAD是从Tconnd接收而后再本身填充一些字段外，其余数据包的TFRAMEHEAD彻底是本身拼的，所以知道须要填充哪些字段。 因此除了TFRAMEHEAD_CMD_START等管理包的TFRAMEHEAD是在主线程收到并拼完，而后12K完整的写进无锁循环队列，其余的TFRAMEHEAD均是主线程将须要的参数写进无锁循环队列，发包线程再根据这些参数拼TFRAMEHEAD。这种优化能够大大下降无锁循环队列所占内存。

1.6 玩家Cache

在当前多进程的服务器的架构下，查看玩家信息亟需优化。当一台服务器（GameServer1）的玩家要查看另外一台服务器（GameServer2）的玩家信息时，须要通过多个服务器的屡次查询中转。譬如，上述请求的流程可能为GameServer1 -> WorldServer -> GameServer2 -> WorldServer -> GameServer1，请求消息共须要转发四次。同时，查看离线玩家信息时，一般须要对数据库进行操做，这都致使查看玩家信息须要被优化。

为此，本文经过对玩家信息进行缓存（玩家cache）实现玩家信息查看优化。具体上，1）同一游戏服务器下的用户不需缓存，譬如，GameServer1玩家A查看GameServer1的玩家B不经过缓存就能够很容易地获取玩家B信息；2）不一样游戏服务器下需进行玩家缓存，且缓存按需更新。譬如，GameServer1玩家A查看GameServer2的玩家C，在GameServer1的玩家cache中查看玩家C，若是玩家C进入缓存时间超过10秒，更新缓存中玩家C信息，若是玩家C不在缓存中，则从数据库加载；3）查看离线玩家一样利用玩家cache，每逢玩家离线，通知全部GameServer更新玩家cache中该玩家信息。

由于被查看的玩家每每都是等级、战力等特别高的玩家，这些玩家会被大量玩家查看，因此本文提出的玩家缓存机制每每命中率极高，实测中缓存命中率达到80%-90%左右。

2、服务器内存优化

2.1 内存统计

在对内存优化以前，须要先肯定程序每一个模块的内存分配。程序的性能有perf、gprof等分析工具，但内存没有较好的分析工具，所以须要自行统计。在linux下/proc/self/statm有当前进程的内存占用状况，共有七项：指标vsize虚拟内存页数、resident物理内存页数、share 共享内存页数、text 代码段内存页数，lib 引用库内存页数、data_stack 数据/堆栈段内存页数、dt 脏页数，七项指标的数字是内存的页数，所以须要乘以getpagesize()转换为byte。在每一个模块结束后统计vsize的增长，便可知该模块占用的内存大小。

在面向对象开发中，内存的消耗由对象的消耗组成，所以须要统计每一个类的成员变量的占用内存大小。使用CLion或者visual studio均可以导出类中定义的全部成员变量，而后在gdb使用命令：

p ((unsigned long)(&((ClassName*)0)->MemberName))，便可打印出类ClassName的成员变量MemberName相对类基地址的偏移，根据偏移从小到大排序后，变量的顺序即为定义的顺序，根据偏移相减便可得出每一个成员变量大小，而后优化占用内存大的成员变量。

2.2 内存泄露

内存泄露是指程序中已动态分配的堆内存因为某种缘由程序未释放或没法释放，致使内存一直增加。虽然有valgrind等工具能够检查内存泄露，但valgrind虚拟出一个CPU环境，在该环境上运行，会致使内存增大、效率下降，对于大规模程序，基本没法在valgrind上运行。所以须要自行检查内存泄露，glibc提供的内存管理器的钩子函数能够监控内存的分配、释放。如图2.2.二、2.2.3所示，分别为钩子函数的分配内存和释放内存。由于服务器启动时须要预先分配不少内存，好比内存池，这些内存是在服务器中止时才释放，所以为了不这些内存的干扰，在服务器启动以后才能开始内存泄露的统计。

首先申请固定大小的vec_stack，记录全部分配的内存，若是有释放，则从vec_stack中删除，最后vec_stack中的元素即为泄露的内存，vec_stack必须为固定大小，不然vector扩容中会有内存分配，也不能够用map，map的红黑树旋转也会有内存分配，会形成干扰；而后经过图2.2.1所示的my_back_hook记录原有的malloc、free；并经过图2.2.2所示的my_init_hook将malloc、free换成自定义的钩子函数。

每次分配内存时，都会进入自定义钩子函数my_malloc_hook中，如图2.2.2所示。在my_malloc_hook中首先经过my_recover_hook将malloc恢复成默认的，不然会形成死递归，而后经过默认的malloc分配大小为size的空间，为了分线程统计内存泄露，还须要对线程号作判断，在stTrace.m_pAttr记录内存分配的地址，m_nSize记录大小，m_szCallTrace记录调用栈，若是vec_stack已满，须要根据m_nSize从大到小排序，若是当前分配内存大于vec_stack记录的最小的分配内存，则替换；若是未满，则直接加入vec_stack，在my_malloc_hook结束时，将malloc替换成自定义的malloc。

每次释放内存时，都会进入自定义钩子函数my_malloc_free中，如图2.2.3所示。在my_malloc_free中首先经过my_recover_hook将free恢复成默认的，不然会形成死递归，对线程号判断，而后在vec_stack中删除对应的分配，并将free替换成自定义free。

<ignore_js_op>

 

图2.2.1

<ignore_js_op>

 

图2.2.2

<ignore_js_op>

 

图2.2.3

2.3 内存池

在游戏服务器内存分配过程当中，glibc中的malloc采用的是ptmalloc，ptmalloc在对小对象进行分配时会产生大量内部碎片，同时也会有外部碎片的产生。所以每每须要自行设计并实现模板化的内存池，采用内存池的好处是，避免内部、外部碎片，对象New/Delete均为O(1)复杂度，同时有利于监控。例如当模板参数为宠物时，首先new出60个宠物的空间，对这60个宠物空间，当60个空间被所有使用时，再分配60个空间。本文在内存池设计中实现两个数据管理器，分别是空闲数据管理器freeList和使用空间管理器usedList，freeList采用queue实现便可，usedList采用vector。

因为这部分较复杂，所以用代码辅以说明。如图2.3.1，在Init函数中传入要建立的对象数目capacity，pointer根据capacity预先分配空间，用于创建全部对象索引，pointer主要用来校验。本文按块Chunk建立对象，每块Chunk有objectperchunk个T类型对象。chunksize记录当前总共建立了多少对象。虽然Init函数设定了capacity，可是初始并无建立capacity个T对象，而是先建立objectperchunk个T对象供使用，并记录到freelist中。

如图2.3.2所示，每次新建立对象时调用NewObj函数，若是freelist为空，说明全部已建立的对象均被使用，则再调用NewChunk建立objectperchunk个T对象；若是不为空，直接返回freeList头部的指针。

如图2.3.3所示，每次删除对象时调用DeleteObj函数，参数为待删除对象指针，除了必要的校验之外，将对象指针从usedList删除，并将usedList最后一个对象指针移动到删除位置，记录删除位置deleteusedlistindex。同时将对象指针所指的对象清空加入freeList，以便再次使用，好处时内存不回收能够重复使用。

如图2.3.4所示，对象的遍历在usedList上进行，但在遍历中可能会删除对象，此时deleteusedlistindex == iterateindex，由于删除对象后，会将usedList最后一个对象指针移动到deleteusedlistindex位置，所以iterateindex不能增长。

<ignore_js_op>

 

图2.3.1

<ignore_js_op>

 

图2.3.2

<ignore_js_op>

 

图2.3.3

<ignore_js_op>

 

图2.3.4

2.4 内存分配（ptmalloc vs tcmalloc）

即便使用内存池，程序中仍然须要大量使用malloc分配空间。但主流使用的ptmalloc存在以下缺点：一，ptmalloc采用多个线程轮询加锁主分配区和非主分配的方式，形成锁的开销；二，多线程间的空闲内存没法复用，利用线程A释放一块内存，因为并不必定会释放给操做系统，线程B申请一样大小的内存时，不能复用A释放的内存，致使使用内存增长；三，ptmalloc分配的每块chunk须要8个字节记录前一个空闲块大小和当前块大小以及一些标记位。

为此，本文提倡使用tcmalloc进行内存分配。tcmalloc对每一个线程单独维护ThreadCache分配小内存；针对ptmalloc多线程内存没法复用的问题，tcmalloc为进程内的全部线程维护公共的CentralCache，ThreadCache会阶段性的回收内存到CentralCache；针对ptmalloc每块chunk使用8个字节表示其余信息，tcmalloc对每块chunk使用大概百分之一的空间表示其余信息，对小对象分配，空间利用率远高于ptmalloc。

3、服务器启动时间优化

3.1 读取阻挡文件优化

服务器启动时，须要读大量文件，其中最大的文件就是阻挡文件，每一个阻挡文件大约有几M，采用c++的ifstream能够一次读取一个字节，也能够一次读取整个文件，后者的速度比前者快几十倍以上。如图3.1.1所示，MATRIX_LEN为4096，阻挡文件为4096*4096byte，共16M，图3.1.1按byte读取阻挡文件须要2564ms，图3.1.2一次性读取阻挡文件须要50ms。

<ignore_js_op>

 

图3.1.1

<ignore_js_op>

 

图3.1.2

来源：腾讯游戏学院
原地址：https://mp.weixin.qq.com/s/1WN9rA4yK6Wi2-BhQFIn5Q