链表本身不引发伪共享，问题在于多线程高频写入的节点字段（如计数器、next/prev指针、state、head/tail）落入同一缓存行；需精准识别高危字段，对齐64字节边界填充，避免过度填充导致缓存利用率下降。
链表本身不直接引发伪共享，真正出问题的是链表节点中被多线程高频写入的字段——比如计数器、状态标志或游标变量。当这些字段在内存中紧挨着存放，又恰好落入同一64字节缓存行时，多个核心就会为同一缓存行反复争抢所有权，性能骤降。所谓“变量填充导致的性能损耗”，往往不是填充本身慢，而是填错了位置、填得过多，或填了本不该填的地方。
识别哪些链表字段真需要缓存隔离
伪共享只发生在**被不同线程独立且高频写入**的变量之间。读多写少、或由单一线程独占修改的字段，无需填充。常见高危字段包括：
- 节点级原子计数器（如访问次数、重试次数）
- 无锁链表中的 next/prev 指针更新字段（尤其在并发插入/删除路径中）
- 状态机字段（如 volatile int state，在多个线程触发状态跃迁时）
- 环形链表中的 head/tail 索引变量（若由不同线程分别推进）
而像 final 类型的 key、不可变 payload 或仅由构造线程初始化的元数据，填充不仅无效，还会浪费 L1 缓存空间，间接降低缓存命中率。
填充必须对齐缓存行边界，而非简单加字段
只在字段前后加几个 long 或 byte 不够——JVM 或编译器可能重新排布字段顺序，或因对象头、对齐填充干扰实际布局。正确做法是确保目标字段起始地址能被 64 整除（x86/ARM 主流平台）。Java 中应使用 @Contended 注解并开启 JVM 参数 -XX:+UseContended；C++ 中用 alignas(64) 配合静态断言验证偏移量。
例如：一个含两个计数器的节点，若都需隔离，不能只给第一个加 56 字节填充，而应让第二个计数器也从下一个缓存行开头开始，即两者间隔至少 64 字节。
避免过度填充带来的新问题
每个节点填充 64 字节，100 万个节点就多占 64MB 内存。这不仅增加 GC 压力，更关键的是降低 L1 缓存行利用率——原本可缓存 16 个紧凑节点的空间，现在只能放 1 个填充节点，有效带宽下降。优化方向是：
- 优先对热点字段填充，冷字段共用缓存行
- 用数组替代链表节点（如 RingBuffer），天然按缓存行对齐分配元素
- 将写操作聚合到线程本地缓冲区，批量刷新，减少跨核同步频次
验证是否真正解决，而不是掩盖问题
填充后性能没提升？可能原因有：
- 伪共享根本不存在——瓶颈其实在锁竞争、内存带宽或分支预测失败
- 填充后变量虽隔离，但引发更多 cache miss（因对象体积变大，相同缓存容量容纳节点数减少）
- 工具误报——perf record -e cache-misses,instructions,cycles 可比对填充前后的 L1-dcache-load-misses 和 remote-node memory access 比例
真正有效的优化，应看到缓存一致性流量（如 LLC-traffic、snoop-responses）显著下降，同时每周期指令数（IPC）上升。
