阿里面试官:你好,谈谈对 Synchronized 的理解?(一
}
public void increase3(){
synchronized (LOCK){
i++;
}
}
}
#increase1
方法表示的是修饰静态方法;#increase2
方法表示的是修饰实例方法;#increase1
方法表示的是修饰代码块。
synchronized
始终与对象关联。如果方法是静态的,那么关联的对象就是类;如果该方法是非静态的,则关联的对象是实例。如果是代码块,那么就是指定的对象。很显然,锁是记录于对象中。那么问题来了,synchronized
的锁具体指的是什么呢?简单理解锁就是一个共享的资源,记录了谁占有它,当前状态是什么等等。我们先来分析对象在内存中是如何存储的。
在Hotspot JVM
中,Java Object
对象在内存中存储中的存储布局分为三个区域,分别是对象头、示例数据、对象填充。如图所示,数组和对象的存储布局十分相似,只是对象的头部大于数组的长度,因为数组需要存储自身的长度,为 4Byte。
从图上可以看出,对象头部包括两部分,分别是对象标记和类元信息(类型指针)。对象标记,也就是Markword
存储对象的 hashCode
、 GC
信息和锁等信息。类元信息存储“类对象信息的指针”。在 32 位的 JVM
中,对象头占用 8 个 byte,另外在 64 位的 JVM
占用 16 个字节。
如上图所示,这个是Markword
类在 32 位的 JVM
的各种情况存储布局,Markword
里面存储的数据会随着锁标志位的变为而变化,大致存储的变化共分为五种情况。我们可以从图上看到从无锁->偏向锁->轻量级锁->重量级锁存储的变化过程,这个就是锁升级的过程。
那么问题来了,是不是所有的对象都能实现锁呢?答案是肯定的。
首先我们对于
Java
有一个共有的认知,那就是所以的对象都派生自Object
,每个 Object 在内存中存储都如我们图上所示的,都有对象头,对象头中有Markword
对象标记。 需要注意的是,对象存储包括Markword
对象标记的实现都是native
的,都是C++
语言实现的对象。线程在获取锁时,实际获取的是一个监视器(monitor)对象,这是一个同步对象,所有的
Java Object
都包含这个对象。同样的,这个对象也是native
的。
Java 1.6
之前,synchronized
是标准的重量级锁,多个线程竞争共享资源时,未竞争到资源的线程会一直处于阻塞状态,性能开销很大,同时对于重量级锁,对于加锁和释放锁也有很多的资源消耗。为了减少性能开销,提升效率,人们针对不同的加锁场景,细分了四种锁状态,包括无锁、偏向锁、轻量级锁,重量级锁,锁的状态会根据线程竞争资源的激烈程度从低到高不断升级。
4.1 偏向锁
很多时候,锁总是被同一线程多次获取,并没有线程竞争锁。对于这样的情况,偏向锁就很适用,那到底什么时候偏向锁呢?在第三章节,我们列出了在synchronized
不同的锁状态下,Markword
内存布局有很大的差异。
4.1.1 偏向锁获取
当一个线程去访问synchronized
关键字修饰的代码块或方法时,会在Markword
中存储当前线程的 ID,当再有线程想尝试进入同步块时,会先通过CAS
比较当前Markword
存储的线程 ID 是否为尝试进入同步块的线程 ID,如果相等,不需要再次获取锁了,可直接执行同步代码块;如果不相等,说明当前偏向锁是偏向于其它线程,需要撤销偏向锁,然后将锁升级成轻量级锁。
4.1.2 偏向锁撤销
撤销偏向锁并不是将锁真正的撤销,成为无锁的状态。对于偏向锁的撤销,对原持有的线程和锁本身有两种情况。
如果原持有
线程刚好执行完了,退出同步代码块,那么这个时候会把Markword
保存的线程 ID 设置为空。
如果原持有线程仍在同步代码块中执行,这个时候偏向锁会升级为轻量级锁,然后原有线程继续执行。
下面图演示在synchronized
修饰的同步代码块下,线程 T1 和线程 T2 先后竞争锁资源的流程。
4.2 轻量级锁
上一小节说到了两个线程竞争锁,导致偏向锁的撤销,撤销过程中有一种常见的锁升级,即升级成轻量级锁。轻量级锁适用于两个线程竞争锁资源,并且同步代码块执行很快的场景。那在对象中的Markword
存储布局有变化成什么呢?
4.2.1 轻量级升级过程
众所周知,在JVM
中,栈是线程私有的。升级成轻量级锁的第一步是在栈的栈帧中搞事情。
栈帧新创建锁记录
LockRecord
,记录中包括displaced hdr
和owner
。将锁对象头中的
Markword
内容复制到刚创建的栈帧中LockRecord
。将锁记录
LockRecord
中的 owner 指向锁对象。最后将对象头的
Markword
中的指向栈中锁记录的指针指向锁记录LockRecord
(这个步骤才是Markword
存储内容真正的变化)。
变化过程如下图所示。
4.2.2 轻量级竞争过程
当一个线程占有轻量级锁时,当另一个线程来竞争时,这个线程会在原地空循环等待,而不是将线程状态转变为Blocked
阻塞态。当占有的线程离开同步块,释放锁以后,另外一个线程就会迅速的获取到锁。
那么为什么未获取到锁资源的线程是循环等待,而不是阻塞呢? 这其中最重要的原因是线程的阻塞和唤醒需要CPU
从用户态转为内核态,频繁的阻塞和唤醒对 CPU 来说是一件负担相当重的工作,势必会给操作系统的并发性能带来非常大的压力。所以采取了循环去等待,这就是自旋锁,这种方式在AQS
锁底层也用到了。
那么未获取到锁资源的线程是如何循环等待的呢? 不停的循环会消耗CPU
性能,这种自旋锁当然是有停止条件的,分为两种情况。
在
Java 1.6
之前,设定了一个自旋的次数,超过循环次数就会循环就会终止,一般设置的次数是 10,可以通过设置HotSpot 参数 -XX:PreBlockSpin
来修改,修改这个参数之前需通先通过设置参数-XX:+UseSpining
开启自旋锁。在
Java 1.6
之后,引入了相较于智能的自适应自旋锁,这种方式是根据前一次在同样的锁自选的时间和锁的状态决定锁的自选时间,而不是固定自旋次数。
4.2.3 自旋锁锁释放
当未获取到锁资源的线程,自旋获取锁失败了,此时会将锁升级成重量级锁,并修改锁对象头的Markword
中的值,修改的内容大致为指向重量级锁的指针和修改锁标志位为 10。 此时线程处于阻塞的状态。
当占有锁的退出同步代码块时,会通过CAS
将栈中存储记录的Markword
内容和当前锁对象Markword
比较然后设值,因为当前Markword
内容已经变化了,肯定会设值失败,此时线程会释放锁,释放监视器(monitor)并唤醒等待的线程。然后另一个被阻塞的线程被唤醒,重新竞争锁资源。
评论