这是个非常典型的JVM内存困惑——我来帮你拆解背后的原因，再分享几个能进一步压低进程内存的实用方法：

为什么NMT显示本地内存降了，但htop里的RSS没变化？ #

核心原因基本都和操作系统的内存管理逻辑以及JVM与OS的内存交互方式有关：

1. glibc malloc的内存缓存坑
   默认情况下，Linux的glibc malloc分配器不会把JVM释放的内存立刻还给操作系统，而是把这些内存存在进程内部的空闲池里（比如多线程场景下的arena机制），留着给JVM后续复用。这就导致NMT统计到的“已提交内存”降了，但OS层面的RSS（驻留物理内存）不会马上跟着降——因为这些内存还在进程的地址空间里，只是标记为空闲而已。

2. OS不会主动回收“闲置”内存
   当系统内存充足时，OS不会急着回收进程释放的空闲页，反而会把这些页当成缓存用，避免后续重新分配的开销。只有当系统内存吃紧时，OS才会主动把这些空闲页收回去，这时候你才能看到RSS下降。

3. NMT的统计盲区（可能性较低）
   虽然NMT能覆盖绝大多数JVM本地内存，但如果你的应用用了JNI调用第三方C/C++库，且这些库直接用自己的malloc分配内存，那NMT可能统计不到这部分。不过你说初始NMT和RSS基本对齐，所以这部分大概率不是问题。

进一步降低Java进程内存的实用技巧 #

除了你已经试过的堆内存限制、栈大小调整、串行GC、类数据共享，还有这些方向可以深挖：

1. 给glibc malloc“瘦身” #

• 设置环境变量 MALLOC_ARENA_MAX=1：默认glibc会给每个线程创建一个内存arena，多线程场景下容易导致内存碎片化和额外占用。把arena数量限制为1，能显著减少这种不必要的内存开销。
• 换用更高效的内存分配器：比如tcmalloc或jemalloc，它们在内存回收和碎片化控制上比glibc malloc好很多，能更快把空闲内存还给OS。启动时可以通过LD_PRELOAD加载：LD_PRELOAD=/usr/lib/libtcmalloc.so java -Xmx64m ...

2. 让JVM更积极地释放内存 #

• 如果用G1GC（适合中小堆场景）：加上-XX:+UseG1GC -XX:G1HeapRegionSize=1M -XX:+ExplicitGCInvokesConcurrent，G1在释放堆外内存时比串行GC更主动，能更快触发OS回收。
• 限制直接内存：如果你的代码用了ByteBuffer.allocateDirect，一定要设置-XX:MaxDirectMemorySize=16M（根据实际需求调），避免直接内存无限制膨胀——这部分内存默认是不受Xmx限制的。
• 禁用大页：添加-XX:-UseLargePages，大页分配后很难被OS回收，禁用后能减少内存预留的冗余。

3. 砍掉类加载和JIT的冗余内存 #

• 优化CDS归档：别只开-XX:+UseAppCDS，要生成精准的类列表。先跑一次应用生成类列表：java -Xmx64m -XX:DumpLoadedClassList=app_classes.lst your.main.Class，再用这个列表生成归档：java -Xmx64m -XX:SharedClassListFile=app_classes.lst -XX:SharedArchiveFile=app_cds.jsa your.main.Class，启动时加载归档能大幅减少类加载的内存开销。
• 关闭分层编译：如果你的应用不需要极致的JIT性能，加-XX:-TieredCompilation，能砍掉JIT编译器的不少内存占用。
• 清理依赖：删掉项目里没用的jar包，用JDK9+的模块化系统（Module），只加载必要的模块，减少类的总数。

4. 排查JNI本地内存泄漏 #

如果你的应用调用了JNI本地代码，一定要检查本地代码的内存管理逻辑——很多时候RSS居高不下是因为本地代码漏释放内存了。可以用valgrind工具检测：valgrind --leak-check=full java -Xmx64m ...，找出泄漏点。

5. 临时验证技巧（测试用） #

如果你想确认是不是OS缓存导致的RSS没降，可以手动触发OS回收空闲页：echo 3 > /proc/sys/vm/drop_caches（需要root权限），执行后再看htop，应该能看到RSS下降。不过这只是测试用，生产环境别频繁这么做，依赖OS自动回收就好。

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