问题出在哪
glibc 的多线程程序会为线程创建内存分配区（arena），每个 arena 各自向内核申请堆空间，线程退出后这些堆通常不会立刻归还，于是出现「线程数降下来了，RSS 却下不去」的现象。两个常用手段：用 MALLOC_ARENA_MAX 环境变量从源头限制 arena 数量，或在运行期调用 malloc_trim(0) 主动把空闲的堆页归还内核。
基本信息
| 环境变量 | MALLOC_ARENA_MAX（常见设为 2 或 4）、MALLOC_TRIM_THRESHOLD_ |
|---|---|
| 主动归还 | malloc_trim(0)，需包含 malloc.h |
| 默认行为 | 64 位 glibc 的 arena 上限与 CPU 核数相关（为核数的数倍） |
| 观察方式 | smaps_rollup 的 Rss、maps 中的 heap 段数量 |
| 适用范围 | glibc；musl 等其它 C 库机制不同 |
| 生效时机 | 环境变量需在进程启动前设置，trim 需应用主动调用 |
典型使用场景
- 高并发短连接服务 RSS 长期偏高，怀疑与 arena 残留有关
- 容器内存水位逼近限额，需要从启动参数层面收敛
- 批处理结束后主动回收，避免临时缓冲区长期占用
- 排查「线程数下降但内存不降」这类反直觉现象
- 做对照实验：设置 arena 上限前后比较 RSS 与吞吐表现
验证与调用
验证与调用
MALLOC_ARENA_MAX=4 ./service # 启动时限制 arena 数量上限
ldd --version | head -1 # 确认使用的是 glibc 及其版本
grep -c heap /proc/12345/maps # 统计 heap 段数量，间接反映 arena 规模
grep -E '^(Rss|Private_Dirty)' /proc/12345/smaps_rollup # 观察实际占用
# 应用侧在空闲时段调用（C）：
# #include <malloc.h>
# malloc_trim(0); // 把空闲的堆页归还内核
pidstat -r -p 12345 1 3 # 归还后观察缺页速率，确认后续是否重新申请手段对照
| 手段 | 作用 | 注意 |
|---|---|---|
| MALLOC_ARENA_MAX | 限制 arena 数量上限 | 过大无意义，过小可能增加分配锁竞争 |
| malloc_trim(0) | 归还空闲堆页 | 碎片严重时效果有限，有调用开销 |
| MALLOC_TRIM_THRESHOLD_ | 调整自动 trim 的阈值 | 需要理解与释放粒度的关系再改 |
| 观察指标 | Rss 与 heap 段数量 | 结合缺页速率判断是否重新申请 |
malloc_trim 只归还堆顶及可释放的空闲页，内存碎片严重时收益有限；频繁调用还会带来锁竞争与缺页开销。通常安排在业务低峰或批处理结束后调用一次。
限制 arena 数量能压低内存，但多线程密集分配时可能增加锁竞争、影响吞吐。调整前后都应在代表性负载下压测，不能只看内存指标。