医院网站建设要求免费建站免费网站申请

医院网站建设要求,免费建站免费网站申请,中国企业网中国商报,jsp和php哪个做网站快文章目录为什么需要这么多锁#xff1f;锁的“状态机”#xff1a;四种锁状态偏向锁#xff1a;专一的锁为什么需要偏向锁#xff1f;偏向锁的工作原理偏向锁的撤销轻量级锁#xff1a;温和的竞争为什么需要轻量级锁#xff1f;轻量级锁的工作原理自旋优化#xff1a;耐…文章目录为什么需要这么多锁锁的“状态机”四种锁状态偏向锁专一的锁为什么需要偏向锁偏向锁的工作原理偏向锁的撤销轻量级锁温和的竞争为什么需要轻量级锁轻量级锁的工作原理自旋优化耐心等待的策略重量级锁真正的强者重量级锁的实现重量级锁的工作流程锁升级的全过程实战场景分析场景一单线程环境适合偏向锁场景二低竞争环境适合轻量级锁场景三高竞争环境需要重量级锁锁优化的其他技术锁粗化Lock Coarsening锁消除Lock Elimination如何选择合适的锁策略总结参考文章大家好我是你们的技术老友科威舟今天我们要一起探索Synchronized锁的升级之路——从偏向锁、轻量级锁到重量级锁的奇幻之旅。如果你曾对Java并发编程感到头疼那么这篇文章就是你的布洛芬深入理解Java并发编程的锁优化让你的程序性能飞起来为什么需要这么多锁在开始之前我们先思考一个简单的问题为什么Java不直接用最强大的重量级锁而是要搞这么多锁状态想象一下你去一家快餐店点餐。重量级锁就像在收银台前修了一个小房间每次只能进入一个人点餐其他人必须在外面排队等待。这安全吗绝对安全但效率呢堪忧而现实中大多数情况是餐厅里其实没什么顾客没有竞争或者即使有多个顾客也是轮流点餐交替执行而不是同时挤在收银台前。JDK的开发者们也意识到了这个问题于是在JDK 1.6中对synchronized进行了大幅优化引入了我们今天要讲的锁升级机制。锁的“状态机”四种锁状态Java中的锁有四种状态它们的关系如下所示锁状态标志位特点无锁01对象未锁定偏向锁01优化同一线程重复获取锁的场景轻量级锁00优化多个线程交替执行同步块的场景重量级锁10真正的互斥锁适用于高竞争场景锁只能从低到高升级不能降级虽然有极少数特殊情况但一般认为不可降级。偏向锁专一的锁为什么需要偏向锁HotSpot的作者发现在大多数情况下锁不仅不存在多线程竞争而且总是由同一线程多次获得。比如你在一个线程安全的多步操作中可能会多次进入同一个同步块publicclassSafeCounter{privateintcount0;publicvoidsafeIncrement(){synchronized(this){count;// 其他操作...synchronized(this){// 再次进入同步块count;}}}}如果没有偏向锁每次进入同步块都需要执行CAS操作而CAS虽然比重量级锁高效但仍有开销。偏向锁的工作原理偏向锁的核心理念是如果锁始终由同一个线程使用就不要反复加锁解锁了。加锁过程检查对象头的Mark Word判断是否处于可偏向状态标志位为01是否偏向为0如果是可偏向状态通过CAS操作将当前线程ID记录到Mark Word中如果CAS成功该线程以后每次进入这个同步块都不需要任何同步操作举个例子偏向锁就像是你家的门锁。只有你家人同一线程有钥匙每次回家直接开门就行不需要每次都在门口检查身份证。偏向锁的撤销当有另一个线程尝试获取偏向锁时偏向锁就要被撤销了。这个过程需要等到全局安全点在这个时间点上没有正在执行的字节码然后检查原持有偏向锁的线程是否还存活。如果原线程已不存活或不在同步块中将对象设置为无锁状态然后新线程可以重新偏向或升级为轻量级锁如果原线程还在同步块中升级为轻量级锁偏向锁的适用场景只有一个线程访问同步块且不存在竞争的情况。在高并发场景下偏向锁反而会降低性能因为多了撤销操作此时可以通过-XX:-UseBiasedLocking禁用。轻量级锁温和的竞争为什么需要轻量级锁当偏向锁遇到竞争时就会升级为轻量级锁。轻量级锁适应的场景是线程交替执行同步块而不是真正的同时竞争。想象一下公司卫生间的使用情况多个人会使用但通常是轮流使用而不是同时挤在门口争夺使用权。轻量级锁的工作原理加锁过程在代码进入同步块时如果同步对象处于无锁状态JVM会在当前线程的栈帧中建立一个名为锁记录Lock Record的空间将对象头的Mark Word复制到锁记录中称为Displaced Mark Word使用CAS操作尝试将对象的Mark Word更新为指向锁记录的指针如果CAS成功当前线程获得锁如果失败表示存在竞争尝试自旋获取锁轻量级锁的释放使用CAS操作将Displaced Mark Word替换回对象头如果成功同步完成如果失败表示锁已膨胀需要在释放锁的同时唤醒被挂起的线程自旋优化耐心等待的策略轻量级锁在竞争失败后不会立即升级为重量级锁而是会进行自旋等待。自旋可以理解为“我再等一会儿说不定马上就能拿到锁了”。// 自旋的简单理解for(inti0;iMAX_SPIN_TIMES;i){if(tryGetLock()){// 获取锁成功return;}// 稍微等待一下再尝试shortWait();}// 自旋多次还没拿到锁升级为重量级锁upgradeToHeavyweightLock();JDK 1.6引入了适应性自旋意味着自旋时间不再固定而是由前一次在同一个锁上的自旋时间及锁的拥有者状态决定。重量级锁真正的强者当轻量级锁自旋超过一定次数或一个线程持有锁另一个在自旋又有第三个来访时轻量级锁会升级为重量级锁。重量级锁的实现重量级锁依赖于操作系统的mutex锁实现线程的阻塞和唤醒需要从用户态切换到内核态成本很高。重量级锁使用ObjectMonitor实现其主要结构包括ContentionList竞争队列所有请求锁的线程首先被放在这个队列中EntryList候选队列ContentionList中有资格成为候选资源的线程被移动到这里WaitSet等待集合调用wait()方法的线程被放置在这里Owner当前持有锁的线程重量级锁的工作流程线程尝试获取锁如果成功成为Owner如果失败线程被封装成ObjectWaiter对象加入到ContentionList中当持有锁的线程释放锁时会根据特定策略从ContentionList或EntryList中选取一个线程唤醒重量级锁就像医院的专家号每个人必须严格排队即使医生暂时闲着也得按规矩来。公平但效率可能不高。锁升级的全过程现在我们把整个锁升级过程串联起来初始状态对象被创建后处于可偏向状态但未偏向任何线程匿名偏向第一次加锁线程A首次进入同步块使用CAS将线程ID设置到对象头进入偏向锁状态同一线程重入线程A再次进入同步块检查对象头中的线程ID与自己一致直接通过无需同步操作出现竞争线程B尝试获取锁发现锁已被线程A偏向偏向锁撤销等待全局安全点检查线程A状态升级轻量级锁如果线程A仍需要锁升级为轻量级锁线程A成为锁持有者线程B自旋等待自旋过度如果线程B自旋等待时间过长或又有线程C来竞争锁升级重量级锁轻量级锁升级为重量级锁线程B和C进入阻塞状态实战场景分析场景一单线程环境适合偏向锁publicclassSingleThreadScenario{publicvoidprocess(){ListStringdatafetchData();synchronized(this){// 处理数据processData(data);}// 其他操作...synchronized(this){// 再次处理furtherProcess(data);}}}这种情况下偏向锁可以大幅提升性能因为同一线程多次获取锁时几乎零开销。场景二低竞争环境适合轻量级锁publicclassLowContentionScenario{publicvoidprocess(){ExecutorServiceexecutorExecutors.newFixedThreadPool(2);// 两个线程交替执行不是同时竞争for(inti0;i10;i){executor.submit(()-{synchronized(this){// 短暂的同步操作shortOperation();}});}}}这种情况下轻量级锁通过自旋避免线程阻塞提高响应速度。场景三高竞争环境需要重量级锁publicclassHighContentionScenario{privatefinalObjectlocknewObject();publicvoidhighContentionMethod(){ExecutorServiceexecutorExecutors.newFixedThreadPool(10);// 10个线程激烈竞争同一把锁for(inti0;i100;i){executor.submit(()-{synchronized(lock){// 较长的同步操作longRunningOperation();}});}}}这种情况下轻量级锁会导致大量自旋消耗CPU重量级锁虽然阻塞线程但总体效率更高。锁优化的其他技术除了锁升级JVM还提供了其他锁优化技术锁粗化Lock Coarsening将多个连续的锁操作合并为一个更大范围的锁操作。// 锁粗化前publicvoidappend(){stringBuffer.append(a);stringBuffer.append(b);stringBuffer.append(c);}// 锁粗化后JVM自动优化publicvoidappend(){// 将三次加锁解锁合并为一次synchronized(stringBuffer){stringBuffer.append(a);stringBuffer.append(b);stringBuffer.append(c);}}锁消除Lock EliminationJVM通过逃逸分析技术发现某些锁操作不可能被其他线程访问就会将这些锁操作消除。publicStringcreateString(){// stringBuffer是局部变量不可能被其他线程访问StringBufferstringBuffernewStringBuffer();stringBuffer.append(hello);stringBuffer.append(world);returnstringBuffer.toString();}这种情况下JVM会消除StringBuffer内部的同步操作。如何选择合适的锁策略如果确定是单线程环境可以开启偏向锁默认开启如果是低竞争环境轻量级锁是最佳选择如果是高竞争环境考虑禁用偏向锁和自旋锁直接使用重量级锁极端高并发场景考虑使用Java并发包中的ReentrantLock等更高级的锁机制可以通过以下JVM参数进行调优关闭偏向锁-XX:-UseBiasedLocking关闭自旋锁-XX:-UseSpinning批量重偏向阈值-XX:BiasedLockingBulkRebiasThreshold20总结Java的锁升级机制是一个精美的性能优化方案它体现了按需分配的思想根据实际的竞争情况提供不同级别的锁机制。偏向锁适用于单线程重复访问的场景轻量级锁适用于低竞争交替执行的场景重量级锁适用于高竞争的场景。理解这些锁的工作原理和升级过程有助于我们编写更高效的并发程序并在出现性能问题时能准确诊断。记住没有绝对的优劣只有适合的场景。选择合适的锁策略让你的程序在并发世界中游刃有余参考文章https://blog.51cto.com/universsky/5377002https://blog.csdn.net/chengyan_1992/article/details/124803701https://blog.csdn.net/w1475995549/article/details/139992087https://blog.csdn.net/lp284558195/article/details/115547269https://blog.csdn.net/MariaOzawa/article/details/107665689希望这篇文章能帮助你理解Java锁升级机制。如果有任何问题欢迎在评论区留言讨论下次我们将深入探讨Java并发包中的其他高级特性敬请期待更多技术干货欢迎关注微信公众号科威舟的AI笔记~【转载须知】转载请注明原文出处及作者信息