1. 程式人生 > >個人珍藏的80道多執行緒併發面試題(1-10答案解析)

個人珍藏的80道多執行緒併發面試題(1-10答案解析)

前言

個人珍藏的80道Java多執行緒/併發經典面試題,因為篇幅太長,現在先給出1-10的答案解析哈,後面一起完善,並且上傳github哈~

https://github.com/whx123/JavaHome

「公眾號:撿田螺的小男孩」

1. synchronized的實現原理以及鎖優化?

synchronized的實現原理

  • synchronized作用於「方法」或者「程式碼塊」,保證被修飾的程式碼在同一時間只能被一個執行緒訪問。
  • synchronized修飾程式碼塊時,JVM採用「monitorenter、monitorexit」兩個指令來實現同步
  • synchronized修飾同步方法時,JVM採用「ACC_SYNCHRONIZED」標記符來實現同步
  • monitorenter、monitorexit或者ACC_SYNCHRONIZED都是「基於Monitor實現」的
  • 例項物件裡有物件頭,物件頭裡面有Mark Word,Mark Word指標指向了「monitor」
  • Monitor其實是一種「同步工具」,也可以說是一種「同步機制」。
  • 在Java虛擬機器(HotSpot)中,Monitor是由「ObjectMonitor實現」的。ObjectMonitor體現出Monitor的工作原理~
ObjectMonitor() {
    _header       = NULL;
    _count        = 0; // 記錄執行緒獲取鎖的次數
    _waiters      = 0,
    _recursions   = 0;  //鎖的重入次數
    _object       = NULL;
    _owner        = NULL;  // 指向持有ObjectMonitor物件的執行緒
    _WaitSet      = NULL;  // 處於wait狀態的執行緒,會被加入到_WaitSet
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ;
    FreeNext      = NULL ;
    _EntryList    = NULL ;  // 處於等待鎖block狀態的執行緒,會被加入到該列表
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
  }

ObjectMonitor的幾個關鍵屬性 _count、_recursions、_owner、_WaitSet、 _EntryList 體現了monitor的工作原理

鎖優化

在討論鎖優化前,先看看JAVA物件頭(32位JVM)中Mark Word的結構圖吧~

Mark Word儲存物件自身的執行資料,如「雜湊碼、GC分代年齡、鎖狀態標誌、偏向時間戳(Epoch)」 等,為什麼區分「偏向鎖、輕量級鎖、重量級鎖」等幾種鎖狀態呢?

在JDK1.6之前,synchronized的實現直接呼叫ObjectMonitor的enter和exit,這種鎖被稱之為「重量級鎖」。從JDK6開始,HotSpot虛擬機器開發團隊對Java中的鎖進行優化,如增加了適應性自旋、鎖消除、鎖粗化、輕量級鎖和偏向鎖等優化策略。

  • 偏向鎖:在無競爭的情況下,把整個同步都消除掉,CAS操作都不做。
  • 輕量級鎖:在沒有多執行緒競爭時,相對重量級鎖,減少作業系統互斥量帶來的效能消耗。但是,如果存在鎖競爭,除了互斥量本身開銷,還額外有CAS操作的開銷。
  • 自旋鎖:減少不必要的CPU上下文切換。在輕量級鎖升級為重量級鎖時,就使用了自旋加鎖的方式
  • 鎖粗化:將多個連續的加鎖、解鎖操作連線在一起,擴充套件成一個範圍更大的鎖。

舉個例子,買門票進動物園。老師帶一群小朋友去參觀,驗票員如果知道他們是個集體,就可以把他們看成一個整體(鎖租化),一次性驗票過,而不需要一個個找他們驗票。

  • 鎖消除:虛擬機器即時編譯器在執行時,對一些程式碼上要求同步,但是被檢測到不可能存在共享資料競爭的鎖進行削除。

有興趣的朋友們可以看看我這篇文章: Synchronized解析——如果你願意一層一層剝開我的心[1]

2. ThreadLocal原理,使用注意點,應用場景有哪些?

回答四個主要點:

  • ThreadLocal是什麼?
  • ThreadLocal原理
  • ThreadLocal使用注意點
  • ThreadLocal的應用場景

ThreadLocal是什麼?

