java中的锁

在并发场景中，会涉及到各种各样的锁，如公平锁，乐观锁，共享锁、分段锁等等，本篇文章主要对并发编程中的各种锁进行介绍，主要内容有：

1. 公平锁 / 非公平锁
2. 可重入锁 / 不可重入锁
3. 独享锁 / 共享锁
4. 互斥锁 / 读写锁
5. 乐观锁 / 悲观锁
6. 分段锁
7. 偏向锁 / 轻量级锁 / 重量级锁
8. 自旋锁
   
   下面对各种锁进行详细介绍：

1、公平锁 / 非公平锁

公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁。就是很公平，在并发环境中，每个线程在获取锁时会先查看此锁维护的等待队列，如果为空，或者当前线程是等待队列的第一个，就占有锁，否则就会加入到等待队列中，以后会按照First In First Out的规则从队列中取到自己。

公平锁的优点是等待锁的线程不会饿死。缺点是整体吞吐效率相对非公平锁要低，等待队列中除第一个线程以外的所有线程都会阻塞，CPU唤醒阻塞线程的开销比非公平锁大。

非公平锁

非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能会造成优先级反转或者饥饿现象。

非公平锁的优点是可以减少唤起线程的开销，整体的吞吐效率高，因为线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程。缺点是处于等待队列中的线程可能会饿死，或者等很久才会获得锁。

典型应用
java jdk并发包中的ReentrantLock可以指定构造函数的boolean类型来创建公平锁和非公平锁(默认)，比如：公平锁可以使用new ReentrantLock(true)实现。 对于Synchronized而言，是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。

关于什么是AQS，以及ReentrantLock的原理，请参考下面这篇文章：
https://www.cnblogs.com/joimages/p/12052657.html

2、可重入锁 / 不可重入锁

可重入锁

广义上的可重入锁指的是可重复、可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁（前提得是同一个对象或者class），这样的锁就叫做可重入锁。ReentrantLock和synchronized都是可重入锁。

synchronized void setA() throws Exception{
	Thread.sleep(1000);
	setB();
}
synchronized void setB() throws Exception{
	Thread.sleep(1000);
}

上面的代码体现了可重入锁的特点，如果不是可重入锁的话，setB可能不会被当前线程执行，可能造成死锁。

不可重入锁

不可重入锁，与可重入锁相反，不可递归调用，递归调用就发生死锁。我们使用自旋锁来模拟一个不可重入锁，代码如下：

import java.util.concurrent.atomic.AtomicReference;

public class UnreentrantLock {
	 private AtomicReference<Thread> owner = new AtomicReference<Thread>();
	 public void lock() {
		 Thread current = Thread.currentThread();
		 //这句是很经典的“自旋”语法，AtomicInteger中也有
		 for (;;) {
			 if (!owner.compareAndSet(null, current)) {
			 	return;
			 }
		 }
	 }
	 
 	public void unlock() {
 		Thread current = Thread.currentThread();
 		owner.compareAndSet(current, null);
 	}
}

代码也比较简单，使用原子引用来存放线程，同一线程两次调用lock()方法，如果不执行unlock()释放锁的话，第二次调用自旋的时候就会产生死锁，这个锁就不是可重入的，而实际上同一个线程不必每次都去释放锁再来获取锁，这样的调度切换是很耗资源的。

把它变成一个可重入锁 ：

import java.util.concurrent.atomic.AtomicReference;

public class UnreentrantLock {
	 private AtomicReference<Thread> owner = new AtomicReference<Thread>();
	 private int state = 0;
	 public void lock() {
		 Thread current = Thread.currentThread();
		 if (current == owner.get()) {
			 state++;
			 return;
		 }
 		//这句是很经典的“自旋”式语法，AtomicInteger中也有
		 for (;;) {
			 if (!owner.compareAndSet(null, current)) {
				 return;
			 }
		 }
	 }
 }
 
	 public void unlock() {
		 Thread current = Thread.currentThread();
		 if (current == owner.get()) {
			 if (state != 0) {
			 	state--;
			 } else {
			 	owner.compareAndSet(current, null);
		 	}
	 	}
	 }
}

在执行每次操作之前，判断当前锁持有者是否是当前对象，采用state计数，不用每次去释放锁。

ReentrantLock中可重入锁实现：

