常见的锁策略

乐观锁和悲观锁

乐观锁：预测接下来不会发生冲突，在数据更新时才检查是否发生冲突，若冲突则返回错误信息，交给用户自己决定。

悲观锁：预测接下来会发生冲突，每次拿取数据都会上锁，当其它人想拿取这个数据的时候就会发生阻塞。

synchronized在冲突的概率不大的时候是乐观锁，发生冲突的概率大的时候为悲观锁。

那么如何去实现乐观锁呢?

版本号法

如给数据表中增加一个数据版本号的字段，当某个线程对数据进行提交修改的时候，版本号会 + 1。当某个线程去修改数据的时候，会先读取到当前数据的版本号，在提交的时候，只有读取的版本号和数据库的版本号相等才会提交成功（即证明当前的数据没有被修改过），否则就会失败，重复该过程直到成功为止。

举例：

假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1. 操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
2. 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
3. 操作员 A 完成了修改工作，将数据版本号（ version=1 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本等于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
4. 操作员 B 完成了操作，也将版本号（ version=1 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 1 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须等于当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

 

---

读写锁

读写锁即在执行加锁操作时要额外写明读写意图，多次读之间并不产生互斥，只有写的时候产生互斥。例如以下三种情况。

1:

线程A尝试加读锁

线程B尝试加写锁

产生互斥，和普通锁没有区别

2:

线程A尝试加读锁

线程B尝试加读 锁

不产生互斥

1:

线程A尝试加读锁

线程B尝试加写锁  

产生互斥，和普通锁没有区别

---

重量级锁和轻量级锁

重量级锁：主要是使用操作系统提供的锁，容易发生阻塞。

轻量级锁：主要使用非操作系统提供的锁，主要以用户态来完成功能，减少用户态和内核态之间                      的转换。尽量避免了挂起等待。

synchronized在竞争激烈的时候是重量级锁，在竞争不激烈的时候是轻量级锁。

---

自旋锁

当抢锁失败时，会立即尝试再次获取锁，无限循环，直到再次获取锁为止。

synchronized的轻量级锁的实现方式一般就是自旋锁。

---

公平锁和非公平锁

公平锁：遵守先来先得的原则。即当B 比 C 先来的. 当 A 释放锁的之后, B 就能先于 C 获取到锁.

非公平锁：即不遵守先来先得的原则。

---

可重入锁和非可重入锁

可重入锁：可重入锁的字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。

即如下面代码所示：当尝试再次加锁时，不会发生阻塞而形成死锁。

 即synchronized为可重入锁。