ThreadLocal,即執行緒本地變數。如果你建立了一個ThreadLocal變數,那麼訪問這個變數的每個執行緒都會有這個變數的一個本地拷貝,多個執行緒操作這個變數的時候,實際是操作自己本地記憶體裡面的變數,從而起到執行緒隔離的作用,避免了執行緒安全問題。

//建立一個ThreadLocal變數
static ThreadLocal<String> localVariable = new ThreadLocal<>();

ThreadLocal原理

ThreadLocal記憶體結構圖:

由結構圖是可以看出:

  • Thread物件中持有一個ThreadLocal.ThreadLocalMap的成員變數。
  • ThreadLocalMap內部維護了Entry陣列,每個Entry代表一個完整的物件,key是ThreadLocal本身,value是ThreadLocal的泛型值。

對照著幾段關鍵原始碼來看,更容易理解一點哈~

public class Thread implements Runnable {
   //ThreadLocal.ThreadLocalMap是Thread的屬性
   ThreadLocal.ThreadLocalMap threadLocals = null;
}

ThreadLocal中的關鍵方法set()和get()

    public void set(T value) {
        Thread t = Thread.currentThread(); //獲取當前執行緒t
        ThreadLocalMap map = getMap(t);  //根據當前執行緒獲取到ThreadLocalMap
        if (map != null)
            map.set(this, value); //K,V設定到ThreadLocalMap中
        else
            createMap(t, value); //建立一個新的ThreadLocalMap
    }

    public T get() {
        Thread t = Thread.currentThread();//獲取當前執行緒t
        ThreadLocalMap map = getMap(t);//根據當前執行緒獲取到ThreadLocalMap
        if (map != null) {
            //由this(即ThreadLoca物件)得到對應的Value,即ThreadLocal的泛型值
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value; 
                return result;
            }
        }
        return setInitialValue();
    }

ThreadLocalMap的Entry陣列

static class ThreadLocalMap {
    static class Entry extends WeakReference<ThreadLocal<?>> {
        /** The value associated with this ThreadLocal. */
        Object value;

        Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    }
}

所以怎麼回答「ThreadLocal的實現原理」?如下,最好是能結合以上結構圖一起說明哈~

  • Thread類有一個型別為ThreadLocal.ThreadLocalMap的例項變數threadLocals,即每個執行緒都有一個屬於自己的ThreadLocalMap。
  • ThreadLocalMap內部維護著Entry陣列,每個Entry代表一個完整的物件,key是ThreadLocal本身,value是ThreadLocal的泛型值。
  • 每個執行緒在往ThreadLocal裡設定值的時候,都是往自己的ThreadLocalMap裡存,讀也是以某個ThreadLocal作為引用,在自己的map裡找對應的key,從而實現了執行緒隔離。

ThreadLocal 記憶體洩露問題

先看看一下的TreadLocal的引用示意圖哈,

ThreadLocalMap中使用的 key 為 ThreadLocal 的弱引用,如下

弱引用:只要垃圾回收機制一執行,不管JVM的記憶體空間是否充足,都會回收該物件佔用的記憶體。

弱引用比較容易被回收。因此,如果ThreadLocal(ThreadLocalMap的Key)被垃圾回收器回收了,但是因為ThreadLocalMap生命週期和Thread是一樣的,它這時候如果不被回收,就會出現這種情況:ThreadLocalMap的key沒了,value還在,這就會「造成了記憶體洩漏問題」。

如何「解決記憶體洩漏問題」?使用完ThreadLocal後,及時呼叫remove()方法釋放記憶體空間。

ThreadLocal的應用場景

  • 資料庫連線池
  • 會話管理中使用

3. synchronized和ReentrantLock的區別?

我記得校招的時候,這道面試題出現的頻率還是挺高的~可以從鎖的實現、功能特點、效能等幾個維度去回答這個問題,

  • 「鎖的實現:」 synchronized是Java語言的關鍵字,基於JVM實現。而ReentrantLock是基於JDK的API層面實現的(一般是lock()和unlock()方法配合try/finally 語句塊來完成。)
  • 「效能:」 在JDK1.6鎖優化以前,synchronized的效能比ReenTrantLock差很多。但是JDK6開始,增加了適應性自旋、鎖消除等,兩者效能就差不多了。
  • 「功能特點:」 ReentrantLock 比 synchronized 增加了一些高階功能,如等待可中斷、可實現公平鎖、可實現選擇性通知。
  • ReentrantLock提供了一種能夠中斷等待鎖的執行緒的機制,通過lock.lockInterruptibly()來實現這個機制。
  • ReentrantLock可以指定是公平鎖還是非公平鎖。而synchronized只能是非公平鎖。所謂的公平鎖就是先等待的執行緒先獲得鎖。
  • synchronized與wait()和notify()/notifyAll()方法結合實現等待/通知機制,ReentrantLock類藉助Condition介面與newCondition()方法實現。
  • ReentrantLock需要手工宣告來加鎖和釋放鎖,一般跟finally配合釋放鎖。而synchronized不用手動釋放鎖。

