一个 4 字节字段让 8 核吞吐掉 35%：Java 对象跨 cache-line 边界的伪共享排查与修复

一、现象与背景：吞吐量"无声"掉了三分之一

去年 11 月，我们一个内部消息路由服务（JDK 17.0.11，Spring Boot 3.1.5，8C16G 容器）做了一次"小需求"：在 RouteEntry 对象上加了一个 int priority 字段（用于灰度路由优先级）。

改动就一行：

public class RouteEntry {
    private String tenantId;       // 16B (header) + 8B (ref)
    private String targetHost;     // + 8B (ref)
    private int weight;            // + 4B
    private int priority;          // ← 新加的这个，4B
    private long lastAccess;       // + 8B
    // ... 还有几个字段
}

上线后第二天，监控曲线出现了一个"台阶"：

• 吞吐从 120 kQPS 降到 78 kQPS（掉了 35%）
• CPU 利用率反而从 62% 涨到 71%（更忙了，但干得更少）
• P50 延迟从 1.8ms 涨到 2.6ms，P99 从 6ms 涨到 11ms
• 没有任何错误日志，GC 频率不变，连接池正常

最诡异的是：如果只开 4 个线程跑压测，吞吐几乎不降（118 vs 120 kQPS）；但 8 线程一上，立刻掉到 78 kQPS。

谢清和-328 在《把 P99 与慢 SQL 纳入接口回归》里说过一句很扎心的话："功能测试和性能测试是两套正交的验收标准。"这次我们的 200 个接口断言全绿、HTTP 状态码全 200、业务字段全对——但性能已经悄悄掉了三分之一。

二、根因分析：4 个字节如何"撬动"整条 cache-line

2.1 对象大小越过了 64 字节边界

Java 对象在 64 位 JVM 上有一个 16 字节的对象头（8B MarkWord + 4B Klass Pointer + 4B padding，JDK 17 CompressedOops 开启时）。RouteEntry 的字段布局（HotSpot 会按宽度降序重排字段）：

| 字段 | 宽度 | 累计偏移 | |------|------|----------| | 对象头 | 16B | 0–15 | | lastAccess (long) | 8B | 16–23 | | tenantId (ref) | 8B | 24–31 | | targetHost (ref) | 8B | 32–39 | | weight (int) | 4B | 40–43 | | priority (int) | 4B | 44–47 | | 对齐 padding | 16B | 48–63 |

等等——看起来还在 64B 内？问题出在还有一个 String tags 字段（8B 引用），加上后对象总大小变成 72 字节。

72B 意味着：一个 RouteEntry 实例 横跨了两条 64B 的 cache-line。

2.2 伪共享（False Sharing）的机制

打个比方：

一条 64B 的 cache-line 就像一块 64 厘米的木板，CPU 核是围着木板坐的工人。CPU 核 A 改了木板上第 30cm 处的螺丝，MESI 协议会把整条木板标记为 Invalid 并通知其他核。如果 CPU 核 B 正在读同一条木板上第 60cm 处的另一颗螺丝，它就得重新从 L2/L3 缓存甚至内存里拉整条木板——哪怕它读的那 8 字节根本没被改过。

在我们的场景里：

• 8 个路由线程（每个绑定一个 CPU 核）各自维护一个 RouteEntry[] 数组
• 数组在堆上连续分配，相邻的 RouteEntry 实例共享同一条 64B cache-line
• 线程 A 写 entries[0].weight++，线程 B 写 entries[1].weight++——它们操作的是不同对象，但落在同一条 cache-line 上
• 每次写入触发 cache-line 在核间"乒乓"（ping-pong），L3 cache 命中率从 94% 掉到 61%

perf stat 抓到了实锤：

$ perf stat -e cache-references,cache-misses,LLC-load-misses ./stress-test -t 8
 Performance counter stats for './stress-test -t 8':
   4,821,330,221  cache-references
     2,940,117,883  cache-misses       # 61.0%  ← 正常应 < 10%
       892,441,006  LLC-load-misses

修改前（4 线程）的 cache-misses 只有 3.2%。

三、具体做法：三步定位 + 两步修复

第一步：用 JOL 确认对象实际大小

import org.openjdk.jol.info.ClassLayout;

public class LayoutCheck {
    public static void main(String[] args) {
        System.out.println(ClassLayout.parseInstance(new RouteEntry()).toPrintable());
    }
}

输出（JDK 17）：

RouteEntry object internals:
 OFFSET  SIZE   TYPE DESCRIPTION
      0    16        (object header)
     16     8    long RouteEntry::lastAccess
     24     8   java.lang.String RouteEntry::tenantId
     32     8   java.lang.String RouteEntry::targetHost
     40     4        int RouteEntry::weight
     44     4        int RouteEntry::priority
     48     8   java.lang.String RouteEntry::tags
     56     8        (loss of alignment)   ← 对齐损耗
  Instance size:  64 bytes  (旧版，无 priority)

