free释放的内存不立即归还OS：小块内存（≤128KB）仅标记空闲形成碎片，仅当释放堆顶连续空闲空间＞128KB时才调用sbrk(-SIZE)回收；大块内存（＞128KB）通过mmap分配，free时立即调用munmap真正释放。
堆内存空间收缩并真正释放给操作系统，不是调用 free 就立刻发生的。它取决于分配器策略、内存布局、系统调用机制以及运行时上下文——尤其在大厂嵌入式或高性能服务场景中，这个“动态红线”常被误判，导致内存长期滞留、OOM 风险隐蔽上升。
触发收缩的核心条件：brk/mmap 的临界决策
Linux glibc malloc 默认使用两种底层方式管理堆：
-
小块内存（sbrk/
brk：调整 program break 指针。只有当堆顶连续空闲区达到阈值（默认 128KB）且位于堆最末端时，malloc 才会调用brk()向下收缩，把内存还给内核；否则空闲块仅链入空闲链表，仍属进程地址空间。 -
大块内存（≥128KB）走
mmap(MAP_ANONYMOUS)：每块独立映射。一旦free，立即调用munmap归还，不经过堆管理器，无延迟。
实际不释放的常见陷阱
以下情况即使反复 free，堆大小（top 看 VIRT 不降，ps 看 SIZE 居高不下）也不会收缩：
- 堆中间存在未释放的小块（如早先分配的 16 字节结构体），阻断了顶部大块空闲区的连续性；
- 程序长期运行后产生碎片，顶部虽有空闲但不足 128KB，默认阈值未触发；
- 使用了
mallopt(M_TRIM_THRESHOLD, ...)但设得过大，或设为 -1（禁用 trim）； - 多线程环境下，主分配区（main arena）之外的 thread arenas 不参与
malloc_trim，需显式调用malloc_trim(0)或使用__malloc_arena_trim（非标准）。
主动干预的可行手段
生产环境不依赖自动收缩，而应结合监控与主动控制：
- 定期调用
malloc_trim(0)强制尝试归还顶部空闲——注意它只作用于主分配区，且可能失败（如有 mmap 块夹在中间）； - 通过
mallinfo().usmblks或更可靠的malloc_stats()//proc/PID/status（看MMAP_COUNT、Heap字段）判断是否真有可回收空间； - 对长周期服务，可设置
MALLOC_ARENA_MAX=1环境变量限制 arena 数量，减少 thread arena 内存滞留； - 关键模块改用内存池（如
jemalloc的--enable-stats+epoch控制）或预分配 slab，绕过通用堆管理器的不确定性。
动态红线的实质：不是容量，而是“可回收连续性”
所谓红线，并非某个固定字节数，而是当前堆顶连续空闲长度 ≥ trim threshold 这一瞬时状态。它随分配/释放序列剧烈波动。在高频小对象场景（如网络包解析），哪怕总空闲达数 MB，只要顶部连续空闲始终卡在 127KB，就永远跨不过那条线——这也是大厂压测中“内存不降反升”类问题的根源。
