一、線程狀態
狀態定義：java.lang.Thread.State內部枚舉類
1、NEW：已創建但尚未啓動運行
2、RUNNABLE：線程可運行，等待CPU調度。代表兩種狀態：正在執行，或可被執行等待調度。
3、BLOCKED：線程阻塞等待監視器鎖定。處於synchronized同步代碼塊或方法中被阻塞，等待資源鎖。
4、WAITING：等待狀態。等待被喚醒。調用Object.wait、Thread.join、LockSupport.park會進入等待狀態，不帶超時，線程一直處於等待狀態，依賴其他線程喚醒。
5、TIMED_WAITING：可指定等待時間的等待狀態。調用Thread.sleep、Object.wait、Thread.join、LockSupport.parkNanos、LockSupport.parkUntil進入等待狀態，可指定等待超時時間，超出後會拋出異常或線程繼續執行。
6、TERMINATED：線程終止狀態。線程正常執行完成或出現異常。
二、線程中止
不正確的線程中止-Stop
Stop：中止線程，並且清除監控器鎖的信息，但是可能導致線程安全問題，JDK不建議用。
Destroy：JDK未實現該方法。
正確的線程中止-interrupt
線程處於等待狀態時被阻塞，那麼interrupt會生效，該線程的中斷狀態將被清除，拋出InterruptedException異常。
如果目標線程被IO或NIO中的Channel所阻塞，同樣，IO操作會被中斷或者返回特殊異常值，達到終止線程的目的。
如果以上條件都不滿足，則會設置此線程的中斷狀態。
正確的線程中止-標誌位
代碼邏輯中，增加一個判斷，用來控制線程執行的中止。循環代碼中，根據條件判斷停止循環，線程完成執行。
Stop強制終止線程，可能導致數據不一致，interrupt終止線程拋出異常，可捕獲進行異常處理。
三、CPU緩存和內存屏障
1、CPU性能優化手段-緩存
例如：CPU高速緩存。儘可能的避免處理器訪問主內存的時間開銷，處理器大多會利用緩存(cache)以提高性能。
- 1> CPU多級緩存(三級緩存)
L1 cache(一級緩存)是CPU第一層高速緩存，分爲數據緩存和指令緩存。一般服務器CPU的L1緩存容量通常在32-4096KB。
L2 由於L1級高速緩存容量的限制，爲了再次提高CPU的運算速率，在CPU外部放置一高速存儲器，即二級緩存。
L3 現在的都是內置的。L3的存在也是基於L1、L2的內存大小限制，L3緩存容量更大些。L3緩存的應用可以進一步降低內存延遲，同時提升大數據量計算時處理器的性能。具有較大L3緩存的處理器提供更有效的文件系統緩存行爲及較短消息和處理器隊列長度。一般是多核共享一個L3緩存。
CPU在讀取數據時，先在L1中尋找，再從L2尋找，再從L3尋找，然後是內存，再後是外存儲器（硬盤之類）。
- 2> 緩存同步協議
爲了解決多CPU讀取同樣數據緩存，進行不同運算後，寫入主內存衝突，多數CPU廠商約定實現緩存一致性協議：
MESI協議：規定每條緩存有個狀態位，定義了下面四個狀態。
修改態(Modified)：此cache行已被修改過（髒行），內容已不同於主內存，爲此cache專有；
專有態(Exclusive)：此cache行內容同於主內存，但不出現於其他cache中；
共享態(Shared)：此cache行內容同於主內存，但也出現於其他cache中；
無效態(Invalid)：此cache行內容無效(空行)。
多處理器時，單個CPU對緩存中數據進行了改動，需要通知給其他CPU。
意味着，CPU除了要控制自己的讀寫操作，還要監聽其他CPU發出的通知，從而保證最終一致。
2、CPU性能優化手段-運行時指令重排
指令重排的場景：當CPU寫緩存時發現緩存區塊正被其他CPU佔用，爲了提高CPU處理性能，可能將後面的讀緩存命令優先執行。
需要遵守as-if-serial語義：
即不管怎麼重排序(編譯器和處理器爲了提高並行度)，(單線程)程序的執行結果不能被改變。編譯器，runtime和處理器都必須遵守as-if-serial語義。不會對存在數據依賴關係的操作做重排序。
兩個問題
1、CPU高速緩存下的問題
緩存中的數據與主內存中的數據不是實時同步的，各CPU(或CPU核心)間緩存的數據也不是實時同步的。在同一個時間點，各CPU所看到同一內存地址的數據的值可能是不一致的。
2、CPU執行指令重排序優化下的問題
遵守as-if-serial語義僅保證了在單CPU自己執行的情況下結果正確。多核線程中，指令邏輯無法分辨因果關聯，可能出現亂序執行，導致程序運行結果錯誤。
3、內存屏障
處理器爲了解決以上兩個問題，提出了兩個內存屏障指令(Memory Barrier)：
寫內存屏障(Store Memory Barrier)：在指令後插入Store Barrier，能讓寫入緩存中的最新數據更新寫入主內存，讓其他線程可見。強制寫入主內存，這種顯示調用，CPU就不會因爲性能考慮而去對指令重排。
讀內存屏障(Load Memory Barrier)：在指令前插入Load Barrier，可以讓高速緩存中的數據失效，強制重新從主內存加載數據。強制讀取主內存內容，讓CPU緩存與主內存保持一致，避免了緩存導致的一致性問題。
四、線程通信
涉及到線程通信的類型：
文件共享、網絡共享、共享變量、jdk提供的線程協調API(suspend/resume、wait/notify、park/unpark)
1、文件共享：線程1-->寫入數據-->文件系統<--讀取數據<--線程2
2、網絡共享
3、變量共享：線程1-->寫入數據-->內存<--讀取數據<--線程2
4、線程協作-JDK API：多線程協作的典型場景：生產者-消費者模型。(線程阻塞、線程喚醒)
API - 被棄用的suspend/resume
Thread.suspend()、Thread.resume()。
作用：調用suspend掛起目標線程，調用resume恢復線程執行。
被棄用是因爲容易寫出死鎖的代碼(在同步代碼中，或者當suspend比resume後執行時)，所以用wait/notify和park/unpark機制進行替代。
API - wait/notify機制
Object.wait()、Object.notify()。
wait方法導致當前線程等待，加入到該對象的等待集合中，並且放棄當前持有的對象鎖。
notify/notifyAll方法喚醒一個或所有正在等待這個對象鎖的線程。
這些方法只能由同一對象鎖的持有者線程調用，也就是寫在同步塊裏面，否則會拋出IllegalMonitorStateException異常。
雖然wait會自動解鎖，但仍對執行順序有要求，如果wait在notify之後調用，線程將會永遠處於WAITING狀態，儘管並不持有鎖。
API - park/unpark機制
LockSupport.park()、LockSupport.unpark(thread)。
線程調用park則等待“許可”，unpark方法爲指定線程提供“許可(permit)”。
不要求park和unpark方法的執行順序。
多次調用unpark後，再調用park，線程會直接運行。只要調用park最終能拿到“許可”，就能繼續執行。
連續多次調用park方法，第一次的調用拿到“許可”直接運行，後續的park調用會進入等待。
park掛起線程後不會像wait一樣釋放鎖，在同步代碼中有發生死鎖的可能(等待、爭搶鎖)。
僞喚醒
代碼中使用if語句來做條件判斷是錯誤的，官方建議應該在循環中檢查條件判斷。因爲處於等待狀態的線程可能會收到錯誤警報和僞喚醒，如果不在循環中檢查條件判斷，程序就會在沒有滿足條件的情況下退出。
僞喚醒是指線程並非因爲notify、notifyAll、unpark等api調用而喚醒，是更底層原因導致的。