揭祕重度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