Lock显式锁

在Java 5.0之前，在协调对共享对象的访问时可以使用的机制只有synchronized和volatile。Java 5.0增加了一种新的机制：Lock。与之前提到过的机制相反，Lock并不是一种替代内置加锁的方法，而是当内置加锁机制不适用时，作为一种可选择的高级功能。

synchronized的缺陷

synchronized是java中的一个关键字，也就是Java语言内置的特性。那么为什么会出现Lock呢？

在上面一篇文章中，我们了解到：如果一个代码块被synchronized修饰了，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待，等待获取锁的线程释放锁，而这里获取锁的线程释放锁只会有两种情况：

1）获取锁的线程执行完了该代码块，然后线程释放对锁的占有；

2）线程执行发生异常，此时JVM会让线程自动释放锁。

那么如果这个获取锁的线程由于要等待I/O或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，试想一下，这多么影响程序执行效率。

因此就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），通过Lock就可以办到。

再举个例子：当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。

但是采用synchronized关键字来实现同步的话，就会导致一个问题：

如果多个线程都只是进行读操作，所以当一个线程在进行读操作时，其他线程便只能等待无法进行读操作。

因此就需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，通过Lock就可以办到。

另外，通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。

总结一下，也就是说Lock提供了比synchronized更多的功能。但是要注意以下几点：

1）Lock不是Java语言内置的，synchronized是Java语言的关键字，因此是内置特性。Lock是一个类，通过这个类可以实现同步访问；

2）Lock和synchronized有一点非常大的不同，采用synchronized不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象。

java.util.concurrent.locks包下常用的类

下面我们就来探讨一下java.util.concurrent.locks包中常用的类和接口。

Lock

首先要说明的就是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()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。unLock()方法是用来释放锁的。newCondition()这个方法暂且不在此讲述，会在后面的线程协作一文中讲述。

在Lock中声明了四个方法来获取锁，那么这四个方法有何区别呢？

• lock()

lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。

在前面讲到如果采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用Lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被释放，防止死锁的发生。通常使用Lock来进行同步的话，是以下面这种形式去使用的：

Lock lock = ...;
lock.lock();
try {
    //处理任务
} catch (Exception ex) {
     
} finally {
    lock.unlock();   //释放锁
}

• tryLock()

tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

• tryLock(long time, TimeUnit unit)

tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。

所以，一般情况下通过tryLock来获取锁时是这样使用的：

Lock lock = ...;
if (lock.tryLock()) {
     try {
         //处理任务
     } catch (Exception ex) {
         
     } finally {
         lock.unlock();   //释放锁
     }
} else {
    //如果不能获取锁，则直接做其他事情
}

• lockInterruptibly()

lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。

由于lockInterruptibly()的声明中抛出了异常，所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出InterruptedException。

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

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

注意：当一个线程获取了锁之后，是不会被interrupt()方法中断的。因为单独调用interrupt()方法不能中断正在运行过程中的线程，只能中断阻塞过程中的线程。

因此当通过lockInterruptibly()方法获取某个锁时，如果不能获取到锁，线程进入阻塞的状态，是可以响应中断的。

而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。

ReentrantLock

ReentrantLock，意思是“可重入锁”，关于可重入锁的概念在下一节讲述。ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法。下面通过一些实例具体看一下如何使用ReentrantLock。

1）lock()的使用方法：

public class LockTest {
    
    public static void main(String[] args) {
        new Thread() {
            public void run() {
                test(Thread.currentThread());
            }
        }.start();
        
        new Thread() {
            public void run() {
                test(Thread.currentThread());
            }
        }.start();
    }
    
    private static Lock lock = new ReentrantLock();
    
    public static void test(Thread t) {
        lock.lock();
        try {
            System.out.println(t.getName() + "获得了锁");
            long startTime = System.currentTimeMillis();
            while (System.currentTimeMillis() - startTime < 5000);
        } finally {
            System.out.println(t.getName() + "释放了锁");
            lock.unlock();
        }
    }
}

执行结果：

Thread-0获得了锁

Thread-0释放了锁

Thread-1获得了锁

Thread-1释放了锁

2）tryLock()的使用方法：

public static void test(Thread t) {
    if (lock.tryLock()) {
        try {
            System.out.println(t.getName() + "获得了锁");
            long startTime = System.currentTimeMillis();
            while (System.currentTimeMillis() - startTime < 5000);
        } finally {
            System.out.println(t.getName() + "释放了锁");
            lock.unlock();
        }
    } else {
        System.out.println(t.getName() + "获取锁失败...");
    }
}

执行结果：

Thread-0获得了锁

Thread-1获取锁失败...

Thread-0释放了锁

3）lockInterruptibly()响应中断的使用方法：

public class LockTest {
    
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread() {
            public void run() {
                try {
                    test(Thread.currentThread());
                } catch (InterruptedException ex) {
                    System.out.println(Thread.currentThread().getName() + "被中断....");
                }
            }
        };
        Thread t2 = new Thread() {
            public void run() {
                try {
                    test(Thread.currentThread());
                } catch (InterruptedException ex) {
                    System.out.println(Thread.currentThread().getName() + "被中断....");
                }
            }
        };
        
        t1.start();
        t2.start();
        
        Thread.sleep(2000);
        t2.interrupt();
    }
    
    private static Lock lock = new ReentrantLock();
    
    public static void test(Thread t) throws InterruptedException {
        lock.lockInterruptibly();
        try {
            System.out.println(t.getName() + "获得了锁");
            long startTime = System.currentTimeMillis();
            while (System.currentTimeMillis() - startTime < 5000);
        } finally {
            System.out.println(t.getName() + "释放了锁");
            lock.unlock();
        }
    }
}

执行结果：

