网站建设和网络营销区别,企业软件定制开发,手机营销网站模板,无代码快速搭建网站1.JVM是如何处理和识别Synchronized的#xff1f;
我们从字节码角度分析synchronized的实现#xff1a; Synchronized(锁对象){}同步代码块底层实现方式是monitorenter和monitorexit指令。 修饰普通同步方法时底层实现方式是执行指令会检查方法是否设置ACC_SYNCHRONIZED
我们从字节码角度分析synchronized的实现 Synchronized(锁对象){}同步代码块底层实现方式是monitorenter和monitorexit指令。 修饰普通同步方法时底层实现方式是执行指令会检查方法是否设置ACC_SYNCHRONIZED如果设置了则会先持有monitor锁(其实就是管程锁对象)然后在执行方法最后释放锁(无论方法执行完或出现异常)。 修饰静态同步方法时底层实现方式是执行指令会检查方法是否同时设置ACC_STATIC和ACC_SYNCHRONIZEDACC_STATIC也用于分辨锁是类锁还是对象锁。
2.为什么任何一个类的对象都可以成为锁对象 在HotSpot虚拟机中监视器monitor采用的是ObjectMonitor实现的在Java中Object是每个类的父类所以每个对象天生都带着一个对象监视器。在ObjectMonitor.java源代码中我们发现里面调用了objectMonitor.cpp文件在objectMonitor.cpp里面又调用了ObjectMonitor.hpp而在hpp文件中很明确的记录了正在持有此锁的线程、锁的重入次数等数据。 3.Synchronized锁的升级
Synchronized锁的状态主要依赖对象头中的MarkWord中锁标志位和偏向锁位。 3.1下面我们就表述锁升级的过程(重点) 初始状态下一个对象被实例化后如果还没有任何线程使用此锁那么它就为无锁状态(偏向锁位为0锁标志位为01)当线程A第一次占用此锁时MarkWord中会记录线程A的线程id然后升级为偏向锁(偏向锁位为1锁标志位为01)然后下一个线程访问时会看MarkWord中记录的线程id是否和访问的线程一致如果一致就相当于还是线程A一直在访问那么就会自动的获取锁无需每次CAS去更新对象头但是如果发现线程的id不一致那么就发生了竞争比如线程B来访问了发现MarkWord中记录的线程id和自己的不一致那么就会尝试使用CAS来替换MarkWord里面的线程id为自己线程B的线程id如果修改竞争成功了那么okMarkWord里面的线程idA更换为线程B的id锁不会升级还是偏向锁但是如果线程B修改竞争失败那么锁的状态就需要发生改变了首先就是要先撤销偏向锁先等待全局的安全点(STW)同时检查正持有偏向锁的线程A执行到哪里了如果说线程A正在处于同步代码块中相当于线程A还没有执行完那么会将锁升级为轻量锁(偏向锁位为0锁标志位为00)线程A继续执行同步代码块而正在竞争的线程B会自动进行自旋。但如果说线程A刚好执行完同步代码块此时会设置为无锁的状态线程AB会同时开始竞争。如下图 假如此时锁升级为了轻量级锁JVM会在每个线程的栈帧中创建用于存储锁记录的空间(Displaced Mark Word)若此时线程A想要获取轻量级锁会把锁对象的MarkWord拷贝复制到自己的DMW里面然后线程A再尝试利用CAS将锁对象中的MarkWord中的指向记录改为指向线程A栈中的Lock Record的指针此时如果线程A的CAS失败了就说明线程B正在占用此锁线程A就会通过不断自旋来获取锁等到线程B执行完后线程B还要将轻量级锁释放线程B使用CAS操作将DMW的内容重新复制回锁对象的Mark Word里面。如果此时有大量的线程涌入参与竞争一个线程自旋到一定的次数锁就会会升级为重量级锁(偏向锁位为0锁标志位为10)没拿到锁的线程会等待操作系统的调动就不在主动的去抢占获取锁了。具体这个自旋次数在Java8之后是自适应自旋锁。 线程如果自旋成功了那下次自旋的最大次数会增加因为JVM认为既然上次成功了那么这一次也大概率会成功 如果很少会自选成功那么下次会减少自旋的次数甚至不自旋避免CPU空转。
3.2几个需要说明的小问题
1.JDK15废除了偏向锁
JDK15以后逐步废弃偏向锁需要手动开启-------因为维护成本高。
2.MarkWord中指向记录在不同状态的指向不同 偏向锁MarkWord存储的是偏向的线程ID 轻量锁MarkWord存储的是指向线程栈中Lock Record的指针 重量锁MarkWord存储的是指向堆中锁的Monitor(监视器)对象修改里面的owner来实现。
3.无锁会默认到偏向锁
实际上无锁是默认会自动升级为偏向锁的但是启动时间有延迟可以通过添加参数让其在程序启动时立即启动。
4.锁升级后hashcode去哪里了
我们可以发现hashcode值的位置和锁指向的内存位置会冲突那么内部是怎么解决的呢—— 在无锁的状态下对象的hashcode()值存储在Mark Word中此时它就再也无法进入到偏向锁状态了。 如果已经在偏向锁状态下才调用hashcode()方法偏向锁的状态会被立即取消锁会膨胀为重量级锁。 在轻量级锁状态下会在DMW中保存拷贝的Mark Word的值释放锁后会将这些信息重新写回到对象头的Mark Word中(相当于覆盖了)。 ObjectMonitor类里面有字段会记录非加锁状态下的Mark Word锁释放后也会重新写回到对象头中的Mark Word中。
3.3JIT编译器对锁的优化
JIT对锁的优化分为锁消除和锁粗化其实这两个概念挺乏味的。
3.3.1锁消除
简单来说就是如果每个线程都拥有一把锁那么我们写的加锁代码就毫无意义了从JIT角度来看就是无视它了消除了对锁的使用。示例代码
public class LockClearUpDemo {static Object object new Object();public void m1() {//锁消除问题JIT会无视它synchronized(o)每次new出来的加锁就无意义了Object o new Object();synchronized (o) {System.out.println(-----------hello LockClearUpDemo \t o.hashCode() \t object.hashCode());}}public static void main(String[] args) {LockClearUpDemo lockClearUpDemo new LockClearUpDemo();for (int i 0; i 10; i) {new Thread(() - {lockClearUpDemo.m1();}, String.valueOf(i)).start();}}
}
3.3.2锁粗化
如方法中多个同步块首尾相接前后使用的都是同一个锁对象那么JIT编译器会把这几个synchronized块合并为一个大块加粗锁的范围。
public class LockBigDemo {static Object objectLock new Object();public static void main(String[] args) {new Thread(() - {synchronized (objectLock) {System.out.println(111111111111);}synchronized (objectLock) {System.out.println(222222222222);}synchronized (objectLock) {System.out.println(333333333333);}synchronized (objectLock) {System.out.println(444444444444);}//底层JIT的锁粗化优化synchronized (objectLock) {System.out.println(111111111111);System.out.println(222222222222);System.out.println(333333333333);System.out.println(444444444444);}}, t1).start();}
}
4.Synchronized的具体实现 线程代码进入到Synchronized代码块时会自动获取锁对象这时其他线程访问时会被阻塞直到Synchroinzed代码块执行完毕或抛出异常调用wait()方法都会释放锁对象。在进入Synchronized代码块时会将主内存的变量读取到自己的工作内存在退出的时候会把工作内存的更新值写入到主内存。Java中Synchronized通过在锁对象的对象头设置标记达到获取锁和释放锁的目的。
