synchronized

临界区（ Critical Section）

一个程序运行多个线程本身是没有问题的，一段代码块内如果存在对共享资源的多线程读写操作，称这段代码块为临界区，其共享资源为临界资源

竞态条件（ Race Condition ）

多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件

为了避免临界区的竞态条件发生，有多种手段可以达到目的：

• 阻塞式的解决方案：synchronized，Lock
• 非阻塞式的解决方案：原子变量

加锁方式

底层原理

• synchronized是JVM内置锁，基于Monitor机制实现，依赖底层操作系统的互斥原语Mutex（互斥量），它是一个重量级锁，性能较低。当然，JVM内置锁在1.5之后版本做了重大的优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）、自适应自旋（Adaptive Spinning）等技术来减少锁操作的开销，内置锁的并发性能已经基本与Lock持平。
• java虚拟机通过一个同步结构支持方法和方法中的指令序列的同步：monitor。

• 同步方法是通过方法中的access_flags中设置ACC_SYNCHRONIZED标志来实现；同步代码块是通过monitorenter和monitorexit来实现。两个指令的执行是JVM通过调用操作系统的互斥原语mutex来实现，被阻塞的线程会被挂起、等待重新调度，会导致“用户态和内核态”两个态之间来回切换，对性能有较大影响。

Monitor（管程/监视器）

Monitor，直译为“监视器”，而操作系统领域一般翻译为“管程”。 管程是指管理共享变量以及对共享变量操作的过程，让它们支持并发。在Java 1.5之前，Java语言提供的唯一并发语言就是管程，Java 1.5之后提供的SDK并发包也是以管程为基础的。除了Java之外，C/C++、C#等高级语言也都是支持管程的。synchronized关键字和wait()、notify()、notifyAll()这三个方法是Java中实现管程技术的组成部分。

MESA模型

管程中引入条件变量的概念，而且每个条件变量都对应有一个等待队列。条件变量和等待队列的作用是解决线程之间的同步问题。

wait()的正确使用

while(条件不满足) {
  wait();

唤醒的时间和获取到锁继续执行的时间是不一致的， 被唤醒的线程再次执行时可能条件又不满足了，所以循环检验条件。MESA模型的wait()方法还有一个超时参数， 为了避免线程进入等待队列永久阻塞。

notify()和notifyAll()分使用

满足以下三个条件时，可以使用notify()，其余情况尽量使用notifyAll()：

• 所有等待线程拥有相同的等待条件；
• 所有等待线程被唤醒后，执行相同的操作；
• 只需要唤醒一个线程。

对象的内存布局

new Object（）占16个子节 mark word+元数据指针+对其填充位

Hotspot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）

• 对象头：比如 hash码，对象所属的年代，对象锁，锁状态标志，偏向锁（线程）ID，偏向时间，数组长度（数组对象才有）等。
• 实例数据：存放类的属性数据信息，包括父类的属性信息；
• 对齐填充：由于虚拟机要求 对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。

64位JVM下的对象结构描述

 偏向锁

偏向锁是一种针对加锁操作的优化手段，经过研究发现， 在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了消除数据在无竞争情况下锁重入（CAS操作）的开销而引入偏向锁。对于没有锁竞争的场合，偏向锁有很好的优化效果。

当JVM启用了偏向锁模式（ jdk6默认开启），新创建对象的Mark Word中的Thread Id为0，说明此时 处于可偏向但未偏向任何线程，也叫做 匿名偏向状态(anonymously biased)。

偏向锁延迟偏向

HotSpot 虚拟机在启动后有个 4s 的延迟才会对每个新建的对象开启偏向锁模式。JVM启动时会进行一系列的复杂活动，比如装载配置，系统类初始化等等。在这个过程中会使用大量synchronized关键字对对象加锁，且这些锁大多数都不是偏向锁。为了减少初始化时间，JVM默认延时加载偏向锁。

偏向锁撤销之调用对象HashCode

用锁对象的obj.hashCode()或System.identityHashCode(obj)方法会导致该对象的偏向锁被撤销。因为对于一个对象，其HashCode只会生成一次并保存，偏向锁是没有地方保存hashcode的。

• 轻量级锁会在锁记录中记录 hashCode 
• 重量级锁会在 Monitor 中记录 hashCode

当对象处于可偏向（也就是线程ID为0）和已偏向的状态下，调用HashCode计算将会使对象再也无法偏向：

• 当对象可偏向时，MarkWord将变成未锁定状态，并只能升级成轻量锁；
• 当对象正处于偏向锁时，调用HashCode将使偏向锁强制升级成重量锁。

偏向锁撤销之调用wait/notify

• 偏向锁状态执行obj.notify() 会升级为轻量级锁
• 调用obj.wait(timeout) 会升级为重量级锁

轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段，此时Mark Word 的结构也变为轻量级锁的结构。 轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在 同一时间多个线程访问同一把锁的场合，就会导致轻量级锁膨胀为重量级锁。

synchronized锁优化

偏向锁批量重偏向&批量撤销

从偏向锁的加锁解锁过程中可看出，当只有一个线程反复进入同步块时，偏向锁带来的性能开销基本可以忽略，但是 当有其他线程尝试获得锁时，就需要等到safe point时，再将偏向锁撤销为无锁状态或升级为轻量级，会消耗一定的性能，所以 在多线程竞争频繁的情况下，偏向锁不仅不能提高性能，还会导致性能下降。于是，就有了 批量重偏向与批量撤销的机制。

应用场景

批量重偏向（bulk rebias）机制是为了解决： 一个线程创建了 大量对象 并执行了初始的同步操作，后来另一个线程也来将 这些对象 作为锁对象进行操作，这样会导致大量的偏向锁撤销操作。

批量撤销（bulk revoke）机制是为了解决： 在明显多线程竞争剧烈的场景下使用偏向锁是不合适的。

自旋优化/自适应自旋

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

自旋的目的是为了减少线程挂起的次数，尽量避免直接挂起线程（挂起操作涉及系统调用，存在用户态和内核态切换，这才是重量级锁最大的开销）

锁粗化

假设一系列的连续操作都会 对同一个对象反复加锁及解锁，甚至加锁操作是出现在循环体中的，即使没有出现线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。如果JVM检测到有一连串零碎的操作都是对同一对象的加锁，将会扩大加锁同步的范围（即锁粗化）到整个操作序列的外部。

锁消除

锁消除即删除不必要的加锁操作。锁消除是Java虚拟机在JIT编译期间，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过锁消除，可以节省毫无意义的请求锁时间。