一線大廠的面試通常會就一個點進行追問深挖，將很多求職者追問到語盡詞窮的地步。因此常常被詬病爲面試造火箭，工作擰螺絲。這跟大廠的選人用人策略有很大關係，也是不同公司人才觀的一種體現。今天就跟大家分享一道簡單的面試題。前面的文章中我們已經介紹了關於syncronized的原理，相信看過的同學對鎖的問題應該會有比較深刻的認識。今天就接着syncronzied的主題分享一道常見的面試題。
面試官S：OK，剛剛聽了你關於syncronized的介紹，感覺理解還是比較全面的，那麼除了syncronized我們平常還用過別的方法來實現線程同步麼？
程序員Q：有的，我們項目中常用的還有併發包中的ReentrantLock類。
面試官S：簡單談一下ReentrantLock與syncronized有什麼不一樣的？
程序員Q：首先從實現層面上syncronized是Java的關鍵字，是JVM實現提供的互斥機制，而ReentrantLock是JDK併發包提供的類，從這個方面來說這兩個是不同層級的東西。syncronized是JVM的一部分，而ReentrantLock是構建在Java語言基礎上的實現類。從使用上來說，syncronized使用更簡單只需要將需要同步的邏輯（類，對象，代碼塊）用關鍵字包裹起來就可以了。而ReentrantLock使用起來相對麻煩一點，需要聲明對象，然後在需要同步的邏輯前後分別調用lock和unlock接口。從功能上來說syncronized關鍵字只支持非公平鎖，而ReentrantLock支持公平和非公平鎖。
面試官S： OK，剛剛你說提到，ReentrantLock是構件在Java語言的基礎上，那麼相關的實現原理有了解過麼？
程序員Q：有的，ReentrantLock是構建在AQS（AbstractQueuedSynchronizer）的基礎上的實現。AQS是Java併發包中線程同步的基礎類，他提供了一個通用的線程的同步模型，用戶在此基礎上可以方便的構建線程同步數據結構，併發包中的很多數據結構都是在此基礎上派生出來的。簡單來說，AbstractQueuedSynchronizer通過狀態標誌state，線程排隊隊列，線程競爭原子操作CAS搭建了一套線程同步的實現框架，派生類通過這個框架可以搭建特定場景的線程同步類，當然Java併發包中已經內置了很多實現供用戶直接使用，如ReentrantLock，CountDowLatch，CyclicBarrier，Semaphore等等。
面試官S：OK，剛剛你提到了ReentrantLock是基於AQS實現的，能夠詳細的談談這邊的實現細節麼？
程序員Q：好的。這個過程跟我們剛剛聊過的syncronized的實現原理很相似。這邊有三個比較重要的成員，狀態變量state，鎖持有線程thread和等待隊列queue。我來畫一張圖表示下這個過程：
整個搶佔過程可以分爲以下幾個步驟：
-
線程lock調用對state成員進行CAS（CompareAndSet）將state從0設置爲1。如果成功則搶佔成功，將thread成員指向自己。
-
如果失敗則說明有線程佔有鎖，檢查thread是否指向自己，如果指向自己則將state加1。否則線程掛起（通過LockSurpport的park接口）進入等待隊列。
-
當持有鎖的線程釋放鎖後，從等待隊列中喚醒頭部節點，進行搶佔。
-
搶佔成功後將thread指向自己，同時移除隊列節點。
這就是搶佔的整個過程，在搶佔過程中的隊列操作都是通過CAS來處理多線程同步問題的。
面試官S：嗯，那麼你之前提到ReentrantLock能夠支持公平鎖和非公平鎖，你剛剛的描述裏面好像沒有涉及，能補充一下麼？
程序員Q：額，好的。公平非公平主要體現在線程第一次搶佔時。非公平模式下，線程調用lock就會立刻進行一次CAS搶佔。此時線程有一定的概率成功（與隊列中的喚醒線程進行PK）。而在公平鎖模式下，線程會檢查當前隊列中有沒有等待線程，如果有存量等待線程，則不進行CAS搶佔，直接進入隊列進行排隊。這就是公平和非公平的差異。
面試官S：嗯，不錯。那麼lock對象被線程搶佔成功後會設置state變量的值。此時如何保證其他線程能夠立刻獲取到最新的state的。我們的線程是自帶工作內存的，CPU也是有高速緩存的。
程序員Q：這個只需要通過volatile關鍵字就可以，他能夠保證多線程變量的可見性。
到此關於ReentrantLock和AQS的追問就告一段落。大部分科技公司通過這種與候選人進行實現細節的探索，可以對候選人的技術深度以及技術熱情進行挖掘。從而尋找到具備專家潛力的程序員。從我的經驗來說，大廠對候選人的考察維度一般從三個方面展開，技術廣度，技術深度和個人潛力。其中個人潛力佔比很大，甚至高於前面兩個部分，有時候甚至具備一票否決權。
歡迎關注：
