Scala 并发与原子性实战：无锁编程、并发数据结构与 STM

可见性（Visibility）：
线程 A 改了变量，线程 B 不一定看得到（CPU 缓存/寄存器）

原子性（Atomicity）：
「读-改-写」三步之间被其他线程打断 → 结果错乱

有序性（Ordering）：
编译器/CPU 重排指令 → 代码顺序 ≠ 执行顺序

// 经典竞态：两个线程同时 +1
var counter = 0
def inc() = counter += 1   // 非原子：读 → 加 → 写，三步可被打断

happens-before 规则（可见性的依据）：
□ 同一线程内：按程序顺序
□ 解锁 → 后续加锁的线程
□ volatile 写 → 后续读该 volatile 的线程
□ 线程 start/join：启动/等待关系
□ 传递性：A → B → C 则 A → C

volatile：保证可见性 + 禁止重排，但不保证原子性
  → volatile 的 i++ 依然是竞态（读改写三步不原子）

final：构造器内写 final 字段 → 发布即安全
  → 不可变对象天然安全（这就是 Scala val/case class 安全的根基）

@volatile var flag = false
// 可见：写 flag 的线程，其他线程一定能看到
// 但 flag 的「读-改-写」不是原子的 → 计数用 AtomicInteger

锁的代价：
□ 阻塞：线程竞争锁失败 → 挂起/唤醒（上下文切换，微秒级）
□ 死锁：多个锁 + 循环等待 → 卡死
□ 锁粒度：锁太大 → 并发度低；锁太小 → 竞态未消除

JVM 锁的优化：
□ 偏向锁/轻量级锁/重量级锁（自适应自旋）
□ 锁消除/锁粗化（JIT 优化）

Scala 侧：
□ synchronized 块与 Java 相同
□ 但更推荐「不可变 + 原子类」替代大部分锁

private val lock = new Object
def update(): Unit = lock.synchronized {
  counter += 1   // 临界区，互斥
}

CAS（Compare-And-Swap）：
读当前值 → 与期望值比较 → 相等则写入新值 → 返回是否成功
不相等 → 重试（或放弃）→ 无阻塞

AtomicInteger/AtomicLong/AtomicReference：
□ getAndIncrement：原子的 +1
□ compareAndSet(expected, new)：原子的条件更新
□ updateAndGet：原子的「读-改-写」回调

代价：
□ CAS 失败会自旋重试（激烈竞争时自旋开销）
□ ABA 问题：值从 A 变 B 又变回 A → 用 AtomicStampedReference

val counter = new AtomicInteger(0)
counter.incrementAndGet()              // 原子的 +1
counter.updateAndGet(prev => prev + 1) // 原子的读-改-写

线程安全集合（java.util.concurrent）：
□ ConcurrentHashMap：分段/桶级锁，读无锁，写并发
□ CopyOnWriteArrayList：读多写少，写时复制（读快写慢）
□ ConcurrentLinkedQueue：无锁队列（生产者-消费者）
□ BlockingQueue（Array/Linked）：带阻塞语义的队列

不安全的旧集合：
□ Hashtable/Vector：全表锁，性能差，已被取代
□ 普通 HashMap/ArrayList：并发改 → 结构损坏/无限循环

Scala 侧：
□ scala.collection.concurrent.TrieMap：无锁并发 map，支持快照
□ mutable.* 集合默认线程不安全

选型口诀：
□ 读多写少 + 频繁遍历 → CopyOnWriteArrayList
□ 高并发读写 map → ConcurrentHashMap / TrieMap
□ 生产者-消费者 → BlockingQueue（含超时/容量）
□ 需要不可变快照 → TrieMap.snapshot

Future（scala.concurrent）：
□ 回调组合：map/flatMap/zip → 链式异步
□ ExecutionContext：线程池抽象
□ 注意：Future 的回调执行顺序与线程不保证 → 依赖块内逻辑自包含

scala.concurrent.duration：超时与优雅处理
Await.result(future, 10.seconds)：阻塞等待（仅限测试/启动）

并发集合增强：
□ TrieMap：无锁 + 快照（比 JUC 更 Scala 友好）
□ .par 并行集合：par.map 自动并行（内部用 ForkJoinPool）

import scala.concurrent.{Future, Await}
import scala.concurrent.duration._

val jobs: List[Future[Int]] = (1 to 10).map(i => Future { i * 2 })
val sum = Future.sequence(jobs).map(_.sum)
println(Await.result(sum, 5.seconds))  // 110

Actor（Akka）：
□ 适合：跨线程传递消息、有状态服务、分布式
□ 模型：邮箱串行化 → 天然避免共享状态竞态
□ 代价：消息开销、邮箱积压

Fiber/Effect（Cats Effect / ZIO）：
□ 适合：异步 IO、大量轻量任务、取消/超时
□ 模型：绿色线程，无阻塞
□ 代价：需要理解 Effect 语义

原子类/锁/STM：
□ 适合：单进程内的低层共享状态（缓存、计数器）
□ 模型：内存级原语，性能最高
□ 代价：无高层抽象，需要自己保证正确性

选择框架：
□ 共享状态跨线程且频繁 → 原子类/锁/STM
□ 逻辑分布在多个「独立状态单元」 → Actor
□ IO 密集型异步 → Fiber/Effect
□ 分布式集群 → Actor 集群

原理：
□ 事务块内对共享变量的读写 → 提交时校验（版本比对）
□ 冲突则重试整个事务（乐观并发）
□ 解决了「锁的顺序死锁」（事务无顺序）

Scala 侧：ScalaSTM（原 Akka STM）
□ atomic { ... } 包裹事务块
□ TRef（事务引用）替代普通引用

适用：
□ 多个共享变量需要「一起原子更新」→ 事务组合
□ 锁难编排的复杂临界区 → STM 简化
□ 读多写少、冲突少的场景（冲突多则重试爆炸）

代价：
□ 重试开销（冲突频繁时性能差）
□ 与外部 IO 混合时事务无法回滚外部副作用 → 事务内不能做 IO

import scala.concurrent.stm._
val balanceA = TRef(100)
val balanceB = TRef(50)
atomic { implicit txn =>
  balanceA() = balanceA() - 30   // 两个 TRef 一起原子更新
  balanceB() = balanceB() + 30
}

陷阱 1：ABA 问题
  值 A→B→A，CAS 误判「没变过」→ 用带版本号的引用

陷阱 2：内存重排（Memory Reordering）
  无锁结构依赖 volatile/CAS 的内存屏障 → 漏一个屏障就出 bug

陷阱 3：伪共享（False Sharing）
  不同线程改相邻字段 → 同一缓存行互相失效 → 性能暴跌
  → 用 @Contended 或字段填充隔离缓存行

陷阱 4：极端难测
  无锁 bug 依赖时序，单元测试跑不出 → 生产才爆

正确姿势：
□ 优先用 JDK 现成并发集合（已无数人验证）
□ 实在要写 → 用 @Contended + 严格内存屏障 + 并发压力测试

伪共享示例：
class Counter { 
  @volatile var a = 0L   // a 与 b 可能在同一缓存行
  @volatile var b = 0L   // 线程改 a、线程改 b → 互相失效
}