慢半拍的 Flink TaskManager：问题不在代码里
多个 TaskManager 结构相同、数据相近，CPU 使用率却差 10%。代码和数据差异都被排除后，剩下的解释只能在 JIT 编译状态与内存布局上——这类问题用业务指标永远看不出来。
#排障
该标签下共 6 篇文章。本页已被搜索引擎索引。
GC 触发 crash，根因却是 unsafe
进程在 YGC 里 SIGSEGV 挂掉，堆栈指向 G1 的 copy_to_survivor_space——看起来像 GC 的 bug。换收集器仍然崩，才说明 JVM 对象模型已被破坏。unsafe 的错误写入不会立刻报错，直接原因与根因的现场差距可以非常大。
让 Java 融入 Linux 系统工具链
Java 与 C/C++ 混合调用场景下，perf、bcc、gdb 这些系统工具默认看不懂 Java 栈。把 JVM 的符号与栈展开接进 Linux 工具链，才能在不改业务代码的前提下做跨语言排查。
百 G 堆内存泄漏的定位方案
heapdump + MAT 是堆泄漏的常规手段，但在百 G 级堆上它本身就不可行：dump 要额外同等内存、解析要数小时、且会 STW。这篇给出一条在超大堆上仍然可用的替代路径。
错误理解 glibc 的 64M 现象，让 Java 内存排查更难
pmap 里出现大量接近 64M 的内存块，就断定是 glibc 的 arena 作祟并去调 MALLOC_ARENA_MAX——这个结论跳过了验证。64M 是 malloc 的 mmap 分配阈值，不是泄漏证据，误判会把排查引向错误方向。
Java 伪共享问题的稳定解法
用 padding 填充 long 字段隔离两个 volatile 变量，实测却毫无提升——因为填充解决的是「同一缓存行内不同字段」的竞争，而伪共享的判定要退到 MESI 协议与缓存行对齐去看。这篇给出可复现的判定顺序。