Java锁机制

老早就想更新本专题了，奈何要学习的东西太多，所以锁机制一直在推。上期更新了Nginx的一些使用，写到后面写不下去了，因为涉及到多进程，而多进程/多线程就涉及到资源征用，资源征用就无可避免的要使用锁来规范行为。其实在更新Redis的时候就提到过分布式锁，分布式锁在我们这里就不赘述了，主要是本地锁。

那么，我们会在本文中详述各个锁的差别，使用方法，使用场景和代码演示，实际上我们开发并不是所有的锁都要用到，适合的才是最好的。

锁与死锁

锁就是我们在开发的时候，需要对资源进行控制，否则我们无法确定资源的征用顺序，资源的存量等。而锁的不恰当使用，就会造成死锁，所谓死锁，就是进程/线程对资源的争夺导致互不释放，且互不使用。一般来说，死锁的条件有：

• 互斥：被征用的资源不能同时间被两个进程/线程使用
• 请求和保持：就是进程贪心，不释放已拥有的资源，还在申请其他的资源
• 不可抢占：其实就是互斥（我一直以为，二者细节不必深究）
• 循环等待：你等我，我等你，大家都不放弃资源。

其实简单的说，就是资源少，调度不公，进程贪心。

现在有一个现实的例子：

疫情期间，我去药店买口罩。药店说，你带上口罩才能进来，我说我得进来才能买口罩。于是药店和我就是两个进程，那么资源是谁？是口罩么？在这个例子中，资源并不是口罩，资源是锁。对的，锁也是一种资源，这里的锁是能否进入药店的门。

那为什么口罩不是资源呢？因为我们并不是对口罩的归属权进行争夺，而是对药店的使用权进行争夺。没有口罩，我就没有进入药店的权力，相对应的，我没有申请释放锁的资格。而药店因为我没有口罩，也不会放弃锁。因此，对锁的争夺是造成死锁的原因。

锁分类

锁有许多种分类，这些分类代表了不同锁的不同性质，他们之间是交集关系，并不是相互独立的。我们由浅入深说。

读锁，写锁，共享锁，排它锁

读锁： 在读取资源前对资源上锁，在我读取资源的时候，不能修改资源。同时，在别人读取资源的时候也不能修改资源。此外，任何人不能在这之上加写锁。保证了我读资源的同时，资源不会被修改。也就是解决了不可重复读的问题。

写锁： 在写资源前对资源上锁，在我写资源的时候，任何人不能加其他锁。期间，我可以读资源也可以写资源，他人只能读，但是不能上锁再读，当然更不能改。

共享锁： 就是读锁。

排它锁： 就是写锁

乐观锁与悲观锁

这是最简单的两种锁，二者不是技术上的锁，而是业务逻辑的锁。

乐观锁： 认为一切对资源的访问都是不修改资源的，所以就不会上锁，但是我们一般说上乐观锁，是因为乐观锁在对资源修改的时候判断该资源有没有其他人修改。常用的方式是利用版本号进行校验，常说的CAS就是利用这个实现的。CAS的真实实现要用到地址的，这里我们简化一下，看看核心原理：

public class OptimisticLock {
	
	private static final long serialVersionUID = 6214790243416807050L;
	
	private int value;
	
	public boolean compareAndSwap(OptimisticLock optimisticLock, int expectedValue, int newValue) {
		if(optimisticLock.serialVersionUID == this.serialVersionUID && expectedValue == this.value) {
			this.value = newValue;
			return true;
		}else {
			return false;
		}
	}
}

悲观锁： 与乐观锁对应，悲观锁指认为一切访问都是要修改资源的，就会导致每次访问数据都要加写锁。

public class PessimisticLock implements Runnable {
	
	private static int value;

	@Override
	public synchronized void run() {		
		for(int i = 0; i < 5; i++) {
			System.out.println("thread id : " +  Thread.currentThread().getId() + " " + Thread.currentThread().getName() + ", value = " + value++);
		}
	}
}

public class LockMechanisms {
	public static void main(String[] args)throws Exception {
		PessimisticLock pessimisticLock = new PessimisticLock();
		Thread thread1 = new Thread(pessimisticLock, "abc");
		Thread thread2 = new Thread(pessimisticLock, "edf");
		thread1.start();
		thread2.start();
	}
}

