reentrantlock 和 synchronized对比

1 synchronized和AQS（AbstractQueueSynchronizer） 和ReentranLock(通过cas实现) 关系

以前JDK1.6之前就用synchronized，性能不好，后面李二狗就写了AQS，用ReentranLock实现了锁，性能很高。后面jdk觉得自己的不能比别人差啊，就去优化了synchronized，以前是一开始就加了一个重量级的锁，性能肯定不好啊，所以就优化了锁，刚刚开始没有锁，然后有偏向锁，再然后有轻量级锁，再最后才有的重量级锁。这样性能就ReentranLock 相当了

ReentranLock 需要手动加解锁，用法如下图

公平锁：线程来了都要排队

Synchronized面试应该怎么说？

1 先说应用，加在方法上，或者 加在方法里面。

锁膨胀过程：无锁-偏向锁-轻量锁-重量锁。并且这个锁是不可逆的

2 是jvm内置锁，隐式锁，枷锁解锁都是内部的，不需要我们去做

ReentranLock 显式锁，枷锁解锁要手动，支持公平和非公平锁，可重入

如何理解ReentranLock的公平锁和非公平锁

公平锁会判断一下队列中是否已经存在等待获取锁的线程，如果存在，则把自己加入到队列的尾部

非公平锁，不会判断队列中是否已经存在等待获取锁的线程，而是直接进行一次获取锁的操作。

reentrantlock synchronized 选型

ReentrantLock绝对是最危险的同步工具；如果你忘记在finally块中调用unlock, 你的代码将很可能看起来能够正常运行，但是已经埋下定时炸弹，并很有可能伤及无辜。 在内部锁不能满足需求，需要使用ReentrantLock的情况下才应该使用。

synchronized和lock(reentrantlock) 区别

而Lock用的是乐观锁方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。乐观锁实现的机制就是CAS操作（Compare and Swap）。我们可以进一步研究ReentrantLock的源代码，会发现其中比较重要的获得锁的一个方法是compareAndSetState

final Lock lock = new ReentrantLock();

需要手动枷锁 和 在finally里面释放锁

synchronized的使用中我们并没有发现它做任何的加锁和解锁操作，这个其实是因为编译器隐式的帮我们做了加锁和解锁操作，这样我们就可以放心大胆的加锁，要不然我们自己去做这个操作的话，一不小心忘记解锁了，那就会造成后面的线程迟迟不能加锁，造成死锁了

锁是如何存储的?

存在对象头

我们发现编译成指令后每个synchronized修饰的代码块前后都会有加上一个monitorenter 和monitorexit指令， 这其实就对应了我们上面那种加锁逻辑图里的lock 和unlock操作，monitorexit 指令又两次是因为在出现异常的时候我们也需要解锁操作。