final boolean nonfairTryAcquire(int acquires) {
	final Thread current = Thread.currentThread();
	int c = getState();
	if (c == 0) {
		if (compareAndSetState(0, acquires)) {
			setExclusiveOwnerThread(current);
			return true;
		}
	}
	//就是这里
	else if (current == getExclusiveOwnerThread()) {
		int nextc = c + acquires;
		if (nextc < 0) // overflow
			throw new Error("Maximum lock count exceeded");
		setState(nextc);
		return true;
	}
	return false;
}

这里看非公平锁的锁获取方法，在AQS中维护了一个private volatile int state来计数重入次数，避免了频繁的持有释放操作，这样既提升了效率，又避免了死锁。

3、独享锁/共享锁

对于C.U.T包下的ReeReentrantLock和ReentrantReadWriteLock，一个是独享锁，一个是共享锁。

独享锁 ：该锁每一次只能被一个线程所持有

共享锁 ：该锁可被多个线程共有

典型的就是ReentrantReadWriteLock里的读锁，它的读锁是可以被共享的，但是它的写锁确每次只能被独占。读锁的共享可保证并发读是非常高效的，但是读写和写写，写读都是互斥的。

独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。 对于Synchronized而言，当然是独享锁。

4、互斥锁 / 读写锁

互斥锁

在访问共享资源之前对进行加锁操作，在访问完成之后进行解锁操作。 加锁后，任何其他试图再次加锁的线程会被阻塞，直到当前进程解锁。如果解锁时有一个以上的线程阻塞，那么所有该锁上的线程都被变为就绪状态， 第一个变为就绪状态的线程又执行加锁操作，那么其他的线程又会进入等待。 在这种方式下，只有一个线程能够访问被互斥锁保护的资源。

读写锁

读写锁既是互斥锁，又是共享锁，read模式是共享，write是互斥(排它锁)的。

读写锁有三种状态 ：读加锁状态、写加锁状态和不加锁状态

读写锁在Java中的具体实现就是 ReadWriteLock：

一次只有一个线程可以占有写模式的读写锁，但是多个线程可以同时占有读模式的读写锁。 只有一个线程可以占有写状态的锁，但可以有多个线程同时占有读状态锁，这也是它可以实现高并发的原因。当其处于写状态锁下，任何想要尝试获得锁的线程都会被阻塞，直到写状态锁被释放；如果是处于读状态锁下，允许其它线程获得它的读状态锁，但是不允许获得它的写状态锁，直到所有线程的读状态锁被释放；为了避免想要尝试写操作的线程一直得不到写状态锁，当读写锁感知到有线程想要获得写状态锁时，便会阻塞其后所有想要获得读状态锁的线程。所以读写锁非常适合资源的读操作远多于写操作的情况。

5、乐观锁 / 悲观锁

乐观锁与悲观锁是一种广义上的概念，体现在看待线程同步的不同角度，在Java和数据库中都有此概念对应的实际应用。

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（ 共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程 ）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量 ，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的 。

CAS全称 Compare And Swap(比较与交换)，是一种无锁算法。在不使用锁(没有线程被阻塞)的情况下实现多线程之间的变量同步。

简单来说，CAS算法有3个三个操作数：

• 需要读写的内存值 V。
• 进行比较的值 A。
• 要写入的新值 B。

当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则返回V。这是一种乐观锁的思路，它相信在它修改之前，没有其它线程去修改它，而Synchronized是一种悲观锁，它认为在它修改之前，一定会有其它线程去修改它，悲观锁效率很低。

• 悲观锁适合写操作多的场景，先加锁可以保证写操作时数据正确。
• 乐观锁适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升。

6、分段锁

分段锁其实是一种锁的设计，并不是具体的一种锁。

对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作：

ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap(JDK7与JDK8中HashMap的实现)的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表;同时又是一个ReentrantLock(Segment继承了ReentrantLock)。当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。

其实说的简单一点就是 ：容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

比如在ConcurrentHashMap中使用了一个包含16个锁的数组，每个锁保护所有散列桶的1/16，其中第N个散列桶由第（N mod 16）个锁来保护。假设使用合理的散列算法使关键字能够均匀的分布，那么这大约能使对锁的请求减少到越来的1/16。也正是这项技术使得ConcurrentHashMap支持多达16个并发的写入线程。

7、偏向锁 / 轻量级锁 / 重量级锁

锁的状态 ：

