各种锁的概述

本文介绍: 当一个线程要获取一个被其他线程持有的独占锁时，该线程会被阻塞，那么当一个线程再次获取它自己已经获取的锁时是否会被阻塞呢?如果不被阻塞，那么我们说该锁是可重入的，也就是只要该线程获取了该锁，那么可以无限次数地进入被该锁锁住的代码。调用helloB方法前会先获取内置锁，然后打印输出。之后调用helloA方法，在调用前会先去获取内置锁，如果内置锁不是可重入的，那么调用线程将会一直被阻塞。实际上，synchronized内部锁是可重入锁。

乐观锁与悲观锁

悲观锁指对数据被外界修改持保守态度，认为数据很容易就会被其他线程修改，所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。

悲观锁的实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁。

如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。

如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。
在这里插入图片描述
假设updateEntry、query、update方法都使用了事务切面的方法，并且事务传播性被设置为required。

执行updateEntry方法时如果上层调用方法里面没有开启事务，则会即时开启一个事务，然后执行代码(1)。

代码(1)调用了query方法，其根据指定id从数据库里面查询出一个记录。

由于事务传播性为requried,所以执行query时没有开启新的事务，而是加入了updateEntry开启的事务，也就是在updateEntry方法执行完毕提交事务时，query方法才会被提交，就是说记录的锁定会持续到updateEntry执行结束。

代码(2)则对获取的记录进行修改，代码(3)把修改的内容写回数据库，同样代码(3)的update方法也没有开启新的事务，而是加入了updateEntry的事务。

也就是updateEntry、query、update方法共用同一个事务。

当多个线程同时调用updateEntry方法，并且传递的是同一个id时，只有一个线程执行代码(1)会成功，其他线程则会被阻塞，这是因为在同一时间只有一个线程可以获取对应记录的锁，在获取锁的线程释放锁前(updateEntry执行完毕，提交事务前),其他线程必须等待，也就是在同一时间只有一个线程可以对该记录进行修改。

乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新时，才会正式对数据冲突与否进行检测。

具体来说，根据update返回的行数让用户决定如何去做。将上面的例子改为使用乐观锁的代码如下。
在这里插入图片描述
当多个线程调用updateEntry方法并且传递相同的id时，多个线程可以同时执行代码(1)获取id对应的记录并把记录放入线程本地栈里面，然后可以同时执行代码(2)对自己栈上的记录进行修改，多个线程修改后各自的entry里面的属性应该都不一样了。

然后多个线程可以同时执行代码(3),代码(3)中的update语句的where条件里面加入了version=#{version}条件，并且set语句中多了version=${version}+1表达式，该表达式的意思是，如果数据库里面id=#{id} and version=#{version}的记录存在，则更新version的值为原来的值加1,这有点CAS操作的意思。

假设多个线程同时执行updateEntry并传递相同的id,那么它们执行代码(1)时获取的Entry是同一个，获取的Entry里面的version值都是相同的(这里假设version=0)。

当多个线程执行代码(3)时，由于update语句本身是原子性的，假如线程A执行update成功了，那么这时候id对应的记录的version值由原始version值变为了1。其他线程执行代码(3)更新时发现数据库里面已经没有了version=0的语句，所以会返回影响行号0。

在业务上根据返回值为0就可以知道当前更新没有成功，那么接下来有两个做法，如果业务发现更新失败了，下面可以什么都不做，也可以选择重试，如果选择重试，则updateEntry的代码可以修改为如下。

在这里插入图片描述
如上代码使用retryNum设置更新失败后的重试次数，如果代码(3.1)执行后返回0,则说明代码(1.1)获取的记录已经被修改了，则循环一次，重新通过代码(1.1)获取最新的数据，然后再次执行代码(3.1)尝试更新。

这类似CAS的自旋操作，只是这里没有使用死循环，而是指定了尝试次数。

乐观锁并不会使用数据库提供的锁机制，一般在表中添加version字段或者使用业务状态来实现。乐观锁直到提交时才锁定，所以不会产生任何死锁。

公平锁与非公平锁

根据线程获取锁的抢占机制，锁可以分为公平锁和非公平锁，公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的，也就是最早请求锁的线程将最早获取到锁。而非公平锁则在运行时闯入，也就是先来不一定先得。
ReentrantLock提供了公平和非公平锁的实现。

公平锁：ReentrantLock pairLock =new ReentrantLock(true)。
非公平锁：ReentrantLock pairLock =new ReentrantLock(false)。如果构造函数不传递参数，则默认是非公平锁。

例如，假设线程A已经持有了锁，这时候线程B请求该锁其将会被挂起。当线程A释放锁后，假如当前有线程C也需要获取该锁，如果采用非公平锁方式，则根据线程调度策略，线程B和线程C两者之一可能获取锁，这时候不需要任何其他干涉，而如果使用公平锁则需要把C挂起，让B获取当前锁。
在没有公平性需求的前提下尽量使用非公平锁，因为公平锁会带来性能开销。