Synchronized

synchronized 可以用来修饰

• 方法
• 静态方法
• 对象

但其实本质就是 锁对象，修饰方法时锁 this，修饰静态方法时锁 class，当一个线程获取了一个对象的锁，那么后到的线程都需要等待锁被释放

    void synchronized syn() {...}

如上代码其实等同于如下代码

    void syn() {
        synchronized(this) {
            // ...
        }
    }

对象锁的状态大致分为四种，锁随着竞争激烈应当逐步升级，但不允许回退

• 无锁
• 偏向锁
• 轻量级锁
• 重量级锁

我们开始重点讨论 synchronized 中锁的实现以及加锁策略之前，需要明白以下概念，在 Java 对象头里的有一个字段叫 Mark Word，其中存储了对象的 HashCode，分代年龄和 锁信息，而锁信息就代表着对象加的是一把什么锁

互斥锁

每个对象拥有一个属于自己的宝贝 - monitor，它就是一把 互斥锁，占有锁时 排斥任何人

monitor 十分重量级，每个对象诞生时，monitor 会被初始化为 0

monitor 是一种可重入的，重量级的互斥锁，之所以称之为 重量级，因为其基于监视器 monitor，而 monitor 本质又依赖于底层操作系统 Mutex Lock，线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作,线程之间的切换成本非常高，应此， monitor 应当成为同步的最后一种手段

获取与释放

对应的虚拟机指令分别为 monitorenter 和 monitorexit

• monitorenter : 尝试获取该对象的锁
• monitorexit : 释放该对象锁

如果我们有一个线程试图占用对象，占用后进行一定操作 some process，之后便结束占用，那么虚拟机指令是如此执行的

    // before monitorenter ...
    monitorenter
    // try own lock of object successfully and do something ...
    monitorexit
    // after monitorexit ...

线程尝试获取一把互斥锁时，需要经过以下步骤

• 若 monitor = 0 ，线程获得一把互斥锁，并且 monitor++
• 若 线程已拥有互斥锁，仍然 monitor++
• 若 monitor != 0 并且 线程未拥有锁，挂起线程，等待锁被释放

线程释放一把互斥锁时，需要经过以下步骤

• monitorexit 后 monitor--
• monitor = 0 后，唤醒等待线程，通知锁已经被释放

自适应自旋锁

线程的阻塞、挂起和唤醒非常损耗性能，耗时比同步代码更长的情况很可能出现，如果同步代码执行本来就比较短，那为何要进行线程切换呢

自旋锁就是为解决这个问题而出现的，当线程尝试获取锁失败时，线程会自旋一段时间后，再尝试获取锁，如果失败那再挂起

自旋过程中，可以理解为等待锁被释放，自旋意思就是做其他事情等待锁被释放，你可以坐着，躺着或干啥都行

自旋性能的关键在于 自旋时长 如何决定，JVM 中采用的是一种 自适应 策略，即通过观察以往自旋时间，若通过该自旋时间后线程获取锁成功，那么下一次自旋这么久也很有可能成功，反着则反，若一直失败，则直接取消自旋会更加划算

锁撤销

当虚拟机检测到，同步的地方并没有同步价值时，编译时会撤销该锁，如下面代码块，则完全不需要同步，String 是不可变对象，完全不可能被修改

    public synchronized void print(String s) {
        System.out.println(s);
    }

锁粗化

我们平时写代码一般要求将锁细化，即只讲锁加在需要同步的地方，然后锁的获取与释放，像刚才提到的互斥锁，是非常耗性能的，因此 当可优化的多段锁出现时，会粗化该锁

    public String plus(String s1, String s2, String s3) {
        return s1 + s2 + s3;
    }

如上述语句可能并发现不了什么不得了的事情，但字符串的拼接是挺费性能的，应当使用 StringBuilder 或者 StringBuffer，虚拟机则如下优化

    public String plus(String s1, String s2, String s3) {
        StringBuffer buffer = new StringBuffer();
        buffer.append(s1);
        buffer.append(s2);
        buffer.append(s3);
        return buffer.toString();
    }

StringBuffer 是同步的，所以拼接时会上三把锁，然而一把锁的性能会更好

轻量级锁

使用重量级互斥锁时，我们应当考虑一个问题，一把互斥锁 并不是每时都在被多线程竞争，在不被竞争时，排斥锁的线程切换，就显得没那么必要了，这就是一个优化的点，所以就引入了轻量级锁

在决定使用底层操作系统的 monitor 之前，应当先考虑 轻量级锁，它不使用线程切换，但能达到同步目的

获取与释放

线程尝试获取一把轻量级锁时，需要经过以下步骤

• 若 Mark Word 无锁，则为当前栈帧开辟出一块 Lock Record 内存，并拷贝一份对象 Mark Word 信息
• 尝试将 Mark Word 指向 Lock Record （CAS）
  • 若成功，线程获得一把轻量级锁，并将 Lock Record 指向 Mark Word
  • 若失败
    • 若 Mark Word 指向 Lock Record，说明已经拥有锁
    • 若 未指向，说明存在多线程竞争，并将 Mark Word 的锁状态 由轻量级锁膨胀为重量级锁

线程释放一把轻量级锁时，需要经过以下步骤

• 尝试将 Lock Record 替换 Mark Word （CAS）
  • 若成功，正常释放
  • 若失败，说明在拥有锁的过程中，锁已经膨胀为重量级锁，则唤醒等待线程，通知锁已经被释放

在无竞争条件下，轻量级锁无需进行线程切换，只需要锁获取和释放时的两次 CAS 操作

偏向锁

使用轻量级锁时，我们应当考虑一个问题，CAS 是很消耗 CPU 的，一个对象只被一个线程访问时，不存在轻量级锁竞争，那么轻量级锁的两次 CAS 操作和内存拷贝，就显得些许多余，所以就引入了偏向锁

偏向锁是指对象偏向某个线程，即在无线程竞争条件下，该对象是属于某个线程的，一旦出现竞争，应当撤销偏向锁 并升级为轻量级锁

获取与撤销

线程尝试获取一把偏向锁时，需要经过以下步骤

• 若 Mark Word 无锁，尝试将 currentThreadId 复制到 Lock Record 与 Mark Word 中 （CAS）
  • 若成功，线程获得一把偏向锁
  • 若失败，说明存在其他线程竞争偏向锁，并撤销偏向锁

撤销偏向锁时，需等到安全点 SafePoint 再执行撤销

加锁策略

虚拟机的加锁策略，是一层一层升级的，简而言之可以如下总结

• 当竞争对象无锁时，先尝试偏向锁
• 当存在不止一个线程获取偏向锁时，应当尝试轻量级锁
• 当存在多线程竞争一个轻量级锁时，需考虑重量级锁
• 当尝试竞争重量级锁失败时，应先尝试自旋锁再考虑线程切换策略

状态转换

当线程竞争锁时，它们之间的状态转化如上图

• Contention List：竞争队列
• Entry List：有资格成为候选人的竞争队列
• OnDeck：锁候选人
• Owner：锁持有者
• Wait Set：线程等待池

与 synchronized 配套使用的 wait / notify / notifyAll，下面我们来探讨它们是如何实现的

• wait ： 释放锁，进入等待池
• notify ： 从等待池中挑选一名同学再次参与竞争
• notifyAll ： 等待池全部恢复竞争

参考

1. 《深入理解Java虚拟机》
2. 《Java并发编程实战》
3. 《Java并发编程艺术》