目前網上的面試題氾濫成災，真正有價值的很少，往往是爛大街的問題，同時也沒有給出正確的解決方案 ， 本文旨在整理一一系列對面試者有幫助的文章，後續會持續更新。

String 類為什麼是final的

答案是為了 “效率”和安全，

安全： 由於String類被final修飾符修飾，那麼他就是不可被繼承，創建出來的物件之後也就是不可以被改變的。加上String字串有常量池的概念，如果沒有被final修飾符修飾，那麼建立之後的物件是不可以保證的，容易產生安全性問題。同時，在String類使用非常廣泛的情況下，這種設計是非常必要的。效率： 設計成final，JVM才不用對相關方法在虛擬函式表中查詢，而直接定位到String類的相關方法上，提高了執行效率。 （涉及到了JVM的實現細節，在此筆者也不是很懂，在此分享給大家，有興趣的可以詳細瞭解）

HashMap的底層實現， jdk1.8有何變化

HashMap底層是通過資料+連結串列的形式實現的， HashMap初始化的時候，會預設建立長度為16的陣列,put的時候通過HashCode求餘的方式來確定KEY的位置，如果HashCode相同，那麼相同hashCode的值會放在一個連結串列上面。 如此可見，當放入HashMap中的key的HashCode衝突比較大時，當嚴重影響效率。

JDK1.8之後，當連結串列數量達到8個以上時，會採用紅黑樹來實現。

HashSet集合實現原理是什麼

HashSet底層採用的是雜湊表來實現的，其原理和HashMap一致，只是對HashMap的API做了一層封裝有點類似於value為null的hashMap

Java中的佇列有哪些，有何區別

在此列出幾個常用的佇列。

阻塞佇列

• ArrayBlockingQueue ：一個由陣列支援的有界佇列，阻塞佇列，讀寫共享一把鎖

• LinkedBlockingQueue ：一個由連結節點支援的可選有界佇列，阻塞佇列 ， 讀寫分別採用的是不同的鎖。

• DelayQueue ：基於時間的排程佇列，比如說往這個佇列中新增一個元素，同時指定3秒鐘，那麼只有過了3秒鐘之後，才能夠從該佇列中取到這個元素

非阻塞佇列

• ConcurrentLinkedQueue

是一個基於連結節點無界安全的佇列，基於CAS操作保證佇列裡面資料的一致性 ， 該佇列的size()方法是會遍歷整個佇列的，因此及其耗費效能，通常使用isEmpty()來判斷集合是否為空。

ConcurrentHashMap實現原理

採用分段鎖的概念， ConcurrentHashMap在初始化時，預設會產生16個段（Segment），每個段內部又是一個數組，陣列中的每個元素又是一個連結串列，說的通俗一點，Segment的結構有點類似於HashMap . 
當有元素需要新增進來的時候，首先進行一次Hash , 計算出該元素會被分配到哪個段裡面，  確定好在哪個段裡面之後，進行第二次Hash, 確定在段的陣列中哪個位置，第二次Hash來確定在陣列中哪個位置，和HashMap的原理一致。

ConcurrentHashMap 大量的採用volatile， CAS，final，lock等技術，減少鎖的競爭對效能產生的影響、

異常的結構，執行時異常和非執行時異常，各舉個例子

異常的結構：

Thorwable 是所有異常和錯誤的基類。

Error 和Exception .

Error : 是JVM執行產生的錯誤，是不可以感知的，當發生時，會導致程式中斷，應用程式無法捕獲

Exception ： 程式可以捕獲的異常，應用程式可以處理的異常資訊，分為執行時異常和非執行時異常

非執行時異常 ： 程式必須要處理的異常，否則不能編譯通過，如： IOException, SQLException

執行時異常 ：程式在執行過程中可能產生的異常，這個不強制要求處理。 如： RuntimeException

弱引用, 軟引用 的概念和使用方式。

軟引用：當JVM記憶體不夠時，會強制回收軟引用，如果回收了之後，還不能滿足當前的記憶體需求，則會報記憶體溢位的錯誤，通常用於本地快取的使用。

弱引用: 通過 WeakReference 標識這是一個弱引用，生命週期比較短，當系統觸發垃圾回收的時候，如果一個物件只具有弱引用，那麼就會被回收 ， 比如：ThreadLocal中引用的ThreadLocalMap中的Entry就是一個弱引用，大家有時間可以取看一下。

