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 = https://www.cnblogs.com/bwscode/p/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]

8. 如何保證多執行緒下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
復制代碼

9. 如何檢測死鎖？怎么預防死鎖？死鎖四個必要條件

死鎖是指多個執行緒因競爭資源而造成的一種互相等待的僵局，如圖感受一下：

「死鎖的四個必要條件：」

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

「如何預防死鎖？」

• 加鎖順序（執行緒按順序辦事）
• 加鎖時限 （執行緒請求所加上權限，超時就放棄，同時釋放自己占有的鎖）
• 死鎖檢測

怎么樣，這幾道題你遇到了能回答多少？

而這，只是常見的多執行緒，高并發以及jvm調優的原始碼問題中最常見的幾道面試題，其他的面試題我已經整理到我的git倉庫中，并在不斷地更新上傳中

相應的文章已經整理形成檔案，git掃碼獲取資料看這里

https://gitee.com/biwangsheng/personal.git

標籤：Java

上一篇：SpringBoot搭建API檔案插件Swagger并美化

下一篇：面試必備：經典演算法影片決議之選擇排序