Java 服务 RSS 3 天内从 4.1G 爬到 5.8G 但堆监控全绿：不重启、不装 agent，纯 cgroup v2 memory.stat + pmap 到底怎么切出那 1.7G 堆外大头？

【背景】 我做了 3 年运维，主责一条 Java 17 网关服务（Spring Boot 3，Netty 4.1，JDK 17.0.9，-Xmx3g -XX:MaxMetaspaceSize=256m），跑在 K8s 1.28 集群（cgroup v2，containerd 1.7），Pod request 4G / limit 8G。平时堆占用稳定在 1.2~1.5G，JMX 监控曲线看着非常健康。

【现象】 近 3 天，同一个 Pod（没有发版、没有流量突刺）的 cgroup memory.current 从 4.1G 缓慢爬到 5.8G，斜率约 30~50M/小时，非常线性。关键反常点：

• JMX 堆占用稳定在 1.3G 左右，Full GC 一次没有；
• pmap -x <pid> | awk '{s+=$2} END {print s}' 跟 memory.current 基本对得上，说明不是 page cache 的锅；
• Netty 的 -Dio.netty.leakDetection.level=PARANOID 开了 48 小时，一行 "LEAK" 日志都没有；
• -XX:MaxDirectMemorySize 没显式设（默认跟 -Xmx 一样 3G），但 jcmd <pid> VM.native_memory summary 里 Other 区块只涨了 800M，不是全部。

也就是说，剩下那 700M~1G 的堆外增长，JVM 自己的工具链看不全，Netty 的 leak detector 也抓不到。

【已尝试的排查与结果】

1. cat /sys/fs/cgroup/.../memory.stat 对比 T0 和 T+48h：anon 涨了约 1.6G，file 几乎不动，slab 涨了 30M——确认是匿名页在涨，不是 page cache / 内核 slab。
2. pmap -x <pid> 全量 dump 到本地，用 awk 按 size 排序看 top 20 大块：最大的几块都在 512M 级别，地址段不连续，怀疑是 glibc 的 malloc arena 碎片化 + DirectByteBuffer 混合，但光看 size 没法区分是哪一类。
3. 想 jcmd <pid> GC.heap_info + jmap -histo:live 对比，发现堆内对象数完全稳定，排除堆内慢漏。
4. 想 attach async-profiler 抓 native 分配，但生产机器上 profiler 权限被禁、也不能重启，这条路走不通。
5. 翻了站内的相关经验：
   • @程清和-127 的《容器 OOMKilled 但 Java 堆没满》（id=166）讲透了 cgroup 预算的坑，但没给"事后怎么切分"的方法；
   • @林亦舟-361 的《Netty 堆外内存缓慢爬升》（id=789）用的 jemalloc heap profiling，我们这边 glibc 默认 malloc、装 jemalloc 等于换运行时，动不了。

【期望得到的答案形态】 不重启、不装 agent、不换 allocator 的前提下，想请教：

1. 纯靠 memory.stat 的哪些字段组合（anon/file/slab/shmem 各涨了多少）能先做哪一档的排除？
2. pmap 两次快照对比，除了看 size，还有哪些维度（如地址段连续性、对齐方式、/proc/<pid>/smaps 里的 VmPTE 或 RssAnon）能帮我区分 glibc arena 碎片 vs DirectByteBuffer vs mmap 的 native 分配（JNI / JNI 库） vs 线程栈？
3. 你们有没有一套"5 分钟能跑完的 OS 侧堆外定位 SOP"？最好带具体命令和判读标准，我可以直接拿去给团队当 checklist。
4. 顺带问一个开放题：如果最后定位下来是 glibc arena 碎片（M_ARENA_MAX 默认 8*CPU 核数），在不重启的前提下，有没有什么运行时手段能缓解（比如 tcmalloc 热替换基本不现实，那还有别的路吗）？

欢迎贴你们的实际命令输出片段（脱敏后），越具体越好。