volatile的理解

volatile是在多執行緒的環境中，對於變數的一個修飾符。

場景：

大家都知道，每個程式有主記憶體， 每個執行緒都有自己的工作記憶體， 執行緒工作記憶體之中的資料是不

共享的，在這裡舉個例子；

Thread A  查詢  int  x   ,此時主記憶體中的x = 0 ，那麼Thread A  通過read ，load 的操作將變數x載入到自己的工作記憶體當中，同時修改x = 1 , 這個時候主記憶體當中的x 還是等於0  ，所以當另外一個執行緒Thread B 過來載入x 的時候，獲取到的還是0 。那麼volatile的作用是什麼呢？ 該關鍵字主要是保證執行緒之間變數的可見性。 按照上面的例子，如果volatile int x = 0 , 然後被Thread A載入到他的工作記憶體中修改為了1 ，那麼他在修改的同時，會將
x = 1 ,推送到主記憶體，修改主記憶體裡面的值。

總而言之： volatile保證變數的可見性，但不保證原子性。

CAS是什麼

CAS是CPU底層的原子命令 ， 裡面有三個概念，一定要記住

記憶體值，預期值，更新值

當： 記憶體值==預期值  的時候，才會將記憶體值修改為 更新值， 否則不做任何操作

AtomicInteger有用過嗎？ 通常用於什麼場景？ 基於什麼原理實現的。

用過， 在專案當中一般用於高併發場景，主要用於計數的功能 。 該類是通過CAS的方式來保證執行緒安全的。

i++為什麼不是執行緒安全的

因為在多執行緒的環境下， i++本身就不是一個原子操作，i++的執行過程過下，

Thread從主記憶體中讀取i = 1 到執行緒的工作記憶體， 線上程中使用完畢之後，執行  i = i+1 , 這個變數i 並沒有同步到主記憶體中區，Thread B又來讀取了，這個時候讀取到的還是 1  ，想到這裡大家應該都明白了，在多執行緒的情況下，i++是會造成資料錯誤的

解決方式：

1. 使用synchronized同步，但是比較耗費效能。不推薦

2. 使用AtomicInteger ， 其是通過CAS原子操作來保證資料的安全行的，推薦使用

SimpleDateFormat是執行緒安全的嗎？

不是， SimpleDateFormat的內部都是使用Calendar這個物件來操作時間的，如果SimpleDateFormat是靜態的，那麼在多執行緒環境下，多個執行緒操作一個物件，是會有執行緒安全問題的。

下面是SimpleDateFormat的parse方法

Date parse() {

  calendar.clear(); // 清理calendar

  ... // 執行一些操作, 設定 calendar 的日期什麼的

  calendar.getTime(); // 獲取calendar的時間

}

這裡會導致的問題就是, 如果 執行緒A 呼叫了 sdf.parse(), 並且進行了 calendar.clear()後還未執行calendar.getTime()的時候,執行緒B又呼叫了sdf.parse(), 這時候執行緒B也執行了sdf.clear()方法, 這樣就導致執行緒A的的calendar資料被清空了(實際上A,B的同時被清空了). 又或者當 A 執行了calendar.clear()後被掛起, 這時候B 開始呼叫sdf.parse()並順利i結束, 這樣 A 的 calendar記憶體儲的的date 變成了後來B設定的calendar的date

解決方案：

1. 每次使用之前，建立一個SimpleDateFormat 物件  ,在高併發的情況下，每次都要建立和銷燬該物件是非常耗費效能的，因此不推薦使用。

2. 使用同步程式碼塊synchronized，同步區域性程式碼。

3. 使用TheadLocal儲存日期物件，為每個執行緒建立自己的SimpleDateFormat 物件，這樣在高併發的情況對效能影響較小。

4. 使用第三方的時間轉換的庫

PS： 以上是筆者自己的理解，如果有什麼地方錯誤了，請留言告知我，  我馬上修改 ， 大家在面試過程中遇到過哪些奇葩問題？ 快快留言告訴我，我整理出來分享給大家。

感興趣的可以關注一下本人的公眾號，大量技術乾貨分享

sharedCode原始碼交流群，歡迎喜歡閱讀原始碼的朋友加群，新增下面的微信， 備註”加群“ 。