Java并发编程——Lock

---

概述

本文借鉴了Java 并发编程这篇博主专栏的文章，他的专栏写的很好，推荐！

synchronized 是java的关键字，是Java的内置特性，在JVM层面实现了对临界资源的同步互斥访问，但 synchronized 粒度有些大，在处理实际问题时存在诸多局限性，比如响应中断等。Lock 提供了比 synchronized更广泛的锁操作，它能以更优雅的方式处理线程同步问题。本文以synchronized与Lock的对比为切入点，对Java中的Lock框架的枝干部分进行了详细介绍，最后给出了锁的一些相关概念。

一、synchronized 的局限性 与 Lock 的优点

如果一个代码块被synchronized关键字修饰，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待直至占有锁的线程释放锁。事实上，占有锁的线程释放锁一般会是以下三种情况之一：

• 占有锁的线程执行完了该代码块，然后释放对锁的占有；
• 占有锁线程执行发生异常，此时JVM会让线程自动释放锁；
• 占有锁线程进入 WAITING 状态从而释放锁，例如在该线程中调用wait()方法等；

解决方案:

• 对于第一种情况，需要有一种机制可以不让等待的线程一直无限等待下去，解决方案：比如只等待一定的时间 (解决方案：tryLock(long time, TimeUnit unit)) 或者 能够响应中断 (解决方案：lockInterruptibly())），这种情况可以通过 Lock 解决；
• 对于第二种情况，当多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作也会发生冲突现象，但是读操作和读操作不会发生冲突现象。但是如果采用synchronized关键字实现同步的话，就会导致一个问题，即当多个线程都只是进行读操作时，也只有一个线程在可以进行读操作，其他线程只能等待锁的释放而无法进行读操作。因此，需要一种机制来使得当多个线程都只是进行读操作时，线程之间不会发生冲突。同样地，Lock也可以解决这种情况 (解决方案：ReentrantReadWriteLock) ；
• 对于第三种情况，Lock得知线程有没有成功获取到锁 (解决方案：ReentrantLock)

Lock 是 java.util.concurrent.locks包 下的接口，Lock 实现提供了比 synchronized 关键字 更灵活、更广泛、粒度更细 的锁操作，它能以更优雅的方式处理线程同步问题。也就是说，Lock提供了比synchronized更多的功能。但是要注意以下几点：

1) synchronized是Java的关键字，因此是Java的内置特性，是基于JVM层面实现的，其经过编译之后，会在同步块的前后分别形成 monitorenter 和 monitorexit 两个字节码指令；而Lock是一个Java接口，是基于JDK层面实现的，通过这个接口可以实现同步访问；

2) 采用synchronized方式不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而 Lock则必须要用户去手动释放锁 (发生异常时，不会自动释放锁)，如果没有主动释放锁，就有可能导致死锁现象

二、java.util.concurrent.locks包下常用的类与接口

---

2.1 Lock

查看Lock的源码可知，Lock是一个接口：

public interface Lock{
	void lock();
    void lockInterruptibly() throws InterruptedException;  // 可以响应中断
    boolean tryLock();
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;  // 可以响应中断
    void unlock();
    Condition newCondition();
}

Lock中声明了四个方法来获取锁，lock()、tryLock()、tryLock(long time, TimeUnit unit) 和 lockInterruptibly()都是用来获取锁的，unLock()方法是用来释放锁的。newCondition() 返回 绑定到此 Lock 的新的 Condition 实例 ，用于线程间的协作。

2.1.1 lock()

lock()就是用来获取锁，如果锁已经被其它线程获取，则进行等待；采用Lock必须主动取释放锁，并且在发生异常时，不会自动释放锁。一般来说，使用Lock必须在try…catch…块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。

使用形式如下：

Lock lock = ... ;
lock.lock();
try{
	//处理事务
}catch(Exception ex){

}finally{
	lock.unlock();//释放锁
}

2.1.2 tryLock() & tryLock(long time, TimeUnit unit)

**tryLock()**方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true；如果获取失败（即锁已被其他线程获取），则返回false；

**tryLock(long time, TimeUnit unit)**方法和tryLock()方法类似，区别在于在拿不到锁时会等待一段时间，在时间内如果还拿不到锁，就返回false,同时立刻中断响应；