4. 說說CountDownLatch與CyclicBarrier區別

  • CountDownLatch:一個或者多個執行緒,等待其他多個執行緒完成某件事情之後才能執行;
  • CyclicBarrier:多個執行緒互相等待,直到到達同一個同步點,再繼續一起執行。

舉個例子吧:

  • CountDownLatch:假設老師跟同學約定週末在公園門口集合,等人齊了再發門票。那麼,發門票(這個主執行緒),需要等各位同學都到齊(多個其他執行緒都完成),才能執行。
  • CyclicBarrier:多名短跑運動員要開始田徑比賽,只有等所有運動員準備好,裁判才會鳴槍開始,這時候所有的運動員才會疾步如飛。

5. Fork/Join框架的理解

Fork/Join框架是Java7提供的一個用於並行執行任務的框架,是一個把大任務分割成若干個小任務,最終彙總每個小任務結果後得到大任務結果的框架。

Fork/Join框架需要理解兩個點,「分而治之」和「工作竊取演算法」。

「分而治之」

以上Fork/Join框架的定義,就是分而治之思想的體現啦

「工作竊取演算法」

把大任務拆分成小任務,放到不同佇列執行,交由不同的執行緒分別執行時。有的執行緒優先把自己負責的任務執行完了,其他執行緒還在慢慢悠悠處理自己的任務,這時候為了充分提高效率,就需要工作盜竊演算法啦~

工作盜竊演算法就是,「某個執行緒從其他佇列中竊取任務進行執行的過程」。一般就是指做得快的執行緒(盜竊執行緒)搶慢的執行緒的任務來做,同時為了減少鎖競爭,通常使用雙端佇列,即快執行緒和慢執行緒各在一端。

6. 為什麼我們呼叫start()方法時會執行run()方法,為什麼我們不能直接呼叫run()方法?

看看Thread的start方法說明哈~

    /**
     * Causes this thread to begin execution; the Java Virtual Machine
     * calls the <code>run</code> method of this thread.
     * <p>
     * The result is that two threads are running concurrently: the
     * current thread (which returns from the call to the
     * <code>start</code> method) and the other thread (which executes its
     * <code>run</code> method).
     * <p>
     * It is never legal to start a thread more than once.
     * In particular, a thread may not be restarted once it has completed
     * execution.
     *
     * @exception  IllegalThreadStateException  if the thread was already
     *               started.
     * @see        #run()
     * @see        #stop()
     */
    public synchronized void start() {
     ......
    }

JVM執行start方法,會另起一條執行緒執行thread的run方法,這才起到多執行緒的效果~ 「為什麼我們不能直接呼叫run()方法?」 如果直接呼叫Thread的run()方法,其方法還是執行在主執行緒中,沒有起到多執行緒效果。

7. CAS?CAS 有什麼缺陷,如何解決?

CAS,Compare and Swap,比較並交換;

CAS 涉及3個運算元,記憶體地址值V,預期原值A,新值B; 如果記憶體位置的值V與預期原A值相匹配,就更新為新值B,否則不更新

CAS有什麼缺陷?

「ABA 問題」

併發環境下,假設初始條件是A,去修改資料時,發現是A就會執行修改。但是看到的雖然是A,中間可能發生了A變B,B又變回A的情況。此時A已經非彼A,資料即使成功修改,也可能有問題。

可以通過AtomicStampedReference「解決ABA問題」,它,一個帶有標記的原子引用類,通過控制變數值的版本來保證CAS的正確性。

「迴圈時間長開銷」

自旋CAS,如果一直迴圈執行,一直不成功,會給CPU帶來非常大的執行開銷。

很多時候,CAS思想體現,是有個自旋次數的,就是為了避開這個耗時問題~

