Docker中.NET内存模式解析：GC、RSS与Cache及OOM问题问询

1. 三项假设的正确性判断 #

• 假设1：基本正确。.NET 8在Linux容器环境下，GC默认以RSS（驻留集大小）作为内存使用的核心感知指标。如果RSS未达到触发激进回收的阈值（默认逻辑下阈值和容器内存限制关联，但不会过度敏感），GC不会主动启动高强度垃圾回收。补充说明：.NET 8会结合容器内存限制做策略调整，但不会直接感知操作系统的Cache占用，因此即便系统Cache占比高，只要RSS没到阈值，GC不会主动回收。
• 假设2：完全正确。Linux系统的页缓存（Page Cache）由内核全权管理，应用程序（包括.NET）无法直接干预，内核仅在内存资源紧张时自动回收Cache，但这个回收过程存在延迟。
• 假设3：逻辑成立，细节需补充。当容器内存已处于90%的高位时，任何突发的RSS增长（比如应用处理大请求、JIT编译突发、依赖库动态加载等）都可能瞬间让总内存（RSS + Cache）触及256 MiB限制。此时内核会立即触发OOM Killer，而GC的回收动作是异步执行的，加上内核回收Cache的速度跟不上内存突增的节奏，最终导致OOMKill。

2. 现有信息能否识别异常内存模式？ #

不能。现有信息仅提及内存持续高位、突发OOMKill，但缺少关键的内存细分数据：比如RSS、Cache、应用堆内存的实时占比，以及OOM发生前后的内存变化曲线。要判断是否是Cache占比过高导致的问题，必须查看Grafana中对应的容器内存指标（如container_memory_rss、container_memory_cache）的数值和趋势，才能定位内存占比高的核心原因，或是确认是否为RSS突发增长引发的OOM。

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