都叫“分代”，ZGC 和 G1 根本不是一回事：实测停顿差 1300 倍
同一套 Renaissance 基准，分代 ZGC 的停顿次数是 G1 的 6 倍，平均停顿却只有 G1 的 1/1300、最大停顿只有 1/2500；堆从 2G 涨到 5G，G1 最大停顿涨了 53%，ZGC 仍是 0.03ms。差别不只在参数：G1 分代是为了缩短 STW，ZGC 分代是为了降低并发回收成本——逻辑分代、并发收集年轻代、染色指针布局反转。
#JVM
该标签下共 5 篇文章。本页已被搜索引擎索引。
慢半拍的 Flink TaskManager：问题不在代码里
多个 TaskManager 结构相同、数据相近，CPU 使用率却差 10%。代码和数据差异都被排除后，剩下的解释只能在 JIT 编译状态与内存布局上——这类问题用业务指标永远看不出来。
G1 释放物理内存：避免长期无效占用
白天有流量、夜间几乎空闲的服务，堆内存一直占着不放。这需要区分「JVM 已回收」和「操作系统已回收」两件事，G1 的周期性 uncommit 与 region 归还策略决定了后者什么时候发生。
百 G 堆内存泄漏的定位方案
heapdump + MAT 是堆泄漏的常规手段，但在百 G 级堆上它本身就不可行：dump 要额外同等内存、解析要数小时、且会 STW。这篇给出一条在超大堆上仍然可用的替代路径。
Java 伪共享问题的稳定解法
用 padding 填充 long 字段隔离两个 volatile 变量，实测却毫无提升——因为填充解决的是「同一缓存行内不同字段」的竞争，而伪共享的判定要退到 MESI 协议与缓存行对齐去看。这篇给出可复现的判定顺序。