K8s中Golang容器线性内存增长但htop无泄漏显示的原因及解决

从你提供的memory.stat数据来看，K8s监控到的线性增长内存是文件页缓存（Page Cache）：

• 数据里的cache项达到3GB左右，其中active_file（2.4GB）+inactive_file（628MB）是主要组成部分，这是操作系统为加速文件读写而缓存的磁盘文件数据。
• 你的服务RSS（常驻内存）仅189MB，和本地htop看到的稳定内存一致，说明Go堆内存和进程实际占用的物理内存是正常的。

本地与K8s统计差异原因 #

本地htop默认统计的是进程的RSS（进程实际占用的物理内存），不包含操作系统管理的文件缓存；但K8s基于cgroup的内存统计会把与该进程相关的所有内存（包括OS为其读写文件分配的page cache）纳入统计范围，所以会出现K8s内存线性增长、本地测试稳定的差异。

释放这类内存的方法 #

这类内存不属于Go runtime管理的堆内存，GC和debug.FreeOSMemory()对它无效（debug.FreeOSMemory()仅能释放Go runtime已归还给OS但未被回收的堆内存），需要从OS层面或业务逻辑入手：

• 主动告知OS回收文件缓存：如果服务处理的是本地磁盘文件，在每次处理完成后，调用syscall.PosixFadvise系统调用，传入POSIX_FADV_DONTNEED参数，告诉OS该文件的缓存不再需要，示例代码：

  import "syscall"
  
  func releaseFileCache(fd int) error {
      return syscall.PosixFadvise(fd, 0, 0, syscall.POSIX_FADV_DONTNEED)
  }
  

• 清理临时文件：如果是处理远程存储（如对象存储）时生成的本地临时文件，处理完成后直接删除文件，OS会自动回收对应的缓存。
• 无需刻意处理（按需选择）：文件页缓存是OS的正常优化机制，当系统内存紧张时，OS会自动回收这部分内存。如果你的服务RSS稳定、没有OOM风险，可以不用处理，仅调整K8s的内存告警阈值即可。
• 绕过page cache：使用直接IO（O_DIRECT）方式读写文件，完全绕过page cache，但会降低文件读写性能，需根据业务场景权衡。

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