JUC并发编程第十一章——Synchronized与锁升级

1 入门知识介绍

1.1 面试题

谈谈你对Synchronized的理解
请你聊聊Synchronized的锁升级

1.2 本章路线总纲

1.2.1 锁使用的强制要求

【强制】高并发时，同步调用应该去考量锁的性能损耗，能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。

说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。

synchronized锁优化的背景

用锁能够实现数据的安全性，但是会带来性能下降。

无锁能够基于现成并行提升程序性能，但是会带来安全性下降

那么如何求平衡？
锁的升级过程

无锁-偏向锁-轻量级锁-重量级锁(锁的范围一点一点变大，还是上面那句话，尽可能锁的范围小)

1.2.2 synchronized锁：由对象头重的Mark Word根据锁标志位的不同而被复用及锁升级策略

2 Synchronized的性能变化

java5以前，只有Synchronized，这个是操作系统级别的重量级操作

重量级锁，假如锁的竞争比较激烈的话，性能下降

Java5之前，用户态和内核态之间的切换

(我们写一个new Thread().start()的话是调用了底层的native方法的）

java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在用户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock(系统互斥量)来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁

（一句话就是尽量减少用户态和内核态的切换）

为什么每一个对象都可以成为一个锁-复习之前的知识

markOop.hpp

我们大概可以知道，每个对象都有一个ObjectMonitor，而每个ObjectMonitor都可以成为锁。

小结：我们说在java中每个对象都可以成为一把锁，因为在JVM中每个对象都一个monitor(监视器锁。对应到C底层叫做Object Monitor，并用c定义了很多信息。再往下到操作系统中是基于Mutex Lock互斥锁实现，涉及到了用户态和内核态的切换，所以非常耗费资源。

结合之前的synchronized和对象头说明

主要就是MarkWord中是什么代码表示了它是什么锁状态

从图中可以看出，如果当前锁对象是重量级锁，它底层还会有ObjectMonitor，保存了很多锁的相关信息。

3 Synchronized锁种类及升级步骤

3.1 多线程访问情况

只有一个线程来访问，有且唯一Only One
有两个线程（2个线程交替访问）
竞争激烈，更多线程来访问

不同线程访问情况，有着不同锁解决问题。

3.2 升级流程

Synchronized用的锁是存在Java对象头里的MarkWord中，锁升级功能主要依赖MarkWord中锁标志位和释放偏向锁标志位

重点关注【偏向锁位】和【锁标志位】

锁指向总结，请牢记

偏向锁：MarkWord存储的是偏向的线程ID；
轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针；
重量锁：MarkWord存储的是指向堆中的monitor对象的指针；

3.3 无锁

复习C源码的MarkWord标记

我们知道，一个对象只是创建出来，它是无锁状态的。无锁状态的MarkWord标记占8字节，也就是64位。其中：25位是没有使用的 (unused)，31位存放了hashcode (hash)，1位未使用，4位是分代年龄 (age 4位二进制最大就是1111，十进制就是15，因此分代年龄最大15)，1位偏向锁位 (biased lock)，2位锁标识位 (normal lock)。25 + 31 + 1 + 4 + 1 + 2 = 64位(8字节)

Code1

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo {

    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }

}

输出结果：
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

提出疑问

以上Code1就是new一个对象，对应64位对象标记图的无锁态！

hashCode对应的是哪31位，为什么都是0？
前8个字节（64位）的对象标记应该正着看还是倒着看？

Code2

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedUpDemo {

    public static void main(String[] args) {
        Object o = new Object();

        System.out.println("10进制：" + o.hashCode());
        System.out.println("16进制：" + Integer.toHexString(o.hashCode()));
        System.out.println("2进制：" + Integer.toBinaryString(o.hashCode()));

        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }

}

输出结果：
10进制：529116035
16进制：1f89ab83
2进制：11111100010011010101110000011
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 83 ab 89 (00000001 10000011 10101011 10001001) (-1985248511)
      4     4        (object header)                           1f 00 00 00 (00011111 00000000 00000000 00000000) (31)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

解答疑问

1.可以看到调用了hashCode()方法后，对象标记打印出了对象的hashCode，所以默认是不打印hashCode的，需要调用对象的hashCode()方法才会打印

2.倒着看的，且每8位正着看，可以看到16进制hashCode刚好对应倒着看的对象标记的31位的hashCode（1f89ab83）

二进制验证
二进制：11111100010011010101110000011
对应对象标记：00011111 10001001 10101011 10000011 ——>（第一位未使用）——>

0011111 10001001 10101011 10000011 ——> 11111 10001001 10101011 10000011 (二进制打印结果)
3.另外，无锁态的对象标志对应这里的具体如下：

程序不会有锁得竞争

无锁：初始状态，一个对象被实例化后，如果还没有被任何线程竞争锁，那么它就为无锁状态（001）

3.4 偏锁

3.4.1 偏向锁：单线程竞争

当线程A第一次竞争到锁时，通过修改Mark Word中的偏向线程ID、偏向模式。如果不存在其他线程竞争，那么持有偏向锁的线程将永远不需要进行同步

主要作用
当一段同步代码一直被同一个线程多次访问，由于只有一个线程那么该线程在后续访问时便会自动获得锁。

例如：同一个老顾客来访，直接老规矩行方便

多线程卖票案例

public class SaleTicketDemo {

    public static void main(String[] args) {
        Ticket ticket = new Ticket();

        new Thread(() -> {
            for (int i = 0; i < 55; i++) {
                ticket.sale();
            }
        }, "a").start();
        new Thread(() -> {
            for (int i = 0; i < 55; i++) {
                ticket.sale();
            }
        }, "b").start();
        new Thread(() -> {
            for (int i = 0; i < 55; i++) {
                ticket.sale();
            }
        }, "c").start();
    }

}

class Ticket {

    private int number = 50;

    Object lockObject = new Object();

    public void sale() {
        synchronized (lockObject) {
            if (number > 0) {
                System.out.println(Thread.currentThread().getName() + "卖出第：\t" + (number--) + "\t 还剩下：" + number);
            }
        }
    }

}

输出结果：
a卖出第：	50	 还剩下：49
a卖出第：	49	 还剩下：48
a卖出第：	48	 还剩下：47
a卖出第：	47	 还剩下：46
a卖出第：	46	 还剩下：45
a卖出第：	45	 还剩下：44
b卖出第：	44	 还剩下：43
b卖出第：	43	 还剩下：42
b卖出第：	42	 还剩下：41
a卖出第：	41	 还剩下：40
a卖出第：	40	 还剩下：39
a卖出第：	39	 还剩下：38
a卖出第：	38	 还剩下：37
a卖出第：	37	 还剩下：36
a卖出第：	36	 还剩下：35
a卖出第：	35	 还剩下：34
a卖出第：	34	 还剩下：33
a卖出第：	33	 还剩下：32
a卖出第：	32	 还剩下：31
a卖出第：	31	 还剩下：30
a卖出第：	30	 还剩下：29
a卖出第：	29	 还剩下：28
a卖出第：	28	 还剩下：27
a卖出第：	27	 还剩下：26
a卖出第：	26	 还剩下：25
a卖出第：	25	 还剩下：24
a卖出第：	24	 还剩下：23
a卖出第：	23	 还剩下：22
a卖出第：	22	 还剩下：21
a卖出第：	21	 还剩下：20
a卖出第：	20	 还剩下：19
a卖出第：	19	 还剩下：18
a卖出第：	18	 还剩下：17
a卖出第：	17	 还剩下：16
a卖出第：	16	 还剩下：15
a卖出第：	15	 还剩下：14
a卖出第：	14	 还剩下：13
a卖出第：	13	 还剩下：12
a卖出第：	12	 还剩下：11
a卖出第：	11	 还剩下：10
a卖出第：	10	 还剩下：9
a卖出第：	9	 还剩下：8
a卖出第：	8	 还剩下：7
a卖出第：	7	 还剩下：6
a卖出第：	6	 还剩下：5
a卖出第：	5	 还剩下：4
a卖出第：	4	 还剩下：3
a卖出第：	3	 还剩下：2
a卖出第：	2	 还剩下：1
a卖出第：	1	 还剩下：0

从运行结果可以看出：大部分情况下都是某一个线程进入同步代码块。这样大大减少了用户态切换到内核态的次数 (synchronized锁是重量级锁，设计底层操作系统，会从用户态切换为内核态。而通过偏锁优化以后，同一个线程再次进入该同步代码块时，不需要再次加锁和释放锁)！提高程序性能！

结论
HotSpot的作者经过研究发现，大多数情况下：

在多线程情况下，锁不仅不存在多线程竞争，还存在由同一个线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有一个线程执行同步时提高性能。

偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他线程访问，则持有偏向锁的线程将永远不需要触发同步。也即偏向锁在资源在没有竞争情况下消除了同步语句，懒得连CAS操作都不做了，直接提高程序性能。

3.4.2 偏向锁的持有

理论落地：

在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。

那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁(后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接会去检查锁的MarkWord里面是不是放的自己的线程ID)。

判断当前线程ID和偏向锁记录的ID是否相等：

1.如果相等，表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程[D与当前线程1D是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。

2.如果不等，表示发生了竞争，锁己经不是总是偏向于同一个线程了，这个时候会尝试使用CAS来替换MarkWord里面的线程ID为新线程的ID，

竞争成功，表示之前的线程不存在了，MarkWord里面的线程1D为新线程的ID，锁不会升级，仍然为偏向锁；
竞争失败，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。

注意，偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。技术实现：

一个synchronized方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位，同时还会占用前54位来存储县城指针作为标识。若该线程再次访问同一个synchronized方法时，该线程只需要去对象头的Mark Word中去判断一下是否有偏向锁指向本身的ID，无需再进入Monitor去竞争对象了。

偏向锁用54位存放线程指针以确定是哪个线程占有了锁。

3.4.3 细化Account对象举例说明

结论：JVM不用和操作系统协商设置Mutex（争取内核，内核态的切换），它只需要记录下线程ID就标识自己获得了当前锁，不用操作系统接入。

偏向锁的操作不用直接捅到操作系统，不涉及用户到内核转换，不必要直接升级为最高级，我们以一个account对象的“对象头”为例

假如有一个线程执行到synchronized代码块的时候，JVM使用CAS操作把线程指针ID记录到Mark Word当中，并修改偏向锁位，标识当前线程就获得该锁，锁对象变成偏向锁（通过CAS修改对象头里的锁标志位），字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。

这时线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己（持有锁的线程ID也在对象头里）。JVM通过account对象的Mark Word判断：当前线程ID还在，说明还持有着这个对象的锁，就可以继续进入临界区工作。由于之前没有释放锁，这里也就不需要重新加锁。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。

结论：JVM不用和操作系统协商设置Mutex（争取内核），它只需要记录下线程ID就表示自己获得了当前锁，不用操作系统介入

上述就是偏向锁：在没有其它线程竞争的时候，一直偏向当前线程，当前线程可以一直执行