为什么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;