英文网站推广公司,宁波建网站一站式服务,网站建设和域名什么关系,本地搭建的wordpress上传到主机synchronized
类锁#xff1a;给类的静态方法加上synchronized 关键字进行修饰#xff0c; 锁的是当前类class#xff0c;一个静态同步方法拿到锁#xff0c;其他静态同步方法就会等待静态同步方法和普通同步方法间是没有竞争的 对象锁#xff1a;给类的方法加上synchron…synchronized
类锁给类的静态方法加上synchronized 关键字进行修饰 锁的是当前类class一个静态同步方法拿到锁其他静态同步方法就会等待静态同步方法和普通同步方法间是没有竞争的 对象锁给类的方法加上synchronized 关键字进行修饰 锁的是当前对象 this如果一个对象里有多个synchronized 方法某个时刻只能有一个线程去调用这个对象其中的一个方法没有加synchronized的方法不受影响如果是不同的对象锁就不同了也就不会互相干扰 同步代码块锁 锁的是 synchronized () 内的对象 加锁可以保证线程安全但是会带来性能的下降在高并发下能不加锁就不要加锁一定要加锁也要使加锁的粒度尽可能的小
为什么每一个对象都可以成为锁
在hotsport虚拟机中monitor采用的是ObjectMonitor实现的每一个对象天生都带着一个监视器对象每一个被锁住的对象都会和monitor关联起来monitor 的本质是依赖于操作系统的 Mutex Lock 实现操作系统实现线程的切换需要在用户态和内核态之间切换成本很高ObjectMonitor对象重要的属性 owner属性记录了持有ObjectMonitor对象的线程idcount 初始值为0表示当前锁对象是否被锁定加锁就加1释放锁就减1recursions 初始值为0表示重入次数entryList 阻塞队列用于存放阻塞的线程waitSet 等待队列存放等待的线程
synchronized
由对象头中的 mark word 根据锁标志位的不同来表示锁的状态在java5之前只有synchronized 是操作系统级别的重量级操作涉及到用户态和内核态的切换如果锁竞争激烈性能下降严重 java的线程是映射到操作系统的原生线程之上的如果要阻塞或者唤起一个线程就需要操作系统的接入就需要在用户态和内核态之间切换这种切换是很消耗系统资源的因为用户态和内核态都有自己专用的内存空间、寄存器等用户态切换至内核态需要传递很多参数和变量给内核内核也需要保存好用户态的一些变量以便内核态调用结束后切换回用户态继续工作所以如果同步代码块中的内容很简单有可能用户态和内核态之间的切换时间比代码本身的执行时间还长 所以 java6之后通过引入轻量级锁和偏向锁来减少获得锁和释放锁所带来的性能消耗从而优化了synchronized
synchronized 的锁升级
无锁对象新建出来还没有和任何synchronized关联就是无锁的状态偏向锁mark word 前54位存储偏向的线程id轻量级锁重量级锁锁升级的过程就是先cas自旋实在得不到再阻塞
流程如下
偏向锁 一个 synchronized 方法被一个线程抢到了锁这个方法所在的对象就会在 mark word 中修改偏向锁的标志位同时前54位也会用来存储线程指针也就是偏向线程id 偏向模式如果不存在其他线程竞争那么持有偏向锁的线程永远不需要进行同步也就是说一段同步代码块如果一直被一个线程多次访问那么该线程后续的访问会自动获得锁 因为HotSpot作者研究发现多线程的情况下大多数时候锁不仅不存在竞争关系还存在锁由同一个线程多次获得的情况 所以只需要锁在第一次被拥有的时候记录下线程的id这样偏向线程会一直持有锁这个线程后续进入和退出听不代码块的时候不需要再次加锁和释放锁而是去检查 mark word 中的偏向线程id是不是自己 如果是那么锁偏向于当前线程就不需要再去尝试获得锁了会直接进入同步块不需要每次都通过CAS更新对象头如果自始至终都只有一个线程持有锁那么偏向锁几乎没由额外的开销性能极高如果偏向线程id不是当前线程表示发生了竞争表示锁已经不是总偏向于一个线程了这个时候会尝试使用CAS来更新 mark word 里的线程id为当前线程的id 如果CAS竞争成功 mark word 里的线程id 就会替换为当前线程的id锁也不会升级仍然是偏向锁只不过是从一个线程偏向到另一个线程但是如果CAS竞争失败这个时候就有可能需要 撤销偏向锁升级为轻量级锁使线程间公平竞争 偏向锁会偏向于第一个访问到锁的线程且只有偏向锁被其他线程竞争持有偏向锁的线程才会释放锁否则线程是不会主动释放锁的而对于持有偏向锁的线程也就不需要触发同步就能在没有资源竞争的情况下消除了同步语句 jdk6之后默认就开启了偏向锁 但是 HotSpot 虚拟机在启动后有个 4s 的延迟才会对每个新建的对象开启偏向锁模式这四秒钟之内默认会进入轻量级锁因为 JVM 启动时会进行一系列的复杂活动比如装载配置系统类初始化等等。在这个过程中会使用大量synchronized关键字对对象加锁且这些锁大多数都不是偏向锁。为了减少初始化时间JVM默认延时加载偏向锁
偏向锁的撤销
只有发生竞争时偏向锁才会释放原本持有偏向锁的线程才会被撤销撤销需要等待全局安全点也就是该时间点上没有字节码正在执行同时检查持有偏向锁的线程是否还在执行如果线程正在执行同步方法则升级锁 其他线程就尝试使用CAS来更新 mark word 里的线程id从而抢夺锁偏向锁就会被取消掉并升级为轻量级锁轻量级锁仍然由原本的线程A持有A会继续执行同步代码其他正在竞争的线程会进入自旋等待重新获取轻量级锁 如果线程执行完了就会释放锁并将对象头设置为无锁状态并撤销偏向锁被其他线程抢占重新偏向
java15后会逐步废弃偏向锁
在java15之前偏向锁是默认开启的但是15之后就默认不在开启了除非手动开启
轻量级锁 关闭偏向锁功能或者多线程竞争偏向锁都会导致偏向锁升级为轻量级锁升级为轻量锁会把偏向锁标记改为0并设置标志位为00 对象头 mark word 前62位用来记录线程的id后两位为锁的标志位 00 轻量级锁在没有多线程的竞争下通过cas来代替重量级锁较少性能的消耗能够在线程近乎交替执行同步代码块时提高性能 轻量级锁升级过程 首先线程A拿到锁这时候的锁是偏向锁偏向于A线程B又来抢夺锁发现锁对象头的 当前线程id 不是自己线程B就会通过CAS操作去修改线程id希望能获得锁如果B获得成功也就是A已经执行完了 B会把 mark word 当前线程id设置为自己锁仍然是偏向锁只是重新偏向于B如果B获取失败也就是锁仍然被其他线程占用锁就会升级为轻量锁轻量级锁仍然由之前持有锁的线程继续持有B线程会自旋等待获取轻量级锁
轻量级锁的加锁
JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间称为 Displaced Mark word如果一个线程获得锁时发现是轻量级锁会把当前锁的 Mark word 复制到自己的 Displaced Mark word 里然后线程尝试用CAS将锁的 Mark word 替换为指向锁记录的指针 如果成功就代表获取到了锁如果失败表示 Mark word 已经被替换为了其他线程的锁记录说明存在其他线程竞争锁当前线程就会尝试使用自旋来获取锁
轻量级锁的释放
释放锁时当前线程会使用CAS将 Displaced Mark word 的内容复制到锁的 Mark word 中如果没有发生竞争这个复制操作就会成功如果有其他线程因为自旋多次导致轻量级锁升级为了重量级锁那么CAS操作会失败此时会释放锁并释放被阻塞的线程
轻量级锁和偏向锁的区别
偏向锁是没有竞争关系的轻量级锁存在锁的竞争竞争失败会自旋尝试抢占锁偏向锁只有竞争发生才会释放锁轻量级锁每次退出同步代码块时都需要释放锁
重量级锁 对象头 mark word 前62位用来指向互斥量 重量级锁 的指针后两位为锁的标志位 10 当线程自旋达到一定次数仍然没有获得锁也就是有大量线程在竞争锁那么就会升级锁为重量级锁 jdk6之前默认是自旋次数达到10次或者自旋线程数超过cpu核数的一半都会升级为重量级锁 jdk7增加了自适应自旋锁也就是自旋的次数变的不在固定 通过同一个锁上一次自旋的时间和拥有锁线程的状态来决定也就是如果线程自旋成功了那么下次自旋的最大次数就会增加因为JVM认为上次成功了那么这次也有很大概率成功反之如果很少会自旋成功那么下次就会减少自旋的次数甚至不自旋来避免cpu空转
synchronized 对于同步代码块 一般情况下一把锁会有一个monitorenter指令和两个monitorexit指令 加锁会执行monitorenter 释放锁会执行monitorexit如果产生异常也会执行monitorexit所以synchronized产生异常也可以释放锁 对于同步方法 会加上 ACC_SYNCHRONIZED 标识代表这个方法是同步方法如果方法持有ACC_SYNCHRONIZED 标识执行前就会去获取 monitor 执行完再释放monitor 对于静态同步方法 会加上 ACC_SYNCHRONIZED 和 ACC_STATIC 标识用于区分类锁和对象锁
synchronized 加锁流程
当执行monitorenter时 如果锁计数器为0就说明锁没有被其他线程持有虚拟机会将当前线程设置为锁的持有线程并且把锁计数器加1重入次数加1然后执行同步代码块的业务代码如果锁计数器不为0 且持有线程是当前线程虚拟机会把锁计数器加1如果不是就需要进入当前锁对象的阻塞队列等待其他线程释放锁 当执行monitoreixt时虚拟机会把锁计数器减1当锁计数器为0时会擦除锁的持有线程这样就释放了锁
锁升级到轻量级锁重量级锁后mark word中保存的就分别是线程栈帧里的锁记录指针和重量级锁指针不在保存hashcode 和GC的年龄这些信息的去向是 首先java中一个对象如果计算过一次哈希码就应该保持这个值不变除非用户手动重载hashcode方法就可以返回任意值如果哈希码经常变动会导致很多依赖哈希码的对象都存在风险 绝大多数对象的哈希码都来自于 object 的 hashcode 方法通过在对象头中存储计算结果来保证第一次计算过后在次调用hashcode 方法取到的哈希码就永远不会改变 无锁状态下mark word 中可以存储对象的 hash code 值当对象的 hashcode 方法第一次被调用调用时JVM就会生成对应的hash code值并存储到 mark word 中 对于偏向锁在线程获取偏向锁时会使用线程id和epoch 值覆盖 hash code值所在的位置所以如果一个对象已经计算过了哈希码这个对象就无法被设置为偏向锁 因为如果允许的话会导致hash code 值和线程id相互覆盖导致前后调用hashcode 方法的计算结构不一致所以偏向锁和哈希码不共存所以如果一个对象处于偏向锁状态锁是偏向锁但是已经释放过了锁被调用hashcode方法后会直接膨胀为轻量级锁如果一个对象处于偏向锁过程中锁是偏向锁且没有释放锁被调用hashcode方法后会直接膨胀为重量级锁 而对于轻量级锁JVM会在当前线程的栈帧中创建一个锁记录的空间用于存放锁对象的mark word 拷贝这个拷贝中就包含了hash code值和GC的年龄释放锁后会将这些信息写回对象头 升级到重量级锁后mark word 保存了重量级锁的ObjectMonitor 类里有字段记录非加锁状态下的mark word 锁释放后信息也会被写回到对象头
synchronized 锁的优缺点
偏向锁的优点是加锁和解锁不需要额外的消耗和执行非同步方法相比仅存在纳秒级的差距缺点是如果线程间存在竞争会带来额外的锁撤销的消耗所以只适用于只有一个线程访问同步块的场景轻量级锁的优点是即使存在线程的竞争也不会阻塞提高了程序的响应速度缺点是始终拿不到锁的线程自旋会消耗cpu适用于追求响应时间同步块执行时间很短的场景重量级锁线程间的竞争不会消耗cpu去自旋缺点是线程阻塞会导致响应缓慢适用于追求吞吐量同步块执行时间较长的情况
锁消除同步省略
在动态编译同步块的时候JIT编译器可以借助逃逸分析来判断同步块锁是否有加锁的必要如果没有就可以不考虑同步也就是所谓的锁消除因为加锁的代价是很高的消除锁可以大大提高并发性和性能这种情况字节码文件依然会有加锁操作但是执行的时候会去掉 public static void test4() {Object obj new Object();//例如这里每个线程进来都会new一个对象每个线程都有一个锁没有意义synchronized (obj){System.out.println(锁消除案例);}}锁粗化
如果对同一个对象执行了连续的加锁和解锁的操作那么 JIT 会将多个连续的加锁、解锁操作连接在一起扩展成一个范围更大的锁避免频繁的加锁和解锁 static Object lock new Object();public static void test5() {new Thread(()-{synchronized (lock){System.out.println(业务1);}synchronized (lock){System.out.println(业务2);}synchronized (lock){System.out.println(业务3);}},锁粗化案例).start();}
