1、多線程有什麼用？
一個可能在很多人看來很扯淡的一個問題：我會用多線程就好了，還管它有什麼用？在我看來，這個回答更扯淡。所謂”知其然知其是以然”，”會用”隻是”知其然”，”為什麼用”才是”知其是以然”，隻有達到”知其然知其是以然”的程度才可以說是把一個知識點運用自如。OK，下面說說我對這個問題的看法：
（1）發揮多核CPU的優勢
随着工業的進步，現在的筆記本、桌上型電腦乃至商用的應用伺服器至少也都是雙核的，4核、8核甚至16核的也都不少見，如果是單線程的程式，那麼在雙核CPU上就浪費了50%，在4核CPU上就浪費了75%。單核CPU上所謂的”多線程”那是假的多線程，同一時間處理器隻會處理一段邏輯，隻不過線程之間切換得比較快，看着像多個線程”同時”運作罷了。多核CPU上的多線程才是真正的多線程，它能讓你的多段邏輯同時工作，多線程，可以真正發揮出多核CPU的優勢來，達到充分利用CPU的目的。
（2）防止阻塞
從程式運作效率的角度來看，單核CPU不但不會發揮出多線程的優勢，反而會因為在單核CPU上運作多線程導緻線程上下文的切換，而降低程式整體的效率。但是單核CPU我們還是要應用多線程，就是為了防止阻塞。試想，如果單核CPU使用單線程，那麼隻要這個線程阻塞了，比方說遠端讀取某個資料吧，對端遲遲未傳回又沒有設定逾時時間，那麼你的整個程式在資料傳回回來之前就停止運作了。多線程可以防止這個問題，多條線程同時運作，哪怕一條線程的代碼執行讀取資料阻塞，也不會影響其它任務的執行。
（3）便于模組化
這是另外一個沒有這麼明顯的優點了。假設有一個大的任務A，單線程程式設計，那麼就要考慮很多，建立整個程式模型比較麻煩。但是如果把這個大的任務A分解成幾個小任務，任務B、任務C、任務D，分别建立程式模型，并通過多線程分别運作這幾個任務，那就簡單很多了。
2、建立線程的方式
比較常見的一個問題了，一般就是兩種：
（1）繼承Thread類
（2）實作Runnable接口
至于哪個好，不用說肯定是後者好，因為實作接口的方式比繼承類的方式更靈活，也能減少程式之間的耦合度，面向接口程式設計也是設計模式6大原則的核心。
3、start()方法和run()方法的差別
隻有調用了start()方法，才會表現出多線程的特性，不同線程的run()方法裡面的代碼交替執行。如果隻是調用run()方法，那麼代碼還是同步執行的，必須等待一個線程的run()方法裡面的代碼全部執行完畢之後，另外一個線程才可以執行其run()方法裡面的代碼。
4、Runnable接口和Callable接口的差別
有點深的問題了，也看出一個Java程式員學習知識的廣度。
Runnable接口中的run()方法的傳回值是void，它做的事情隻是純粹地去執行run()方法中的代碼而已；Callable接口中的call()方法是有傳回值的，是一個泛型，和Future、FutureTask配合可以用來擷取異步執行的結果。
這其實是很有用的一個特性，因為多線程相比單線程更難、更複雜的一個重要原因就是因為多線程充滿着未知性，某條線程是否執行了？某條線程執行了多久？某條線程執行的時候我們期望的資料是否已經指派完畢？無法得知，我們能做的隻是等待這條多線程的任務執行完畢而已。而Callable+Future/FutureTask卻可以擷取多線程運作的結果，可以在等待時間太長沒擷取到需要的資料的情況下取消該線程的任務，真的是非常有用。
5、CyclicBarrier和CountDownLatch的差別
兩個看上去有點像的類，都在java.util.concurrent下，都可以用來表示代碼運作到某個點上，二者的差別在于：
（1）CyclicBarrier的某個線程運作到某個點上之後，該線程即停止運作，直到所有的線程都到達了這個點，所有線程才重新運作；CountDownLatch則不是，某線程運作到某個點上之後，隻是給某個數值-1而已，該線程繼續運作
（2）CyclicBarrier隻能喚起一個任務，CountDownLatch可以喚起多個任務
（3）CyclicBarrier可重用，CountDownLatch不可重用，計數值為0該CountDownLatch就不可再用了
6、volatile關鍵字的作用
一個非常重要的問題，是每個學習、應用多線程的Java程式員都必須掌握的。了解volatile關鍵字的作用的前提是要了解Java記憶體模型，這裡就不講Java記憶體模型了，可以參見第31點，volatile關鍵字的作用主要有兩個：
（1）多線程主要圍繞可見性和原子性兩個特性而展開，使用volatile關鍵字修飾的變量，保證了其在多線程之間的可見性，即每次讀取到volatile變量，一定是最新的資料
（2）代碼底層執行不像我們看到的進階語言—-Java程式這麼簡單，它的執行是Java代碼–>位元組碼–>根據位元組碼執行對應的C/C++代碼–>C/C++代碼被編譯成彙編語言–>和硬體電路互動，現實中，為了擷取更好的性能JVM可能會對指令進行重排序，多線程下可能會出現一些意想不到的問題。使用volatile則會對禁止語義重排序，當然這也一定程度上降低了代碼執行效率
從實踐角度而言，volatile的一個重要作用就是和CAS結合，保證了原子性，詳細的可以參見java.util.concurrent.atomic包下的類，比如AtomicInteger。
7、什麼是線程安全
又是一個理論的問題，各式各樣的答案有很多，我給出一個個人認為解釋地最好的：如果你的代碼在多線程下執行和在單線程下執行永遠都能獲得一樣的結果，那麼你的代碼就是線程安全的。
這個問題有值得一提的地方，就是線程安全也是有幾個級别的：
（1）不可變
像String、Integer、Long這些，都是final類型的類，任何一個線程都改變不了它們的值，要改變除非新建立一個，是以這些不可變對象不需要任何同步手段就可以直接在多線程環境下使用
（2）絕對線程安全
不管運作時環境如何，調用者都不需要額外的同步措施。要做到這一點通常需要付出許多額外的代價，Java中标注自己是線程安全的類，實際上絕大多數都不是線程安全的，不過絕對線程安全的類，Java中也有，比方說CopyOnWriteArrayList、CopyOnWriteArraySet
（3）相對線程安全
相對線程安全也就是我們通常意義上所說的線程安全，像Vector這種，add、remove方法都是原子操作，不會被打斷，但也僅限于此，如果有個線程在周遊某個Vector、有個線程同時在add這個Vector，99%的情況下都會出現ConcurrentModificationException，也就是fail-fast機制。
（4）線程非安全
這個就沒什麼好說的了，ArrayList、LinkedList、HashMap等都是線程非安全的類
8、Java中如何擷取到線程dump檔案
死循環、死鎖、阻塞、頁面打開慢等問題，打線程dump是最好的解決問題的途徑。所謂線程dump也就是線程堆棧，擷取到線程堆棧有兩步：
（1）擷取到線程的pid，可以通過使用jps指令，在Linux環境下還可以使用ps -ef | grep java
（2）列印線程堆棧，可以通過使用jstack pid指令，在Linux環境下還可以使用kill -3 pid
另外提一點，Thread類提供了一個getStackTrace()方法也可以用于擷取線程堆棧。這是一個執行個體方法，是以此方法是和具體線程執行個體綁定的，每次擷取擷取到的是具體某個線程目前運作的堆棧，
9、一個線程如果出現了運作時異常會怎麼樣
如果這個異常沒有被捕獲的話，這個線程就停止執行了。另外重要的一點是：如果這個線程持有某個某個對象的螢幕，那麼這個對象螢幕會被立即釋放
10、如何在兩個線程之間共享資料
通過線上程之間共享對象就可以了，然後通過wait/notify/notifyAll、await/signal/signalAll進行喚起和等待，比方說阻塞隊列BlockingQueue就是為線程之間共享資料而設計的
11、sleep方法和wait方法有什麼差別
這個問題常問，sleep方法和wait方法都可以用來放棄CPU一定的時間，不同點在于如果線程持有某個對象的螢幕，sleep方法不會放棄這個對象的螢幕，wait方法會放棄這個對象的螢幕
12、生産者消費者模型的作用是什麼
這個問題很理論，但是很重要：
（1）通過平衡生産者的生産能力和消費者的消費能力來提升整個系統的運作效率，這是生産者消費者模型最重要的作用
（2）解耦，這是生産者消費者模型附帶的作用，解耦意味着生産者和消費者之間的聯系少，聯系越少越可以獨自發展而不需要收到互相的制約
13、ThreadLocal有什麼用
簡單說ThreadLocal就是一種以空間換時間的做法，在每個Thread裡面維護了一個以開位址法實作的ThreadLocal.ThreadLocalMap，把資料進行隔離，資料不共享，自然就沒有線程安全方面的問題了
14、為什麼wait()方法和notify()/notifyAll()方法要在同步塊中被調用
這是JDK強制的，wait()方法和notify()/notifyAll()方法在調用前都必須先獲得對象的鎖
15、wait()方法和notify()/notifyAll()方法在放棄對象螢幕時有什麼差別
wait()方法和notify()/notifyAll()方法在放棄對象螢幕的時候的差別在于：wait()方法立即釋放對象螢幕，notify()/notifyAll()方法則會等待線程剩餘代碼執行完畢才會放棄對象螢幕。
16、為什麼要使用線程池
避免頻繁地建立和銷毀線程，達到線程對象的重用。另外，使用線程池還可以根據項目靈活地控制并發的數目。
17、怎麼檢測一個線程是否持有對象螢幕
我也是在網上看到一道多線程面試題才知道有方法可以判斷某個線程是否持有對象螢幕：Thread類提供了一個holdsLock(Object obj)方法，當且僅當對象obj的螢幕被某條線程持有的時候才會傳回true，注意這是一個static方法，這意味着“某條線程”指的是目前線程。
18、synchronized和ReentrantLock的差別
synchronized是和if、else、for、while一樣的關鍵字，ReentrantLock是類，這是二者的本質差別。既然ReentrantLock是類，那麼它就提供了比synchronized更多更靈活的特性，可以被繼承、可以有方法、可以有各種各樣的類變量，ReentrantLock比synchronized的擴充性展現在幾點上：
（1）ReentrantLock可以對擷取鎖的等待時間進行設定，這樣就避免了死鎖
（2）ReentrantLock可以擷取各種鎖的資訊
（3）ReentrantLock可以靈活地實作多路通知
另外，二者的鎖機制其實也是不一樣的。ReentrantLock底層調用的是Unsafe的park方法加鎖，synchronized操作的應該是對象頭中mark word，這點我不能确定。
19、ConcurrentHashMap的并發度是什麼
ConcurrentHashMap的并發度就是segment的大小，預設為16，這意味着最多同時可以有16條線程操作ConcurrentHashMap，這也是ConcurrentHashMap對Hashtable的最大優勢，任何情況下，Hashtable能同時有兩條線程擷取Hashtable中的資料嗎？
20、ReadWriteLock是什麼
首先明确一下，不是說ReentrantLock不好，隻是ReentrantLock某些時候有局限。如果使用ReentrantLock，可能本身是為了防止線程A在寫資料、線程B在讀資料造成的資料不一緻，但這樣，如果線程C在讀資料、線程D也在讀資料，讀資料是不會改變資料的，沒有必要加鎖，但是還是加鎖了，降低了程式的性能。
因為這個，才誕生了讀寫鎖ReadWriteLock。ReadWriteLock是一個讀寫鎖接口，ReentrantReadWriteLock是ReadWriteLock接口的一個具體實作，實作了讀寫的分離，讀鎖是共享的，寫鎖是獨占的，讀和讀之間不會互斥，讀和寫、寫和讀、寫和寫之間才會互斥，提升了讀寫的性能。