1、资源管理基础：游戏服务器资源概述、CPU与内存模型、资源泄漏的危害

1.1 游戏服务器里的「资源」到底是什么？

说实话，很多刚入行的朋友一听到「资源管理」，第一反应就是「内存管理」。其实不然。

在我眼里，游戏服务器的资源，泛指一切有限且可被占用的系统实体。包括但不限于：

• 内存：堆内存、栈内存、共享内存、对象池
• CPU 时间片：线程、协程、定时器、逻辑帧
• 网络连接：socket 句柄、连接池、epoll 实例
• 文件句柄：日志文件、配置文件、热更资源
• 数据库连接：连接池中的长连接、事务上下文
• 锁与同步原语：互斥锁、读写锁、信号量、条件变量

你想想看，一个 MMORPG 的服务器，同时在线几千人。每个人身上挂着几十个 buff，每个 buff 可能是一个定时器对象。再加上场景里的怪物 AI、掉落物、玩家之间的交互……资源总量轻松上百万。

1.2 CPU 与内存模型：你得懂一点硬件

做服务器优化，不能只停留在语言层面。你得知道你的代码最终跑在什么样的硬件上。

1.2.1 内存层次结构

我习惯把内存想象成一个金字塔：

层级	容量	速度	谁管理
寄存器	几十字节	~0.3 ns	编译器
L1 缓存	32KB	~1 ns	硬件
L2 缓存	256KB	~3 ns	硬件
L3 缓存	8-32MB	~12 ns	硬件
主内存	GB 级别	~100 ns	OS
磁盘/SSD	TB 级别	~100 μs	OS

嗯，这里要注意：一次主内存访问的时间，足够 CPU 执行几百条指令。所以，缓存命中率直接决定了你的服务器性能。

我在项目中遇到过一个问题：一个排行榜系统，每次更新都要遍历几千个玩家对象。代码逻辑没问题，但 CPU 占用居高不下。后来用 perf 一看，L1 缓存 miss 率高达 40%。原因很简单——玩家对象在内存里是散乱分布的，每次访问都要从主存拉数据。

1.2.2 CPU 的「伪共享」陷阱

多核 CPU 下，每个核心有自己的 L1/L2 缓存。但缓存是以「缓存行」（通常 64 字节）为单位同步的。

假设两个线程分别修改两个相邻的 int 变量，恰好落在同一个缓存行里。那么即使它们逻辑上毫无关系，CPU 也会频繁地在这两个核心之间同步缓存行。这就是伪共享。

// 伪共享的典型例子
struct Counter {
    int64_t thread1_counter;  // 核心1 频繁写
    int64_t thread2_counter;  // 核心2 频繁写
};  // 两个变量在同一个缓存行里！

// 优化方案：填充到不同缓存行
struct Counter {
    alignas(64) int64_t thread1_counter;
    alignas(64) int64_t thread2_counter;
};

我曾经在一个战斗服务器里排查性能抖动，最后发现就是伪共享导致的。两个线程分别处理玩家输入和 AI 逻辑，共享一个状态结构体。加上 alignas(64) 之后，吞吐量直接提升了 30%。

1.3 资源泄漏的危害：不只是内存

说到泄漏，很多人第一反应是「内存泄漏」。但在我眼里，任何资源的「只借不还」都是泄漏。

1.3.1 内存泄漏

这个最直观。C++ 里 new 了没 delete，Java/C# 里对象被全局容器引用着无法 GC。后果就是：

• 进程内存持续增长，直到被 OOM killer 干掉
• 或者触发频繁的 GC，导致「世界暂停」
• 更隐蔽的：内存碎片化，导致大块分配失败

1.3.2 句柄泄漏

文件句柄、socket 句柄、数据库连接……这些都是操作系统级别的资源。泄漏的后果比内存更严重：

• Linux 默认单进程最多 1024 个文件句柄
• 一旦耗尽，新连接进不来，日志写不了
• 而且句柄泄漏通常不会触发 crash，只会让服务「慢慢死掉」

我记得有一次线上事故：玩家反馈「登录不了」，但服务器进程还在。查了半天，发现是日志库在轮转文件时，旧文件句柄没关闭。每次日志轮转就泄漏一个句柄。运营了 7 天后，句柄数达到上限，所有新连接全部被拒绝。

1.3.3 线程/协程泄漏

这个比较隐蔽。比如你用了线程池，但某个任务里创建了线程却没加入池管理。或者协程被挂起后，再也没有被唤醒。

后果：

• 线程泄漏会导致进程的线程数暴涨，上下文切换开销剧增
• 协程泄漏会导致「协程孤儿」，占着栈内存不释放
• 更可怕的是：泄漏的线程如果持有锁，可能引发死锁

1.3.4 泄漏的「蝴蝶效应」

资源泄漏最可怕的地方，不是它本身，而是它引发的连锁反应：

1. 内存泄漏 → 可用内存减少 → 系统开始使用 swap → 性能暴跌
2. 性能暴跌 → 请求处理变慢 → 请求堆积 → 连接数暴涨
3. 连接数暴涨 → 句柄泄漏加剧 → 新连接被拒绝
4. 玩家重试连接 → 压力更大 → 雪崩

1.4 本章小结

这一章我们聊了三个核心问题：

• 资源是什么——不只是内存，还有 CPU、网络、文件、锁等一切有限实体
• 硬件长什么样——缓存层次、伪共享，这些底层知识决定了你的优化方向
• 泄漏有多痛——从内存到句柄到线程，每一种泄漏都能让服务器「慢性死亡」

下一章，我会带你深入 C++ 和 C# 的内存分配机制，看看 new 和 malloc 背后到底发生了什么。到时候我会分享一个我踩过的「内存池碎片化」的大坑——嗯，那个故事挺有意思的。