乐观锁和悲观锁
悲观锁
- 适合写操作多的场景，先加锁可以保证写操作时数据正确。
- 显式的锁定之后再操作同步资源
- synchronized关键字和Lock的实现类都是悲观锁
//=============悲观锁的调用方式
public synchronized void m1()
{
//加锁后的业务逻辑......
}
// 保证多个线程使用的是同一个lock对象的前提下
ReentrantLock lock = new ReentrantLock();
public void m2() {
lock.lock();
try {
// 操作同步资源
}finally {
lock.unlock();
}
}
乐观锁
- 适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升。
- 乐观锁则直接去操作同步资源，是一种无锁算法，得之我幸不得我命，再抢
- 采用版本号机制
- CAS（Compare-and-Swap，即比较并替换）算法实现
synchronized的字节码实现
synchronized同步代码块
synchronized普通同步方法
调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否被设置。如果设置了，执行线程会将先持有monitor然后再执行方法，
最后在方法完成(无论是正常完成还是非正常完成)时释放 monitor
synchronized静态同步方法
ACC_STATIC, ACC_SYNCHRONIZED访问标志区分该方法是否静态同步方法
管程monitor
管程 (英语：Monitors，也称为监视器) 是一种程序结构，结构内的多个子程序（对象或模块）形成的多个工作线程互斥访问共享资源。
这些共享资源一般是硬件设备或一群变量。对共享变量能够进行的所有操作集中在一个模块中。（把信号量及其操作原语“封装”在一个对象内部）管程实现了在一个时间点，最多只有一个线程在执行管程的某个子程序。管程提供了一种机制，管程可以看做一个软件模块，它是将共享的变量和对于这些共享变量的操作封装起来，形成一个具有一定接口的功能模块，进程可以调用管程来实现进程级别的并发控制。
公平锁/非公平锁
为什么会有公平锁/非公平锁的设计为什么默认非公平？
1.恢复挂起的线程到真正锁的获取还是有时间差的，从开发人员来看这个时间微乎其微，但是从CPU的角度来看，这个时间差存在的还是很明显的。所以非公平锁能更充分的利用CPU 的时间片，尽量减少 CPU 空闲状态时间。
- 使用多线程很重要的考量点是线程切换的开销，当采用非公平锁时，当1个线程请求锁获取同步状态，然后释放同步状态，因为不需要考虑是否还有前驱节点，所以刚释放锁的线程在此刻再次获取同步状态的概率就变得非常大，所以就减少了线程的开销。
使?非公平锁会有什么问题?
公平锁保证了排队的公平性，非公平锁霸气的忽视这个规则，所以就有可能导致排队的长时间在排队，也没有机会获取到锁，
这就是传说中的 “锁饥饿”
