Java 锁的学习

个人学习整理，所有资料均来源于网络，非原创。

死锁的四个必要条件：
互斥条件(Mutual exclusion)：资源不能被共享，只能由一个进程使用。
请求与保持条件(Hold and wait)：已经得到资源的进程可以再次申请新的资源。一个进程因请求资源而阻塞时，对已获得的资源保持不放。
非剥夺条件(No pre-emption)：已经分配的资源不能从相应的进程中被强制地剥夺。
循环等待条件(Circular wait)：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。

不难看出，在死锁的四个必要条件中，第二、三和四项条件比较容易消除。通过引入事务机制，往往可以消除第二、三两项条件，方法是将所有上锁操作均作为事务对待，一旦开始上锁，即确保全部操作均可回退，同时通过锁管理器检测死锁，并剥夺资源（回退事务）。这种做法有时会造成较大开销，而且也需要对上锁模式进行较多改动。

消除第四项条件是比较容易且代价较低的办法。具体来说这种方法约定：上锁的顺序必须一致。具体来说，我们人为地给锁指定一种类似“水位”的方向性属性。无论已持有任何锁，该执行绪所有的上锁操作，必须按照一致的先后顺序从低到高（或从高到低）进行，且在一个系统中，只允许使用一种先后次序。

请注意，放锁的顺序并不会导致死锁。也就是说，尽管按照 锁A, 锁B, 放A, 放B 这样的顺序来进行锁操作看上去有些怪异，但是只要大家都按先A后B的顺序上锁，便不会导致死锁。

避免死锁的算法，银行家算法，等到有时间的时候，再去研究吧。

再来说说锁的可重入性：

每个锁都关联一个请求计数器和一个占有他的线程，当请求计数器为0时，这个锁可以被认为是unhled的，当一个线程请求一个unheld的锁时，JVM记录锁的拥有者，并把锁的请求计数加1，如果同一个线程再次请求这个锁时，请求计数器就会增加，当该线程退出syncronized块时，计数器减1，当计数器为0时，锁被释放。

基于下面的这些分析，目前总结了一下，关于synchronized和ReentrantLock的区别，如下：

1.在发生异常的情况下，synchronized的锁，JVM会被回收，ReentrantLock的不会。

2.在jstack里，如果可以看到synchronized导致线程等待的情况，ReentrantLock的不会。（这点我倒是很少看到有文章会说出来）

3.ReentrantLock的性能更好一些，但是随着JVM的优化，变的不甚明显。另一个差别是，synchronized永远是公平的，ReentrantLock默认情况下为不公平锁。公平情况下，操作会排一个队按顺序执行，来保证执行顺序。（会消耗更多的时间来排队），不公平情况下，是无序状态允许插队，jvm会自动计算如何处理更快速来调度插队。（如果不关心顺序，这个速度会更快）。

4.ReentrantLock有更好的可操控性，例如，我们在lock的时候，会trylock()一下，看能不能获得锁，如果获得不了，也可以等待一段时间，lock()了以后，也可以中断而释放锁，这个机制显然就比synchronized更加灵活了。

可重入的概念是：

若一个程序或子程序可以“安全的被并行执行(Parallel computing)”，则称其为可重入（reentrant或re-entrant）的。即当该子程序正在运行时，可以再次进入并执行它（并行执行时，个别的执行结果，都符合设计时的预期）。可重入概念是在单线程操作系统的时代提出的。

锁的可重入性机制可以用来解决下面这个问题：

public class Widget {
    public synchronized void doSomething() {
        ...
    }
}  

public class LoggingWidget extends Widget {
    public synchronized void doSomething() {
        System.out.println(toString() + ": calling doSomething");
        super.doSomething();
    }
}

如果没有Java锁的可重入性，当一个线程获取LoggingWidget的doSomething()代码块的锁后，这个线程已经拿到了LoggingWidget的锁，当调用父类中的doSomething()方法的时，JVM会认为这个线程已经获取了LoggingWidget的锁，而不能再次获取，从而无法调用Widget的doSomething()方法，从而照成死锁。从中我们也能看出，java线程是基于“每线程（per-thread）”，而不是基于“每调用的（per-invocation）”的，也就是说java为每个线程分配一个锁，而不是为每次调用分配一个锁。

可重入锁，当锁定没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁定并返回。如果当前线程已经拥有该锁定，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。

对于可重入锁，有一点理解就是要注意：

线程在等待时(con.await)，已经不在拥有（keep）该锁了，所以其他线程就可以获得重入锁了。

有必要会过头再看看Java官方的解释：“如果该锁定被另一个线程保持，则出于线程调度的目的，禁用当前线程，并且在获得锁定之前，该线程将一直处于休眠状态”。我对这里的“保持”的理解是指非wait状态外的所有状态，比如线程Sleep、for循环等一切有CPU参与的活动。一旦线程进入wait状态后，它就不再keep这个锁了，其他线程就可以获得该锁；当该线程被唤醒（触发信号或者timeout）后，就接着执行，会重新“保持”锁，当然前提依然是其他线程已经不再“保持”了该重入锁。

对于这一点，我觉得可以理解成，synchronized和ReentrantLock都是具备可重入性的，wait都会释放占有的锁。

这样一个应用场景就是，对于Java concurrent中关于任务调度的实现时，延迟队列DelayQueue，比如take()。该方法的主要功能是从优先队列（PriorityQueue）取出一个最应该执行的任务（最优值），如果该任务的预订执行时间未到，则需要wait这段时间差。反之，如果时间到了，则返回该任务。而offer()方法是将一个任务添加到该队列中。（这是一个非常有用的功能，有空的时候要写一写这个功能的demo代码）

后来产生了一个疑问：如果最应该执行的任务是一个小时后执行的，而此时需要提交一个10秒后执行的任务，会出现什么状况？会不会一直等待take()返回后才能提交呢？

答案是否定的，因为take()和offer()都用到了是可重入锁的机制，它确实是一个无阻塞的锁。中间有一段await（）的操作。

可重入锁的使用场景：

 场景1：如果发现该操作已经在执行中则不再执行（有状态执行）

          a、用在定时任务时，如果任务执行时间可能超过下次计划执行时间，确保该有状态任务只有一个正在执行，忽略重复触发。

          b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。

以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）

private ReentrantLock lock = new ReentrantLock();

if (lock.tryLock()) {  //如果已经被lock，则立即返回false不会等待，达到忽略操作的效果 

                    try {

                       //操作

                    } finally {
                        lock.unlock();
                    }

                }

场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）

场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）

场景4：如果发现该操作已经在执行，等待执行。这时可中断正在进行的操作立刻释放锁继续下一操作。

synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）

这种情况主要用于取消某些操作对资源的占用。如：（取消正在同步运行的操作，来防止不正常操作长时间占用造成的阻塞）

try {
    lock.lockInterruptibly();
    //操作

} catch (InterruptedException e) {
    e.printStackTrace();
} finally {
    lock.unlock();
}