juc包下AQS
await之后进入条件等待队列，singal/signalAll之后进入同步等待队列
加锁解锁只与同步等待队列有关
ReentrantLock解决线程安全问题
竞争不够激烈使用synchronized（轻量级锁完全在用户态执行，不用阻塞线程 cas很多次阻塞线程） 竞争激烈使用ReentrantLock（只要有竞争就会阻塞线程、会有一次cas成功率低）
cas乐观锁
java里面实现数组有两种实现：1、数组2、链表3、堆
悲观锁：很悲观别人一定会来抢我的，一定要上一把锁一定要阻塞住
乐观锁：cas 数据库版本号
自旋：cas 不停地尝试去获取锁
非自旋： 直接阻塞 很重的操作
中断：调用这个线程的中断方法，加锁的逻辑里面能对中断标记有判断，读到中断标记可以终止线程
不可中断：没有去判断这个线程是否有中断标记
可重入锁：同一个锁对象，再次进入，不会阻塞住持有锁的线程
不可重入锁：
共享锁：tryAcquireShared 信号量 资源与线程
独占锁：
非公平锁效率高
- synchronized是JVM层次的锁实现，ReentrantLock是JDK层次的锁实现；
- synchronized的锁状态是无法在代码中直接判断的，但是ReentrantLock可以通过ReentrantLock#isLocked判断；
- synchronized是非公平锁，ReentrantLock是可以是公平也可以是非公平的；
- synchronized是不可以被中断的，而ReentrantLock#lockInterruptibly方法是可以被中断的；
- 在发生异常时synchronized会自动释放锁，而ReentrantLock需要开发者在finally块中显式释放锁；
- ReentrantLock获取锁的形式有多种：如立即返回是否成功的tryLock(),以及等待指定时长的获取，更加灵活；
- synchronized在特定的情况下对于已经在等待的线程是后来的线程先获得锁（回顾一下sychronized的唤醒策略），而ReentrantLock对于已经在等待的线程是先来的线程先获得锁；