悲观锁和乐观锁
引言
以下代码：
count++
执行步骤：
- 读取
count值 - 将值加1
- 将新值写入
场景：
线程A如果读取了count，还没写入新值，线程B也读取了count，那么当线程B结束，则线程A等于白干。
悲观锁
synchronized：安全，但有代价。
即假设了会发生冲突，则提前获取锁才能进行操作，迫使其他线程等待。（即永远做最坏的打算）在任何时间只有1个线程能进来干活。
缺点：大量线程争抢同一把锁则会拖慢系统运行速度。
乐观锁
CAS:（比较并交换循环）快，完全不加锁。
假设冲突很少发生，直接尝试更新，当数据在此期间被其他线程改变了才会失败。
步骤：
- 读取当前值（count）
- 计算新值（count+1）
- 原子性检查：当前值仍然是
count吗，是，则与count+1交换（换上新值）。 - 检查失败，则返回第一步重试。
整个CAS机制是直接植入硬件中的，由CPU里的特殊原子指令来支持的。
缺点：会出现ABA问题，即：
graph LR
1[A] --> b --> 2[A]
如果一个值变了，又变回了原来的样子。
即线程A拿到了值，突然线程B冲进来改了值做完运算并又改了回来。A则认为这个值仍然是原来的那个值。
解决方案：给值加入版本号（戳记）。Java类：atomic stamped reference。
则A线程不仅要校验值，也要校验版本号。
使用法则
比较：
| 特性 | synchronized | 原子变量（CAS） |
|---|---|---|
| 并发策略 | 悲观锁 | 乐观锁 |
| 线程状态 | 可能阻塞/挂起 | 非阻塞，自旋重试 |
| 开销 | 高（上下文切换） | 低（硬件级） |
| 操作粒度 | 粗（代码块） | 细（单个变量） |
| 安全性 | 无ABA问题 | 存在ABA问题 |
synchronized：适用用来保护大块复杂业务逻辑代码。
CAS：保护单个变量。（性能优化的首选）