ReentrantLock（三）：公平锁与非公平锁

本篇主要承接上篇文章，简单介绍ReentrantLock的部分API应用和公平锁与非公平锁的区别。

在ReentrantLock中很明显可以看到其中同步包括两种，分别是公平的FairSync和非公平的NonfairSync。
可以看看ReentrantLock的源码构造方法

    public ReentrantLock()    {        sync = new NonfairSync();    }    public ReentrantLock(boolean flag)    {        sync = ((Sync) (flag ? ((Sync) (new FairSync())) : ((Sync) (new NonfairSync()))));    }

默认情况下ReentrantLock是通过非公平锁来进行同步的，包括synchronized关键字都是如此，因为这样性能会更好。
在公平的锁上，线程获取锁的顺序是按照线程加锁的顺序来分配的，即先来先得的FIFO先进先出顺序，而非公平锁就是一种获取锁的抢占机制，是随机获得锁的，它允许插队：当一个线程请求非公平锁时，如果在发出请求的同时该锁变成可用状态，那么这个线程会跳过队列中所有的等待线程而获得锁。 非公平的ReentrantLock 并不提倡 插队行为，但是无法防止某个线程在合适的时候进行插队。
在公平的锁中，如果有另一个线程持有锁或者有其他线程在等待队列中等待这个所，那么新发出的请求的线程将被放入到队列中。而非公平锁上，只有当锁被某个线程持有时，新发出请求的线程才会被放入队列中。
非公平锁性能高于公平锁性能的原因：
从线程进入了RUNNABLE状态，可以执行开始，到实际线程执行是要比较久的时间的。而且，在一个锁释放之后，其他的线程会需要重新来获取锁。其中经历了持有锁的线程释放锁，其他线程从挂起恢复到RUNNABLE状态，其他线程请求锁，获得锁，线程执行，这一系列步骤。如果这个时候，存在一个线程直接请求锁，可能就避开挂起到恢复RUNNABLE状态的这段消耗，所以性能更优化。
假设线程A持有一个锁，并且线程B请求这个锁。由于锁被A持有，因此B将被挂起。当A释放锁时，B将被唤醒，因此B会再次尝试获取这个锁。与此同时，如果线程C也请求这个锁，那么C很可能会在B被完全唤醒之前获得、使用以及释放这个锁。这样就是一种双赢的局面：B获得锁的时刻并没有推迟，C更早的获得了锁，并且吞吐量也提高了。
当持有锁的时间相对较长或者请求锁的平均时间间隔较长，应该使用公平锁。在这些情况下，插队带来的吞吐量提升（当锁处于可用状态时，线程却还处于被唤醒的过程中）可能不会出现。
如以下例子：

public class Service {    private ReentrantLock lock;    public Service(boolean isFair) {        super();        lock = new ReentrantLock(isFair);    }    public void serviceMethod() {        try {            lock.lock();            System.out.println("ThreadName=" + Thread.currentThread().getName()                    + "获得锁定");            if (lock.isFair())            {                System.out.println("ThreadName="                        + Thread.currentThread().getName() + "是公平锁");            }            else            {                System.out.println("ThreadName="                        + Thread.currentThread().getName() + "是非公平锁");            }        } finally {            lock.unlock();        }    }}public class RunFair {    public static void main(String[] args) throws InterruptedException {        final Service service = new Service(true);        Runnable runnable = new Runnable() {            @Override            public void run() {                System.out.println("★线程" + Thread.currentThread().getName()                        + "运行了");                service.serviceMethod();            }        };        Thread[] threadArray = new Thread[10];        for (int i = 0; i < 10; i++) {            threadArray[i] = new Thread(runnable);        }        for (int i = 0; i < 10; i++) {            threadArray[i].start();        }    }}

从执行结果可以看出公平锁执行是有序的。

public class RunNotFair {    public static void main(String[] args) throws InterruptedException {        final Service service = new Service(false);        Runnable runnable = new Runnable() {            @Override            public void run() {                System.out.println("☆线程" + Thread.currentThread().getName()                        + "运行了");                service.serviceMethod();            }        };        Thread[] threadArray = new Thread[5];        for (int i = 0; i < 5; i++) {            threadArray[i] = new Thread(runnable);        }        for (int i = 0; i < 5; i++) {            threadArray[i].start();        }    }}

从执行结果看出非公平锁是乱序的，说明先start()启动的线程不代表先获得锁

方法摘要

isFair

