Lock锁底层原理实现以及与synchronized的比较

lock是一个接口，而synchronized是在JVM层面实现的。synchronized释放锁有两种方式：

获取锁的线程执行完同步代码，释放锁 。

线程执行发生异常，jvm会让线程释放锁。

lock锁的释放，出现异常时必须在finally中释放锁，不然容易造成线程死锁。lock显式获取锁和释放锁，提供超时获取锁、可中断地获取锁。

synchronized是以隐式地获取和释放锁，synchronized无法中断一个正在等待获取锁的线程。

synchronized原始采用的是CPU悲观锁机制，即线程获得的是独占锁。独占锁意味着其他线程只能依靠阻塞来等待线程释放锁。而在CPU转换线程阻塞时会引起线程上下文切换，当有很多线程竞争锁的时候，会引起CPU频繁的上下文切换导致效率很低。

Lock用的是乐观锁方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。乐观锁实现的机制就是CAS操作。

具体的悲观锁和乐观锁的详细介绍请参考这篇文章[浅谈数据库乐观锁、悲观锁]

在JDK5中增加了一个Lock接口实现类ReentrantLock.它不仅拥有和synchronized相同的并发性和内存语义,还多了锁投票,定时锁,等候和中断锁等.它们的性能在不同的情况下会有不同。

在资源竞争不是很激烈的情况下,synchronized的性能要由于ReentrantLock,但是在资源竞争很激烈的情况下,synchronized的性能会下降得非常快,而ReentrantLock的性能基本保持不变.

接下来我们会进一步研究ReentrantLock的源代码，会发现其中比较重要的获得锁的一个方法是compareAndSetState。

Java中ReentrantLock重入锁中的AQS队列排队策略，是基于CLH队列的一种变种实现。原始的CLH队列，一般用于实现自旋锁。而AQS队列的实现，是获取不到锁的线程，先进行一小段时间的自旋，然后进入Park挂起状态。【同样的，ZK中的分布式锁，也使用了类似方式，获取不到锁的线程值监听前一个节点】。因此AQS解决了CLH每个线程无限自旋的问题，应用场景也更加广泛。

这里谈到了自旋锁，那么我们也顺便说下互斥锁。这里的互斥锁说的是传统意义的互斥锁，就是多个线程并发竞争锁的时候，没有抢到锁的线程会进入休眠状态即sleep-waiting，当锁被释放的时候，处于休眠状态的一个线程会再次获取到锁。缺点就是这一些列过程需要线程切换，需要执行很多CPU指令，同样需要时间。如果CPU执行线程切换的时间比锁占用的时间还长，那么可能还不如使用自旋锁。因此互斥锁适用于锁占用时间长的场合。