Ryzom 伺服器端記憶體管理架構深度剖析：四大分配策略的設計哲學與適用場景

前言：為何 MMORPG 伺服器需要自定義記憶體分配器？

雲風大神屢次強調：穩定高效的 MMORPG 伺服器必須擁有專屬記憶體分配機制。標準 new/delete 或 malloc/free 在高併發、長時間運行、頻繁小物件分配場景下，易產生碎片、鎖競爭、效能抖動。Ryzom 開源專案在 misc 目錄實作四種互補策略，針對不同物件生命週期與存取模式優化。

四大分配器架構圖譜

1. CBlockMemory：固定大小區塊分配器

• 機制：預先分配固定元素數量的記憶體區塊；用盡則新增區塊；單一區塊不釋放，僅 purge() 釋放所有區塊。
• 適用場景：生命週期長、數量可預估、頻繁建立/銷毀的同質物件（如怪物、玩家、NPC 實體）。
• 優勢：O(1) 分配釋放、零碎片、極佳快取局部性。

2. CContiguousBlockAllocator：連續記憶體池分配器

• 機制：一次性分配大塊連續記憶體，按需劃分；耗盡則回退 new。
• 適用場景：需連續記憶體的緩衝區、陣列擴充、臨時大物件。
• 優勢：減少系統呼叫、利於向量化運算、避免碎片。

3. CPoolMemory：向量池分配器

• 機制：std::vector 預分配 N 個元素，多個 vector 以 list 串聯；釋放時批次銷毀所有 vector。
• 適用場景：短生命週期臨時物件（如封包封裝、事件結構、腳本上下文）。
• 優勢：批次管理、釋放高效、適合「申請-用畢-整批回收」模式。

4. CHeapMemory：標準堆包裝器

• 機制：直接封裝 new/delete，不改變分配行為。
• 定位：作為兜底方案，或用於不適合上述三類的雜項分配。
• 作者註記：效能無提升，工程意義有限，專案中極少使用。

策略選擇決策樹

核心心得

「要弄清楚自己最小的需求是什麼。」—— 沒有銀彈，只有對業務模式精準建模後的工程權衡。Ryzom 四大分配器各司其職，共同支撐千萬級物件的穩定運作。