Thread-0获得了锁

Thread-1被中断....

Thread-0释放了锁

ReadWriteLock

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

public interface ReadWriteLock {
    Lock readLock();
    Lock writeLock();
}

一个用来获取读锁，一个用来获取写锁。也就是说将文件的读写操作分开，分成2个锁来分配给线程，从而使得多个线程可以同时进行读操作。下面的ReentrantReadWriteLock实现了ReadWriteLock接口。

ReentrantReadWriteLock

ReentrantReadWriteLock里面提供了很多丰富的方法，不过最主要的有两个方法：readLock()和writeLock()用来获取读锁和写锁。

下面通过一个例子来看一下ReentrantReadWriteLock的具体用法：

public class ReadWriteLockTest {
    
    public static void main(String[] args) {
        new Thread() {
            public void run() {
                test(Thread.currentThread());
            }
        }.start();
        
        new Thread() {
            public void run() {
                test(Thread.currentThread());
            }
        }.start();
    }
    
    private static ReadWriteLock lock = new ReentrantReadWriteLock();
    
    public static void test(Thread t) {
        lock.readLock().lock();
        try {
            long startTime = System.currentTimeMillis();
            while (System.currentTimeMillis() - startTime < 1000) {
                System.out.println(t.getName() + "正在进行读操作");
            }
        } finally {
            System.out.println(t.getName() + "执行完读操作");
            lock.readLock().unlock();
        }
    }
}

执行结果：

Thread-0正在进行读操作

Thread-1正在进行读操作

Thread-1正在进行读操作

Thread-0正在进行读操作

Thread-1正在进行读操作

Thread-1执行完读操作

Thread-0执行完读操作

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

公平锁

公平锁即尽量以请求锁的顺序来获取锁。比如同时有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该锁，这种就是公平锁。

非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。

在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。

而对于ReentrantLock和ReentrantReadWriteLock，它在默认情况下是非公平锁，但是可以设置为公平锁。

我们可以在创建ReentrantLock对象时，通过以下方式来设置锁的公平性：

ReentrantLock lock = new ReentrantLock(true);

如果参数为true表示为公平锁，fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。

非公平锁的性能通常高于公平锁的性能。在实际情况中，统计上的公平性保证——确保被阻塞的线程能最终获得锁，通常已经够用了，并且实际开销也小得多。

ReetrankLock与synchronized比较

性能比较

在JDK1.5中，synchronized是性能低效的。因为这是一个重量级操作，它对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力。相比之下使用Java提供的Lock对象，性能更高一些。Brian Goetz对这两种锁在JDK1.5、单核处理器及双Xeon处理器环境下做了一组吞吐量对比的实验，发现多线程环境下，synchronized的吞吐量下降的非常严重，而ReentrankLock则能基本保持在同一个比较稳定的水平上。但与其说ReetrantLock性能好，倒不如说synchronized还有非常大的优化余地，于是到了JDK1.6，发生了变化，对synchronized加入了很多优化措施，有自适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在JDK1.6上synchronized的性能并不比Lock差。官方也表示，他们也更支持synchronized，在未来的版本中还有优化余地，所以还是提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步。

下面浅析以下两种锁机制的底层的实现策略。

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因而这种同步又称为阻塞同步，它属于一种悲观的并发策略，即线程获得的是独占锁。独占锁意味着其他线程只能依靠阻塞来等待线程释放锁。当挂起被阻塞的线程时，会引起CPU的上下文切换，当有很多线程竞争锁的时候，会引起CPU频繁的上下文切换导致效率很低。synchronized采用的便是这种并发策略。

随着指令集的发展，我们有了另一种选择：基于冲突检测的乐观并发策略，通俗地讲就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了，如果共享数据被争用，产生了冲突，那就再进行其他的补偿措施（最常见的补偿措施就是不断地重试，直到重试成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步被称为非阻塞同步。ReetrantLock采用的便是这种并发策略。

在乐观的并发策略中，需要操作和冲突检测这两个步骤具备原子性，它靠硬件指令来保证，这里用的是CAS操作（Compare and Swap）。JDK1.5之后，Java程序才可以使用CAS操作。我们可以进一步研究ReentrantLock的源代码，会发现其中比较重要的获得锁的一个方法是compareAndSetState，这里其实就是调用的CPU提供的特殊指令。现代的CPU提供了指令，可以自动更新共享数据，而且能够检测到其他线程的干扰，而compareAndSet() 就用这些代替了锁定。这个算法称作非阻塞算法，意思是一个线程的失败或者挂起不应该影响其他线程的失败或挂起。

Java 5中引入了注入AutomicInteger、AutomicLong、AutomicReference等特殊的原子性变量类，它们提供的如：compareAndSet（）、incrementAndSet（）和getAndIncrement（）等方法都使用了CAS操作。因此，它们都是由硬件指令来保证的原子方法。

用途比较

1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；

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

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

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

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

6）Lock可以实现公平锁：多个线程在等待同一个锁时，必须按照申请锁的时间顺序排队等待，而非公平锁则不保证这点，在锁释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平锁，ReentrantLock在默认情况下也是非公平锁，但可以通过构造方法ReentrantLock（ture）来要求使用公平锁。

7）Lock可以绑定多个条件：ReentrantLock对象可以同时绑定多个Condition对象（名曰：条件变量或条件队列），而在synchronized中，锁对象的wait（）和notify（）或notifyAll（）方法可以实现一个隐含条件，但如果要和多于一个的条件关联的时候，就不得不额外地添加一个锁，而ReentrantLock则无需这么做，只需要多次调用newCondition（）方法即可。而且我们还可以通过绑定Condition对象来判断当前线程通知的是哪些线程（即与Condition对象绑定在一起的其他线程）。