synchronized详解
在多线程同时访问一个共享变量时，volatile是一个轻量级的解决方案，但是volatile只能修饰一个变量并且不保证原子性。在Java中还提供了两种方式实现同步互斥访问：synchronized和Lock
其实这些本质上就是加锁，
加锁目的:序列化访问临界资源，即同一时刻只能有一个线程访问临界资源(同步互斥访问) 不过有一点需要区别的是:当多个线程执行一个方法时，该方法内部的局部变量并不是临界资源，因为这些局部变量是在每个线程的 私有栈中，因此不具有共享性，不会导致线程安全问题。
下面我们详细讲一讲synchronized
1.原理
synchronized是一种对象锁，是可重入的，但是不可中断的（这个不可中断指的是在阻塞队列中排队是不可中断),非公平的锁。
synchronized是基于JVM内置锁实现，通过内部对象Monitor(监视器锁)实现，基于进入与退出Monitor对象实现方法与代码块同步，监视器锁的实现依赖底层操作系统的Mutex lock(互斥锁)实现。
加了synchronized后，在字节码会有二条指令,如代码第4和13标识位
synchronized (Test3.class){
System.out.println(1);
}
4: monitorenter
5: getstatic #6 // Field java/lang/System.out:Ljava/io/PrintStream;
8: iconst_1
9: invokevirtual #7 // Method java/io/PrintStream.println:(I)V
12: aload_1
13: monitorexit
- monitorenter:每个对象都是一个监视器锁(monitor)。当monitor被占用时就会处于锁定状态，线程执行 monitorenter指令时尝试获取monitor的所有权，过程如下:
a. 如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor 的所有者;
b. 如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1;
c. 如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝 试获取monitor的所有权;
- monitorexit:执行monitorexit的线程必须是objectref所对应的monitor的所有者。指令执行时，monitor的进入数减 1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去 获取这个 monitor 的所有权。
synchronized加锁加在对象上，对象是如何记录锁状态的呢?答案是锁状态是被记录在每个对象 的对象头(Mark Word)中，下面我们一起认识一下对象的内存布局
2.对象内存分布
- 对象头:Java对象头一般占有2个机器码(在32位虚拟机中，1个机器码等于4字节，也就是32bit， 在64位虚拟机中，1个机器码是8个字节，也就是64bit)，但是 如果对象是数组类型，则需要3个 机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的 元数据来确认数组的大小，所以用一块来记录数组长度
- 实例数据:存放类的属性数据信息，包括父类的属性信息;
- 对齐填充:由于虚拟机要求 对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。
3.锁升级
在JDK1.5之前一直是一种重量级锁的状态，也就是每次加锁和释放锁都直接和操作系统打交道。
JDK1.5后，就做了很多优化偏向锁，轻量级锁，自适应自旋等。
偏向锁
偏向锁是Java 6之后加入的新锁，它是一种针对加锁操作的优化手段，经过研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。
偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时， 无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。
所以，对于没有锁竞争 的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就 失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的 是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。下面我们接着了解轻量级锁。
默认开启偏向锁
开启偏向锁:-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 关闭偏向锁:-XX:-UseBiasedLocking
轻量级锁
倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞 争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场 合，就会导致轻量级锁膨胀为重量级锁。
自旋锁
轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要 从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线 程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，一般不会太久，可能是50个循环或 100循环，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是 自旋锁的优化方式，这种方式确实也是可以提升效率的。
最后没办法也就只能升级为重量级锁了。
最后来一下对比
| 锁 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 偏向锁 | 加锁和解锁不需要CAS操作，没有额外的性能消耗，和执行非同步方法相比仅存在纳秒级的差距 | 若线程间存在锁竞争，会带来额外的锁撤销的消耗 | 只有一个线程访问同步块或者同步方法 |
| 轻量级锁 | 竞争的线程不会阻塞，提高了程序的响应速度 | 若线程长时间竞争不到锁，自旋会消耗 CPU 性能 | 线程交替执行同步块或者同步方法，追求响应时间，锁占用时间很短，阻塞还不如自旋的场景 |
| 重量级锁 | 线程竞争不使用自旋，不会消耗CPU | 线程阻塞，响应时间缓慢，在多线程下，频繁的获取释放锁，会带来巨大的性能消耗 | 追求吞吐量，锁占用时间较长 |
⚠️注意啊，锁的升级是不可逆的！！！！！！！
⚠️注意啊，锁的升级是不可逆的！！！！！！！
⚠️注意啊，锁的升级是不可逆的！！！！！！！