Reentrantlock类
重入锁代表一段代码可以被同一个线程多次进入，其中unlock()次数对应lock()的次数。
区别于jvm实现的synchronized关键字，ReentrantLock是Lock的实现，代码层级的锁，常在finally中调用unlock()释放锁，所以在程序崩溃情况下，有可能造成死锁。
//创建一个非公平锁，默认是非公平锁
Lock nonFairLock= new ReentrantLock();
Lock nonFairLock= new ReentrantLock(false);
//创建一个公平锁，构造传参true
Lock fairLock= new ReentrantLock(true);
公平锁 & 非公平锁
-
公平锁 加锁前先查看是否有排队等待的线程，有的话优先处理排在前面的线程，先来先得。
-
非公平锁 线程加锁时直接尝试获取锁，获取不到就自动到队尾等待。
更多的是直接使用非公平锁：非公平锁比公平锁性能高5-10倍，因为公平锁需要在多核情况下维护一个队列，如果当前线程不是队列的第一个无法获取锁，增加了线程切换次数。
synchronized关键字
1. 作用及范围
当时用synchronized修饰静态方法时，锁住的是class 当时用synchronized修饰非静态方法时，锁住的是对象
用synchronized修饰的代码块，编译阶段会在方法执行前后生成monitorenter、monitorexit指令 当修饰方法会在常量池生成ACC_SYNCHRONIZED
2. 锁升级过程
jdk1.6引入了锁优化，替代了原来只有重量级锁性能较差的问题。
偏向锁 -> 轻量级锁 -> 重量级锁
a. 偏向锁
偏向锁是jdk1.6引入的一项锁优化，其中的“偏”是偏心的偏。它的意思就是说，这个锁会偏向于第一个获得它的线程，在接下来的执行过程中，假如该锁没有被其他线程所获取，没有其他线程来竞争该锁，那么持有偏向锁的线程将永远不需要进行同步操作。
即：在此线程之后的执行过程中，如果再次进入或者退出同一段同步块代码，并不再需要去进行加锁或者解锁操作 ，而是会做以下的步骤：
- Load-and-test，也就是简单判断一下当前线程id是否与Markword当中的线程id是否一致.
- 如果一致，则说明此线程已经成功获得了锁，继续执行下面的代码.
- 如果不一致，则要检查一下对象是否还是可偏向，即“是否偏向锁”标志位的值。
- 如果还未偏向，则利用CAS操作来竞争锁，也即是第一次获取锁时的操作。
假如有两个线程来竞争该锁话，那么偏向锁就失效了，进而升级成轻量级锁了。
也就是锁膨胀。
锁撤销
由于偏向锁失效了，那么接下来就得把该锁撤销，锁撤销的开销花费还是挺大的，其大概的过程如下：
- 在一个安全点停止拥有锁的线程。
- 遍历线程栈，如果存在锁记录的话，需要修复锁记录和Markword，使其变成无锁状态。
- 唤醒当前线程，将当前锁升级成轻量级锁。
所以，如果某些同步代码块大多数情况下都是有两个及以上的线程竞争的话，那么偏向锁就会是一种累赘，对于这种情况，我们可以一开始就把偏向锁这个默认功能给关闭（关闭偏向锁:-XX:-UseBiasedLocking）。
b. 轻量级锁
包含两种
- 自旋锁
- 自适应自旋锁
偏向锁是同一个线程多次获取锁，轻量级锁是多个线程交替获取锁。相同点是假定都不存在锁竞争
自适应自旋锁
由于线程1刚刚获得过该锁，那么虚拟机觉得线程1这次自旋也是很有可能能够再次成功获得该锁的，所以会延长线程1自旋的次数。
如果对于某一个锁，一个线程自旋之后，很少成功获得该锁，那么以后这个线程要获取该锁时，是有可能直接忽略掉自旋过程，直接升级为重量级锁的，以免空循环等待浪费资源。
c. 重量级锁
轻量级锁膨胀之后，就升级为重量级锁了。重量级锁是依赖对象内部的monitor锁来实现的，而monitor又依赖操作系统的MutexLock(互斥锁)来实现的，所以重量级锁也被成为互斥锁。
当系统检查到锁是重量级锁之后，会把等待想要获得锁的线程进行阻塞，被阻塞的线程不会消耗cup。但是阻塞或者唤醒一个线程时，都需要操作系统来帮忙，这就需要从用户态转换到内核态，而转换状态是需要消耗很多时间的，有可能比用户执行代码的时间还要长。
ReentrantLock和Synchronized区别
- Lock是一个接口，而synchronized是关键字。
- synchronized会自动释放锁，而Lock必须手动释放锁。
- Lock可以让等待锁的线程响应中断，而synchronized不会，线程会一直等待下去。
- 通过Lock可以知道线程有没有拿到锁，而synchronized不能。
- Lock能提高多个线程读操作的效率。
- synchronized能锁住类、方法和代码块，而Lock是块范围内的
Synchronized性能问题
Synchronized关键字会让没有得到锁资源的线程进入BLOCKED状态，而后在争夺到锁资源后恢复为RUNNABLE状态，这个过程中涉及到操作系统用户模式和内核模式的转换，代价比较高。
尽管Java1.6为Synchronized做了优化，增加了从偏向锁到轻量级锁再到重量级锁的过度，但是在最终转变为重量级锁之后，性能仍然较低。
Synchronized属于悲观锁，悲观地认为程序中的并发情况严重，所以严防死守。CAS属于乐观锁，乐观地认为程序中的并发情况不那么严重，所以让线程不断去尝试更新。
CAS的缺点
1.CPU开销较大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。
2.不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。
因为它本身就只是一个锁住总线的原子交换操作啊。两个CAS操作之间并不能保证没有重入现象。
3.ABA问题
这是CAS机制最大的问题所在。