为什么Java有了synchronized之后还造了Lock锁这个轮子？

众所周知，synchronized和Lock锁是java并发变成中两大利器，可以用来解决线程安全的问题。但是为什么Java有了synchronized之后还是提供了Lock接口这个api，难道仅仅只是重复造了轮子这么简单么？本文就来探讨一下这个问题。

谈到这个问题，其实很多同学第一反应都会说，Lock锁的性能比synchronized好，synchronized属于重量级的锁。但是在JDK 1.6版本之后，JDK对synchronized进行了一系列性能的优化，synchronized的性能其实有了大大的提升（如果不清楚的同学可以看一下 synchronized真的很重么？ 这篇文章，文章内详细的说明JDK对synchronized做了哪些优化），那么既然性能不是问题，那么主要的问题是什么呢？

synchronized抢占锁的特性

我们先来看一下synchronized抢占锁的特性。synchronized在抢占锁的时候，如果抢占不到，线程直接就进入阻塞状态了，而线程进入阻塞状态，其实什么也干不了，也释放不了线程已经占有的资源，并且也无法主动或者被动打断阻塞获取锁的操作，只有等别的线程释放锁之后才会被唤醒来重新获取锁。

synchronized阻塞获取锁产生的问题

那synchronized这种获取锁阻塞的特性，有什么问题么？其实有一种很重要的问题，那就是会产生死锁的问题。

那什么是死锁？死锁是指两个或者两个以上的线程在执行的过程中，因争夺资源产生的一种互相等待的现象。

举个例子来说，线程1先对加A加锁，线程2对B加锁。代码运行到某一时刻，线程1需要对B加锁，但是此时B的锁已经被线程2占有，于是线程1就会阻塞，与此同时线程2同时也需要对A加锁，发现A已经被线程1持有，也会进入阻塞，于是线程1和线程2都在等对方释放资源，就产生了死锁的问题，并且由于synchronized阻塞的特性，线程无法主动或者被动停止阻塞，势必会导致这个死锁永远无法通过主动或者人为干预（其它线程干预）来解决。

那么有什么好的办法来解决阻塞导致死锁的问题呢？

我们分析一下死锁产生的问题主要是线程都在相互等待其它线程释放资源导致的，基于这个问题我们思考一下，如果一个线程获取不到锁，然后就停止获取锁，不阻塞，或者是阻塞一会就不再阻塞，又或是阻塞过程中被其他线程打断，那样这是不是就不是产生死锁的问题了。

就拿上面的例子来说，假设线程1获取B的阻塞锁超过一定时间，主动放弃获取B的锁，那么线程1代码就可以继续往下执行，当执行完之后，线程1释放了A锁，此时线程2就能获取到A的锁，那么线程2就可以继续执行了，这样是不是死锁的问题就完美解决了。

其实Lock锁就提供了上述提到的几种解决方案的api，接下来我们就来看看Lock锁提供的api。

Lock锁

void lockInterruptibly() throws InterruptedException;

阻塞可以被打断的加锁方法，这是一个被动放弃获取锁的方法。就是说其它线程主动当调用阻塞线程的interrupt方法之后，该阻塞线程就会放弃继续获取锁，然后抛出InterruptedException 异常，所以对于使用方来说，只要捕获这个异常，就能保证线程的代码继续执行了。

boolean tryLock();

这个方法是尝试加锁，加锁失败后就放弃加锁，不会阻塞，直接返回false。

boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

这个方法相比上面的就是尝试加锁失败后在阻塞的一定时间之后，如果还没有获取到锁，那么就放弃获取锁。

Lock接口的实现有很多，但基本上都是基于Java的AQS的实现来完成的。AQS其实主要是维护了一个锁的状态字段state和一个双向链表。当线程获取锁失败之后，就会加入到双向链表中，然后阻塞或者不阻塞，这得看具体的方法实现。

Lock接口的一个实现ReentrantLock就是基于AQS实现来讲的，这里就不继续展开讲解ReentrantLock的实现原理，如果有感兴趣的同学，可以看一下 一文带你看懂Java中的Lock锁底层AQS到底是如何实现的 这篇文章，文章是基于ReentrantLock来讲解AQS的加锁和释放锁的原理。

总结

好了，到这里其实大家应该知道了，为什么需要Lock锁，因为synchronized获取不到锁的时候会阻塞，并且阻塞不可被打断的特性会导致可能会产生死锁的问题，为了解决这个问题，Java就提供了Lock锁的实现，从主动放弃获取锁或者被动放弃获取锁的方式，解决一直阻塞可能产生的死锁问题。