锁策略
- 悲观锁
- 乐观锁
- 乐观锁的实现方式
- 公平锁 vs 非公平锁
悲观锁
悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题，例如共享数据被修改等，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。
synchronized ReentrantLock 等独占锁就是悲观锁思想实现的。
乐观锁
乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源数据是否被其它线程修改了（具体方法可以使用版本号机制或 CAS 算法）。
例如java.util.concurrent.atomic包下面的AtomicInteger、LongAdder就是使用了乐观锁的一种实现方式CAS实现。
高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试，这样同样会非常影响性能，导致 CPU 飙升。
不过，大量失败重试的问题也是可以解决的，像我们前面提到的 LongAdder以空间换时间的方式就解决了这个问题。
理论上来说：
- 悲观锁通常多用于
写比较多的情况（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如LongAdder），也是可以考虑使用乐观锁的，要视实际情况而定。 - 乐观锁通常多用于
写比较少的情况（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考java.util.concurrent.atomic包下面的原子变量类）。
乐观锁的实现方式
版本号机制或 CAS 算法实现
CAS（Compare and Swap）是一种轻量级的同步操作，也是乐观锁的一种实现，它用于实现多线程环境下的并发算法。CAS 操作包含三个操作数：内存位置（或者说是一个变量的引用）、预期的值和新值。如果内存位置的值和预期值相等，那么处理器会自动将该位置的值更新为新值，否则不进行任何操作。
带版本号的 CAS，也称为双重 CAS（Double CAS）或者版本号 CAS。具体来说，每次进行 CAS 操作时，不仅需要比较要修改的内存地址的值与期望的值是否相等，还需要比较这个内存地址的版本号是否与期望的版本号相等。如果相等，才进行修改操作。这样，在修改后的值后面追加上一个版本号，即使变量的值从 A 变成了 B 再变成了 A，版本号也会发生变化，从而避免了误判。
公平锁 vs 非公平锁
公平锁 : 锁被释放之后，先申请的线程先得到锁。性能较差一些，因为公平锁为了保证时间上的绝对顺序，上下文切换更频繁。
非公平锁：锁被释放之后，后申请的线程可能会先获取到锁，是随机或者按照其他优先级排序的。性能更好，但可能会导致某些线程永远无法获取到锁。
