synchronized 锁定的是一个对象，执行某段代码的时候必须锁定一个对象，不锁定就无法执行
一、概念介绍
1.1 用户态与内核态
- 内核态（kener）：内核/操作系统可以做的一些操作。
- 用户态（APP）：用户的程序可以做的一些操作。
- 用户态的程序要访问一些比较危险的操作的时候，比如格式化硬盘或直接访问内存网卡等，必须经过操作系统即内核的允许，这样可以保证安全性。
- 从指令来讲，用户态只能执行某些指令，而内核态可以执行所有指令。
- 对于 JVM 虚拟机来说就是一个普通程序，即属于用户态。
- 早期的 synchronized 叫重量级锁，因为早期使用 synchronized 加锁的时候要结果内核态的允许，即要经过操作系统线程的调度才能拿到锁，所以称为重量级锁。
- 后期经过了优化在某些特定情况下不需要结果操作系统，在用户态就可以解决，即使轻量级锁，比如 CAS 只是一个对比和交换，不需要经过操作系统是轻量级锁（锁的升级）。
1.2 CAS
CAS ：compare and swap/compare and exchange
- 举个例子：
- A 线程获取变量 a 的值此时 a = 1，然后 A 线程对变量 a 进行 a++ 操作，操作完成要写回内存。
- 此时会再次获取当前时间下变量 a 的值，如果此时 a 依旧为0，就认为没有线程操作过 a，就正常将 a=1 写入。
- 如果发现 a 的值已近变了比如 a = 3了，说明有线程对 a 做了操作，那就不写入。
- 此时重新获取 a 的值，在进行 ++ 操作，操作完在判断当前 a 的值和 ++ 前的值是否一致。这样一致循环下去。
- 上面说的这种情况不用上锁， CAS 也称为自旋锁/无锁。无锁不是没有锁，是没有内核状态的锁。
对图中的 ABA 问题做一下解释：
还是上面的例子，A 线程执行完 a++ 操作后，要将新的 a 值写入内存，此时会再次获取当前时间下变量 a 的值，如果此时 a 依旧为0，就认为没有线程操作过 a，就正常将 a=1 写入。但是可能存在这种情况，就是 B 线程将变量 a 改为3，然后 C 线程又将变量 a 改为了0，实际上此时变量 a 已经发生了变化。这就是 ABA 问题。
解决方法：可以给变量 a 增加一个版本号
再举个例子：
public static void main(String[] args) throws InterruptedException {
AtomicInteger integer = new AtomicInteger(0);
Thread[] threads = new Thread[10];
// 等待线程结束
CountDownLatch downLatch = new CountDownLatch(threads.length);
for (int i = 0; i < threads.length; i++) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
System.out.println(Thread.currentThread().getName());
for (int j = 0; j < 5; j++) {
// 如果是 integer++ 的话就要加锁
integer.incrementAndGet();
}
downLatch.countDown();
}
});
threads[i] = thread;
}
Arrays.stream(threads).forEach(f -> f.start());
downLatch.await();
System.out.println(Thread.currentThread().getName() + " " + integer);
}
上面的代码中如果采用 integer++ 这种方式就要进行加锁，采用 integer.incrementAndGet() 就不需要加锁，因为 incrementAndGet 方法底层就是采用的 CAS 实现的，是汇编的一条指令lock cmpxchg 指令。cmpxchg 指令不是原子的，所以需要 lock 指令给 CPU 加锁，只让一个线程操作。
1.3 对象在内存中的分布
二、锁的升级
偏向锁、自旋锁都是在用户空间完成
重量级锁都需要向内核空间申请
偏向锁：
- 向 markword 上记录自己的线程指针，实际上没有上锁，只是标记，此时只有一个线程执行，没有竞争的概念。
- 为何会有偏向锁：因为经过统计大多数情况下 synchronized 方法只有一个线程在执行（如：stringbuffer的一些sync方法，vector的一些sync方法），此时没必要申请锁，节约资源
- JVM 中偏向锁是默认打开的，但是有延迟 4S，可以设置参数修改 1.-XX:BiasedLockingStartupDelay=0。对应的就是锁升级图中 new 一个对象后会有两种情况。
- 偏向锁默认打开原因是：JVM 虚拟机自己有一些默认启动的线程，里面有好多 sync 代码，这些 sync 代码启动时就知道肯定会有竞争，如果使用偏向锁，就会造成偏向锁不断的进行锁撤销和锁升级的操作，效率较低。
- 偏向锁是否一定比自旋锁效率高：不一定，在明确知道会有多线程竞争的情况下，偏向锁肯定会涉及锁撤销，这时候直接使用自旋锁不涉及锁撤销，效果高。
自旋锁/轻量级锁：
- 有偏向锁升级而来，当有多个线程执行（>= 2）的时候，此时就会有竞争不能在采用偏向锁了。
- 多个线程通过竞争，某一个线程会将自己的线程指针写入 markword，标记自己占有，其他线程只能等待。
- 怎么等待呢，就是采用 CAS 的方式，不停的去获取 markword 上记录的指针信息，看是不是被占有，如果没有被占有就把自己的指针写进去。这种方式下等待的线程会占用 CPU 资源
- 所以自旋锁也没有经过内核态的操作，是轻量级锁。
- 每个线程有自己的 LockRecord 在自己的线程栈上，用 CAS 去争用 markword 的 LR 的指针，指针指向哪个线程的 LR，哪个线程就拥有锁。
重量级锁：
- 可以是自旋锁升级而来，自旋是消耗 CPU 资源的，如果锁的时间长，或者自旋线程多，CPU 会被大量消耗。
- 重量级锁有等待队列，竞争队列，所有拿不到锁的进入等待队列，不需要消耗 CPU 资源。
- JDK6之前，一个线程自旋超过10次，或者等待的线程数超过 CPU 核数的1/2，升级为重量级锁，如果太多线程自旋 CPU 消耗过大，不如升级为重量级锁，进入等待队列（不消耗CPU）。自旋次数和等待的线程数都可以通过参数控制。-XX:PreBlockSpin。
- 自旋锁在 JDK1.4.2 中引入，使用 -XX:+UseSpinning 来开启。JDK 6 中变为默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。
- 自适应自旋锁意味着自旋的时间（次数）不再固定，根据历史情况由 JVM 来管理。
- 偏向锁耗时过长，或有 wait 时也会进入重量级锁。