Lock lock = ... ;
if(lock.tryLock()){
	try{
		//处理任务
	}catch(Exception ex){

	}finally{
		lock.unlock();//释放锁
	}
}else{
   //如果不能获取锁，就做其他事情
}

2.1.3 lockInterruptibly()

当通过这个方法去获取锁时，如果线程 正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态，去做别的事情。

例如，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。

lockInterruptibly()一般的使用形式如下：

public void method() throws InterruptedException{
	lock.lockInterruptibly();
	try{
		//...
	}
	finally{
		lock.unlock();
	}
}

当一个线程获取了锁之后，是不会被interrupt()方法中断的;

注意：
在使用Lock时，无论以哪种方式获取锁，习惯上最好一律将获取锁的代码放到 try…catch…，因为我们一般将锁的unlock操作放到finally子句中，如果线程没有获取到锁，在执行finally子句时，就会执行unlock操作，从而抛出 IllegalMonitorStateException，因为该线程并未获得到锁却执行了解锁操作。

2.2 ReentrantLock(可重入锁)

ReentrantLock，即可重入锁。ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法。

Lock的正确使用方式

public class Test{
	private ArrayList<Integer> arrayList = new ArrayList<Integer>();

	public static void main(String[] args){
		final Test test = new Test();
	
		new Thread("A"){
			public void run(){
				test.insert(Thread.currentThread);
			};
		}.start();
		
		new Thread("B"){
			public void run(){
				test.insert(Thread.currentThread);
			};
		}.start();
	} 

	public void insert(Thread thread){
		Lock lock =  new ReentrantLock();
		lock.lock();
		try{
			System.out.println("线程"+thread.getName()+"得到了锁...");
			for (int i = 0; i < 5; i++) {
                arrayList.add(i);
		}
	}catch(Exception e){
		
	}finally{
		System.out.println("线程"+thread.getName()+"释放了锁...");
		lock.unlock();
	}
}/* Output: 
        线程A得到了锁...
        线程B得到了锁...
        线程A释放了锁...
        线程B释放了锁...
 *///:~

结果或许让人觉得诧异。第二个线程怎么会在第一个线程释放锁之前得到了锁？原因在于，在insert方法中的lock变量是局部变量，每个线程执行该方法时都会保存一个副本，那么每个线程执行到lock.lock()处获取的是不同的锁，所以就不会对临界资源形成同步互斥访问。因此，我们只需要将lock声明为成员变量即可

public class Test {
    private ArrayList<Integer> arrayList = new ArrayList<Integer>();
    private Lock lock = new ReentrantLock();  // 注意这个地方:lock被声明为成员变量
    ...
}/* Output: 
        线程A得到了锁...
        线程A释放了锁...
        线程B得到了锁...
        线程B释放了锁...
 *///:~

2.3 ReadWriteLock

ReadWriteLock也是一个接口，在它里面只定义了两个方法:

public interface ReadWriteLock {
    /**
     * Returns the lock used for reading.
     *
     * @return the lock used for reading.
     */
    Lock readLock();

    /**
     * Returns the lock used for writing.
     *
     * @return the lock used for writing.
     */
    Lock writeLock();
}

一个用来获取读锁，一个用来获取写锁，将对临界资源的读写操作分成两个锁来分配给线程，从而使得多个线程可以同时进行读操作。

2.4 ReentrantReadWriteLock

ReentrantReadWriteLock 实现了 ReadWriteLock 接口( 注意，ReentrantReadWriteLock 并没有实现 Lock 接口 )，其包含两个很重要的方法：readLock() 和 writeLock() 分别用来获取读锁和写锁，并且这两个锁实现了Lock接口.

如果采用synchronized关键字，线程A执行完读操作之后，才会打印线程B执行读操作的信息；

若改成读写锁之后：

public class Test {
    private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

    public static void main(String[] args) {
        final Test test = new Test();

        new Thread("A") {
            public void run() {
                test.get(Thread.currentThread());
            };
        }.start();

        new Thread("B") {
            public void run() {
                test.get(Thread.currentThread());
            };
        }.start();
    }

