慢半拍的 Flink TaskManager：问题不在代码里
多个 TaskManager 结构相同、数据相近，CPU 使用率却差 10%。代码和数据差异都被排除后，剩下的解释只能在 JIT 编译状态与内存布局上——这类问题用业务指标永远看不出来。
#内存
该标签下共 4 篇文章。文章数未达 5 篇，本页暂不被搜索引擎索引。
G1 释放物理内存：避免长期无效占用
白天有流量、夜间几乎空闲的服务，堆内存一直占着不放。这需要区分「JVM 已回收」和「操作系统已回收」两件事，G1 的周期性 uncommit 与 region 归还策略决定了后者什么时候发生。
百 G 堆内存泄漏的定位方案
heapdump + MAT 是堆泄漏的常规手段，但在百 G 级堆上它本身就不可行：dump 要额外同等内存、解析要数小时、且会 STW。这篇给出一条在超大堆上仍然可用的替代路径。
错误理解 glibc 的 64M 现象，让 Java 内存排查更难
pmap 里出现大量接近 64M 的内存块，就断定是 glibc 的 arena 作祟并去调 MALLOC_ARENA_MAX——这个结论跳过了验证。64M 是 malloc 的 mmap 分配阈值，不是泄漏证据，误判会把排查引向错误方向。