.NET6非托管内存在AWS EC2 Docker容器中未释放问题咨询

我开发了一个Worker应用，核心逻辑是调用C++函数，主要算力和内存开销都来自非托管代码侧。程序通过无限循环从Redis拉取任务执行，已经按照公开指南在原生代码中实现了原生内存释放逻辑，但程序在两个环境的内存表现差异极大：

• 环境1：运行在AWS EC2上、设置2GiB内存限制的Linux Docker容器
• 环境2：配备32GB内存的Windows物理机

不同环境的内存表现 #

Linux容器环境 #

通过AWS CloudWatch监控发现：多次发送相同负载时，内存使用率会持续上涨直到进入稳定状态，且无任务运行时内存占用也不会下降。内存进入稳定平台期后不会持续增长触发OOM，但生产环境确实出现过一次OOM，这也是本次排查的起因。

Windows物理机环境 #

相同程序在Windows机器上整体内存占用低很多，无负载时内存会回落到接近程序启动后的初始水平。

已确认信息 #

两个平台下通过GC.GetTotalMemory(false)获取的GC托管内存总量始终不超过50MB。
我清楚不同平台、可用内存容量差异、监控统计口径差异（AWS CloudWatch上报物理内存，VS诊断工具统计私有字节）可能导致对比不完全公平，核心疑问是：

Linux容器环境下到底出现了什么情况？

目前判断该现象不太可能是原生代码内存泄漏导致：因为内存进入稳定状态后就不再持续增长，更像是这部分内存要等到.NET（或是操作系统）判定必须释放时才会真正归还，需要明确该现象的内在逻辑，以及Linux容器与Windows环境下内存表现存在差异的根本原因。

核心差异来自两个系统的原生内存分配器策略 #

你观察到的现象和.NET GC几乎没有关系——毕竟你已经验证托管堆内存始终低于50MB，内存开销几乎全在非托管侧，本质是Linux默认的glibc ptmalloc2分配器和Windows NT堆分配器的内存归还逻辑完全不同。

1. Windows堆分配器的行为 #

Windows用户态堆分配器默认采用更积极的内存归还策略：

• 当你通过free/delete释放原生内存时，只要释放的内存块达到阈值、且存在足够大的连续空闲区域，分配器会立刻调用VirtualFree把对应物理页交还给操作系统，进程的私有字节、工作集都会同步下降，这就是你在Windows上看到无负载时内存回落的直接原因。
• Windows堆分配器对内存归还的阈值设置很低，哪怕系统总内存非常充足，也会主动回收空闲大块内存，不会长期持有空闲内存占用RSS。

2. Linux glibc ptmalloc2分配器的行为 #

Linux下默认的ptmalloc2分配器对内存归还的策略要保守得多，这也是容器内内存不下降的核心原因：

• 你调用free/delete释放的内存，首先只会被标记为ptmalloc内部的空闲块，不会立刻归还给操作系统。ptmalloc会维护多个独立的内存分配区（arena），每个arena独立管理自己的内存块，只有当某个arena顶部的连续空闲内存超过128KB（默认阈值，可通过M_TRIM_THRESHOLD调整）时，才会通过sbrk/madvise把这部分顶端内存归还给OS。
• 如果释放的内存块不在arena的顶端，哪怕块很大、空闲时间很久，ptmalloc也不会把它归还给OS——因为ptmalloc不会做全局的内存块移动（移动原生内存块会导致所有持有该块指针的业务代码失效），这些夹在已分配块中间的空闲内存只会留在进程地址空间，留作后续内存分配请求复用，这部分内存会计入进程的常驻内存集（RSS），也就是CloudWatch监控到的物理内存占用。
• 当系统/容器内存充足时，ptmalloc完全没有动力归还空闲内存，毕竟内存留在进程内复用的分配速度远高于每次向OS申请新内存。只有当OS触发内存压力（比如容器内存占用接近cgroup限制）时，内核才会主动回收可丢弃页，ptmalloc也会在分配压力下触发更多trim操作归还空闲内存，这就是你看到内存涨到平台期就稳定的原因：涨到这个水位后，后续新的内存分配请求都直接复用ptmalloc持有的空闲块，不需要再向OS申请新物理页，所以内存不会持续上涨。

你可以做个简单验证：在容器无任务时，通过代码主动调用malloc_trim(0)，就能看到进程RSS立刻下降，和Windows上的表现接近，这就能坐实是ptmalloc的策略问题，不是真的内存泄漏。

偶发OOM的原因 #

生产环境遇到的偶发OOM，本质是ptmalloc的多arena机制导致的内存碎片问题：

• ptmalloc默认会为每个线程创建独立arena，64位系统下默认arena数量上限是8 * CPU核心数。如果Worker处理任务时会创建多个工作线程，每个线程的arena都会持有自己的空闲内存块，这些块不能跨arena复用。
• 当任务负载波动时，多个arena各自持有一部分零散空闲内存，总空闲内存看起来很多，但没有足够大的连续块满足新的大内存分配请求时，ptmalloc就会向OS申请新内存，最终总内存突破cgroup的2GiB限制触发OOM。

可落地的优化方案 #

• 替换非托管代码的内存分配器：把glibc默认的ptmalloc2换成jemalloc或者tcmalloc，这两个分配器的内存规整效率更高，归还内存给OS的策略更积极，内存碎片率远低于ptmalloc2，绝大多数Linux环境部署的C++服务都会做这个替换，通常能直接降低30%以上的常驻内存，也能解决碎片导致的偶发OOM。
• 调整ptmalloc行为参数：如果不想换分配器，可以通过环境变量调低M_TRIM_THRESHOLD、M_MMAP_THRESHOLD参数，让ptmalloc更频繁归还空闲内存，也可以在C++代码中周期性调用malloc_trim(0)主动触发ptmalloc归还所有可释放的空闲内存。
• 调整容器内存阈值：如果暂时不改动代码，建议把容器内存限制调到你观测到的稳定内存水位的1.2~1.5倍，给内存碎片留出足够缓冲空间，避免偶发OOM。

内容的提问来源于stack exchange，提问作者Luke Liu