聊聊Java中的那些锁
说到Java中锁的分类，有很多种。本文就来聊聊公平锁、非公平锁、可重入锁、独占锁、共享锁和自旋锁。
一、公平锁和非公平锁
1、什么是公平锁？什么是非公平锁？
-
公平锁：是指多个线程按照申请锁的顺序来获取锁，也就是说按秩序排队，先来后到。
-
非公平锁：是指多个线程获取锁的顺序并不是按照申请锁的顺序来的。就像排队打饭，总有些高年级同学会插队。在高并发情况下，有可能会造成优先级反转或者饥饿现象(优先级反转好理解，就是本来轮到排在队头那个人打饭了，但是突然一人插队跑前面了，这就是优先级反转；如果一直有人插队，那么仅管这个同学已经排在队头了，但是还是一直没吃上饭，这就是饥饿现象)。
2、两者区别：
在并发环境中，每个线程获取锁时都会查看此锁维护的等待队列，如果为空，或者当前线程是等待队列的第一个，就占锁，否则就加入到等待队列中。而非公平锁比较粗鲁，上来就尝试占锁，如果占锁失败，就采用类似公平锁的那种方式。非公平锁性能比较好，吞吐量比较大。ReentrantLock实例化的时候可以传入参数true或者false指定创建公平锁还是非公平锁，true是公平锁，false是非公平锁，不传默认是false。而synchronized也是非公平锁。
二、可重入锁
1、什么是可重入锁？
可重入锁又叫递归锁。指的是外层函数获得锁之后，它可以进入它所同步着的所有代码，即使内层函数也被锁住，，也无需重新获取锁。
public synchronized void method1(){
method2();
}
public synchronized void method2(){
}
method1是加了锁的，method2也是加了锁的，然后在method1里面调用method2。当method1获取了锁之后，调用的method2虽然也是加了锁的，但是不用重新获取锁了，这就叫可重入锁。也就说，可以理解为method1和method2获取到的锁可以理解为同一把锁。ReentrantLock和synchronized都是可重入锁。可重入锁最大的作用就是防止死锁。
2、可重入锁demo：
- 验证synchronized是可重入锁：
public class LockDemo {
public synchronized void fun1(){
System.out.println(Thread.currentThread().getId() + "执行fun1方法");
fun2();
}
public synchronized void fun2(){
System.out.println(Thread.currentThread().getId() + "执行fun2方法");
}
public static void main(String[] args){
LockDemo lockDemo = new LockDemo();
new Thread( () -> lockDemo.fun1()).start();
}
}
看这段代码，fun1一个同步方法，在里面输出一句话，然后又调用了同步方法fun2。最后在main方法里面创建一个线程去执行fun1方法。如果synchronized是可重入锁，那么打印这两个输出语句的应该是同一个线程。
运行结果
- 验证ReentrantLock是可重入锁：
public class LockDemo {
public void fun1(){
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
System.out.println(Thread.currentThread().getName() + ": 执行fun1方法");
fun2();
}finally {
lock.unlock();
}
}
public void fun2(){
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
System.out.println(Thread.currentThread().getName() + ": 执行fun2方法");
}finally {
lock.unlock();
}
}
public static void main(String[] args){
LockDemo lockDemo = new LockDemo();
new Thread( () -> lockDemo.fun1()).start();
}
}
这段代码只不过把synchronized换成了lock锁，运行结果是一样的。以上两端代码说明synchronized和ReentrantLock都是可重入锁。
三、自旋锁
前面聊CAS的时候说到了它底层用的就是UnSafe类和自旋锁。这里就详细说一说自旋锁。
1、什么是自旋锁？
我们知道像synchronized和ReentrantLock锁，当这个线程没有获取到锁的时候就是阻塞状态。而自旋锁就是采用循环的方式去尝试获取锁，这样的好处就是减少上下文切换的消耗，但是比较消耗CPU资源。再来看看原子包装类的getAddIncrement方法：
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
当while条件不成立时，就会一直执行do语句，所以很消耗CPU。
举个生活中的例子再来说明一下什么是自旋锁：小明同学遇到了个问题，跑到讲台边上去问老师。可是这时候老师在打电话，没办法立即给小明解答。小明就站在边上干等着。这是小明就处于阻塞状态，做不了其他事。而自旋锁就是，小明看到老师现在没时间，就先回到座位上写作业，过一会儿再上去看，老师还没时间，小明又回去做其他事。就这样不断的尝试，知道成功。
2、手写自旋锁：
public class MyLock {
AtomicReference<Thread> atomicReference = new AtomicReference<>();
public void myLock() {
Thread thread = Thread.currentThread();
System.out.println(thread.getName() + ": come in");
while (!atomicReference.compareAndSet(null, thread)) {
}
}
public void myUnlock() {
Thread thread = Thread.currentThread();
atomicReference.compareAndSet(thread, null);
System.out.println(thread.getName() + ": come out");
}
}
分析一下这段代码：这个类有一个成员变量，原子引用类型的Thread，关于原子引用，之前在CAS详解一文中说到过。这个类还有两个方法，一个是myLock加锁方法，一个是myUnlock，释放锁的方法。
- myLock方法：首先获取到当前线程，然后比较并交换，看看当前线程是不是null，如果是，就设置为当前线程thread，此时操作结果就是true，取反后就是false，就不进入循环。如果当前线程不是null，那么操作结果取反后就是true，那么就会进入循环，知道thread重新变回null为止。
- myUnlock方法：获取到当前线程，然后将其设置为null，这就相当于释放锁。
用下面的代码测试一下：
public static void main(String[] args) {
MyLock myLock = new MyLock();
new Thread(() -> {
myLock.myLock();
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
myLock.myUnlock();
},"A").start();
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
new Thread(() -> {
myLock.myLock();
myLock.myUnlock();
},"B").start();
}
A线程进去，发现当前是thread是null，所以就将当前线程指向自己。此时的当前线程就是A，然后小睡5秒。在睡的过程中，B进来了，发现当前线程是A，所以进入while循环，一直进行compareAndSet。5秒中后，A线程释放锁，将当前线程设置为了null，这时B发现当前线程是null了，就将当前线程设置为了B，最后B也释放锁，将当前线程设置为null。如果把线程A的myUnlock方法注释掉，那么线程B将一直在while循环中出不来，造成死循环。
四、独占锁和共享锁
1、什么是独占锁？什么是共享锁？
- 独占锁：不管是读操作还是写操作，该锁一次只能被一个线程持有。synchronized和ReentrantLock都是独占锁。
- 共享锁：指该锁可以被多个线程持有。
- ReentrantReadWriteLock的读锁是共享锁，写锁是独占锁。这样可以保证读操作的并发性。读&读可以共享锁，读&写不能共存，写&写也不能共存。
下面看一段代码：
public class MyCache {
private volatile Map<String, Object> map = new HashMap<>();
public void put(String key, Object value){
System.out.println(Thread.currentThread().getName() + ": 正在写入： "+ value );
map.put(key, value);
System.out.println(Thread.currentThread().getName() + "：写入完成");
}
public void get(String key){
System.out.println(Thread.currentThread().getName() + ": 正在读取");
Object result = map.get(key);
System.out.println(Thread.currentThread().getName() + ": 读取完成： " + result);
}
}
这段代码就是模拟一个缓存，用HashMap存数据。现在创建5个线程去写，5个线程去读，看看情况如何。
public static void main(String[] args){
MyCache myCache = new MyCache();
for (int i=0; i<5; i++){
final Integer temp = i;
new Thread(() -> myCache.put(temp+"", temp),temp +"号线程").start();
}
for (int i=0; i<5; i++){
final Integer temp = i;
new Thread(() -> myCache.get(temp+""),temp +"号线程").start();
}
}
看运行结果：
运行结果
可以看到，0号线程还没写入完成，2号线程进来了，2号线程还没完成，3号线程又进来了。这就没有保证写操作是独占的，没有保证写操作的原子性。看看使用ReentrantReadWriteLock如何解决：
public class MyCache {
private volatile Map<String, Object> map = new HashMap<>();
ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
public void put(String key, Object value){
lock.writeLock().lock();
System.out.println(Thread.currentThread().getName() + ": 正在写入： "+ value );
map.put(key, value);
System.out.println(Thread.currentThread().getName() + "：写入完成");
lock.writeLock().unlock();
}
public void get(String key){
lock.readLock().lock();
System.out.println(Thread.currentThread().getName() + ": 正在读取");
Object result = map.get(key);
System.out.println(Thread.currentThread().getName() + ": 读取完成： " + result);
lock.readLock().unlock();
}
}
只需要在写操作那里加写锁，在读操作那里加读锁，这样既可以保证数据的正确性，也提高了并发能力。看运行结果：
运行结果
可以看到，写操作的时候，保证了每次写操作的原子性，是独占锁；读的时候可以多个线程同时访问，是共享锁。
总结：
说起锁，好像有很多很多种，其实无外乎synchronized、ReentrantLock、ReentrantReadWriteLock和 自旋锁。其他的都是从不同角度对这几种锁进行分类而已。
- synchronized: 是非公平锁、可重入锁、独占锁；
- ReentrantLock：默认非公平锁，在构造方法中可传入true变成公平锁；是可重入锁，也是独占锁；
- ReentrantReadWriteLock：读锁是共享锁，写锁是独占锁；
- 自旋锁：通过CAS实现的一种锁。
