這9道面試題，給你答案都不必定能看明白，但面試必問，建議看完

時間 2020-08-20

原文原文鏈接

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

synchronized的實現原理git

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上下文切換。在輕量級鎖升級爲重量級鎖時，就使用了自旋加鎖的方式
鎖粗化：將多個連續的加鎖、解鎖操做鏈接在一塊兒，擴展成一個範圍更大的鎖。

❝框架

舉個例子，買門票進動物園。老師帶一羣小朋友去參觀，驗票員若是知道他們是個集體，就能夠把他們當作一個總體（鎖租化），一次性驗票過，而不須要一個個找他們驗票。jvm

❞

鎖消除:虛擬機即時編譯器在運行時，對一些代碼上要求同步，可是被檢測到不可能存在共享數據競爭的鎖進行消除。

有興趣的朋友們能夠看看我這篇文章： 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]

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
複製代碼