「只能保證一個變數的原子操作。」

CAS 保證的是對一個變數執行操作的原子性,如果對多個變數操作時,CAS 目前無法直接保證操作的原子性的。

可以通過這兩個方式解決這個問題:

  • 使用互斥鎖來保證原子性;
  • 將多個變數封裝成物件,通過AtomicReference來保證原子性。

有興趣的朋友可以看看我之前的這篇實戰文章哈~ CAS樂觀鎖解決併發問題的一次實踐[2]

9. 如何保證多執行緒下i++ 結果正確?

  • 使用迴圈CAS,實現i++原子操作
  • 使用鎖機制,實現i++原子操作
  • 使用synchronized,實現i++原子操作

沒有程式碼demo,感覺是沒有靈魂的~ 如下:

/**
 *  @Author 撿田螺的小男孩
 */
public class AtomicIntegerTest {

    private static AtomicInteger atomicInteger = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        testIAdd();
    }

    private static void testIAdd() throws InterruptedException {
        //建立執行緒池
        ExecutorService executorService = Executors.newFixedThreadPool(2);
        for (int i = 0; i < 1000; i++) {
            executorService.execute(() -> {
                for (int j = 0; j < 2; j++) {
                    //自增並返回當前值
                    int andIncrement = atomicInteger.incrementAndGet();
                    System.out.println("執行緒:" + Thread.currentThread().getName() + " count=" + andIncrement);
                }
            });
        }
        executorService.shutdown();
        Thread.sleep(100);
        System.out.println("最終結果是 :" + atomicInteger.get());
    }
    
}

執行結果:

...
執行緒:pool-1-thread-1 count=1997
執行緒:pool-1-thread-1 count=1998
執行緒:pool-1-thread-1 count=1999
執行緒:pool-1-thread-2 count=315
執行緒:pool-1-thread-2 count=2000
最終結果是 :2000

10. 如何檢測死鎖?怎麼預防死鎖?死鎖四個必要條件

死鎖是指多個執行緒因競爭資源而造成的一種互相等待的僵局。如圖感受一下: 「死鎖的四個必要條件:」

  • 互斥:一次只有一個程序可以使用一個資源。其他程序不能訪問已分配給其他程序的資源。
  • 佔有且等待:當一個程序在等待分配得到其他資源時,其繼續佔有已分配得到的資源。
  • 非搶佔:不能強行搶佔程序中已佔有的資源。
  • 迴圈等待:存在一個封閉的程序鏈,使得每個資源至少佔有此鏈中下一個程序所需要的一個資源。

「如何預防死鎖?」

  • 加鎖順序(執行緒按順序辦事)
  • 加鎖時限 (執行緒請求所加上許可權,超時就放棄,同時釋放自己佔有的鎖)
  • 死鎖檢測

參考與感謝

牛頓說,我之所以看得遠,是因為我站在巨人的肩膀上~ 謝謝以下各位前輩哈~

  • 面試必問的CAS,你懂了嗎?[3]
  • Java多執行緒:死鎖[4]
  • ReenTrantLock可重入鎖(和synchronized的區別)總結[5]
  • 聊聊併發(八)——Fork/Join 框架介紹[6]

個人公眾號

  • 覺得寫得好的小夥伴給個點贊+關注啦,謝謝~
  • 如果有寫得不正確的地方,麻煩指出,感激不盡。
  • 同時非常期待小夥伴們能夠關注我公眾號,後面慢慢推出更好的乾貨~嘻嘻
  • github地址:https://github.com/whx123/JavaHome

Reference

[1]

Synchronized解析——如果你願意一層一層剝開我的心: https://juejin.im/post/5d5374076fb9a06ac76da894#comment

[2]

CAS樂觀鎖解決併發問題的一次實踐: https://juejin.im/post/5d0616ade51d457756536791

[3]

面試必問的CAS,你懂了嗎?: https://blog.csdn.net/v123411739/article/details/79561458

[4]

Java多執行緒:死鎖: https://www.cnblogs.com/xiaoxi/p/8311034.html

[5]

ReenTrantLock可重入鎖(和synchronized的區別)總結: https://blog.csdn.net/qq838642798/article/details/65441415

[6]

聊聊併發(八)——Fork/Join 框架介紹: https://www.infoq.cn/article/fork-join-introduction