标签:耗资源 情况下 obj 需要 导致 源码 img mamicode 很多
看如下代码
public class Test { StringBuffer stb = new StringBuffer(); public void test1(){ //jvm的优化,锁的粗化 stb.append("1"); stb.append("2"); stb.append("3"); stb.append("4"); }
首先我们要清除StringBuffer是线程安全的,因为它在每一个方法上都加了synchronized锁,下图是StringBuffer的源码
按照正常的理解synchronized是对当前对象加锁,那么我们调用了四次append方法,那么jvm是将这把对象锁加了四次吗?如下图:
那这样的化,jvm就需要加四次锁,当然也要释放四次锁,频繁加解锁引起线程上下文的切换,非常消耗性能,所以jvm做了优化,只加一次锁,叫做锁的粗化,可以理解为将锁的颗粒度放大
如图看下面代码
public void test2(){ //jvm的优化,JVM不会对同步块进行加锁 synchronized (new Object()) { //伪代码:很多逻辑 //jvm是否会加锁? //jvm会进行逃逸分析 } }
这个地方加锁等于没有加锁,因为每个线程都会new object,大家都不会用同一把锁,jvm分析优化后不会对这种代码加锁(逃逸分析),所以,我们平时加锁一定要注意,加锁要加同一把锁。
synchronized的锁的状态总共有四种,无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争,锁可以从偏向锁升级到轻量级锁,再升级的重量级锁,但是锁的升级是单向的,也就是说只能从低到高升级,锁状态的升级不可逆。
JDK1.6版本之后对synchronized的实现进行了各种优化,如自旋锁、偏向锁和轻量级锁 并默认开启偏向锁 开启偏向锁:-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 关闭偏向锁:-XX:-UseBiasedLocking。如果直接上来就是重量级锁,那么实在是太消耗资源了。
注意一下几点:
线程1获取轻量级锁后会将Object Mark Word 复制自己的一份到自己的栈空间,然后在自己的栈空间开辟一个指针lockerecord 指向Object Mark Word,同时Object Mark Word也会指向lockerecord,当线程1执行完代码块释放轻量级锁之后,发现Object Mark Word不在指向自己,说明当前锁已经改为重量级锁,那么它会唤醒阻塞队列中所有线程重新竞争锁。
总结:偏向锁,轻量级锁都是基于Object Mark Word的标记实现,java尽可能避免使用重量级锁。
并发编程之synchronized(二)------jvm对synchronized的优化
标签:耗资源 情况下 obj 需要 导致 源码 img mamicode 很多
原文地址:https://www.cnblogs.com/jihuifeng/p/13296670.html