sychronized使用方式总结
底层通过monitor锁来实现。
1.锁对象
- 通过在实例方法中加sychronized修饰
- 代码块中，即sychronized(this){}，也是对当前对象加锁
2.锁类
- 通过对静态方法加sychronized修饰
- 代码块中，即sychronized(this.clss){}，也是对当前对象的类加锁
monitor锁操作是基于操作系统的底层Mutex Lock实现的，对所要加锁线程加上互斥锁，但是加锁时间相比其他指令就长很多了，因此将这种基于互斥锁的加锁机制成为重量级锁。
JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
jdk1.6后对锁的优化
都是JVM级别的优化
偏头锁：指的是在没有线程竞争的情况下，会把整个同步消除
轻量级锁：在没有多线程竞争的时候，采用CAS操作，不使用互斥量。
自旋锁：由于互斥同步对性能最大的开销是在于线程的挂起恢复，所以对于一些持有锁时间不是很长的线程，其他线程等待的时候我们不把他挂起，而是让线程执行一个循环，等待持有锁线程的释放。自旋次数可以改变，默认是10.
自适应自旋锁：针对线程状态等情况，动态生成自旋时间。
sychronized和reentrantlock的区别
sychronized针对JVM,而reentrantlock依赖于api,
两者均为可重入锁，即一个线程已经获得了this对象，然后当再次想要获得该锁的时候，可重入锁还可以继续获得该锁，如果不可重入，此时会产生死锁。因为锁计数器到0的时候才会释放锁。
可重入锁理解：https://blog.csdn.net/yiifaa/article/details/74200849reentrantlock提供了更多的功能，是Lock的实现
- ReenTrantLock提供了一种能够中断等待锁的线程的机制
- 可中断锁。可中断锁是指线程尝试获取锁的过程中，是否可以响应中断。synchronized是不可中断锁，而ReentrantLock则提供了中断功能。
- ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。公平不公平指的是获取锁的机制，reentrantlock主要通过一份FIFO的队列来实现的公平
- synchronized关键字与wait()和notify/notifyAll()方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition() 方法。Condition是JDK1.5之后才有的，使用notify和notifyAll方法进行通知时，被通知的线程是由JVM随机选择的，但是ReentrantLock结合Condition可以实现前面介绍过的“选择性通知”,这个功能是非常重要的。 而且是Condition接口默认提供的。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的所有等待线程。
reentrantlock实现原理
https://blog.csdn.net/u011202334/article/details/73188404
锁问题的几个核心
锁要解决的大概就只有这4个问题：
“谁拿到了锁“这个信息存哪里（可以是当前class，当前instance的markword，还可以是某个具体的Lock的实例）
谁能抢到锁的规则（只能一个人抢到 - Mutex；能抢有限多个数量 - Semphore；自己可以反复抢 - 重入锁；读可以反复抢到但是写独占 - 读写锁……）
抢不到时怎么办（抢不到玩命抢；抢不到暂时睡着，等一段时间再试/等通知再试；或者二者的结合，先玩命抢几次，还没抢到就睡着）
如果锁被释放了还有其他等待锁的怎么办（不管，让等的线程通过超时机制自己抢；按照一定规则通知某一个等待的线程；通知所有线程唤醒他们，让他们一起抢……）
有了这些选择，你就可以按照业务需求组装出你需要锁，而且可以针对具体业务选择对应的锁来减轻开销。
可重入锁？？？死锁？？？？读写锁？？？