加了 priority 后 Instance size 变成 72 bytes，跨了 cache-line。

第二步：perf 确认 cache-line ping-pong

# 在 8 线程压测时，观察 LLC 命中率
$ perf stat -e LLC-load-misses,LLC-loads ./app &
$ curl -X POST http://localhost:8080/stress -d '{"threads":8,"duration":30}'
# 对比 4 线程 vs 8 线程的 LLC-load-misses 比例

如果 8 线程时 LLC-load-misses / LLC-loads > 30%，而 4 线程时 < 10%，基本锁定是伪共享。

第三步（修复方案 A）：@Contended 注解

import jdk.incubator.contended.Contended;

public class RouteEntry {
    private String tenantId;
    private String targetHost;
    private int weight;
    @Contended private int priority;   // 强制独立 cache-line
    private long lastAccess;
    @Contended private String tags;
}

启动参数：

# JDK 17：@Contended 在 incubator 模块，需要显式开放
java --add-modules jdk.incubator.contended \
     --add-exports jdk.incubator.contended/jdk.incubator.contended=ALL-UNNAMED \
     -jar route-service.jar

修复后复测（8 线程，30s）：

| 指标 | 修复前 | 修复后 | |------|--------|--------| | 吞吐 | 78 kQPS | 119 kQPS | | P50 | 2.6ms | 1.9ms | | P99 | 11ms | 6.2ms | | cache-miss | 61% | 4.1% |

修复方案 B：手动 padding（不依赖 incubator）

如果不想引入 jdk.incubator.contended（毕竟标注了 "incubator"），可以手动加 padding 字段：

public class RouteEntry {
    private String tenantId;
    private String targetHost;
    private int weight;
    private int priority;
    // 手动 padding：确保 weight+priority 独占一条 cache-line
    private long pad0, pad1, pad2, pad3, pad4, pad5, pad6, pad7;
    private long lastAccess;
    private String tags;
}

代价是内存多占 64B/实例。如果 RouteEntry 数量在百万级，多占 64MB，需要权衡。

四、踩过的坑与反直觉之处

坑 1：@Contended 在 JDK 12+ 被标记为 incubator，很多团队直接禁用了

JDK 12 把 sun.misc.Contended 移到了 jdk.incubator.contended，且默认 不生效（需要 --add-modules + --add-exports）。我们一开始加了注解但没加启动参数，跑了一整天发现"没效果"——因为注解根本没被处理。

坑 2：-XX:-RestrictContended 在 JDK 17 已移除

老文档里建议加 -XX:-RestrictContended 让 @Contended 对任意类生效。JDK 17 直接删了这个 flag，现在只有 jdk.incubator.contended 模块里的注解才有效。

坑 3：字段重排不是"声明顺序"

HotSpot 会按 宽度降序（long > ref > int > short > byte）重排实例字段，和你在 Java 源码里的声明顺序无关。你以为把 priority 声明在最后就没事，实际上 HotSpot 把它排在了 weight 后面——恰好把对象推过了 64B 边界。

坑 4：4 线程不暴露、8 线程才炸

伪共享的严重程度和并发核数正相关。4 线程时，OS 调度器经常把 4 个线程分到 4 个不同的 NUMA 节点或 L2 缓存域，cache-line 乒乓概率低；8 线程全部挤在同一 L3 缓存上，乒乓频率指数级上升。这就是为什么"本地 4 核机器测着没问题，上了 8 核容器就炸"。

坑 5：jstat / jconsole 完全看不到

这不是 GC 问题、不是内存泄漏、不是 CPU 瓶颈——所有常规 Java 监控工具都显示"一切正常"。只有 perf stat 看 cache-miss 才能发现。

五、结论与可复用清单

| # | 检查项 | 命令 / 工具 | |---|--------|------------| | 1 | 热路径对象大小是否跨 64B 边界 | JOL ClassLayout.parseInstance(obj).toPrintable() | | 2 | 多线程写同一数组相邻元素时，cache-miss 是否异常 | perf stat -e cache-misses,LLC-load-misses | | 3 | 对象是否被 HotSpot 重排到非预期位置 | JOL 输出对比 vs 源码声明顺序 | | 4 | @Contended 是否真正生效 | 启动参数确认 --add-modules jdk.incubator.contended | | 5 | 修复后 cache-miss 是否回到 < 10% | perf stat 对比 | | 6 | 新增字段后是否重新跑了多核压测 | 至少 2× 物理核数的并发 |

一句话总结：在 Java 里加一个 int 字段看起来人畜无害，但如果它把热路径对象推过了 64 字节的 cache-line 边界，8 个核就会像 8 个人抢一块木板上的螺丝——谁都拧不动。性能优化的世界里，4 个字节可能就是 35% 的吞吐。