    public void get(Thread thread) {
        rwl.readLock().lock(); // 在外面获取锁
        try {
            long start = System.currentTimeMillis();
            System.out.println("线程" + thread.getName() + "开始读操作...");
            while (System.currentTimeMillis() - start <= 1) {
                System.out.println("线程" + thread.getName() + "正在进行读操作...");
            }
            System.out.println("线程" + thread.getName() + "读操作完毕...");
        } finally {
            rwl.readLock().unlock();
        }
    }
}/* Output: 
        线程A开始读操作...
        线程B开始读操作...
        线程A正在进行读操作...
        线程A正在进行读操作...
        线程B正在进行读操作...
        ...
        线程A读操作完毕...
        线程B读操作完毕...
 *///:~

可以看到，线程A和线程B在同时进行读操作，这样就大大提升了读操作的效率。不过要注意的是，如果有一个线程已经占用了读锁，则此时其他线程如果要申请写锁，则申请写锁的线程会一直等待释放读锁。如果有一个线程已经占用了写锁，则此时其他线程如果申请写锁或者读锁，则申请的线程也会一直等待释放写锁。

2.5 Lock和Synchronized的选择

Lock 和 Synchronized 有以下几点不同：

1. Lock是一个接口，是JDK层面的实现；而synchronized是Java中的关键字，是Java的内置特性，是JVM层面的实现；

2. synchronized 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过**unLock()**去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；

3. Lock 可以让等待锁的线程响应中断，而使用synchronized时，等待的线程会一直等待下去，不能够响应中断；

4. 通过Lock可以知道有没有成功获取锁，而synchronized却无法办到；

5. Lock可以提高多个线程进行读操作的效率；

当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。

三、锁的相关概念

---

3.1 可重入锁

synchronized 和 ReentrantLock 都是可重入锁,可重入性实际上表明了 锁的分配粒度：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。

class Test{
	public synchronized void method1(){
		method2();
	}
	
	public synchronized void method2(){

	}
}

假设在某个时刻，线程A执行method1并获取了这个对象的锁，而method2也是采用了synchronized关键字，如果synchronized不具备可重入性，此时线程A就需要重新申请锁，这就会造成死锁。因为线程A已经有了该对象的锁，而又在申请该对象的锁，就会让线程A一直等待永远不会获取到这个锁。

3.2 可中断锁

可中断锁就是可以响应中断的锁。在Java中，synchronized就不是可中断锁，而Lock是可中断锁；

3.3 公平锁

公平锁即 尽量 以请求锁的顺序来获取锁。比如，当多个线程在等待一个锁，当这个锁被释放的时候，等待时间最久的线程会获得该锁，非公平锁则无法保证锁的获取是按照请求锁的顺序进行的，这样就可能导致某个或者一些线程永远获取不到锁。

在Java中，synchronized就是非公平锁（抢占锁），它无法保证等待的线程获取锁的顺序。而对于ReentrantLock 和 ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为 公平锁（协同式线程调度）。

3.4 读写锁

读写锁将对临界资源的访问分成了两个锁，一个读锁和一个写锁。正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。可以通过readLock()获取读锁，通过writeLock()获取写锁。

3.5 悲观锁

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

3.6 乐观锁

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

乐观锁两种实现方式

---

3.6.1 版本号机制

一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会+1。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

3.6.2 CAS算法

compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。

CAS算法涉及到三个操作数：

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

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。

3.6.3 乐观锁的缺点

1、ABA问题
如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。

JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

2、循环时间长开销大：自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。

3、只能保证一个共享变量的原子操作

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作。

3.6.4 CAS与synchronized的使用情景

简单的来说CAS适用于写比较少的情况下（多读场景，冲突一般较少）；
synchronized适用于写比较多的情况下（多写场景，冲突一般较多）；

• 资源竞争比较少时，使用synchronized同步锁进行线程阻塞和唤醒切换，以及用户态内核态之间的切换操作额外的消耗CPU资源；CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。
• 对**于资源竞争严重（线程冲突严重）**的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized

Java并发编程这个领域中synchronized关键字一直都是元老级的角色，很久之前很多人都会称它为 “重量级锁” 。但是，在JavaSE 1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的 偏向锁 和 轻量级锁 以及其它各种优化之后变得在某些情况下并不是那么重了。

synchronized的底层实现主要依靠 Lock-Free 的队列，基本思路是 自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

3.7 乐观锁和悲观锁的使用场景

• 乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
• 多写的场景下用悲观锁就比较合适；

四、常见问题

---

4.1 synchronized和lock的差别

博客上面有；

4.2 Lock的内部实现

4.3 Java中的锁机制

4.4 如何减少锁粒度？