說好了面試系列已經完結了，結果發現還是真香，嗯，以為我發現我的Java基礎都沒寫，所以這個就算作續集了，續集第一篇請各位收好。
說說程式和執行緒的區別？
程式是程式的一次執行，是系統進行資源分配和排程的獨立單位，他的作用是是程式能夠併發執行提高資源利用率和吞吐率。
由於程式是資源分配和排程的基本單位，因為程式的建立、銷燬、切換產生大量的時間和空間的開銷，程式的數量不能太多，而執行緒是比程式更小的能獨立執行的基本單位，他是程式的一個實體，可以減少程式併發執行時的時間和空間開銷，使得作業系統具有更好的併發性。
執行緒基本不擁有系統資源，只有一些執行時必不可少的資源，比如程式計數器、暫存器和棧，程式則佔有堆、棧。
知道synchronized原理嗎？
synchronized是java提供的原子性內建鎖，這種內建的並且使用者看不到的鎖也被稱為監視器鎖，使用synchronized之後，會在編譯之後在同步的程式碼塊前後加上monitorenter和monitorexit位元組碼指令，他依賴作業系統底層互斥鎖實現。他的作用主要就是實現原子性操作和解決共享變數的記憶體可見性問題。
執行monitorenter指令時會嘗試獲取物件鎖，如果物件沒有被鎖定或者已經獲得了鎖，鎖的計數器+1。此時其他競爭鎖的執行緒則會進入等待佇列中。
執行monitorexit指令時則會把計數器-1，當計數器值為0時，則鎖釋放，處於等待佇列中的執行緒再繼續競爭鎖。
synchronized是排它鎖，當一個執行緒獲得鎖之後，其他執行緒必須等待該執行緒釋放鎖後才能獲得鎖，而且由於Java中的執行緒和作業系統原生執行緒是一一對應的，執行緒被阻塞或者喚醒時時會從使用者態切換到核心態，這種轉換非常消耗效能。
從記憶體語義來說，加鎖的過程會清除工作記憶體中的共享變數，再從主記憶體讀取，而釋放鎖的過程則是將工作記憶體中的共享變數寫回主記憶體。
實際上大部分時候我認為說到monitorenter就行了，但是為了更清楚的描述，還是再具體一點。
如果再深入到原始碼來說，synchronized實際上有兩個佇列waitSet和entryList。
- 當多個執行緒進入同步程式碼塊時，首先進入entryList
- 有一個執行緒獲取到monitor鎖後，就賦值給當前執行緒，並且計數器+1
- 如果執行緒呼叫wait方法，將釋放鎖，當前執行緒置為null，計數器-1，同時進入waitSet等待被喚醒，呼叫notify或者notifyAll之後又會進入entryList競爭鎖
- 如果執行緒執行完畢，同樣釋放鎖，計數器-1，當前執行緒置為null
那鎖的優化機制瞭解嗎？
從JDK1.6版本之後，synchronized本身也在不斷優化鎖的機制，有些情況下他並不會是一個很重量級的鎖了。優化機制包括自適應鎖、自旋鎖、鎖消除、鎖粗化、輕量級鎖和偏向鎖。
鎖的狀態從低到高依次為無鎖->偏向鎖->輕量級鎖->重量級鎖，升級的過程就是從低到高，降級在一定條件也是有可能發生的。
自旋鎖：由於大部分時候，鎖被佔用的時間很短，共享變數的鎖定時間也很短，所有沒有必要掛起執行緒，使用者態和核心態的來回上下文切換嚴重影響效能。自旋的概念就是讓執行緒執行一個忙迴圈，可以理解為就是啥也不幹，防止從使用者態轉入核心態，自旋鎖可以通過設定-XX:+UseSpining來開啟，自旋的預設次數是10次，可以使用-XX:PreBlockSpin設定。
自適應鎖：自適應鎖就是自適應的自旋鎖，自旋的時間不是固定時間，而是由前一次在同一個鎖上的自旋時間和鎖的持有者狀態來決定。
鎖消除：鎖消除指的是JVM檢測到一些同步的程式碼塊，完全不存在資料競爭的場景，也就是不需要加鎖，就會進行鎖消除。
鎖粗化：鎖粗化指的是有很多操作都是對同一個物件進行加鎖，就會把鎖的同步範圍擴充套件到整個操作序列之外。
偏向鎖：當執行緒訪問同步塊獲取鎖時，會在物件頭和棧幀中的鎖記錄裡儲存偏向鎖的執行緒ID，之後這個執行緒再次進入同步塊時都不需要CAS來加鎖和解鎖了，偏向鎖會永遠偏向第一個獲得鎖的執行緒，如果後續沒有其他執行緒獲得過這個鎖，持有鎖的執行緒就永遠不需要進行同步，反之，當有其他執行緒競爭偏向鎖時，持有偏向鎖的執行緒就會釋放偏向鎖。可以用過設定-XX:+UseBiasedLocking開啟偏向鎖。
輕量級鎖：JVM的物件的物件頭中包含有一些鎖的標誌位，程式碼進入同步塊的時候，JVM將會使用CAS方式來嘗試獲取鎖，如果更新成功則會把物件頭中的狀態位標記為輕量級鎖，如果更新失敗，當前執行緒就嘗試自旋來獲得鎖。
整個鎖升級的過程非常複雜，我盡力去除一些無用的環節，簡單來描述整個升級的機制。
簡單點說，偏向鎖就是通過物件頭的偏向執行緒ID來對比，甚至都不需要CAS了，而輕量級鎖主要就是通過CAS修改物件頭鎖記錄和自旋來實現，重量級鎖則是除了擁有鎖的執行緒其他全部阻塞。
那物件頭具體都包含哪些內容？
在我們常用的Hotspot虛擬機器中，物件在記憶體中佈局實際包含3個部分：
- 物件頭
- 例項資料
- 對齊填充
而物件頭包含兩部分內容，Mark Word中的內容會隨著鎖標誌位而發生變化，所以只說儲存結構就好了。
- 物件自身執行時所需的資料，也被稱為Mark Word，也就是用於輕量級鎖和偏向鎖的關鍵點。具體的內容包含物件的hashcode、分代年齡、輕量級鎖指標、重量級鎖指標、GC標記、偏向鎖執行緒ID、偏向鎖時間戳。
- 儲存型別指標，也就是指向類的後設資料的指標，通過這個指標才能確定物件是屬於哪個類的例項。
如果是陣列的話，則還包含了陣列的長度
對於加鎖，那再說下ReentrantLock原理？他和synchronized有什麼區別？
相比於synchronized，ReentrantLock需要顯式的獲取鎖和釋放鎖，相對現在基本都是用JDK7和JDK8的版本，ReentrantLock的效率和synchronized區別基本可以持平了。他們的主要區別有以下幾點：
- 等待可中斷，當持有鎖的執行緒長時間不釋放鎖的時候，等待中的執行緒可以選擇放棄等待，轉而處理其他的任務。
- 公平鎖：synchronized和ReentrantLock預設都是非公平鎖，但是ReentrantLock可以通過建構函式傳參改變。只不過使用公平鎖的話會導致效能急劇下降。
- 繫結多個條件：ReentrantLock可以同時繫結多個Condition條件物件。
ReentrantLock基於AQS(AbstractQueuedSynchronizer 抽象佇列同步器)實現。別說了，我知道問題了，AQS原理我來講。
AQS內部維護一個state狀態位，嘗試加鎖的時候通過CAS(CompareAndSwap)修改值，如果成功設定為1，並且把當前執行緒ID賦值，則代表加鎖成功，一旦獲取到鎖，其他的執行緒將會被阻塞進入阻塞佇列自旋，獲得鎖的執行緒釋放鎖的時候將會喚醒阻塞佇列中的執行緒，釋放鎖的時候則會把state重新置為0，同時當前執行緒ID置為空。
CAS的原理呢？
CAS叫做CompareAndSwap，比較並交換，主要是通過處理器的指令來保證操作的原子性，它包含三個運算元：
- 變數記憶體地址，V表示
- 舊的預期值，A表示
- 準備設定的新值，B表示
當執行CAS指令時，只有當V等於A時，才會用B去更新V的值，否則就不會執行更新操作。
那麼CAS有什麼缺點嗎？
CAS的缺點主要有3點：
ABA問題：ABA的問題指的是在CAS更新的過程中，當讀取到的值是A，然後準備賦值的時候仍然是A，但是實際上有可能A的值被改成了B，然後又被改回了A，這個CAS更新的漏洞就叫做ABA。只是ABA的問題大部分場景下都不影響併發的最終效果。
Java中有AtomicStampedReference來解決這個問題，他加入了預期標誌和更新後標誌兩個欄位，更新時不光檢查值，還要檢查當前的標誌是否等於預期標誌，全部相等的話才會更新。
迴圈時間長開銷大：自旋CAS的方式如果長時間不成功，會給CPU帶來很大的開銷。
只能保證一個共享變數的原子操作：只對一個共享變數操作可以保證原子性，但是多個則不行，多個可以通過AtomicReference來處理或者使用鎖synchronized實現。
好，說說HashMap原理吧？
HashMap主要由陣列和連結串列組成，他不是執行緒安全的。核心的點就是put插入資料的過程，get查詢資料以及擴容的方式。JDK1.7和1.8的主要區別在於頭插和尾插方式的修改，頭插容易導致HashMap連結串列死迴圈，並且1.8之後加入紅黑樹對效能有提升。
put插入資料流程
往map插入元素的時候首先通過對key hash然後與陣列長度-1進行與運算((n-1)&hash)，都是2的次冪所以等同於取模，但是位運算的效率更高。找到陣列中的位置之後，如果陣列中沒有元素直接存入，反之則判斷key是否相同，key相同就覆蓋，否則就會插入到連結串列的尾部，如果連結串列的長度超過8，則會轉換成紅黑樹，最後判斷陣列長度是否超過預設的長度*負載因子也就是12，超過則進行擴容。
get查詢資料
查詢資料相對來說就比較簡單了，首先計算出hash值，然後去陣列查詢，是紅黑樹就去紅黑樹查，連結串列就遍歷連結串列查詢就可以了。
resize擴容過程
擴容的過程就是對key重新計算hash，然後把資料拷貝到新的陣列。
那多執行緒環境怎麼使用Map呢？ConcurrentHashmap瞭解過嗎？
多執行緒環境可以使用Collections.synchronizedMap同步加鎖的方式，還可以使用HashTable，但是同步的方式顯然效能不達標，而ConurrentHashMap更適合高併發場景使用。
ConcurrentHashmap在JDK1.7和1.8的版本改動比較大，1.7使用Segment+HashEntry分段鎖的方式實現，1.8則拋棄了Segment，改為使用CAS+synchronized+Node實現，同樣也加入了紅黑樹，避免連結串列過長導致效能的問題。
1.7分段鎖
從結構上說，1.7版本的ConcurrentHashMap採用分段鎖機制，裡面包含一個Segment陣列，Segment繼承與ReentrantLock，Segment則包含HashEntry的陣列，HashEntry本身就是一個連結串列的結構，具有儲存key、value的能力能指向下一個節點的指標。
實際上就是相當於每個Segment都是一個HashMap，預設的Segment長度是16，也就是支援16個執行緒的併發寫，Segment之間相互不會受到影響。
put流程
其實發現整個流程和HashMap非常類似，只不過是先定位到具體的Segment，然後通過ReentrantLock去操作而已，後面的流程我就簡化了，因為和HashMap基本上是一樣的。
- 計算hash，定位到segment，segment如果是空就先初始化
- 使用ReentrantLock加鎖，如果獲取鎖失敗則嘗試自旋，自旋超過次數就阻塞獲取，保證一定獲取鎖成功
- 遍歷HashEntry，就是和HashMap一樣，陣列中key和hash一樣就直接替換，不存在就再插入連結串列，連結串列同樣
get流程
get也很簡單，key通過hash定位到segment，再遍歷連結串列定位到具體的元素上，需要注意的是value是volatile的，所以get是不需要加鎖的。
1.8CAS+synchronized
1.8拋棄分段鎖，轉為用CAS+synchronized來實現，同樣HashEntry改為Node，也加入了紅黑樹的實現。主要還是看put的流程。
put流程
- 首先計算hash，遍歷node陣列，如果node是空的話，就通過CAS+自旋的方式初始化
- 如果當前陣列位置是空則直接通過CAS自旋寫入資料
- 如果hash==MOVED，說明需要擴容，執行擴容
- 如果都不滿足，就使用synchronized寫入資料，寫入資料同樣判斷連結串列、紅黑樹，連結串列寫入和HashMap的方式一樣，key hash一樣就覆蓋，反之就尾插法，連結串列長度超過8就轉換成紅黑樹
get查詢
get很簡單，通過key計算hash，如果key hash相同就返回，如果是紅黑樹按照紅黑樹獲取，都不是就遍歷連結串列獲取。
volatile原理知道嗎？
相比synchronized的加鎖方式來解決共享變數的記憶體可見性問題，volatile就是更輕量的選擇，他沒有上下文切換的額外開銷成本。使用volatile宣告的變數，可以確保值被更新的時候對其他執行緒立刻可見。volatile使用記憶體屏障來保證不會發生指令重排，解決了記憶體可見性的問題。
我們知道，執行緒都是從主記憶體中讀取共享變數到工作記憶體來操作，完成之後再把結果寫會主記憶體，但是這樣就會帶來可見性問題。舉個例子，假設現在我們是兩級快取的雙核CPU架構，包含L1、L2兩級快取。
- 執行緒A首先獲取變數X的值，由於最初兩級快取都是空，所以直接從主記憶體中讀取X，假設X初始值為0，執行緒A讀取之後把X值都修改為1，同時寫回主記憶體。這時候快取和主記憶體的情況如下圖。
-
執行緒B也同樣讀取變數X的值，由於L2快取已經有快取X=1，所以直接從L2快取讀取，之後執行緒B把X修改為2，同時寫回L2和主記憶體。這時候的X值入下圖所示。
那麼執行緒A如果再想獲取變數X的值，因為L1快取已經有x=1了，所以這時候變數記憶體不可見問題就產生了，B修改為2的值對A來說沒有感知。
image-20201111171451466
那麼，如果X變數用volatile修飾的話，當執行緒A再次讀取變數X的話，CPU就會根據快取一致性協議強制執行緒A重新從主記憶體載入最新的值到自己的工作記憶體，而不是直接用快取中的值。
再來說記憶體屏障的問題，volatile修飾之後會加入不同的記憶體屏障來保證可見性的問題能正確執行。這裡寫的屏障基於書中提供的內容，但是實際上由於CPU架構不同，重排序的策略不同，提供的記憶體屏障也不一樣，比如x86平臺上，只有StoreLoad一種記憶體屏障。
- StoreStore屏障，保證上面的普通寫不和volatile寫發生重排序
- StoreLoad屏障，保證volatile寫與後面可能的volatile讀寫不發生重排序
- LoadLoad屏障，禁止volatile讀與後面的普通讀重排序
- LoadStore屏障，禁止volatile讀和後面的普通寫重排序
那麼說說你對JMM記憶體模型的理解？為什麼需要JMM？
本身隨著CPU和記憶體的發展速度差異的問題，導致CPU的速度遠快於記憶體，所以現在的CPU加入了快取記憶體，快取記憶體一般可以分為L1、L2、L3三級快取。基於上面的例子我們知道了這導致了快取一致性的問題，所以加入了快取一致性協議，同時導致了記憶體可見性的問題，而編譯器和CPU的重排序導致了原子性和有序性的問題，JMM記憶體模型正是對多執行緒操作下的一系列規範約束，因為不可能讓陳僱員的程式碼去相容所有的CPU，通過JMM我們才遮蔽了不同硬體和作業系統記憶體的訪問差異，這樣保證了Java程式在不同的平臺下達到一致的記憶體訪問效果，同時也是保證在高效併發的時候程式能夠正確執行。
原子性：Java記憶體模型通過read、load、assign、use、store、write來保證原子性操作，此外還有lock和unlock，直接對應著synchronized關鍵字的monitorenter和monitorexit位元組碼指令。
可見性：可見性的問題在上面的回答已經說過，Java保證可見性可以認為通過volatile、synchronized、final來實現。
有序性：由於處理器和編譯器的重排序導致的有序性問題，Java通過volatile、synchronized來保證。
happen-before規則
雖然指令重排提高了併發的效能，但是Java虛擬機器會對指令重排做出一些規則限制，並不能讓所有的指令都隨意的改變執行位置，主要有以下幾點：
- 單執行緒每個操作，happen-before於該執行緒中任意後續操作
- volatile寫happen-before與後續對這個變數的讀
- synchronized解鎖happen-before後續對這個鎖的加鎖
- final變數的寫happen-before於final域物件的讀，happen-before後續對final變數的讀
- 傳遞性規則，A先於B，B先於C，那麼A一定先於C發生
說了半天，到底工作記憶體和主記憶體是什麼？
主記憶體可以認為就是實體記憶體，Java記憶體模型中實際就是虛擬機器記憶體的一部分。而工作記憶體就是CPU快取，他有可能是暫存器也有可能是L1\L2\L3快取，都是有可能的。
說說ThreadLocal原理？
ThreadLocal可以理解為執行緒本地變數，他會在每個執行緒都建立一個副本，那麼線上程之間訪問內部副本變數就行了，做到了執行緒之間互相隔離，相比於synchronized的做法是用空間來換時間。
ThreadLocal有一個靜態內部類ThreadLocalMap，ThreadLocalMap又包含了一個Entry陣列，Entry本身是一個弱引用，他的key是指向ThreadLocal的弱引用，Entry具備了儲存key value鍵值對的能力。
弱引用的目的是為了防止記憶體洩露，如果是強引用那麼ThreadLocal物件除非執行緒結束否則始終無法被回收，弱引用則會在下一次GC的時候被回收。
但是這樣還是會存在記憶體洩露的問題，假如key和ThreadLocal物件被回收之後，entry中就存在key為null，但是value有值的entry物件，但是永遠沒辦法被訪問到，同樣除非執行緒結束執行。
但是隻要ThreadLocal使用恰當，在使用完之後呼叫remove方法刪除Entry物件，實際上是不會出現這個問題的。
那引用型別有哪些？有什麼區別？
引用型別主要分為強軟弱虛四種：
- 強引用指的就是程式碼中普遍存在的賦值方式，比如A a = new A()這種。強引用關聯的物件，永遠不會被GC回收。
- 軟引用可以用SoftReference來描述，指的是那些有用但是不是必須要的物件。系統在發生記憶體溢位前會對這類引用的物件進行回收。
- 弱引用可以用WeakReference來描述，他的強度比軟引用更低一點，弱引用的物件下一次GC的時候一定會被回收，而不管記憶體是否足夠。
- 虛引用也被稱作幻影引用，是最弱的引用關係，可以用PhantomReference來描述，他必須和ReferenceQueue一起使用，同樣的當發生GC的時候，虛引用也會被回收。可以用虛引用來管理堆外記憶體。
執行緒池原理知道嗎？
首先執行緒池有幾個核心的引數概念：
-
最大執行緒數maximumPoolSize
-
核心執行緒數corePoolSize
-
活躍時間keepAliveTime
-
阻塞佇列workQueue
-
拒絕策略RejectedExecutionHandler
當提交一個新任務到執行緒池時，具體的執行流程如下：
- 當我們提交任務，執行緒池會根據corePoolSize大小建立若干任務數量執行緒執行任務
- 當任務的數量超過corePoolSize數量，後續的任務將會進入阻塞佇列阻塞排隊
- 當阻塞佇列也滿了之後，那麼將會繼續建立(maximumPoolSize-corePoolSize)個數量的執行緒來執行任務，如果任務處理完成，maximumPoolSize-corePoolSize額外建立的執行緒等待keepAliveTime之後被自動銷燬
- 如果達到maximumPoolSize，阻塞佇列還是滿的狀態，那麼將根據不同的拒絕策略對應處理
拒絕策略有哪些？
主要有4種拒絕策略：
- AbortPolicy：直接丟棄任務，丟擲異常，這是預設策略
- CallerRunsPolicy：只用呼叫者所在的執行緒來處理任務
- DiscardOldestPolicy：丟棄等待佇列中最近的任務，並執行當前任務
- DiscardPolicy：直接丟棄任務，也不丟擲異常
- END -