运用范围
synchronized的优化
- 在jdk1.6中对synchronized做了相关的优化
锁消除
锁胀大
- 在一个循环中频繁的呈现锁资源的获取与开释操作,会带来资源的耗费,于是便会将锁的范围扩大到循环的外边,避免频繁的竞争和获取锁资源而导致的资源耗费
public void method(){
for (int i = 0; i < Integer.MAX_VALUE; i++) {
synchronized ("") {
// 事务代码
}
}
}


锁晋级
- ReentrantLock中是根据乐观锁的CAS获取线程资源。资源拿不到的情况下才会挂起线程。synchronized在jdk1.6之间彻底获取不到锁的情况下立即挂起线程,但是在1.6之后进行了锁的晋级与优化。
- 无锁、匿名倾向:当时目标没有作为锁的存在
- 倾向锁:当时锁资源,只有一个线程频繁的获取和开释锁,那么只有该线程获取锁是判别是否是同一个线程,假如是线程资源拿走。假如线程不是当时自己的线程,则选用根据CAS的方法,测验将倾向锁指向当时线程。假如获取不到则触发锁晋级为轻量级锁,也就意味着发生了锁竞争的情况。
- 轻量级锁:运用自旋锁的方法频繁的选用CAS的方法获取锁资源。这里选用的自适应自旋锁(JVM更具前次的自旋成果来进行判别本次的自旋时刻长短)。假如成功获取锁资源,资源取走。假如获取锁资源失利,锁晋级。
- 重量级锁:最为传统的synchronized完成方法。拿不到锁资源之间挂起线程,然后进行用户态和内核态的不断切换。。。
synchronized锁的完成原理
synchronized锁晋级的过程演示
- 运用之前需求导入一个依赖
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>

- 锁在默许情况下,敞开了倾向锁的推迟
- 原因是因为在倾向锁晋级为轻量级锁的时分会涉及到倾向锁的撤销,需求比及一个安全点(STW),才干完成对倾向锁的撤销,所以在并发的情况下就能够选择不敞开倾向锁,或许设置倾向锁推迟敞开
- 在JVM发动时会大量加载.class文件到内存,该操作会涉及synchronized运用,为了避免呈现倾向锁撤销的操作。在发动初期,有一个推迟5s敞开倾向锁的操作。
- 要是正常敞开倾向锁,那么就不会呈现无锁的状况,而是直接进入匿名倾向锁

- 变成了倾向锁

/**
* @author 舒一笑
* @date 2023/5/28
*/
public class Test15 {
public static void main(String[] args) throws InterruptedException {
Thread.sleep(5000);
Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
//thread 线程倾向锁
Thread thread = new Thread(()->{
synchronized (o){
System.out.println("thread线程 :"+ClassLayout.parseInstance(o).toPrintable());
}
});
thread.start();
// 轻量级锁 -> 重量级锁
synchronized (o){
System.out.println("main线程 :"+ClassLayout.parseInstance(o).toPrintable());
}
}
}

锁转化状况示意图

LockRecord和ObjectMonitor存储的内容示意图

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。