中國工程建設焊接協(xié)會網(wǎng)站,網(wǎng)站建設的一些銷售技巧,小語種建網(wǎng)站建設,有了域名怎么做網(wǎng)站目錄 從synchronized到Condition#xff1a;FooBar交替打印的進階之路 一、基礎(chǔ)解法#xff1a;能用但不夠好的synchronized版本 1.1 基礎(chǔ)版代碼實現(xiàn) 1.2 基礎(chǔ)版的核心痛點 二、進階解法#xff1a;ReentrantLock Condition精準控制 2.1 進階版代碼實現(xiàn)#xff08;工…目錄從synchronized到ConditionFooBar交替打印的進階之路一、基礎(chǔ)解法能用但不夠好的synchronized版本1.1 基礎(chǔ)版代碼實現(xiàn)1.2 基礎(chǔ)版的核心痛點二、進階解法ReentrantLock Condition精準控制2.1 進階版代碼實現(xiàn)工業(yè)級標準解法2.2 核心知識點拆解從陌生到熟悉維度1ReentrantLock——更靈活的顯式鎖維度2Condition——精準喚醒的“條件隊列”維度3while循環(huán)——延續(xù)的“虛假喚醒”防御三、執(zhí)行流程推演理解交替的本質(zhì)四、學習感悟多線程的“進階思維”五、擴展這些知識點能解決哪些問題六、總結(jié)從synchronized到ConditionFooBar交替打印的進階之路作為多線程編程的初學者我最近在啃LeetCode 1115「交替打印FooBar」這個經(jīng)典問題。一開始用自己熟悉的synchronized wait while實現(xiàn)了基礎(chǔ)版本但總覺得執(zhí)行不夠高效。直到接觸了ReentrantLock Condition的組合才發(fā)現(xiàn)多線程同步原來能如此精準靈活。這篇文章就記錄下我的學習過程從基礎(chǔ)解法的痛點出發(fā)帶你一步步理解這個進階方案的核心邏輯。在作答1115題的時候用最基礎(chǔ)的synchronizedwhilewaitnotifyAll能正確回答問題但是學習編程的都知道正確不代表性能用基礎(chǔ)的知識做出了的速度實在太慢所以就去回憶了之前學的ReentrantLock。一、基礎(chǔ)解法能用但不夠好的synchronized版本在學習ReentrantLock之前我對多線程同步的認知停留在synchronized關(guān)鍵字上。針對FooBar問題基礎(chǔ)思路很明確用一個布爾變量做輪次標記配合wait()和notifyAll()實現(xiàn)線程通信再用while循環(huán)防止虛假喚醒。1.1 基礎(chǔ)版代碼實現(xiàn)? class FooBar { private int n; private boolean isFooTurn true; // true為foo輪次false為bar輪次 private final Object lock new Object(); ? public FooBar(int n) { this.n n; } ? public void foo(Runnable printFoo) throws InterruptedException { for (int i 0; i n; i) { synchronized (lock) { // 不是foo輪次就等待 while (!isFooTurn) { lock.wait(); } printFoo.run(); isFooTurn false; // 切換輪次 lock.notifyAll(); // 喚醒所有等待線程 } } } ? public void bar(Runnable printBar) throws InterruptedException { for (int i 0; i n; i) { synchronized (lock) { // 不是bar輪次就等待 while (isFooTurn) { lock.wait(); } printBar.run(); isFooTurn true; // 切換輪次 lock.notifyAll(); // 喚醒所有等待線程 } } } }1.2 基礎(chǔ)版的核心痛點這個版本能滿足“交替打印”的基本需求但在實際運行中會發(fā)現(xiàn)明顯瓶頸——notifyAll()方法是“無差別喚醒”。比如foo執(zhí)行完后只需要喚醒等待的bar線程但notifyAll()會把所有等待lock的線程都喚醒包括可能存在的其他線程雖然這個問題里只有兩個線程。被喚醒的線程會重新競爭鎖沒搶到的線程只能再次阻塞這就產(chǎn)生了“無意義的鎖競爭開銷”。當n很大比如100萬次交替時這種開銷會被無限放大執(zhí)行效率大幅下降。二、進階解法ReentrantLock Condition精準控制為了解決“無差別喚醒”的問題我接觸到了JUCjava.util.concurrent包中的ReentrantLock和Condition。這對組合的核心優(yōu)勢是“精準喚醒”——可以只喚醒需要執(zhí)行的目標線程徹底消除冗余的鎖競爭。2.1 進階版代碼實現(xiàn)工業(yè)級標準解法? import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.ReentrantLock; ? class FooBar { private int n; // 輪次標記false→foo輪次true→bar輪次 private boolean flag false; // 可重入鎖替代synchronized private final ReentrantLock lock new ReentrantLock(); // 專屬條件隊列分別管理等待的foo和bar線程 private final Condition fooCond lock.newCondition(); private final Condition barCond lock.newCondition(); ? public FooBar(int n) { this.n n; } ? public void foo(Runnable printFoo) throws InterruptedException { for (int i 0; i n; i) { lock.lock(); // 加鎖顯式操作 try { // 不是foo輪次→進入foo專屬隊列等待 while (flag true) { fooCond.await(); // 釋放鎖僅foo線程等待 } printFoo.run(); // 執(zhí)行核心邏輯 flag true; // 切換為bar輪次 barCond.signal(); // 精準喚醒bar線程 } finally { lock.unlock(); // 必須在finally釋放鎖防止死鎖 } } } ? public void bar(Runnable printBar) throws InterruptedException { for (int i 0; i n; i) { lock.lock(); try { // 不是bar輪次→進入bar專屬隊列等待 while (flag false) { barCond.await(); } printBar.run(); flag false; // 切換為foo輪次 fooCond.signal(); // 精準喚醒foo線程 } finally { lock.unlock(); } } } }2.2 核心知識點拆解從陌生到熟悉作為初學者我一開始對ReentrantLock和Condition充滿陌生感但把它們和熟悉的synchronized對比后很快就理解了核心邏輯。下面從三個關(guān)鍵維度拆解維度1ReentrantLock——更靈活的顯式鎖ReentrantLock翻譯為“可重入鎖”是synchronized的增強版核心是“顯式操作”加鎖解鎖用lock.lock()加鎖、lock.unlock()解鎖替代synchronized的隱式加鎖必須在finally釋放顯式鎖不會像synchronized那樣自動釋放放在finally中能保證即使發(fā)生異常鎖也能正常釋放避免死鎖可重入特性同一線程可以多次獲取同一把鎖不會自己阻塞自己比如遞歸調(diào)用加鎖方法。對我來說最直觀的感受是“控制權(quán)變多了”——可以自主決定加鎖和解鎖的時機而不是依賴代碼塊的作用域。維度2Condition——精準喚醒的“條件隊列”這是進階版的核心也是解決notifyAll()痛點的關(guān)鍵。Condition可以理解為“綁定在鎖上的專屬等待隊列”每個Condition對應一類需要等待的線程。創(chuàng)建方式通過lock.newCondition()創(chuàng)建一個鎖可以綁定多個Condition核心方法await()替代Object.wait()讓當前線程釋放鎖并進入該Condition的等待隊列signal()替代Object.notify()只喚醒該Condition隊列中的一個線程精準性體現(xiàn)foo執(zhí)行完后調(diào)用barCond.signal()只會喚醒等待的bar線程不會打擾其他線程即使有。維度3while循環(huán)——延續(xù)的“虛假喚醒”防御雖然用了新的API但“防止虛假喚醒”的核心邏輯沒有變依然需要用while循環(huán)檢查輪次標記而不是if。所謂“虛假喚醒”是指線程可能在沒有被signal()喚醒的情況下突然從await()中返回JVM底層機制導致。如果用if判斷虛假喚醒后會直接執(zhí)行打印邏輯導致順序混亂而while會循環(huán)檢查輪次確保只有滿足條件時才繼續(xù)執(zhí)行。三、執(zhí)行流程推演理解交替的本質(zhì)為了徹底搞懂代碼邏輯我手動推演了n2時的執(zhí)行流程這對理解線程交互非常有幫助初始狀態(tài)flagfalsefoo輪次foo和bar線程啟動后爭搶lock第一次foo執(zhí)行foo搶到鎖while(flagtrue)不成立執(zhí)行printFoo.run()設置flagtrue調(diào)用barCond.signal()喚醒bar線程finally中釋放鎖foo線程退出同步塊準備下一輪循環(huán)。第一次bar執(zhí)行被喚醒的bar搶到鎖while(flagfalse)不成立執(zhí)行printBar.run()設置flagfalse調(diào)用fooCond.signal()喚醒foo線程finally中釋放鎖bar線程退出同步塊。第二次循環(huán)重復步驟2-3直到foo和bar都完成n次執(zhí)行最終輸出foo bar foo bar。四、學習感悟多線程的“進階思維”從synchronized到ReentrantLock Condition我不僅學會了一個問題的更優(yōu)解法更體會到多線程編程的核心思維轉(zhuǎn)變從“能用”到“好用”基礎(chǔ)解法能滿足功能但工業(yè)級開發(fā)更關(guān)注效率和健壯性。Condition的精準喚醒就是從“能用”到“好用”的關(guān)鍵理解“鎖”的本質(zhì)鎖不僅是“互斥”的工具更是“線程通信”的橋梁。ReentrantLock通過綁定Condition讓線程通信更精準API是工具邏輯是核心不管是wait()還是await()核心都是“釋放鎖等待-被喚醒搶鎖”的循環(huán)while防虛假喚醒的邏輯永遠適用。五、擴展這些知識點能解決哪些問題這個解法的核心思路鎖條件隊列狀態(tài)標記不是只針對FooBar問題而是多線程交替執(zhí)行的通用方案能解決很多類似問題LeetCode 1116「打印零與奇偶數(shù)」用多個Condition分別管理打印0、奇數(shù)、偶數(shù)的線程交替打印ABC創(chuàng)建3個ConditionA執(zhí)行完喚醒BB執(zhí)行完喚醒CC執(zhí)行完喚醒A生產(chǎn)者-消費者問題用兩個Condition分別管理生產(chǎn)者和消費者線程實現(xiàn)供需平衡。六、總結(jié)作為多線程初學者FooBar問題的進階解法讓我打開了JUC并發(fā)編程的大門。ReentrantLock的顯式控制和Condition的精準喚醒看似復雜實則是對synchronized機制的優(yōu)化和延伸。核心知識點回顧1. 顯式鎖ReentrantLock的lock()/unlock()必須在finally釋放 2. 條件隊列Condition的await()/signal()實現(xiàn)精準線程通信 3. 健壯性while循環(huán)防御虛假喚醒保證執(zhí)行順序穩(wěn)定 4. 核心邏輯狀態(tài)標記控制輪次鎖保證原子性和可見性。如果你也剛學完synchronized建議從這個問題入手手動推演執(zhí)行流程相信你會和我一樣對多線程同步有更深刻的理解~