• 无锁状态
• 偏向锁状态
• 轻量级锁状态
• 重量级锁状态

锁的状态是通过对象监视器在对象头中的字段来表明的。 四种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级。 这四种状态都不是Java语言中的锁 ，而是Jvm为了提高锁的获取与释放效率而做的优化( 使用synchronized时 )。

偏向锁

偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。

轻量级

轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。

重量级锁

重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。

8、自旋锁

是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环 。

它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。 无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁 。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，”自旋”一词就是因此而得名。

Java如何实现自旋锁？下面是个简单的例子：

public class SpinLock {
	 private AtomicReference<Thread> cas = new AtomicReference<Thread>();
	 public void lock() {
		 Thread current = Thread.currentThread();
		 // 利用CAS
		 while (!cas.compareAndSet(null, current)) {
			 // DO nothing
		 }
	}
	public void unlock() {
		Thread current = Thread.currentThread();
		cas.compareAndSet(current, null);
		}
	}
}

lock（)方法利用的CAS，当第一个线程A获取锁的时候，能够成功获取到，不会进入while循环，如果此时线程A没有释放锁，另一个线程B又来获取锁，此时由于不满足CAS，所以就会进入while循环，不断判断是否满足CAS，直到A线程调用unlock方法释放了该锁。

自旋锁存在的问题：

1、如果某个线程持有锁的时间过长，就会导致其它等待获取锁的线程进入循环等待，消耗CPU。使用不当会造成CPU使用率极高；

2、上面Java实现的自旋锁不是公平的，即无法满足等待时间最长的线程优先获取锁。不公平的锁就会存在“线程饥饿”问题。

自旋锁的优点：

1、自旋锁不会使线程状态发生切换，一直处于用户态，即线程一直都是active的；不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快；

2、非自旋锁在获取不到锁的时候会进入阻塞状态，从而进入内核态，当获取到锁的时候需要从内核态恢复，需要线程上下文切换。 （线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能）。

可重入的自旋锁和不可重入的自旋锁：

开始的那段代码，仔细分析一下就可以看出，它是不支持重入的，即当一个线程第一次已经获取到了该锁，在锁释放之前又一次重新获取该锁，第二次就不能成功获取到。由于不满足CAS，所以第二次获取会进入while循环等待，而如果是可重入锁，第二次也是应该能够成功获取到的。而且，即使第二次能够成功获取，那么当第一次释放锁的时候，第二次获取到的锁也会被释放，而这是不合理的。

为了实现可重入锁，我们需要引入一个计数器，用来记录获取锁的线程数。

public class ReentrantSpinLock {
	private AtomicReference<Thread> cas = new AtomicReference<Thread>();
	private int count;
	public void lock() {
		Thread current = Thread.currentThread();
		if (current == cas.get()) { // 如果当前线程已经获取到了锁，线程数增加一，然后返回
			count++;
			return;
		}
		// 如果没获取到锁，则通过CAS自旋
		while (!cas.compareAndSet(null, current)) {
			// DO nothing
		}
	}
	
	public void unlock() {
		Thread cur = Thread.currentThread();
		if (cur == cas.get()) {
			if (count > 0) {// 如果大于0，表示当前线程多次获取了该锁，释放锁通过count减一来模拟
				count--;
			} else {// 如果count==0，可以将锁释放，这样就能保证获取锁的次数与释放锁的次数是一致的了。
				cas.compareAndSet(cur, null);
			}
		}
	}
}

自旋锁与互斥锁：

• 自旋锁与互斥锁都是为了实现保护资源共享的机制。
• 无论是自旋锁还是互斥锁，在任意时刻，都最多只能有一个保持者。
• 获取互斥锁的线程，如果锁已经被占用，则该线程将进入睡眠状态；获取自旋锁的线程则不会睡眠，而是一直循环等待锁释放。

自旋锁总结：

• 自旋锁：线程获取锁的时候，如果锁被其他线程持有，则当前线程将循环等待，直到获取到锁。
• 自旋锁等待期间，线程的状态不会改变，线程一直是用户态并且是活动的(active)。
• 自旋锁如果持有锁的时间太长，则会导致其它等待获取锁的线程耗尽CPU。
• 自旋锁本身无法保证公平性，同时也无法保证可重入性。
• 基于自旋锁，可以实现具备公平性和可重入性质的锁。