假设我把关键字synchronized去掉，结果可能是：

注意这里，即使是去掉锁，理论上也不可能出现两个0啊，这是为什么？其实这就是出现了不可重复读的现象。两个线程同时访问了value，同时将value修改成1，最后的结果就是出现了两个0。

可重入锁

讲这个之前我们看一个现实中的例子：我虽然没钱穷B，但是不妨碍我会看电视。电视剧中的剧情往往有一个土豪开保险箱的镜头，这个保险箱一般都是密码锁加钥匙的组合，也就是说，密码锁必须对上，钥匙才能转动，否则钥匙即使插进去也无法转动。这个双重保险机制都是为了锁定保险箱。而打开保险箱的唯一方式就是先拿到密码锁的密码，再拿到机械锁的钥匙。而其他人只拿到钥匙，或者只有密码都无法打开保险箱。

可重入锁和这个很像，就是一个进程/线程可以多次对对象进行上锁，其他进程/线程必须等待所有的锁释放完毕后才能进行剩下的操作。而多次上锁的操作不能阻塞进程。

我们用传统的synchronized方法演示一下：

public class ReentrantLock implements Runnable {
	
	private static int test;
	@Override
	public void run() {
		synchronized (this) {
			System.out.println("Outer lock, the object is : " + this);
			synchronized (this) {
				while(test++ < 5) {
					System.out.println("Inner lock " + test + ", the object is : " + this);
				}
			}
			System.out.println("release the inner lock " + this);
		}
		System.out.println("release the outer lock " + this);
		test = 0;
	}
}

public class LockMechanisms {

	public static void main(String[] args)throws Exception {
		ReentrantLock reentrantLock = new ReentrantLock();
		Thread thread = new Thread(reentrantLock, "abc");
		Thread thread2 = new Thread(reentrantLock, "bcd");
		thread.start();
		thread2.start();
	}
}

上面是传统的synchronized方法进行加锁，可见，synchronized方法本身是可重入的。而在JDK1.5以后，我们又多了一种新的加锁方法：lock。它是利用AbstractQueuedSynchronizer接口，关于lock的一切动作都在这个接口中定义。这也是著名的AQS。

在说lock之前，我们需要简单提一下AQS的基本原理和设计方法。

编程的场景中，有一个很常见的问题，就是生产者–消费者模型。做过Xinu操作系统的开发的小伙伴都会知道，刚开始搞这东西还是挺头疼的，那就是遇见 1：n或者n：n 模式的时候，如何分配资源？

我们在做的时候，会分情况：

1. 当资源空闲，有线程请求资源，该线程获取资源，且资源上锁。
2. 当资源占用，有一个线程请求资源，该线程会等待资源释放，之后获取资源并上锁。
3. 当资源占用，有多个线程请求资源，线程进入队列，资源释放后会通知相应的线程进行消费。

如何将线程/进程加入队列，又如何唤醒线程/进程进行消费，就是AQS干的事。

AQS维护了一个队列，先进先出，也就是先申请资源的线程/进程先获取资源，这个队列被称为CLH，那如何判断资源被释放？这里AQS和我在做Xinu的时候用了两个不同的方法，但是原理都相同。AQS将资源认为成volatile的，啥是volatile后文再说。我用了信号量作为资源，当信号量可被消费时，传递给队列。但是最终都需要这个队列进行循环获取资源，直到资源获取成功。怎么不断获取？很简单：while(!getLock());

到此为止，剩下的有缘再谈。

回到Lock，java里有好多关于lock的包，几乎能覆盖所有的可重入锁的场景。我们还拿之前的代码演示一下：

public class ReentrantLock implements Runnable {
	
	private static int test;
	
	java.util.concurrent.locks.ReentrantLock reentrantLock;
	public ReentrantLock() {
		reentrantLock = new java.util.concurrent.locks.ReentrantLock();
	}
	@Override
	public void run() {
		
		reentrantLock.lock();
		System.out.println("Outer lock, the object is : " + this);
		reentrantLock.lock();
		while (test++ < 5) {
			System.out.println("Inner lock " + test + ", the object is : " + Thread.currentThread().getName());
		}
		reentrantLock.unlock();
		System.out.println("release the inner lock " + this);
		reentrantLock.unlock();
		System.out.println("release the outer lock " + this);
		test=0;
	}
}

