ReentrantLock：公平锁与非公平锁

在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
--------------------- 
作者：落叶初秋 
来源：CSDN 
原文：https://blog.csdn.net/zhang199416/article/details/70792587?utm_source=copy 
版权声明：本文为博主原创文章，转载请附上博文链接！