本文節選自《2018騰訊移動游戲技術評審標准與實踐案例》手冊，由騰訊互娛工程師王傑分享《仙劍奇俠傳online》項目中游戲后台的優化經驗，深度解析尋路算法、視野管理、內存優化、同步優化等常見問題。
一、服務器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尋找跳點的過程有三種優化：一，位運算；二；預處理；三；剪枝中間跳點。
1.1.1.2 JPS算法舉例
下面舉例說明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 2、StarCraft為三個游戲龍騰世紀：起源、、龍騰世紀2、星際爭霸的場景圖集合，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。
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倍左右。
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)、jp2、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)步到達的點）。
下面以圖1.1.2.2.1 的問題場景示例JPS-BitPrune如何在剪枝的同時進行尋路。起點為S（坐標為(1,1)，即S(1,1)），節點1、4、6均為中間跳點：因為節點2、3是滿足定義二第(2)條的跳點，所以節點1是為了到達節點2、3的中間跳點，同理節點4、6也為中間跳點。在剪枝中間跳點之前，要將中間跳點的后繼節點的父節點調整為該中間跳點的父節點。例如圖1.1.2.2.1 中，節點1的后繼跳點為節點2、3、4，其中節點4也為中間跳點，刪掉中間跳點中的節點1后，節點2、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，然后在水平方向和垂直方向尋找到跳點節點2、3，將節點2、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的后繼跳點，水平方向和垂直方向找到跳點節點2、3，對角線方向找到跳點節點4，此時openset有節點2、3、4；
從openset取出F值最小跳點節點4，並搜索節點4的后繼跳點，水平和垂直方向找到跳點節點5，對角線方向找到跳點6，此時openset有節點2、3、5、6；
從openset取出F值最小跳點節點6，垂直方向找到跳點7，此時openset有節點2、3、5、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，然后在水平方向和垂直方向尋找到跳點節點2、3，將節點2、3的父跳點設為節點S；繼續沿對角線方向尋找跳點，走到節點4后，沿水平方向和垂直方向尋找到跳點節點5，將節點5的父跳點設為節點S；繼續沿對角線方向尋找跳點，走到節點6后，沿水平方向和垂直方向尋找到跳點7，將跳點7的父跳點設為節點S；繼續沿對角線方向尋找跳點，遇到阻擋，搜索終止，此時openset有節點2、3、5、7；
從openset取出F值最小的跳點節點7，為目的點，搜索結束，此時獲得的路徑為S(1,1) 、節點7(4,6)。不同於無剪枝的JPS需要拓展中間跳點1、4、6，在JPS-BitPrune中，節點1、4、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步。
以圖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所示，其中，節點1、2、3均為滿足定義二的跳點，直接加入openset，對於節點4、5、6、7、8，首先判斷終點T位於以N為中心的南、西南、西、西北、北的哪部分，因為T位於西南方向，只有節點5位於西南方向，因此節點4、6、7、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后，需要沿八個方向尋找跳點，節點1、3、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、1、2的連通區域編號均為1，點3、4、E的連通區域編號均為2，S、E連通區域編號不同，因此S、E不在同一連通區域，不需要尋找路徑。表1.1.2.4.1的算法在程序啟動時計算一次即可，算法復雜度為O(N)，N為Grid網格數目，運行時只需要查詢兩點是否在同一連通區域，算法復雜度為O(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，而且只有當走到一個路點后，才采樣檢查該路點之后的路點是否可以合並，將采樣的消耗平攤在行走的過程中，因此采樣的消耗可以忽略。
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則主動更新視野列表，玩家可見范圍為紫色和綠色格子內的玩家。
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指針存放相互可見的兩個玩家。采用內存池好處是避免內存碎片、以及頻繁分配的消耗。
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的雙向鏈表中刪除。
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時老視野列表里的玩家為：User1、User2、User3、User4、User5、User6；Me移動到格子8時，紫色和綠色格子內的玩家有User3、User4、User5、User6、User7、User8。首先對雙向鏈表User1到User6六個玩家打標簽1；然后對User3到User8打標簽，因為User3到User6已打標簽1，所以對這4個玩家打標簽2，而User7、User8沒打標簽1，所以這兩個玩家加入EnterList；再遍歷雙向鏈表User1、User2因為仍然是標簽1，所以將這兩個玩家加入LeaveList，同時記錄這兩個玩家的pPair。
對LeaveList的兩個玩家User1、User2，因為已知pPair，所以已知Me和User1、User2三個玩家的雙向鏈表中CChainItem<ViewLinkNode>的指針位置，刪除即可。
對EnterList中的玩家，需要按照優先級高低放到不同的桶里，比如隊友的優先級比其他玩家優先級高。然后按照優先級高低的順序加入視野列表，如果視野列表已滿，優先級高的玩家仍然沒進入視野列表，需要從視野列表中刪除優先級低的玩家，以便騰出空間將優先級高的玩家加入。對EnterList的兩個玩家User7、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往往是個位數，所以最優算法可以將效率提升幾十倍。
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所示。
本文介紹一個gcc的內置函數，__builtin_ffs(uint32 n)，返回n最后一個為1的位是從后向前的第幾位，例如若n為10001100，則__builtin_ffs(n)為3，該函數對應的x86匯編代碼，O0編譯結果如圖1.3.2.3所示，僅有四條匯編指令。該內置函數64位的版本為__builtin_ffsll(uint64 n)。
接下來正式介紹本文的優化算法，假設有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倍。本文的優化算法不僅適用於屬性同步，所有臟標記相關的功能均可采用，例如數據的判斷置臟並落地存儲。
1.4 跨服戰團匹配算法的優化
游戲中存在跨服戰等需求，將一些隊伍組成固定規模戰團，然后戰團之間戰斗，戰團匹配過程應當盡量高效、快速，同時實現戰力均衡。為了實現盡可能公平均衡的戰團匹配，直觀的做法當然是搜索所有隊伍組成固定規模的戰團，然而其時間復雜度為指數級，以極高的計算代價換取最優匹配顯然是不現實的，因此，戰團匹配問題也成為制約服務器性能瓶頸問題。
為此，本文利用壓桶法實現了快速組成固定規模為K的戰團，在盡量保證匹配戰團的戰力均衡前提下，將戰團匹配的時間復雜度降為O(n)。具體上，當有玩家或隊伍（實際中，隊伍人數為1到5）申請組成戰團時，將其加入隊列尾部。然后在游戲的心跳中遍歷隊列，如果當前遍歷的玩家或隊伍的人數加上桶里的人數小於等於K，則將當前玩家或隊伍加入桶，並從隊列中刪除；否則新建一個桶，將玩家或隊伍加入新桶中。在戰團匹配時，找出所有人數為K的桶，將桶里所有玩家的戰力值的和設為對應桶的權重值，並以此對所有的滿的桶進行排序，每次選擇戰力值最接近的兩個戰團進行戰力均衡的調整，然后傳送到戰斗服務器進行戰斗。
然而，由於壓桶法是為了節省時間而選擇的貪心算法，可能會遺漏能組成戰團的玩家或隊伍，因此在壓桶法后，本文采用查表法對剩余的玩家和隊伍再次嘗試組成固定規模的戰團。首先在服務器啟動時做些預處理，群舉所有能組成兩個固定規模戰團的組合（隊伍人數為一的隊伍數目，隊伍人數為二的隊伍數目，...，隊伍人數為五的隊伍數目），並存在set里，該步驟是全局唯一的，並且只需要做一次。然后統計剩下的玩家和隊伍，計算人數為一、二、...、五的隊伍數目。如果剩下的玩家或隊伍隊伍人數為一到五的隊伍數目均大於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.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.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。
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不能增加。
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.1 讀取阻擋文件優化
服務器啟動時，需要讀大量文件，其中最大的文件就是阻擋文件，每個阻擋文件大約有幾M，采用c++的ifstream可以一次讀取一個字節，也可以一次讀取整個文件，后者的速度比前者快幾十倍以上。如圖3.1.1所示，MATRIX_LEN為4096，阻擋文件為4096*4096byte，共16M，圖3.1.1按byte讀取阻擋文件需要2564ms，圖3.1.2一次性讀取阻擋文件需要50ms。
來源：騰訊游戲學院
原地址：https://mp.weixin.qq.com/s/1WN9rA4yK6Wi2-BhQFIn5Q