.jpg)
是的，synchronized同步塊內(nèi)拋出異常時(shí)會(huì)自動(dòng)釋放鎖。1. synchronized依賴(lài)jvm的monitor機(jī)制，在線程退出同步塊時(shí)無(wú)論是否異常都會(huì)執(zhí)行monitorexit指令釋放鎖；2. 反編譯代碼可見(jiàn)monitorenter和monitorexit指令對(duì)稱(chēng)存在；3. 異常導(dǎo)致鎖釋放后，其他線程需競(jìng)爭(zhēng)獲取鎖，具體由jvm調(diào)度策略決定；4. 為防止異常影響程序其他部分，應(yīng)在synchronized塊內(nèi)使用try-catch捕獲異常并在finally塊中清理資源；5. 與reentrantlock不同，synchronized隱式釋放鎖而reentrantlock需顯式在finally中調(diào)用unlock()方法。
是的，當(dāng) synchronized 同步塊內(nèi)拋出異常時(shí)，持有的鎖會(huì)自動(dòng)釋放。這實(shí)際上是 synchronized 關(guān)鍵字的核心特性之一，確保了即使在異常情況下，鎖也能被正確釋放，避免死鎖的發(fā)生。
解決方案
synchronized 依賴(lài)于 JVM 的 monitor 機(jī)制。當(dāng)線程進(jìn)入 synchronized 塊時(shí)，會(huì)嘗試獲取 monitor 的所有權(quán)，如果獲取成功，則持有鎖；當(dāng)線程正常退出 synchronized 塊或者因?yàn)楫惓Ｍ顺鰰r(shí)，JVM 會(huì)負(fù)責(zé)釋放 monitor，從而釋放鎖。
具體來(lái)說(shuō)，可以這樣理解：synchronized 塊實(shí)際上會(huì)被編譯成包含 monitorenter 和 monitorexit 指令的代碼。monitorenter 用于獲取鎖，而 monitorexit 用于釋放鎖。無(wú)論 synchronized 塊中的代碼是否拋出異常，JVM 都會(huì)確保執(zhí)行 monitorexit 指令，從而釋放鎖。
如果想要更清晰地看到這一點(diǎn)，可以嘗試使用 Javap -c 命令反編譯包含 synchronized 塊的 Java 代碼，你會(huì)看到 monitorenter 和 monitorexit 指令。
synchronized塊中出現(xiàn)異常，鎖釋放后，其他線程會(huì)立即獲得鎖嗎？
不一定立即獲得。即使鎖被釋放，其他線程也需要競(jìng)爭(zhēng)才能獲得鎖。釋放鎖僅僅是讓鎖變得可用，至于哪個(gè)線程能獲得，取決于 JVM 的調(diào)度策略和各個(gè)線程的優(yōu)先級(jí)等因素。簡(jiǎn)單來(lái)說(shuō)，鎖釋放后，所有等待該鎖的線程都會(huì)進(jìn)入就緒狀態(tài)，然后由 JVM 決定哪個(gè)線程先執(zhí)行。這與操作系統(tǒng)的進(jìn)程調(diào)度類(lèi)似，具有一定的隨機(jī)性。如果持有鎖的時(shí)間很短，可能另一個(gè)線程還沒(méi)有來(lái)得及被調(diào)度到，鎖就被再次獲取了。
如何確保synchronized代碼塊中的異常不會(huì)影響程序的其他部分？
使用 try-catch 塊來(lái)捕獲 synchronized 塊中的異常。即使 synchronized 塊內(nèi)的代碼拋出異常，catch 塊也能處理它，防止異常傳播到程序的其他部分，從而保證程序的穩(wěn)定性。
例如：
public class SynchronizedExample { private final Object lock = new Object(); public void doSomething() { synchronized (lock) { try { // 可能會(huì)拋出異常的代碼 System.out.println("開(kāi)始執(zhí)行同步代碼塊"); if (true) { throw new RuntimeException("模擬異常"); } System.out.println("同步代碼塊執(zhí)行完畢"); // 這行代碼可能不會(huì)執(zhí)行 } catch (Exception e) { System.err.println("捕獲到異常: " + e.getMessage()); // 處理異常，例如記錄日志、清理資源等 } finally { System.out.println("finally 塊執(zhí)行"); // 無(wú)論是否發(fā)生異常，finally 塊都會(huì)執(zhí)行 } } System.out.println("同步代碼塊之外的代碼"); // 這行代碼總是會(huì)執(zhí)行 } public static void main(String[] args) { SynchronizedExample example = new SynchronizedExample(); example.doSomething(); } }
在這個(gè)例子中，即使 synchronized 塊中的代碼拋出了 RuntimeException，catch 塊也會(huì)捕獲它并進(jìn)行處理。finally 塊中的代碼也會(huì)被執(zhí)行，確保資源得到清理。這樣，異常就被限制在了 doSomething 方法內(nèi)部，不會(huì)影響程序的其他部分。
synchronized和ReentrantLock在異常處理方面有什么不同？
synchronized 依賴(lài)于 JVM 隱式地釋放鎖，而 ReentrantLock 需要顯式地釋放鎖。這意味著在使用 ReentrantLock 時(shí)，必須在 finally 塊中調(diào)用 unlock() 方法來(lái)釋放鎖，否則可能會(huì)導(dǎo)致死鎖。
import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class ReentrantLockExample { private final Lock lock = new ReentrantLock(); public void doSomething() { lock.lock(); try { // 可能會(huì)拋出異常的代碼 System.out.println("開(kāi)始執(zhí)行同步代碼塊"); if (true) { throw new RuntimeException("模擬異常"); } System.out.println("同步代碼塊執(zhí)行完畢"); // 這行代碼可能不會(huì)執(zhí)行 } catch (Exception e) { System.err.println("捕獲到異常: " + e.getMessage()); // 處理異常，例如記錄日志、清理資源等 } finally { lock.unlock(); // 必須在 finally 塊中釋放鎖 System.out.println("finally 塊執(zhí)行"); } System.out.println("同步代碼塊之外的代碼"); // 這行代碼總是會(huì)執(zhí)行 } public static void main(String[] args) { ReentrantLockExample example = new ReentrantLockExample(); example.doSomething(); } }
從異常處理的角度來(lái)看，ReentrantLock 比 synchronized 更加靈活，但也更容易出錯(cuò)。如果忘記在 finally 塊中釋放鎖，就會(huì)導(dǎo)致死鎖。因此，在使用 ReentrantLock 時(shí)，必須非常小心，確保鎖總是被正確釋放。
.png)
