每一个Object对象中内置了一个Monitor对象。(对象头的MarkWord中的LockWord指向monitor的起始地址)
Monitor相当于一个许可证,线程拿到许可证即可以进行操作,没有拿到则需要阻塞等待。
ObjectMonitor中有几个关键属性:
_owner:指向持有ObjectMonitor对象的线程
_WaitSet:存放处于wait状态的线程队列
_EntryList:存放处于等待锁block状态的线程队列
_recursions:锁的重入次数
_count:用来记录该线程获取锁的次数
线程T等待对象锁:_EntryList中加入T
线程T获取对象锁:_EntryList移除T,_owner置为T,计数器_count+1
持有对象锁的线程调用wait():_owner置为T,计数器_count+1,_WaitSet中加入T
四、synchronized原理
利用javap工具查看生成的class文件信息来分析Synchronize的实现
(摘自: 【死磕Java并发】—–深入分析synchronized的实现原理)
public class SynchronizedTest {
public synchronized void test1(){
}
public void test2(){
synchronized (this){
}
}
}
同步代码块:monitorenter指令插入到同步代码块的开始位置,monitorexit指令插入到同步代码块的结束位置,JVM需要保证每一个monitorenter都有一个monitorexit与之相对应。任何对象都有一个monitor与之相关联,当且一个monitor被持有之后,他将处于锁定状态。线程执行到monitorenter指令时,将会尝试获取对象所对应的monitor所有权,即尝试获取对象的锁;
同步方法:synchronized方法则会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令,在VM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法,而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1,表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass做为锁对象。
五、synchronized解决并发问题
synchronized保证原子性
1)通过monitorenter
和monitorexit
指令,可以保证被synchronized
修饰的代码在同一时间只能被一个线程访问,在锁未释放之前,无法被其他线程访问到。
2)即使在执行过程中,由于某种原因,比如CPU时间片用完,线程1放弃了CPU,但是它并没有进行解锁。而由于synchronized
的锁是可重入的,下一个时间片还是只能被他自己获取到,还是会继续执行代码。直到所有代码执行完。
synchronized保证可见性
保证可见性规则:对一个synchronized修饰的变量解锁之前,必须先把此变量同步回主存中。
synchronized保证有序性
由于synchronized
修饰的代码,同一时间只能被同一线程访问。(如果在本线程内观察,所有操作都是天然有序的)
synchronized
是无法禁止指令重排和处理器优化的,但是同一线程内的执行遵守as-if-serial语义。
六、锁优化
重量级锁
synchronized
其实是借助Monitor实现的,在加锁时会调用objectMonitor的enter
方法,解锁的时候会调用exit
方法。
通过对象内部的监视器(monitor)实现,其中monitor的本质是依赖于底层操作系统的Mutex Lock实现,操作系统实现线程之间的切换需要从用户态到内核态的切换,切换成本非常高。
Java的线程是映射到操作系统原生线程之上的,如果要阻塞或唤醒一个线程就需要操作系统的帮忙,这就要从用户态转换到核心态,因此状态转换需要花费很多的处理器时间,是java语言中一个重量级的操纵。
只有在JDK1.6之前,synchronized的实现才会直接调用ObjectMonitor的enter
和exit。
在JDK1.6中出现对锁进行了很多的优化,进而出现轻量级锁,偏向锁,锁消除,适应性自旋锁,锁粗化。
自旋锁
共享数据的锁定状态一般只会持续很短的一段时间,为了这段时间去挂起和恢复线程其实并不值得。
让后面来的线程“稍微等一下”,但是并不放弃处理器的执行时间,看看持有锁的线程会不会很快释放锁。这个“稍微等一下”的过程就是自旋。(怎么等待呢?执行一段无意义的循环即可)
1、由于自旋锁只是将当前线程不停地执行循环体,不进行线程状态的改变,所以响应速度更快。
2、但当线程数不停增加时,性能下降明显,因为每个线程都需要执行,占用CPU时间。
3、自旋锁和阻塞锁最大的区别就是,到底要不要放弃处理器的执行时间。阻塞锁是放弃了CPU时间,进入了等待区,等待被唤醒。而自旋锁是一直“自旋”在那里,时刻的检查共享资源是否可以被访问。
锁消除
JVM检测到不可能存在共享数据竞争,这是JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。
注意:我们在使用一些JDK的内置API时,如StringBuffer、Vector、HashTable等,这个时候会存在隐形的加锁操作。
// 在运行这段代码时,JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外,所以JVM可以大胆地将vector内部的加锁操作消除。
public void vectorTest() {
Vector<String> vector = new Vector<String>();
for (int i = 0; i < 10; i++) {
vector.add(i + "");// vector是线程安全的,每个方法都有synchronized修饰
}
System.out.println(vector);
}
锁粗化
我们提倡尽量减小锁的粒度:使用同步锁的时候,需要让同步块的作用范围尽可能小—仅在共享数据的实际作用域中才进行同步,这样做的目的是为了使需要同步的操作数量尽可能缩小,如果存在锁竞争,那么等待锁的线程也能尽快拿到锁。
问题:如果一系列的连续加锁解锁操作,可能会导致不必要的性能损耗。
锁粗化:将多个连续的加锁、解锁操作连接在一起,扩展成一个范围更大的锁。
for(int i=0;i<100000;i++){
synchronized(this){
do();
}
// 被优化之后
synchronized(this){
for(int i=0;i<100000;i++){
do();
}
轻量级锁
引入轻量级锁的主要目的是在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
只有在“对于绝大部分的锁,在整个生命周期内都是不会存在竞争的”情况下,轻量级锁才有较好的性能。
如果存在竞争的情况,轻量级锁需要膨胀为重量级锁,而且还会有额外的CAS操作,会比重量级锁性能更差。
正常获取锁过程:
1)当前线程的栈帧中建立一个的空间Lock Record,将锁对象的Mark Word的拷贝过来
2)JVM利用CAS操作将对象的Mark Word更新为指向Lock Record的指针,如果成功表示竞争到锁
3)直接执行同步块代码,不需要monitor
获取锁所有情况:
1)判断当前对象是否处于无锁状态(hashcode、0、01)
无锁状态:JVM首先将在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间,用于存储锁对象目前的Mark Word的拷贝,执行(2)
有锁:执行步骤(3);
2)JVM利用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针
更新指针成功:表示竞争到锁,则将锁标志位变成00(表示此对象处于轻量级锁状态),直接执行同步块代码,不需要monitor,结束;
更新指针成功:未竞争到锁,执行步骤(3);
3)判断当前对象的Mark Word是否指向当前线程的栈帧,
指向当前线程的栈帧:表示当前线程已经持有当前对象的锁,则直接执行同步代码块,不需要monitor,结束;
最后
由于细节内容实在太多了,为了不影响文章的观赏性,只截出了一部分知识点大致的介绍一下,每个小节点里面都有更细化的内容!
需要这份文档的朋友可以帮忙点个赞,点击下方神秘超链接,就可以免费获取到了,还有小编准备的一份Java进阶学习路线图(Xmind)以及来年金三银四必备的一份《Java面试必备指南》
资料领取链接:Java进阶学习路线图(Xmind)+《Java面试必备指南》
锁,则直接执行同步代码块,不需要monitor,结束;
最后
由于细节内容实在太多了,为了不影响文章的观赏性,只截出了一部分知识点大致的介绍一下,每个小节点里面都有更细化的内容!
[外链图片转存中…(img-5FLFXKzB-1628227596580)]
需要这份文档的朋友可以帮忙点个赞,点击下方神秘超链接,就可以免费获取到了,还有小编准备的一份Java进阶学习路线图(Xmind)以及来年金三银四必备的一份《Java面试必备指南》