Treiber栈必须用AtomicReference而非普通引用，因其push/pop需原子性地读-算-写栈顶指针，CAS保证原子性与可见性，配合final字段避免发布问题，并需防ABA、空栈死循环及CPU自旋耗尽。
为什么 Treiber 栈必须用 AtomicReference 而不是普通引用
因为栈顶指针的更新必须是原子的：push 和 pop 都要「读当前顶点 → 计算新顶点 → 写回」三步，中间不能被其他线程插队。普通 Node 引用赋值不具备原子性，哪怕加 synchronized 也破坏了“无锁”前提。
AtomicReference 提供 compareAndSet(oldValue, newValue)，底层调用 CPU 的 CAS 指令，失败就重试（自旋），不阻塞线程。
- 错误写法：
top = newNode—— 竞态下会丢失更新 - 正确模式：循环调用
compareAndSet(oldTop, newTop)，直到成功 - 注意
compareAndSet返回boolean，必须检查返回值，不能忽略失败
push 操作中容易漏掉的内存可见性问题
CAS 本身保证可见性，但 Node 字段（如 next）的写入如果不配合 happens-before 关系，其他线程可能看到未初始化的字段值。JVM 不保证构造器内字段写入对其他线程立即可见。
- 必须把
next字段声明为final（推荐）或volatile - 错误示例：
Node node = new Node(value); node.next = oldTop; top.compareAndSet(oldTop, node)—— 中间两行无同步，node.next可能为 null - 正确做法：在构造器里完成
next赋值，且该字段为final，利用 final field semantics 保证发布安全
pop 自旋逻辑里最常写的死循环陷阱
看似简单的一次 CAS 尝试，实际要处理空栈、ABA 问题（虽不影响正确性，但影响性能）、以及无限自旋耗尽 CPU。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 必须先检查
top.get() == null，再进 CAS 循环，否则空栈时会永远自旋 - 不要在 while(true) 里裸跑
compareAndSet，至少加个Thread.onSpinWait()（Java 9+）缓解 CPU 占用 - ABA 问题在这里不破坏逻辑（Treiber 栈只关心引用相等），但若中间有节点被回收又复用，可能触发 JVM 的 unsafe 内存复用警告（极少见）
- 示例片段：
Node current, next;<br>do {<br> current = top.get();<br> if (current == null) return null;<br> next = current.next;<br>} while (!top.compareAndSet(current, next));<br>return current;
和 ConcurrentLinkedStack 对比时的关键差异点
Java 8+ 的 ConcurrentLinkedStack 本质就是 Treiber 栈的工业实现，但它做了大量优化：延迟初始化、批量回收、更精细的自旋退避。自己手写时容易低估这些细节。
- 它用
UNSAFE直接操作内存地址，绕过AtomicReference的一层封装，性能略高 - 它的
pop在多次失败后会短暂让出 CPU（不是yield，而是类似LockSupport.parkNanos(1)） - 自己实现时若没做退避，高争用下吞吐反而不如
Stack+synchronized - 除非你在写教学代码或嵌入式受限环境，否则直接用
ConcurrentLinkedStack更稳
真正难的不是写出能跑通的 CAS 循环，而是让自旋不卡死、内存不乱序、边界不崩溃——这些全藏在几行 if 和 while 后面。