lock需要手动释放。

自旋锁

这又是个啥？这啥也不是。

自旋锁实际上不能算作锁，而是一种锁的操作。我们在线程等待资源的时候，对锁进行进行不断的获取，这个行为就是自旋，因此自旋锁并不是一类锁，而是锁的一种操作方式。上述AQS获取资源的方式就是自旋方法。

公平锁与非公平锁

其实写到这里，我已经不想总结了，因为剩下的锁大多都是业务逻辑的扩展。像这个公平锁与非公平锁。

公平锁就是先到先得，谁先申请，下一个锁就是谁的；非公平锁就是谁申请就是谁的。

synchronized是非公平锁，因为当多个线程同时访问资源，他不管先后顺序，而是看运气，在申请时哪个线程申请到就归谁。lock可以实现公平，也可以做非公平锁，看参数，默认是非公平的。

非公平锁更快，公平锁还要进行线程申请顺序的判断。

可中断锁

这是我们这部分最后一个锁，可中断锁就是可以被中断的锁。什么时候被中断呢？就是比如当时间到了，或者某种条件达成了，该锁自动释放。synchronized是不可中断的，lock是可以中断的，其他的也没啥可说的了。

volatile与semaphore

其实这二者没有联系，是我强行把这俩绑定在一起的。为啥绑定？是因为再做Xinu的时候，我认为明明有一个变量可以用volatile去做，跑出来结果也正确，但是放在OJ上就是超时，必须需要信号量做。

先说volatile，这个关键字如果不是中级开发人员以上，应该接触的很少。volatile这个关键字特别用于多线程的情况下，需要强制写入内存的时候用。我们先总结一下这个关键字的作用：

1. 代码重排序。我们写一个多线程的例子，看看结果。

   public class VolatileUsage implements Runnable{
   
   	public static boolean shared_var = true;
   
   	@Override
   	public void run(){
   		while(shared_var) {}
   		System.out.println(shared_var + " " + Thread.currentThread().getName());
   	}
   }
   

   	public class LockMechanisms {
   
   	public static void main(String[] args)throws Exception {
   		VolatileUsage volatileUsage = new VolatileUsage();
   	
   		Thread thread = new Thread(volatileUsage, "abc");
   		Thread thread2 = new Thread(volatileUsage, "edf");
   	
   		thread.start();
   		thread2.start();
   		Thread.sleep(1000);
   		VolatileUsage.shared_var = false;
   	}
   }
   

   结果是线程卡死。如果我们在shared_var前面用volatile修饰，则不会发生这种情况。

   这是因为在两个线程访问变量的时候，变量都处于true的状态。编译器为了提升效率，会将代码重新排序，因此false可能对于上面代码来说就是不可见的。举个例子：

   int a = 0;
   a = 2;
   a = 1;
   

   这个代码很傻，但是编译器会直接将其优化为int a = 1。

2. 代码可见性。其实和上面的禁止重排序一起用的，volatile修饰的变量，对于所有进程都是可见的。

再说说信号量，这个在不同的操作系统有不同的实现，但是一般来说，信号量是对全局可见的。实际上信号量就是一个全局可见的特殊变量，他能控制其他线程对其的访问。具体说，信号量有以下几个情况：

1. 信号量大于0。其他线程可以获取信号量，并让信号量减一。线程结束信号量加一。
2. 信号量不大于0。其他线程阻塞。

相对应的，就是PV原子操作。P(semaphore)指申请信号量，同时对信号量减一，若信号量小于等于0，挂起进程，不对信号量做操作。V(semaphore)指释放信号量，同时对信号量加一，如果有挂起的进程，不对信号量做操作，直接将挂起的进程恢复。

信号量和volatile的相似之处就在于，二者都是对全线程可见的。不同之处是，volatile更倾向于线程，而信号量是操作系统帮助实现进程/线程同步的机制，是系统级别的。

下一个篇章更新《Unix环境高级编程》中的I/O模型。