版本号机制

1. 线程1读取内存中数据为A
2. 线程2将该数据修改为B
3. 线程2将该数据修改为A
4. 线程1对数据进行CAS操作

在第 4 步中，由于内存中数据仍然为A，因此CAS操作成功，但实际上该数据已经被线程2修改过了。这就是ABA问题（就是乐观锁并不知道数据已经改变了，仅仅基于值是否变化作为判断依据）

但是在某些场景下，ABA却会带来隐患，例如栈顶问题：一个栈的栈顶经过两次(或多次)变化又恢复了原值，但是栈可能已发生了变化。

解决方法：

引入版本号，内存中的值每发生一次变化，版本号都+1；在进行CAS操作时，不仅比较内存中的值，也会比较版本号，只有当二者都没有变化时，CAS才能执行成功。

Java中的AtomicStampedReference类便是使用版本号来解决ABA问题的。

高竞争下的开销问题：

在并发冲突概率大的高竞争环境下，如果CAS一直失败，会一直᯿试，CPU开销较大。

解决方法：

思路一：是引入退出机制，如᯿试次数超过一定阈值后失败退出；

思路二：更᯿要的是避免在高竞争环境下使用乐观锁。

2、功能限制

CAS的功能是比较受限的，例如CAS只能保证单个变ᰁ（或者说单个内存值）操作的原子性，这意味着：

(1) 原子性不一定能保证线程安全，例如在Java中需要与volatile配合来保证线程安全；

(2) 当涉及到多个变ᰁ(内存值)时，CAS也无能为力。

除此之外，CAS的实现需要硬件层面处理器的支持，灵活性受到限制。

版本号机制

基本思路：

在数据中增加一个字段version，表示该数据的版本号，每当数据被修改，版本号加1。

当某个线程查询数据时，将该数据的版本号一起查出来；当该线程更新数据时，判断当前版本号与之前读取的版本号是否一致，如果一致才进行操作

也可以使用时间戳作为标记；

典型锁

1、互斥锁(mutex)--线程锁

一次只能一个线程拥有互斥锁，其他线程只有等待。

为了实现锁的状态发生改变时唤醒阻塞的线程或者进程，需要把锁交给操作系统管理，所以互斥锁在加锁操作时涉及上下文的切换。

2、条件变量(cond)--线程锁

条件变ᰁ分为两部分

1. 条件
2. 变ᰁ

条件本身是由互斥ᰁ保护的，线程在改变条件状态前先要锁住互斥ᰁ，它利用线程间共享的全局变ᰁ进行同步的一种机制。

用来等待而不是用来上锁的。条件变ᰁ用来自动阻塞一个线程，直到某特殊情况发生为止。

条件变ᰁ通过允许线程阻塞和等待另一个线程发送信号的方法弥补了互斥锁的不足，他常和互斥锁一起使用，以免出现竞态条件。

当条件不满足时，线程往往解开相应的互斥锁并阻塞线程然后等待条件发生变化。

一旦其他的某个线程改变了条件变ᰁ，他将通知相应的条件变ᰁ唤醒一个或多个正被此条件变ᰁ阻塞的线程。满足条件则被唤醒

3、自旋锁(spin)--线程锁

属于busy-waiting类型的锁

如果线程A是使用pthread_spin_lock操作去请求锁

如果自旋锁已经被线程B所持有，那么线程A就会一直在core 0上进行忙等待并不停的进行锁请求，检查该自旋锁是否已经被线程B释放，直到得到这个锁为止。

因为自旋锁不会引起调用者睡眠，所以自旋锁的效率远高于互斥锁。

缺点：

（1）自旋锁一直占用CPU

在未获得锁的情况下，一直进行自旋，所以占用着CPU，如果不能在很短的时间内获得锁，无疑会使CPU效率降低。

（2）在用自旋锁时有可能造成死锁

当递归调用时有可能造成死锁。

（3）自旋锁只有在内核可抢占式或SMP的情况下才真正需要

在单CPU且不可抢占式的内核下，自旋锁的操作为空操作。自旋锁适用于锁使用者保持锁时间比较短的情况下。

4、读写锁

1. 多个读者可以同时进行读
2. 写者必须互斥（只允许一个写者写，也不能读者写者同时进行）