synchronized语义

synchronized又被称为内置锁，线程进入同步代码块时会获得该锁，退出代码块自动释放锁，锁可以让线程在临界区互斥执行，呈现串行语义。
所以synchronized可以解决任何并发情况下线程安全的问题，包含原子性，可见性，有序性。
java中每一个对象都可以作为锁，根据synchronized修饰的目标不同锁定的对象有如下3中情况：

1、修饰普通方法，锁当前对象

2、修饰静态方法，锁当前类的class对象

3、修饰代码块，锁括号中的对象

synchronized状态

JDK6之前synchronized采用操作系统MutexLock互斥锁机制实现，因其资源开销很大，对性能有一定影响被称为重量级锁。

之后的JDK对锁进行了一系列的优化，优化措施之一就是引入了基于CAS指令(CASCompare-And-Swap，CPU原子指令,汇编指令CMPXCHG。是一种乐观加锁策略,后续在J.U.C中总结)的偏向锁和轻量级锁，使得synchronized的性能有了显著提高。

锁的信息保存在对象头的MarkWord字段中，随着锁状态的变化MarkWord中存储在内容也会跟着变化：

对象存储布局

对象头存储内容大小（markOop.hpp）

锁状态对应的MarkWord

偏向锁
是为了满足一个线程在无竞争条件下访问同步代码块而设置的锁，只需要在替换ThreadID时进行一次CAS操作，线程获取锁的代价极低。

偏向锁获取过程

偏向锁获取代码(biasedLocking.cpp)

偏向锁只有当其他线程竞争锁时，持有线程才释放锁。释放发生在全局安全点上(此刻无其他字节码执行)，暂停持有线程，根据锁对象是否被锁定，将锁状态恢复至无锁状态，或膨胀到轻量级锁。

轻量级锁
是为了满足多线程交替执行步代码块而设置的锁。采用CAS指令和自旋来减少系统级别的互斥操作所带来的性能开销。如果有多个线程同时竞争一个锁，则会膨胀到重量级锁。

轻量级锁获取过程

轻量级锁获取代码(synchronizer.cpp)

轻量级锁的释放也是采用CAS方式进行的，首先会尝试将DisplacedMark Word替换回当前对象的Mark Word，替换成功则轻量级锁释放成功，否则，说明其他线程在尝试获取轻量级锁则膨胀只重量级锁。

重量级锁
通常锁说的互斥锁，利用操作系统的MutexLock互斥锁机制实现，通过对象内的监视器(monitor)进行加锁操作。
监视器monitor有时也被称作管程，JVM规范规定，每个对象和类在逻辑上都是和一个监视器关联。操作系统底层的MutexLock，使用操作系统的内核进行调度使线程在临界区互斥，其线程状态切换成本很高，所以称为重量级锁。

同步代码进入时，JVM底层使用指令entermonitor用来获取monitor的所有权，进行加锁。离开时，使用指令leavemonitor来释放对monitor占用，即解锁。

同步方法进入时，JVM会在方法的常量池中设置ACC_SYNCHRONIZED访问标志，并获取monitor对象，执行完毕会释放掉monitor对象，在此期间其他任何线程都无权获取这个monitor对象，处于阻塞状态。

运行过程中随着锁的竞争，偏向锁可以膨胀到轻量级锁，轻量级锁可以膨胀到重量级锁，膨胀的过程是单向的，即重量级锁不会降级到轻量级锁，轻量级锁也不会降级到偏向锁。

锁膨胀流程

synchronized 重入性

重入锁指一个线程可以多次获取自己已经持有的锁，比如一个线程在自己还没有释放锁的时候，再次进入临界区操作，如果锁不可重入，那么线程将会被自己锁死。

内置锁synchronized是一个可重入锁，即一个持有类/对象可重入锁的线程在调用本类/对象中其他synchronized方法/块或父类中的synchronized方法/块时，都不会被阻塞或者锁死。

可重入性是通过对象监视器中递归计数器(_recursion)实现的，初始值为0，表示没有线程持有锁，当有线程竞争到该锁，计数器为1，并阻塞其他线程竞争。如果持有线程再次竞争该锁时，计数器加1记录重入的次数。线程退出时，计数器会递减，值为0时释放锁。

锁重入计数器(objectMonitor.cpp)

synchronized 公平性

公平锁是指线程获得锁的顺序按照先进先出的原则进行的，即先发起锁站在的先排队的先得。非公平锁指每个线程都先要竞争锁，不管排队先后，所以后到的线程有可能无需进入等待队列直接竞争到锁。

线程饥饿是指CUP运行时间片长时间被其他线程占据而导致线程得不到CUP运行时间。公平锁不会造成线程饥饿，如果持有锁的时间较长或请求锁的平均间隔时间较长，可以考虑使用公平锁。

但是非公平锁的吞吐率是公平锁的好几倍。假如A线程持有锁，B线程请求这个锁，这时B线程会被挂起。当A线程释放锁时，B线程将会被唤醒，并尝试获取锁，于此同时C线程也在请求这个锁，有可能C线程会在B线程被唤醒之前已经使用完并释放这个锁了，所以非公平锁比公平锁的吞吐量高的原因就在于线程从被唤醒到获取锁有一定的时间延迟，非公平锁能充分利用这段延迟的时间

对象监视器代码片段(objectMonitor.hpp)

在JVM实现中，等待获取锁的线程放入等待_EntryList，_owner指向当前持有锁的线程，_owner被wait后进入阻塞队列_WaitSet，被notify后再次进入等待队列_EntryList，_owner会在解锁时从_EntryList队列头拉出一个等待线程作为备选线程，_owner会把锁竞争的权利交给备选线程，而不是直接把锁交给备选线程，备选线程能不能获取锁还得进行重新竞争，备选线程获取锁即成为_owner线程，获取不了锁则重新进入_EntryList队列等待。这就是JVM线程竞争切换机制的大致流程。

JVM线程竞争切换机制使得synchronized内置锁是一个非公平锁，也无法通过其他手段将其设置为公平锁。

小结

1、锁语义对临界区进行互斥，保障原子性，有序性，可见性
2、synchronized使用对象监视器(monitor)进行加锁操作
3、synchronized通过偏向锁、轻量级锁来提高性能，所以和它和JUC中的显式锁(ReentrantLock等)相比性能并不低
4、synchronized是可重入的非公平锁
5、当不十分确定volatile是否能保证安全的情况下，尽量选择synchronized

并发专题目录贴

码字不易，转载请保留原文连接https://www.jianshu.com/p/a4788939b81c