public final boolean isFair()如果此锁的公平设置为 true，则返回 true。返回：如果此锁的公平设置为 true，则返回 true

实现可轮询的锁请求
在内部锁中，死锁是致命的——唯一的恢复方法是重新启动程序，唯一的预防方法是在构建程序时不要出错。而可轮询的锁获取模式具有更完善的错误恢复机制，可以规避死锁的发生。
如果你不能获得所有需要的锁，那么使用可轮询的获取方式使你能够重新拿到控制权，它会释放你已经获得的这些锁，然后再重新尝试。可轮询的锁获取模式，由tryLock()方法实现。此方法仅在调用时锁为空闲状态才获取该锁。如果锁可用，则获取锁，并立即返回值true。如果锁不可用，则此方法将立即返回值false。

注意的是，未定时的 tryLock 方法并没有使用公平设置。因为即使其他线程正在等待，只要该锁是可用的，此方法就可以获得成功。

tryLock

public boolean tryLock()仅在调用时锁未被另一个线程保持的情况下，才获取该锁。如果该锁没有被另一个线程保持，并且立即返回 true 值，则将锁的保持计数设置为 1。即使已将此锁设置为使用公平排序策略，但是调用 tryLock() 仍将 立即获取锁（如果有可用的），而不管其他线程当前是否正在等待该锁。在某些情况下，此“闯入”行为可能很有用，即使它会打破公平性也如此。如果希望遵守此锁的公平设置，则使用 tryLock(0, TimeUnit.SECONDS) ，它几乎是等效的（也检测中断）。如果当前线程已经保持此锁，则将保持计数加 1，该方法将返回 true。如果锁被另一个线程保持，则此方法将立即返回 false 值。返回：如果锁是自由的并且被当前线程获取，或者当前线程已经保持该锁，则返回 true；否则返回 false

从以下例子可以简单了解一下tryLock的用法：

public ReentrantLock lock = new ReentrantLock();    public void waitMethod() {        if (lock.tryLock()) {            System.out.println(Thread.currentThread().getName() + "获得锁");        } else {            System.out.println(Thread.currentThread().getName() + "没有获得锁");        }    }public static void main(String[] args) throws InterruptedException {        final MyService service = new MyService();        Runnable runnableRef = new Runnable() {            @Override            public void run() {                service.waitMethod();            }        };        Thread threadA = new Thread(runnableRef);        threadA.setName("A");        threadA.start();        Thread threadB = new Thread(runnableRef);        threadB.setName("B");        threadB.start();    }

执行结果：

B没有获得锁A获得锁

tryLock（定时）

public boolean tryLock(long timeout,                       TimeUnit unit)                throws InterruptedException如果锁在给定等待时间内没有被另一个线程保持，且当前线程未被中断，则获取该锁。如果该锁没有被另一个线程保持，并且立即返回 true 值，则将锁的保持计数设置为 1。如果为了使用公平的排序策略，已经设置此锁，并且其他线程都在等待该锁，则不会 获取一个可用的锁。这与 tryLock() 方法相反。如果想使用一个允许闯入公平锁的定时 tryLock，那么可以将定时形式和不定时形式组合在一起：if (lock.tryLock() || lock.tryLock(timeout, unit) ) { ... }如果当前线程已经保持此锁，则将保持计数加 1，该方法将返回 true。如果锁被另一个线程保持，则出于线程调度目的，禁用当前线程，并且在发生以下三种情况之一以前，该线程将一直处于休眠状态：  ● 锁由当前线程获得；或者  ● 其他某个线程中断 当前线程；或者  ● 已超过指定的等待时间如果获得该锁，则返回 true 值，并将锁保持计数设置为 1。如果当前线程：  ● 在进入此方法时已经设置了该线程的中断状态；或者  ● 在等待获取锁的同时被中断。则抛出 InterruptedException，并且清除当前线程的已中断状态。如果超出了指定的等待时间，则返回值为 false。如果该时间小于等于 0，则此方法根本不会等待。在此实现中，因为此方法是一个显式中断点，所以要优先考虑响应中断，而不是响应锁的普通获取或重入获取，或者报告所用的等待时间。参数：timeout - 等待锁的时间unit - timeout 参数的时间单位返回：如果锁是自由的并且由当前线程获取，或者当前线程已经保持该锁，则返回 true；如果在获取该锁之前已经到达等待时间，则返回 false抛出：InterruptedException - 如果当前线程被中断NullPointerException - 如果时间单位为 null

参考：http://blog.csdn.net/zmx729618/article/details/51354201