欢迎大家关注 github.com/hsfxuebao/j… ,希望对大家有所帮助,要是觉得可以的话麻烦给点一下Star哈
前言
毫无疑问,synchronized是我们用过的第一个并发关键字,很多博文都在讲解这个技术。不过大多数讲解还停留在对synchronized的使用层面,其底层的很多原理和优化,很多人可能并不知晓。因此本文将通过对synchronized的大量C源码分析,让大家对他的了解更加透彻点。
本篇将从为什么要引入synchronized,常见的使用方式,存在的问题以及优化部分这四个方面描述,话不多说,直接进入主题。
可见性问题及解决
概念描述
指一个线程对共享变量进行修改,另一个能立刻获取到修改后的最新值。
代码展示
类:
public class Example1 { //1.创建共享变量 private static boolean flag = true; public static void main(String[] args) throws Exception { //2.t1空循环,如果flag为true,不退出 Thread t1 = new Thread(new Runnable() { @Override public void run() { while (true) { if(!flag){ System.out.println("进入if"); break; } } } }); t1.start(); Thread.sleep(2000L); //2.t2修改flag为false Thread t2 = new Thread(new Runnable() { @Override public void run() { flag = false; System.out.println("修改了"); } }); t2.start(); } } 复制代码
运行结果:
分析
这边先要了解下Java的内存模式,不明白的可点击传送门,todo。
下图线程t1,t2从主内存分别获取flag=true,t1空循环,直到flag为false的时候退出循环。t2拿到flag的值,将其改为false,并写入到主内存。此时主内存和线程t2的工作内存中flag均为false,但是线程t1工作内存中的flag还是true,所以一直退不了循环,程序将一直执行。
synchronized如何解决可见性
首先我们尝试在t1线程中加一行打印语句,看看效果。
代码:
public class Example1 { //1.创建共享变量 private static boolean flag = true; public static void main(String[] args) throws Exception { //2.t1空循环,如果flag为true,不退出 Thread t1 = new Thread(new Runnable() { @Override public void run() { while (true) { //新增的打印语句 System.out.println(flag); if(!flag){ System.out.println("进入if"); break; } } } }); t1.start(); Thread.sleep(2000L); //2.t2修改flag为false Thread t2 = new Thread(new Runnable() { @Override public void run() { flag = false; System.out.println("修改了"); } }); t2.start(); } } 复制代码
运行结果:
我们发现if里面的语句已经打印出来了,线程1已经感知到线程2对flag的修改,即这条打印语句已经影响了可见性。这是为啥?
答案就是println中,我们看下源码:
println有个上锁的过程,即操作如下:
1.获取同步锁。
2.清空自己工作内存上的变量。
3.从主内存获取最新值,并加载到工作内存中。
4.打印并输出。
所以这里解释了为什么线程t1加了打印语句之后,t1立刻能感知t2对flag的修改。因为每次打印的时候其都从主内存上获取了最新值,当t2修改的时候,t1立刻从主内存获取了值,所以进入了if语句,并最终能跳出循环。
synchronized的原理就是清空自己工作内存上的值,通过将主内存最新值刷新到工作内存中,让各个线程能互相感知修改。
原子性问题及解决
概念描述
在一次或多个操作中,要不所有操作都执行,要不所有操作都不执行。
代码展示
类:
public class Example2 { //1.定义全局变量number private static int number = 0; public static void main(String[] args) throws Exception { Runnable runnable = () -> { for (int i = 0; i < 10000; i++) { number++; } }; //2.t1让其自增10000 Thread t1 = new Thread(runnable); t1.start(); //3.t2让其自增10000 Thread t2 = new Thread(runnable); t2.start(); //4.等待t1,t2运行结束 t1.join(); t2.join(); System.out.println("number=" + number); } } 复制代码
运行结果:
分析
每个线程执行的逻辑是循环1万次,每次加1,那我们希望的结果是2万,但是实际上结果是不足2万的。我们先用javap命令反汇编,我们看到很多代码,但是number++涉及的指令有四句,具体看第二张图。
如果有多条线程执行这段number++代码,当前number为0,线程1先执行到iconst_1指令,即将执行iadd操作,而线程2执行到getstatic指令,这个时候number值还没有改变,所以线程2获取到的静态字段是0,线程1执行完iadd操作,number变为1,线程2执行完iadd操作,number还是1。这个时候就发现问题了,做了两次number++操作,但是number只增加了1。
并发编程时,会出现原子性问题,当一个线程对共享变量操作到一半的时候,另外一个线程也有可能来操作共享变量,这个时候就出现了问题。
synchronized如何解决原子性问题
在上面的分析中,我们已经知道发生问题的原因,number++是由四条指令组成,没有保证原子操作。所以,我们只要将number++作为一个整体就行,即保证他的原子性。具体代码如下:
public class Example2 { //1.定义全局变量number private static int number = 0; //新增一个静态变量object private static Object object = new Object(); public static void main(String[] args) throws Exception { Runnable runnable = () -> { for (int i = 0; i < 10000; i++) { //将number++的操作用object对象锁住 synchronized (object) { number++; } } }; //2.t1让其自增10000 Thread t1 = new Thread(runnable); t1.start(); //3.t2让其自增10000 Thread t2 = new Thread(runnable); t2.start(); //4.等待t1,t2运行结束 t1.join(); t2.join(); System.out.println("number=" + number); } } 复制代码
我们看到最终number为20000,那为什么要加上synchronized,结果就正确了?我们再反编译下Example2,可以看到在四行指令前后分别有monitorenter和monitorexist,线程1在执行中间指令时,其他线程不可以进入monitorenter,需要等线程1执行完monitorexist,其他进程才能继续monitorenter,进行自增操作。
monitorenter指令
每个对象都会与一个monitor相关联,当某个monitor被拥有之后就会被锁住,当线程执行到monitorenter指令时,就会去尝试获得对应的monitor。步骤如下:
- 每个monitor维护着一个记录着拥有次数的计数器。未被拥有的monitor的该计数器为0,当一个线程获得monitor(执行monitorenter)后,该计数器自增变为 1 。
- 当同一个线程再次获得该monitor的时候,计数器再次自增;
- 当不同线程想要获得该monitor的时候,就会被阻塞。
- 当同一个线程释放 monitor(执行monitorexit指令)的时候,计数器再自减。当计数器为0的时候。monitor将被释放,其他线程便可以获得monitor。
monitorexit指令
当线程执行monitorexit指令时,会去讲monitor的计数器减一,如果结果是0,则该线程将不再拥有该monitor。其他线程就可以获得该monitor了。
有序性问题及解决
概念描述
代码中程序执行的顺序,Java在编译和运行时会对代码进行优化,这样会导致我们最终的执行顺序并不是我们编写代码的书写顺序。
代码展示
咱先来看一个概念,重排序
,也就是语句的执行顺序会被重新安排。其主要分为三种:
1.编译器优化的重排序:可以重新安排语句的执行顺序。
2.指令级并行的重排序:现代处理器采用指令级并行技术,将多条指令重叠执行。
3.内存系统的重排序:由于处理器使用缓存和读写缓冲区,所以看上去可能是乱序的。
上面代码中的a = new A();可能被被JVM分解成如下代码:
// 可以分解为以下三个步骤 1 memory=allocate();// 分配内存 相当于c的malloc 2 ctorInstanc(memory) //初始化对象 3 s=memory //设置s指向刚分配的地址 // 上述三个步骤可能会被重排序为 1-3-2,也就是: 1 memory=allocate();// 分配内存 相当于c的malloc 3 s=memory //设置s指向刚分配的地址 2 ctorInstanc(memory) //初始化对象
一旦假设发生了这样的重排序,比如线程A在执行了步骤1和步骤3,但是步骤2还没有执行完。这个时候线程B进入了第一个语句,它会判断a不为空,即直接返回了a。其实这是一个未初始化完成的a,即会出现问题。
synchronized如何解决有序性问题
给上面的三个步骤加上一个synchronized关键字,即使发生重排序也不会出现问题。线程A在执行步骤1和步骤3时,线程B因为没法获取到锁,所以也不能进入第一个语句。只有线程A都执行完,释放锁,线程B才能重新获取锁,再执行相关操作。
synchronized的常见使用方式
修饰代码块(同步代码块)
synchronized (object) { //具体代码 }
修饰方法
synchronized void test(){ //具体代码 }
通过javap -v 反汇编之后的代码:
同步方法和同步代码块总结
- 同步方法和同步代码块底层都是通过monitor来实现同步的。
- 两者的区别:同步方式是通过方法中的access_flags中设置ACC_SYNCHRONIZED标志来实现;同步代码块是通过monitorenter和monitorexit来实现
- 我们知道了每个对象都与一个monitor相关联。而monitor可以被线程拥有或释放。
synchronized不能继承?(插曲)
父类A:
public class A { synchronized void test() throws Exception { try { System.out.println("main 下一步 sleep begin threadName=" + Thread.currentThread().getName() + " time=" + System.currentTimeMillis()); Thread.sleep(5000); System.out.println("main 下一步 sleep end threadName=" + Thread.currentThread().getName() + " time=" + System.currentTimeMillis()); } catch (Exception e) { e.printStackTrace(); } } }
子类B:(未重写test方法)
public class B extends A { }复制代码
子类C:(重写test方法)
public class C extends A { @Override void test() throws Exception{ try { System.out.println("sub 下一步 sleep begin threadName=" + Thread.currentThread().getName() + " time=" + System.currentTimeMillis()); Thread.sleep(5000); System.out.println("sub 下一步 sleep end threadName=" + Thread.currentThread().getName() + " time=" + System.currentTimeMillis()); } catch (Exception e) { e.printStackTrace(); } } } 复制代码
线程A:
public class ThreadA extends Thread { private A a; public void setter (A a) { this.a = a; } @Override public void run() { try{ a.test(); }catch (Exception e){ } } }复制代码
线程B:
public class ThreadB extends Thread { private B b; public void setB(B b){ this.b=b; } @Override public void run() { try{ b.test(); }catch (Exception e){ } } } 复制代码
线程C:
public class ThreadC extends Thread{ private C c; public void setC(C c){ this.c=c; } @Override public void run() { try{ c.test(); }catch (Exception e){ } } }复制代码
测试类test:
public class test { public static void main(String[] args) throws Exception { A a = new A(); ThreadA A1 = new ThreadA(); A1.setter(a); A1.setName("A1"); A1.start(); ThreadA A2 = new ThreadA(); A2.setter(a); A2.setName("A2"); A2.start(); A1.join(); A2.join(); System.out.println("============="); B b = new B(); ThreadB B1 = new ThreadB(); B1.setB(b); B1.setName("B1"); B1.start(); ThreadB B2 = new ThreadB(); B2.setB(b); B2.setName("B2"); B2.start(); B1.join(); B2.join(); System.out.println("============="); C c = new C(); ThreadC C1 = new ThreadC(); C1.setName("C1"); C1.setC(c); C1.start(); ThreadC C2 = new ThreadC(); C2.setName("C2"); C2.setC(c); C2.start(); C1.join(); C2.join(); } }复制代码
运行结果:
子类B继承了父类A,但是没有重写test方法,ThreadB仍然是同步的。子类C继承了父类A,也重写了test方法,但是未明确写上synchronized,所以这个方法并不是同步方法。只有显式的写上synchronized关键字,才是同步方法。
所以synchronized不能继承这句话有歧义,我们只要记住子类如果想要重写父类的同步方法,synchronized关键字一定要显示写出,否则无效。
修饰静态方法
synchronized static void test(){ //具体代码 }
修饰类
synchronized (Example2.class) { //具体代码 }
Java对象 Mark Word
在JVM中,对象在内存中的布局分为三块区域:对象头,实例数据和对齐数据,如下图:
其中Mark Word值在不同锁状态
下的展示如下:(重点看线程id,是否为偏向锁,锁标志位信息)
在64位系统中,Mark Word占了8个字节,类型指针占了8个字节,一共是16
个字节。Talk is cheap. Show me the code. 咱来看代码。
- 我们想要看Java对象的Mark Word,先要加载一个jar包,在pom.xml添加即可。
org.openjdk.jol jol-core 0.9 复制代码 - 新建一个对象A,拥有初始值为666的变量x。
public class A { private int x=666; }复制代码 - 新建一个测试类test,这涉及到刚才加载的jar,我们打印Java对象。
import org.openjdk.jol.info.ClassLayout;
public class test { public static void main(String[] args) { A a=new A(); System.out.println( ClassLayout.parseInstance(a).toPrintable()); } }复制代码 - 我们发现对象头(object header)占了
12
个字节,为啥和上面说的16个字节不一样。
- 其实上是默认开启了指针压缩,我们需要关闭指针压缩,也就是添加
-XX:-UseCompressedOops
配置。
- 再次执行,发现对象头为16个字节。
对象状态
根据上面可以把对象分为六种状态:无锁不可偏向、无锁可偏向、偏向锁、轻量级锁、重量级锁、被GC标记状态。
判断方式看最后两位:
如果是 11表示被GC标记
如果是10表示重量级锁
如果是00表示轻量级锁
如果是01 那么继续看倒数第三位,
- 如果是0,表示无锁,且不可偏向
- 如果是1,看前面54bit,如果全是0,表示无锁,但是处于可以偏向状态
- 如果是1,前面54bit有数据,表示偏向锁,54bit里面存储的就是当前偏向的线程信息
偏向锁
什么是偏向锁
JDK1.6之前锁为重量级锁(待会说,只要知道他和内核交互,消耗资源),1.6之后Java设计人员发现很多情况下并不存在多个线程竞争的关系,所以为了资源问题引入了无锁
,偏向锁
,轻量级锁
,重量级锁
的概念。先说偏向锁,他是偏心,偏袒的意思,这个锁会偏向于第一个获取他的线程。
偏向锁演示
- 创建并启动一个线程,run方法里面用了synchronized关键字,功能是打印this的Java对象。
public class test { public static void main(String[] args) { Thread thread=new Thread(new Runnable() { @Override public void run() { synchronized (this){ System.out.println(ClassLayout.parseInstance(this).toPrintable()); } } }); thread.start(); } }复制代码
标红的地方为000,根据之前Mark Word在不同状态下的标志,得此为轻量级锁状态。理论上一个线程使用synchronized关键字,应为偏向锁。
- 实际上偏向锁在JDK1.6之后是默认开启的,但是启动时间有延迟,所以需要添加参数
-XX:BiasedLockingStartupDelay=0
,让其在程序启动时立刻启动。
- 重新运行下代码,发现标红地方101,对比Mark Word在不同状态下的标志,得此状态为偏向锁。
偏向锁原理图解
- 在线程的run方法中,刚执行到synchronized,会判断当前对象是否为偏向锁和锁标志,没有任何线程执行该对象,我们可以看到是否为偏向锁为0,锁标志位01,即无锁状态。
- 线程会将自己的id赋值给markword,即将原来的hashcode值改为线程id,是否是偏向锁改为1,表示线程拥有对象锁,可以执行下面的业务逻辑。
如果synchronized执行完,对象还是偏向锁状态;如果线程结束之后,会撤销偏向锁,将该对象还原成无锁状态。
- 如果同一个线程中又对该对象进行加锁操作,我们只要对比
对象的线程id
是否与线程id
相同,如果相同即为线程锁重入问题。
优势
加锁和解锁不需要额外的消耗,和执行非同步方法相比只有纳秒级的差距。
白话翻译
线程1锁定对象this,他发现对象为无锁状态,所以将线程id赋值给对象的Mark Word字段,表示对象为线程1专用,即使他退出了同步代码,其他线程也不能使用该对象。
同学A去自习教室C,他发现教室无人,所以在门口写了个名字,表示当前教室有人在使用,这样即使他出去吃了饭,其他同学也不能使用这个房间。
偏向锁撤销
偏向锁使用了一种等到竞争出现才释放锁的机制,所以当其他线程尝试竞争偏向锁时, 持有偏向锁的线程才会释放锁。偏向锁的撤销,需要等待全局安全点(在这个时间点上没有正 在执行的字节码)。它会首先暂停拥有偏向锁的线程,然后检查持有偏向锁的线程是否活着, 如果线程不处于活动状态,则将对象头设置成无锁状态;如果线程仍然活着,拥有偏向锁的栈 会被执行,遍历偏向对象的锁记录,栈中的锁记录和对象头的Mark Word要么重新偏向于其他 线程,要么恢复到无锁或者标记对象不适合作为偏向锁,最后唤醒暂停的线程。
轻量锁
什么是轻量级锁
在多线程交替同步代码块的情况下,线程间没有竞争,使用轻量级锁可以避免重量级锁引入的性能消耗。
轻量级图解
- 在刚才偏向锁的基础上,如果有另外一个线程也想错峰使用该资源,通过对比线程id是否相同,Java内存会立刻撤销偏向锁(需要等待全局安全点),进行锁升级的操作。
- 撤销完偏向锁,会在线程1的方法栈中新增一个锁记录,对象的Mark Word与锁记录交换。
优势
竞争的线程不会阻塞,提高了程序的响应速度。
白话翻译
在刚才偏向锁的基础上,另外一个线程也想要获取资源,所以线程1需要撤销偏向锁,升级为轻量锁。
同学A在使用自习教室外面写了自己的名字,所以同学B来也想要使用自习教室,他需要提醒同学A,不能使用重量级锁,同学A将自习教室门口的名字擦掉,换成了一个书包,里面是自己的书籍。这样在同学A不使用自习教室的时候,同学B也能使用自习教室,只需要将自己的书包也挂在外面即可。这样下次来使用的同学就能知道已经有人占用了该教室。
轻量级锁加锁
线程在执行同步块之前,JVM会先在当前线程的栈桢中创建用于存储锁记录的空间,并 将对象头中的Mark Word复制到锁记录中,官方称为Displaced Mark Word。然后线程尝试使用 CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功,当前线程获得锁,如果失 败,表示其他线程竞争锁,当前线程便尝试使用自旋来获取锁。
轻量级锁解锁
轻量级解锁时,会使用原子的CAS操作将Displaced Mark Word替换回到对象头,如果成 功,则表示没有竞争发生。如果失败,表示当前锁存在竞争,锁就会膨胀成重量级锁。图2-2是 两个线程同时争夺锁,导致锁膨胀的流程图
重量级锁
什么是重量级锁
当多线程之间发生竞争,Java内存会申请一个Monitor对象来实现。
重量级锁原理图解
在刚才的轻量级锁的基础上,线程2也想要申请资源,发现锁的标志位为00,即为轻量级锁,所以向内存申请一个Monitor,让对象的MarkWord指向Monitor地址,并将ower指针指向线程1的地址,线程2放在等待队列里面,等线程1指向完毕,释放锁资源。
锁升级流程简化版
举例:线程八锁
/* * 题目:判断打印的 "one" or "two" ? * * 1. 两个普通同步方法,两个线程,标准打印, 打印? //one two * 2. 新增 Thread.sleep() 给 getOne() ,打印? //one two * 3. 新增普通方法 getThree() , 打印? //three one two * 4. 两个普通同步方法,两个 Number 对象,打印? //two one * 5. 修改 getOne() 为静态同步方法,打印? //two one * 6. 修改两个方法均为静态同步方法,一个 Number 对象? //one two * 7. 一个静态同步方法,一个非静态同步方法,两个 Number 对象? //two one * 8. 两个静态同步方法,两个 Number 对象? //one two * * 线程八锁的关键: * ①非静态方法的锁默认为 this, 静态方法的锁为 对应的 Class 实例 * ②某一个时刻内,只能有一个线程持有锁,无论几个方法。 */ public class TestThread8Monitor { public static void main(String[] args) { Number number = new Number(); Number number2 = new Number(); new Thread(new Runnable() { @Override public void run() { number.getOne(); // Number.getOne(); } }).start(); new Thread(new Runnable() { @Override public void run() { number.getTwo(); // number2.getTwo(); } }).start(); // new Thread(new Runnable() { // @Override // public void run() { // number.getThree(); // } // }).start(); } } class Number{ public static synchronized void getOne(){//Number.class try { Thread.sleep(3000); } catch (InterruptedException e) { } System.out.println("one"); } public synchronized void getTwo(){//this System.out.println("two"); } public void getThree(){ System.out.println("three"); } }
Monitor源码分析
环境搭建
我们去官网http://openjdk.java.net/
找下open源码,也可以通过其他途径下载。源码是C实现的,可以通过DEV C++工具打开,效果如下图:
构造函数
我们先看下\hotspot\src\share\vm\runtime\ObjectMonitor.hpp
,以.hpp结尾的文件是导入的一些包和一些声明,之后可以被.cpp文件导入。
ObjectMonitor() { _header = NULL; _count = 0; _waiters = 0, _recursions = 0;//线程重入次数 _object = NULL;//存储该monitor的对象 _owner = NULL;//标识拥有该monitor的线程 _WaitSet = NULL;//处于wait状态的线程,会加入到_waitSet _WaitSetLock = 0 ; _Responsible = NULL ; _succ = NULL ; _cxq = NULL ;//多线程竞争锁时的单项列表 FreeNext = NULL ; _EntryList = NULL ;//处于等待锁lock状态的线程,会被加入到该列表 _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ; _previous_owner_tid = 0; }复制代码
锁竞争的过程
我们先看下\hotspot\src\share\vm\interpreter\interpreterRuntime.cpp
,IRT_ENTRY_NO_ASYNC
即为锁竞争过程。
//%note monitor_1 IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem)) #ifdef ASSERT thread->last_frame().interpreter_frame_verify_monitor(elem); #endif if (PrintBiasedLockingStatistics) { Atomic::inc(BiasedLocking::slow_path_entry_count_addr()); } Handle h_obj(thread, elem->obj()); assert(Universe::heap()->is_in_reserved_or_null(h_obj()), "must be NULL or an object"); //是否使用偏向锁,可加参数进行设置 if (UseBiasedLocking) { //如果可以使用偏向锁,即进入fast_enter // Retry fast entry if bias is revoked to avoid unnecessary inflation ObjectSynchronizer::fast_enter(h_obj, elem->lock(), true, CHECK); } else {//如果不可以使用偏向锁,即进行slow_enter ObjectSynchronizer::slow_enter(h_obj, elem->lock(), CHECK); } assert(Universe::heap()->is_in_reserved_or_null(elem->obj()), "must be NULL or an object"); #ifdef ASSERT thread->last_frame().interpreter_frame_verify_monitor(elem); #endif IRT_END复制代码
slow_enter实际上调用的ObjectMonitor.cpp的enter 方法
void ATTR ObjectMonitor::enter(TRAPS) { // The following code is ordered to check the most common cases first // and to reduce RTS->RTO cache line upgrades on SPARC and IA32 processors. Thread * const Self = THREAD ; void * cur ; //通过CAS操作尝试将monitor的_owner设置为当前线程 cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ; //如果设置不成功,直接返回 if (cur == NULL) { // Either ASSERT _recursions == 0 or explicitly set _recursions = 0. assert (_recursions == 0 , "invariant") ; assert (_owner == Self, "invariant") ; // CONSIDER: set or assert OwnerIsThread == 1 return ; } //如果_owner等于当前线程,重入数_recursions加1,直接返回 if (cur == Self) { // TODO-FIXME: check for integer overflow! BUGID 6557169. _recursions ++ ; return ; } //如果当前线程第一次进入该monitor,设置重入数_recursions为1,_owner为当前线程,返回 if (Self->is_lock_owned ((address)cur)) { assert (_recursions == 0, "internal state error"); _recursions = 1 ; // Commute owner from a thread-specific on-stack BasicLockObject address to // a full-fledged "Thread *". _owner = Self ; OwnerIsThread = 1 ; return ; } //如果未抢到锁,则进行自旋优化,如果还未获取锁,则放入到list里面 // We've encountered genuine contention. assert (Self->_Stalled == 0, "invariant") ; Self->_Stalled = intptr_t(this) ; // Try one round of spinning *before* enqueueing Self // and before going through the awkward and expensive state // transitions. The following spin is strictly optional ... // Note that if we acquire the monitor from an initial spin // we forgo posting JVMTI events and firing DTRACE probes. if (Knob_SpinEarly && TrySpin (Self) > 0) { assert (_owner == Self , "invariant") ; assert (_recursions == 0 , "invariant") ; assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ; Self->_Stalled = 0 ; return ; } assert (_owner != Self , "invariant") ; assert (_succ != Self , "invariant") ; assert (Self->is_Java_thread() , "invariant") ; JavaThread * jt = (JavaThread *) Self ; assert (!SafepointSynchronize::is_at_safepoint(), "invariant") ; assert (jt->thread_state() != _thread_blocked , "invariant") ; assert (this->object() != NULL , "invariant") ; assert (_count >= 0, "invariant") ; // Prevent deflation at STW-time. See deflate_idle_monitors() and is_busy(). // Ensure the object-monitor relationship remains stable while there's contention. Atomic::inc_ptr(&_count); EventJavaMonitorEnter event; { // Change java thread status to indicate blocked on monitor enter. JavaThreadBlockedOnMonitorEnterState jtbmes(jt, this); DTRACE_MONITOR_PROBE(contended__enter, this, object(), jt); if (JvmtiExport::should_post_monitor_contended_enter()) { JvmtiExport::post_monitor_contended_enter(jt, this); } OSThreadContendState osts(Self->osthread()); ThreadBlockInVM tbivm(jt); Self->set_current_pending_monitor(this); // TODO-FIXME: change the following for(;;) loop to straight-line code. for (;;) { jt->set_suspend_equivalent(); // cleared by handle_special_suspend_equivalent_condition() // or java_suspend_self() EnterI (THREAD) ; if (!ExitSuspendEquivalent(jt)) break ; // // We have acquired the contended monitor, but while we were // waiting another thread suspended us. We don't want to enter // the monitor while suspended because that would surprise the // thread that suspended us. // _recursions = 0 ; _succ = NULL ; exit (false, Self) ; jt->java_suspend_self(); } Self->set_current_pending_monitor(NULL); } Atomic::dec_ptr(&_count); assert (_count >= 0, "invariant") ; Self->_Stalled = 0 ; // Must either set _recursions = 0 or ASSERT _recursions == 0. assert (_recursions == 0 , "invariant") ; assert (_owner == Self , "invariant") ; assert (_succ != Self , "invariant") ; assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ; // The thread -- now the owner -- is back in vm mode. // Report the glorious news via TI,DTrace and jvmstat. // The probe effect is non-trivial. All the reportage occurs // while we hold the monitor, increasing the length of the critical // section. Amdahl's parallel speedup law comes vividly into play. // // Another option might be to aggregate the events (thread local or // per-monitor aggregation) and defer reporting until a more opportune // time -- such as next time some thread encounters contention but has // yet to acquire the lock. While spinning that thread could // spinning we could increment JVMStat counters, etc. DTRACE_MONITOR_PROBE(contended__entered, this, object(), jt); if (JvmtiExport::should_post_monitor_contended_entered()) { JvmtiExport::post_monitor_contended_entered(jt, this); } if (event.should_commit()) { event.set_klass(((oop)this->object())->klass()); event.set_previousOwner((TYPE_JAVALANGTHREAD)_previous_owner_tid); event.set_address((TYPE_ADDRESS)(uintptr_t)(this->object_addr())); event.commit(); } if (ObjectMonitor::_sync_ContendedLockAttempts != NULL) { ObjectMonitor::_sync_ContendedLockAttempts->inc() ; } } 复制代码
白话翻译
同学A在使用自习教室的时候,同学B在同一时刻也想使用自习教室,那就发生了竞争关系。所以同学B在A运行过程中,加入等待队列。如果此时同学C也要使用该教室,也会加入等待队列。等同学A使用结束,同学B和C将竞争自习教室。
自旋优化
自旋优化比较简单,如果将其他线程加入等待队列,那之后唤醒并运行线程需要消耗资源,所以设计人员让其空转一会,看看线程能不能一会结束了,这样就不要在加入等待队列。
白话来说,如果同学A在使用自习教室,同学B可以回宿舍,等A使用结束再来,但是B回宿舍再来的过程需要1个小时,而A只要10分钟就结束了。所以B可以先不回宿舍,而是在门口等个10分钟,以防止来回时间的浪费。