- 修饰非静态成员: 例如修饰this代码块,非静态方法等使用的是this锁,调用进入同步区域时就必须先获得对象锁。如果此对象的对象锁已被其他调用者占用，则需要等待此锁被释放,java的所有对象都含有一个互斥锁，这个锁由jvm自动获取和释放.synchronized方法正常返回或者抛异常而终止，jvm会自动释放对象锁。这里也体现了用synchronized来加锁的一个好处，即 ：方法抛异常的时候，锁仍然可以由jvm来自动释放
- 修饰静态成员: 例如修饰class,静态代码块,静态方法等不论被实例化多少次，其中的静态方法和静态变量在内存中都只有一份。所以，一旦一个静态的方法被声明为synchronized。此类所有的实例对象在调用此方法，共用同一把锁，我们称之为类锁, 对象锁是用来控制实例方法之间的同步，而类锁是用来控制静态方法（或者静态变量互斥体）之间的同步的。类锁只是一个概念上的东西，并不是真实存在的，他只是用来帮助我们理解锁定实例方法和静态方法的区别的。java类可能会有很多对象，但是只有一个Class(字节码)对象，也就是说类的不同实例之间共享该类的Class对象。Class对象其实也仅仅是1个java对象，只不过有点特殊而已。由于每个java对象都有1个互斥锁，而类的静态方法是需要Class对象。所以所谓的类锁，只不过是Class对象的锁而已。获取类的Class对象的方法有好几种，最简单的是[类名.class]的方式
- javap -c 需要反编译的类名.class
- 如果需要查看更多信息使用" javap -v XXX.class" 会输出包括行号,本地变量表等详细信息
public class SynchronizedTest {
private Object objLock = new Object();
public void method1(){
synchronized (objLock) {
System.out.println("执行");
}
}
public static void main(String[] args) {
}
}
public class SynchronizedTest {
private Object objLock = new Object();
public synchronized void method() {
System.out.println("执行");
}
public static synchronized void method2() {
System.out.println("静态同步方法");
}
public static void main(String[] args) {
}
}
使用synchronized修饰方法实现锁原理: 与同步代码块不同,在执行调用指令时通过判断调用的方法是否被"ACC_SYNCHRONIZED"标识,如果有,执行线程会先持有monitor,然后再执行方法,方法执行完成释放monitor(无论方法正常或是异常都会释放),并且同步静态方法也是该方式与非同步方法比只是多了一个"ACC_STATIC"静态标识
- 同步一段指令序列(同步代码块): 在对象头的"mark_word"中设置"monitorenter"指令表示加锁,"monitorexit"指令表示释放锁,正常情况下一个monitorenter对应两个monitorexit,防止执行的代码块中发生异常锁无法释放,当代码块中手动抛出异常时,一个monitorexit对应一个monitorexit, 将异常释放放到了在异常抛到同步方法的边界之外时自动释放
- 方法级同步(同步方法): 是隐式同步,无序通过字节指令来控制,虚拟机通过判断方法常量池中该方法的表结构中是否有"ACC_SYNCHRONIZED"标志来判断这个方法是否是同步方法,如果是执行线程会先成功持有管程,然后才去执行方法,在执行期间其它线程无法获取同一个管程,如果该方法执行中抛出异常,那这个方法持有的管程将在异常抛到同步方法的边界之外时自动释放
//结构体如下
ObjectMonitor::ObjectMonitor() {
_header = NULL;
_count = 0;
_waiters = 0,
_recursions = 0; //线程的重入次数
_object = NULL;
_owner = NULL; //标识拥有该monitor的线程
_WaitSet = NULL; //等待线程组成的双向循环链表，_WaitSet是第一个节点
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ; //多线程竞争锁进入时的单向链表
FreeNext = NULL ;
_EntryList = NULL ; //_owner从该双向循环链表中唤醒线程结点，_EntryList是第一个节点
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>
import org.openjdk.jol.info.ClassLayout;
public class MyObject {
public static void main(String[] args) {
Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
- 锁是通过对象头中的"mark_word"实现,在查看对象头信息时值关注前两行"mark_word"部分即可
- 通过"ClassLayout.parseInstance(“对象”).toPrintable()"查看输出对象头信息VALUE下括号中的数子编码时,输出的数字编码是二进制的,要从后向前看
- VALUE 下括号中的是二进制数据,括号前面是对应括号中的十六进制数据
- 在前面我们学习对象头时,已经了解到创建对象后每个对象都有它对应的hashCode,为什么此处没有,因为hashCode是调用获取时才会生成,否则不会生成
import org.openjdk.jol.info.ClassLayout;
public class MyObject {
public static void main(String[] args) {
Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
- 判断对象头中偏向锁偏向当前线程: 不需要再次尝试获取锁,直接进入同步代码,并且不需要加锁释放锁时通过CAS更新对象头,几乎没有性能消耗
- 判断对象头中不是当前线程ID: 说明发送了竞争,然后进行重偏向,或升级变为轻量级锁操作
public static void main(String[] args) {
Object o = new Object();
new Thread(() -> {
synchronized (o) {
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}, "t5").start();
}
- 情况一: 第一个线程正在执行synchronized方法(处于同步块)还未执行完毕,此时其它线程进来争夺线程,该偏向锁会被取消,升级为轻量级锁,轻量级锁由原持有偏向锁的线程持有,从安全点继续执行同步代码,后面进来的竞争线程会进入自旋等待升级为轻量级锁的线程执行完毕释放,获取到该锁
- 情况二: 第一个线程执行完毕,第二个线程进来判断对象头MarkWord中线程指针不是当前线程的,会将对象头设置成无锁状态并撤销偏向锁,然后进行重偏向
- (什么是全局安全点STW=stop the world 虚拟机相关有解释)
- 当一个对象已经调用默认 hashCode() 或者 System.identityHashCode()，即计算过 identity hashcode 后，它就无法进入偏向锁状态。这意味着，如果要在不发生争用的对象上进行同步，则最好覆盖默认hashCode()实现，否则JVM不会优化。
- 当一个对象当前正处于偏向锁状态,需要计算 identity hashCode 的话,则它的偏向锁会被撤销,并且锁会膨胀为轻量级锁或者重量锁；
- 轻量级锁的实现中，会通过线程栈帧的锁记录存储 Displaced Mark Word；
- 重量锁的实现中，ObjectMonitor 类里有字段可以记录非加锁状态下的 mark word，其中可以存储 identity hash code 的值。
public static void main(String[] args) {
Object o = new Object();
new Thread(() -> {
synchronized (o) {
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}, "t5").start();
}
//外部声明了一个锁对象
private static Object lock = new Object();
//而m1方法内部会new出来新的锁对象
//此时m1每执行一次都会新建一个锁对象
//synchronized锁的各自的新的对象,会出现锁不住的情况
public void m1(){
Object lock = new Object();
synchronized (lock) {
}
}
//声明锁对象
private static Object lock = new Object();
public void m1(){
//在t1线程中多次获取同一把锁lock
new Thread(()->{
synchronized (lock) {
System.out.println("11111");
}
synchronized (lock) {
System.out.println("2222");
}
synchronized (lock) {
System.out.println("3333");
}
synchronized (lock) {
System.out.println("4444");
}
synchronized (lock) {
System.out.println("5555");
}
},"t").start();
}
//优化后可看为是下方
public void m2() {
//在t1线程中多次获取同一把锁lock
new Thread(() -> {
synchronized (lock) {
System.out.println("11111");
System.out.println("2222");
System.out.println("3333");
System.out.println("4444");
System.out.println("5555");
}
}, "t").start();
}
- 对象布局: 对象在堆内存中,存储布局可划分为三个部分:对象头Header, 实例数据Instance Data, 和对齐填充Padding,其中对象头内部是由对象标记MarkWord, 类型指针Class Pointer(又叫类元信息klass pointer) 两部分组成,对象标记MarkWord中用"31bit” 存储对象的哈希码,“4bit” 存储对象分代年龄,"1bit"用来标记是否偏向锁,再未获取对象hashCode时,有54bit存储偏向锁的线程id,等信息
- 管程: 在java中所有类都继承自Object,每个object的对象里 markOop->monitor() 里可以保存ObjectMonitor的对象,这个ObjectMonitor就是指管程monitor对象,在ObjectMonitor有几个需要关注的属性:
- _owner: 持有ObjectMonitor对象线程
- _WaitSet: 存放处于wait状态的线程队列
- _EntryList: 存放处于等等锁block状态的线程队列
- _recursions: 锁的重入次数
- _count: 记录该线程获取锁的次数
- 当多个线程同时访问一段同步代码时：
- 首先会进入_EntryList集合，当线程获取到对象的monitor后，进入_owner区域并把monitor中的owner变量设置为当前线程，同时monitor中的计数器count加1；
- 若线程调用wait()方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入WaitSet集合中等待被唤醒；
- 当前线程执行完毕，也将释放monitor（锁）并复位count的值，以便其他线程进入获取monitor（锁）；
- 同时，Monitor对象存在于每个Java对象的对象头Mark Word中（存储的指针的指向），Synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时notify/notifyAll/wait等方法会使用到Monitor锁对象，所以必须在同步代码块中使用。
监视器可以确保监视器上的数据在同一时刻只会有一个线程在访问，锁状态是被记录在每个对象的对象头（Mark Word）中，下面我们一起认识认识一下对象的内存布局
- 底层在对象头的"mark_word"中设置"monitorenter"指令表示加锁,"monitorexit"指令表示释放锁
- 通常情况下一个monitorenter加锁命令会对应两个monitorexit释放锁指令,防止代码发生异常时锁无法释放
- monitorenter与monitorexit 不是成对出现的那么monitorexit 一定会是两个吗?: 不一定,假设示例代码的method1()方法中我们手动抛出异常,再去对该class进行反编译,就会发现只出现了一个monitorenter对应一个monitorexit,并且会伴随两个athrow
与同步代码块不同,在执行调用指令时通过判断调用的方法是否被"ACC_SYNCHRONIZED"标识,如果有,执行线程会先持有monitor,然后再执行方法,方法执行完成释放monitor(无论方法正常或是异常都会释放),并且同步静态方法也是该方式与非同步方法比只是多了一个"ACC_STATIC"静态标识
- 偏向锁的优点: 偏向锁的操作不涉及用户态到内核态的切换,同一个线程时不需要多次释放与获取锁,不存在CAS修改MarkWord线程指针, 加锁线程执行完毕后,不会主动释放锁
- 获取偏向锁流程: 当线程执行被synchronized修饰的代码时,会在对象头MarkWord中标记为偏向锁状态,并使用54位存储线程指针作为偏向线程标识,当再次获取锁时首先判断线程id与MarkWord中存储的是否一致
- 一致: 不需要再次尝试获取锁,直接进入同步代码,并且不需要加锁释放锁时通过CAS更新对象头,几乎没有性能消耗
- 不一致: 说明发送了竞争,JVM进行CAS操作修改MarkWord存储的线程指针为当前线程进行重偏向,或执行偏向锁锁撤销
- 偏向锁锁撤销: 如果CAS修改失败说明锁已经被其它线程获取,这时将阻塞,撤销偏向锁,撤销需要等待到全局安全点,同时检查持有偏向锁的线程是否还在执行(两种情况)
- 锁被其它线程获取还未执行完毕,此时其它线程进来争夺线程,该偏向锁会被取消,升级为轻量级锁,轻量级锁由原持有偏向锁的线程持有,从安全点继续执行同步代码,后面进来的竞争线程会进入自旋等待升级为轻量级锁的线程执行完毕释放,获取到该锁
- 前面获取锁线程执行完毕,当前线程进来判断对象头MarkWord中线程指针不是当前线程的,会将对象头设置成无锁状态并撤销偏向锁,然后进行重偏向
- 偏向锁还有一个注意点: 偏向锁与hashCode, 偏向锁是由对象头中的MarkWord中存储偏向线程id来实现的,如果一个对象获取了hashCode,会造成对象头中无法存储偏向线程id,或获取偏向锁后,执行hashcode将对象头中记录的偏向线程id给覆盖了, HotSpot VM 规定
- 当一个对象执行 hashCode() 或System.identityHashCode()，计算了 hashcode 后,则无法进入偏向锁状态。这意味着，如果要在不发生争用的对象上进行同步，则最好覆盖默认hashCode()实现，否则JVM不会优化。
- 当一个对象当前正处于偏向锁状态,需要计算 identity hashCode 的话,则它的偏向锁会被撤销,并且锁会膨胀为轻量级锁或者重量锁；
- 轻量级锁的实现中，会通过线程栈帧的锁记录存储 Displaced Mark Word；
- 重量锁的实现中，ObjectMonitor 类里有字段可以记录非加锁状态下的 mark word，其中可以存储 identity hash code 的值。
- 返回头来再说一下为什么要有偏向锁:在我们测试多线程并发争抢锁时,由于CPU调度问题会发现有有几个线程获取锁的概率始终比较高,也就是会出现饥饿,根据这一特性同一个线程,直接进入同步代码没有性能消耗, 然后再说一下如何解决锁饥饿,例如JUC下的ReentrantLock公平锁
- 先举个例子: 假设AB两个线程执行, A线程先获取到锁,后续B线程执行判断MarkWord中的线程指针不是当前B线程的,此时B线程CAS尝试获取锁,有两种情况: B线程CAS成功将MarkWord中的线程指针修改为当前线程说明获取偏向锁成功,并重偏向与当前线程,情况二如果CAS修改MarkWord失败,则偏向锁升级为轻量级锁,并且由原持有偏向锁的线程持有,此时B线程就会进入自旋等待A线程执行完毕释放轻量级锁
- 轻量级锁每次退出同步块时都需要释放锁,
- 上面说到过假设两个线程竞争执行同步代码块,A线程还未执行完毕,此时B线程会在外面CAS等待,假如说A线程始终不释放锁,这时候B线程一直在外面CAS会销毁大量CPU资源,假如A线程不释放接着进来了B,C,D等多个线程呢,防止这个问题,轻量级锁设置了自旋的次数,与竞争线程数规定,当超过这个次数轻量级锁将不再自旋,升级为重量级锁
- java6前: 自旋线程数,自旋次数限制默认开启:默认自旋次数10次,或自旋线程数超过cpu核的一半会放弃自旋升级为重量级锁, java6后: 底层根据同一个锁上一次自旋的时间,拥有锁线程的状态来决定的