工具网站有哪些,南平 建网站,python抓取更新wordpress,百度搜索风云榜排行榜目录
synchronized 特性
synchronized 优化机制
锁升级#xff08;锁膨胀#xff09;
其他优化机制
锁消除
锁粗化 synchronized 特性 开始时是乐观锁#xff0c;如果锁冲突频繁#xff0c;就转为悲观锁开始是轻量级锁#xff0c;如果锁被持有的时间较长#xff0c…目录
synchronized 特性
synchronized 优化机制
锁升级锁膨胀
其他优化机制
锁消除
锁粗化 synchronized 特性 开始时是乐观锁如果锁冲突频繁就转为悲观锁开始是轻量级锁如果锁被持有的时间较长就转化成重量级锁实现轻量级锁的时候大概率用到的自旋锁策略是一个不公平锁是一种可重入锁不是读写锁 synchronized 优化机制 锁升级锁膨胀 JVM 将 synchronized 分为以下四个状态会根据情况依次进行升级 无锁偏向锁轻量级锁重量级锁 无锁状态 即代码还未执行到加锁的代码块中该状态称为无锁状态 偏向锁状态 偏向锁的获取和释放操作开销非常低几乎可以忽略不记因为它不需要进行线程间的竞争和同步当一个线程第一次尝试获取锁时会将锁的标记设置为偏向锁并将线程ID 记录在锁的元数据中当同一个线程再次尝试获取锁时无需竞争直接获取到锁不需要进行任何同步操作如果在整个使用锁的过程中都没有出现锁竞争那在 synchronized 执行完之后取消偏向锁即可如果期间另一个线程尝试获取锁偏向锁会自动撤销升级为真正的加锁状态从而另一个线程也就只能阻塞等待了 注意 偏向锁的使用是 JVM 自动进行的开发人员无需显式地使用偏向锁JVM 会根据锁的竞争情况自动选择使用偏向锁、轻量级锁、重量级锁以优化锁的性能和吞吐量 轻量级锁状态 当 synchronized 发生锁竞争的时候就会从偏向锁升级成轻量级锁此时 synchronized 相当于通过 CAS 操作以不断自旋的方式来进行加锁如果别人很快就释放锁了自旋是划算的但是如果迟迟拿不到锁一直自旋显然是不划算的因为会长期占用的 CPU 资源造成性能损失 重量级锁状态 当然 synchronized 自旋不是无休止的自旋自旋到一定程度之后就会再次升级成 重量级锁挂起等待锁如果线程进行了重量级锁的加锁并且发生锁竞争此时线程就会被放到阻塞队列中暂时不参与 CPU 调度了然后直到锁被释放这个线程才有机会被调度到并且有机会获取到锁一旦 线程被切换出 CPU此时就会变得比较低效了 注意 在 JVM 主流实现中只有锁升级没有锁降级 其他优化机制 锁消除 编译器智能的判定看当前的代码是否真的要加锁如果这个场景不需要加锁程序员也加了就自动把锁给干掉 实例理解 StringBuffer 中的关键方法都带有 synchronized 如果在单线程中使用 StringBuffersynchronized 加了也白加此时编译器就会直接把这些加锁操作消除掉了 锁粗化 锁的粒度 synchronized 包含的代码越多粒度就越粗包含的代码越少粒度就越细 通常理解 一般情况下认为锁的粒度细一点是比较好的加锁部分的代码是不能并发执行的锁的粒度越细能并发的代码就越多反之越少但有些情况下锁的粒度粗一些反而更好 如上图这里的间隙非常小就算并发了也没啥太大效果然而每次加锁都是带有开销的此时并发节省的时间反而不如加锁的开销大所以我们不如将其转变为直接加一把大锁 上述过程就相当于锁粗化
