concurrenthashmap 的 value 字段不加 volatile，因其通过 unsafe cas 操作和内存屏障保障可见性，而非依赖字段修饰符；jdk 8/9+ 中 node.value 均为普通字段，加 volatile 反增写屏障开销且无必要。
为什么 ConcurrentHashMap 的 value 字段不加 volatile？
因为 ConcurrentHashMap 本身不靠 volatile 保证 value 的可见性，而是通过 Unsafe 的 CAS 操作 + 内存屏障（如 UNSAFE.putObjectVolatile）在关键路径上施加更强的语义。value 字段本身是普通字段，但所有写入都发生在受控的原子操作中——比如 putVal 里对 Node.value 的赋值，实际由 UNSAFE.putObject 或带 volatile 语义的变体完成，不是直接裸赋值。
常见错误现象：
有人手动把 ConcurrentHashMap 的 value 类型改成 volatile Object，结果发现编译不过（泛型擦除后无法约束字段修饰符），或者自己封装了一个带 volatile value 的 Node，却忘了读写仍需同步控制——这时 volatile 单独存在毫无意义，甚至掩盖真正的线程安全漏洞。
- 使用场景：只有你自己实现并发容器时才需要考虑字段级 volatile；用标准
ConcurrentHashMap就别碰 value 字段的可见性 - 参数差异：JDK 8 中
Node的val是普通字段；JDK 9+ 引入TreeBin和ForwardingNode，其内部字段也未加volatile，逻辑一致 - 性能影响：给每个 value 加
volatile会显著增加写屏障开销，而ConcurrentHashMap的设计目标是写少读多，且写已天然序列化
什么时候必须给集合字段加 volatile？
当你暴露一个非线程安全集合的引用，并且多个线程可能同时读/写这个引用本身（不是集合内容）时，比如缓存单例、配置映射表等静态或成员变量。
典型错误：private Map<string string> configMap = new HashMap();</string> —— 如果在初始化线程里构建完后，其他线程直接读取该字段，可能看到部分构造、甚至 null 引用（由于指令重排序）。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：用
volatile修饰该字段，例如private volatile Map<string string> configMap;</string> - 注意：这仅保证“引用”本身的可见性，不保证
configMap内部操作线程安全；若需运行时修改，仍得换成ConcurrentHashMap或加锁 - 兼容性：JDK 5+ 生效；JDK 1.4 及之前 volatile 语义弱，不能依赖
CopyOnWriteArrayList 的 elementData 为什么是 volatile？
因为 CopyOnWriteArrayList 的核心机制是“读不加锁、写复制”，每次写操作（add/set/remove）都会新建数组并用 volatile 写入 elementData 字段。读线程能立即看到新数组，靠的就是这个 volatile 写的 happens-before 保证。
容易踩的坑：
误以为 volatile 能让数组元素本身可见——其实不能。如果数组里存的是可变对象（比如 new AtomicReference(0)），改它的状态，仍需对象自身同步；volatile 只管 elementData 这个引用换没换。
- 使用场景：适合读远多于写的场合，比如监听器列表、配置快照
- 性能影响：写操作要数组复制 + volatile 写，代价高；频繁写时比
ConcurrentLinkedQueue慢得多 - 示例：
volatile Object[] elementData;在 JDK 源码中明确声明，不可省略
自定义并发集合时，volatile 字段的边界在哪？
volatile 只解决单个字段的可见性与重排序问题，它不能替代锁或 CAS 来保护复合操作。比如你写一个简易的无锁栈，即使 top 指针用 volatile，push 仍需 CAS 循环，否则两个线程同时 push 会丢失节点。
真实调试中常遇到：
看到某个字段加了 volatile 就以为“线程安全了”，结果在多线程下出现数据覆盖、计数不准、链表断裂——根本原因是漏掉了对操作原子性的保障。
- 原则：volatile 用于状态标志（running、closed）、引用替换（head/tail）、或作为 CAS 的基础字段；绝不用于保护“读-改-写”流程
- 替代方案：优先用
AtomicReferenceFieldUpdater控制字段级原子更新，比反射 + volatile 更安全可控 - 复杂点在于：volatile 和 final 在构造期间的交互很微妙；如果在构造器里把 this 逸出，volatile 字段也可能被其他线程看到初始值而非写入值
