volatile写不能避免跨核缓存同步，它仍依赖MESI协议广播invalidate请求，引发缓存行争用和总线带宽饱和。
Java里 volatile 变量的写操作真能避免跨核缓存同步吗
不能。volatile 写触发 StoreStore 和 StoreLoad 屏障，但底层仍需通过 MESI 协议广播 invalidate 请求——这本身就是跨核同步开销的来源。
常见错误现象：以为加了 volatile 就“无锁快如飞”，结果在 32 核机器上测出写延迟突增 3–5 倍；其实不是 Java 问题，是缓存行被多核反复争夺导致总线/互连带宽打满。
- 使用场景：适合读多写少、且写后不立即被其他核高频读的变量（比如状态标志位）
-
volatile对 long/double 的读写保证原子性，但不保证复合操作（如i++）原子——这点和 MESI 无关，纯语言规范 - 性能影响：单次
volatile写在 Intel x86 上平均比普通写慢 10–20ns，但高并发下可能因缓存行失效风暴拉长到百纳秒级
MESI 状态切换如何让 Java 的 synchronized 块变慢
当多个线程在不同核上竞争同一把锁时，monitor 对象头里的 mark word 所在缓存行会频繁在 Modified → Invalid → Shared 之间跳变，每次状态迁移都伴随一次 cache-coherence traffic。
典型表现：压测时看到 perf stat -e cache-misses,cache-references 中 cache-miss rate 超过 30%，同时 LLC-load-misses 暴涨——说明 L3 缓存已无法缓解跨核同步压力。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 对象布局影响大：
synchronized锁的对象若和其他热点字段共用缓存行（64 字节），会引发 false sharing，放大 MESI 开销 - 偏向锁在 JDK 15+ 默认关闭，意味着所有锁竞争都走轻量级锁路径，直接触发 CAS + 缓存行失效，没得绕
- 如果锁内只做简单赋值（如
count++），不如改用AtomicInteger——它用lock xadd指令，在硬件层就完成原子更新，比 JVM monitor 更贴近 MESI 优化边界
Unsafe.compareAndSet 为什么有时比 synchronized 还慢
因为 compareAndSet 底层调用的是 cmpxchg 指令，它隐式带有 full memory barrier，且在失败重试时反复读写同一缓存行，容易卡在 Exclusive 状态争抢上。
错误用法示例：用 AtomicInteger 实现一个计数器，但在每毫秒内被 10 个核各调用 1000 次——这时 compareAndSet 失败率超 70%，大量空转消耗 cycles，而 synchronized 反而靠队列化降低了冲突密度。
- 适用条件：预期 CAS 失败率低于 10%；否则考虑分段计数（如
LongAdder）或锁升级 - JDK 8+ 的
LongAdder在高竞争下自动拆成 cell 数组，每个 cell 独占缓存行，本质是用空间换 MESI 安静 - 注意
Unsafe.compareAndSet不检查对象是否为空，传入 null 会直接抛NullPointerException，不是IllegalMonitorStateException
Linux perf 能否直接观测到 MESI 引起的延迟
不能直接看到“MESI 协议开销”这个指标，但可以通过组合事件定位其副作用。
最有效的信号是：perf stat -e cycles,instructions,cache-references,cache-misses,mem-loads,mem-stores,mem-loads-retired.l3_miss 中，l3_miss 比例异常高，且 cycles/instruction 显著上升——说明 CPU 正在等远端核响应 cache line 请求。
- 不要只看
cache-misses：它包含 TLB miss、page fault 等干扰项；重点盯mem-loads-retired.l3_miss（需要 CPU 支持 PEBS） - Intel CPU 可用
uncore_imc/data_reads查看内存控制器实际读流量，若该值接近理论带宽上限，基本可断定是跨核同步拖慢了内存访问 - perf record + perf report 只能定位热点函数，没法告诉你哪条指令触发了
Invalidate；得结合perf script -F ip,sym,trace和 kernel tracepointsyscalls/sys_enter_futex交叉分析
跨核同步不是抽象概念，它落在每一条 cache line 的状态迁移上，也落在每次 volatile 写、每个 monitorenter、每一次 cmpxchg 的执行周期里。真正难的不是知道 MESI，而是判断当前代码里哪一行正在把缓存行变成战场。
