要點提煉| 理解JVM以內存模型&線程

本篇將介紹虛擬機如何實現多線程、多線程之間因爲共享和競爭數據而致使的一系列問題及解決方案。

• 概述
• Java內存模型
• Java與線程

---

1.概述

a.多任務處理的必要性：

• 充分利用計算機處理器的能力，避免處理器在磁盤I/O、網絡通訊或數據庫訪問時老是處於等待其餘資源的狀態。
• 便於一個服務端同時對多個客戶端提供服務。經過指標TPS（Transactions Per Second）可衡量一個服務性能的高低好壞，它表示每秒服務端平均能響應的請求總數，進而體現出程序的併發能力。

b.硬件的效率與一致性

爲了更好的理解Java內存模型，先理解物理計算機中的併發問題，二者有很高的可比性。

爲了平衡計算機的存儲設備與處理器的運算速度之間幾個數量級的差距，引入一層高速緩存（Cache）來做爲內存與處理器之間的緩衝：

• 將運算須要使用到的數據複製到緩存中，讓運算能快速進行；
• 當運算結束後再從緩存同步回內存之中，而無須讓處理器等待緩慢的內存讀寫。

可是基於高速緩存的存儲交互在多處理器系統中會帶來緩存一致性（Cache Coherence）的問題。這是由於每一個處理器都有本身的高速緩存，而它們又共享同一主內存（Main Memory），當多個處理器的運算任務都涉及同一塊主內存區域時，就可能致使各自的緩存數據不一致。解決辦法就是須要各個處理器訪問緩存時都遵循一些協議，在讀寫時要根據協議來進行操做。以下圖。

所以，這裏所說的內存模型能夠理解爲：在特定的操做協議下，對特定的內存或高速緩存進行讀寫訪問的過程抽象。

---

2.Java內存模型（Java Memory Model，JMM）

a.目的：屏蔽掉各類硬件和操做系統的內存訪問差別，實現Java程序在各類平臺下都能達到一致的內存訪問效果。

b.方法：經過定義程序中各個變量的訪問規則，即在虛擬機中將變量存儲到內存和從內存中取出變量這樣的底層細節。

注意：這裏的變量與Java中說的變量不一樣，而指的是實例字段、靜態字段和構成數組對象的元素，但不包括局部變量與方法參數，由於後者是線程私有的，不會被共享，天然就不會存在競爭問題。

c.結構：模型結構如圖，和上張圖進行類比。

• 主內存（Main Memory）：全部變量的存儲位置。直接對應於物理硬件的內存。

注意：這裏的主內存、工做內存與要點提煉| 理解JVM以內存管理說的Java內存區域中的Java堆、棧、方法區等並非同一個層次的內存劃分。

• 工做內存（Working Memory）：每條線程還有本身的工做內存，用於保存被該線程使用到的變量的主內存副本拷貝。爲了獲取更好的運行速度，虛擬機可能會讓工做內存優先存儲於寄存器和高速緩存中。

注意：

• 線程對變量的全部操做都必須在工做內存中進行，而不能直接讀寫主內存中的變量。
• 不一樣的線程之間也沒法直接訪問對方工做內存中的變量，線程間變量值的傳遞必須經過主內存來完成。

• 交互協議：用於規定一個變量如何從主內存拷貝到工做內存、如何從工做內存同步回主內存之類的實現細節。共有8種操做：
  • ①用於主內存變量：
  • 鎖定（lock）：把變量標識爲一條線程獨佔的狀態。
  • 解鎖（unlock）：把處於鎖定狀態的變量釋放出來。
  • 讀取（read）：把變量的值從主內存傳輸到線程的工做內存中，以便隨後的load動做使用。
  • 載入（load）：把read操做從主內存中獲得的變量值放入工做內存的變量副本中。
  • ②用於工做內存變量：
  • 使用（use）：把工做內存中一個變量的值傳遞給執行引擎。
  • 賦值（assign）：把從執行引擎接收到的值賦給工做內存的變量。
  • 存儲（store）：把工做內存中變量的值傳送到主內存中，以便隨後的write操做使用。
  • 寫入（write）：把store操做從工做內存中獲得的變量的值放入主內存的變量中。

結論：注意是順序非連續

• 若是要把變量從主內存複製到工做內存，那就要順序地執行read和load。
• 若是要把變量從工做內存同步回主內存，就要順序地執行store和write。

d.確保併發操做安全的原則：

①在Java內存模型中規定了執行上述8種基本操做時須要知足以下規則：

• 不容許read和load、store和write操做之一單獨出現，即不容許一個變量從主內存讀取了但工做內存不接受，或者從工做內存發起回寫了但主內存不接受的狀況出現。
• 不容許一個線程丟棄它的最近的assign操做，即變量在工做內存中改變了以後必須把該變化同步回主內存。
• 不容許一個線程無緣由地，即沒有發生過任何assign操做就把數據從線程的工做內存同步回主內存中。
• 一個新的變量只能在主內存中「誕生」，不容許在工做內存中直接使用一個未被初始化（load或assign）的變量，即對一個變量實施use、store操做以前必須先執行過了assign和load操做。
• 一個變量在同一個時刻只容許一條線程對其進行lock操做，但lock操做能夠被同一條線程重複執行屢次，屢次執行lock後，只有執行相同次數的unlock操做，變量纔會被解鎖。
• 若是對一個變量執行lock操做，那將會清空工做內存中此變量的值，在執行引擎使用這個變量前，須要從新執行load或assign操做初始化變量的值。
• 若是一個變量事先沒有被lock操做鎖定，那就不容許對它執行unlock操做，也不容許去unlock一個被其餘線程鎖定住的變量。
• 對一個變量執行unlock操做以前，必須先把此變量同步回主內存中。

可見這麼多規則很是繁瑣，實踐也麻煩，下面再介紹一個等效判斷原則--先行發生原則。

②先行發生原則：是Java內存模型中定義的兩項操做之間的偏序關係。下面例舉一些「自然的」先行發生關係，無須任何同步器協助就已經存在，能夠在編碼中直接使用。

• 程序次序規則（Program Order Rule）：在一個線程內，按照控制流順序，書寫在前面的操做先行發生於書寫在後面的操做。
• 管程鎖定規則（Monitor Lock Rule）：一個unlock操做先行發生於後面對同一個鎖的lock操做。
• volatile變量規則（Volatile Variable Rule）：對一個volatile變量的寫操做先行發生於後面對這個變量的讀操做。
• 線程啓動規則（Thread Start Rule）：Thread對象的start()先行發生於此線程的每個動做。
• 線程終止規則（Thread Termination Rule）：線程中的全部操做都先行發生於對此線程的終止檢測.可經過Thread.join()結束、Thread.isAlive()的返回值等手段檢測到線程已經終止執行。
• 線程中斷規則（Thread Interruption Rule）：對線程interrupt()的調用先行發生於被中斷線程的代碼檢測到中斷事件的發生。可經過Thread.interrupted()檢測到是否有中斷髮生。
• 對象終結規則（Finalizer Rule）：一個對象的初始化完成先行發生於它的finalize()的開始。
• 傳遞性（Transitivity）：若是操做A先行發生於操做B，操做B先行發生於操做C，那麼操做A必定先行發生於操做C。

e.Java內存模型保證併發過程的原子性、可見性和有序性的措施：

• 原子性（Atomicity）：一個操做要麼都執行要麼都不執行。
  • 可直接保證的原子性變量操做有：read、load、assign、use、store和write，所以可認爲基本數據類型的訪問讀寫是具有原子性的。
  • 若須要保證更大範圍的原子性，可經過更高層次的字節碼指令monitorenter和monitorexit來隱式地使用lock和unlock這兩個操做，反映到Java代碼中就是同步代碼塊synchronized關鍵字。
• 可見性（Visibility）：當一個線程修改了共享變量的值，其餘線程可以當即得知這個修改。
  • 經過在變量修改後將新值同步回主內存，在變量讀取前從主內存刷新變量值這種依賴主內存做爲傳遞媒介的方式來實現。
  • 提供三個關鍵字保證可見性：volatile能保證新值能當即同步到主內存，且每次使用前當即從主內存刷新；synchronized對一個變量執行unlock操做以前能夠先把此變量同步回主內存中；被final修飾的字段在構造器中一旦初始化完成且構造器沒有把this的引用傳遞出去，就能夠在其餘線程中就能看見final字段的值。
• 有序性（Ordering）：程序代碼按照指令順序執行。
  • 若是在本線程內觀察，全部的操做都是有序的，指「線程內表現爲串行的語義」；若是在一個線程中觀察另外一個線程，全部的操做都是無序的，指「指令重排序」現象和「工做內存與主內存同步延遲」現象。
  • 提供兩個關鍵字保證有序性：volatile 自己就包含了禁止指令重排序的語義；synchronized保證一個變量在同一個時刻只容許一條線程對其進行lock操做，使得持有同一個鎖的兩個同步塊只能串行地進入。

---

3.Java與線程

a.線程實現的三種方式

①使用內核線程（Kernel-Level Thread,KLT）

• 定義：直接由操做系統內核支持的線程。
• 原理：由內核來完成線程切換，內核經過操縱調度器（Scheduler）對線程進行調度，並負責將線程的任務映射到各個處理器上。每一個內核線程能夠視爲內核的一個分身， 這樣操做系統就有能力同時處理多件事情。
• 多線程內核（Multi-Threads Kernel）：支持多線程的內核
• 輕量級進程（Light Weight Process,LWP）：內核線程的一種高級接口
  • 優勢：每一個輕量級進程都由一個內核線程支持，所以每一個都成爲一個獨立的調度單元，即便有一個輕量級進程在系統調用中阻塞，也不會影響整個進程繼續工做。
  • 缺點：因爲基於內核線程實現，因此各類線程操做（建立、析構及同步）都須要進行系統調用，代價相對較高，須要在用戶態（User Mode）和內核態（Kernel Mode）中來回切換；另外，一個系統支持輕量級進程的數量是有限的。
  • 一對一線程模型：輕量級進程與內核線程之間1：1的關係，如圖所示

②使用用戶線程（User Thread,UT）

• 定義：廣義上認爲一個線程不是內核線程就是用戶線程；狹義上認爲用戶線程指的是徹底創建在用戶空間的線程庫上，而系統內核不能感知線程存在的實現。
• 優勢：因爲用戶線程的創建、同步、銷燬和調度徹底在用戶態中完成，不須要內核的幫助，甚至能夠不須要切換到內核態，因此操做很是快速且低消耗的，且能夠支持規模更大的線程數量。
• 缺點：因爲沒有系統內核的支援，全部的線程操做都須要用戶程序本身處理，線程的建立、切換和調度都是須要考慮的問題，實現較複雜。
• 一對多的線程模型進程：進程與用戶線程之間1：N的關係，如圖所示

③使用用戶線程加輕量級進程混合

• 定義：既存在用戶線程，也存在輕量級進程。
• 優勢：用戶線程徹底創建在用戶空間中，所以用戶線程的建立、切換、析構等操做依然廉價，而且能夠支持大規模的用戶線程併發；操做系統提供支持的輕量級進程做爲用戶線程和內核線程之間的橋樑，可使用內核提供的線程調度功能及處理器映射，且用戶線程的系統調用要經過輕量級線程來完成，大大下降了整個進程被徹底阻塞的風險。
• 多對多的線程模型：用戶線程與輕量級進程的數量比不定，即用戶線程與輕量級進程之間N：M的關係，如圖所示

那麼Java線程的實現是選擇哪種呢？答案是不肯定的。操做系統支持怎樣的線程模型，在很大程度上決定了Java虛擬機的線程是怎樣映射的。線程模型只對線程的併發規模和操做成本產生影響，而對Java程序的編碼和運行過程來講，這些差別都是透明的。

b.Java線程調度的兩種方式

線程調度：指系統爲線程分配處理器使用權的過程。

①協同式線程調度（Cooperative Threads-Scheduling）

• 由線程自己來控制線程的執行時間。線程把本身的工做執行完後，要主動通知系統切換到另一個線程上。
• 好處：實現簡單；切換操做本身可知，不存在線程同步的問題。
• 壞處：線程執行時間不可控，假如一個線程編寫有問題一直不告知系統進行線程切換，那麼程序就會一直被阻塞。

②搶佔式線程調度（Preemptive Threads-Scheduling）

• 由系統來分配每一個線程的執行時間。
• 好處：線程執行時間是系統可控的，不存在一個線程致使整個進程阻塞的問題。
• 能夠經過設置線程優先級，優先級越高的線程越容易被系統選擇執行。

可是線程優先級並非太靠譜，一方面由於Java的線程是經過映射到系統的原生線程上來實現的，因此線程調度最終仍是取決於操做系統，在一些平臺上不一樣的優先級實際會變得相同；另外一方面優先級可能會被系統自行改變。

c.線程的五種狀態

在任意一個時間點，一個線程只能有且只有其中的一種狀態：

• 新建（New）：線程建立後還沒有啓動
• 運行（Runable）：包括正在執行（Running）和等待着CPU爲它分配執行時間（Ready）兩種
• 無限期等待（Waiting）：該線程不會被分配CPU執行時間，要等待被其餘線程顯式地喚醒。如下方法會讓線程陷入無限期等待狀態：
  • 沒有設置Timeout參數的Object.wait()
  • 沒有設置Timeout參數的Thread.join()
  • LockSupport.park()
• 限期等待（Timed Waiting）：該線程不會被分配CPU執行時間，但在必定時間後會被系統自動喚醒。如下方法會讓線程進入限期等待狀態：
  • Thread.sleep()
  • 設置了Timeout參數的Object.wai()
  • 設置了Timeout參數的Thread.join()
  • LockSupport.parkNanos()
  • LockSupport.parkUntil()
• 阻塞（Blocked）：線程被阻塞

注意區別：

• 阻塞狀態：在等待獲取到一個排他鎖，在另一個線程放棄這個鎖的時候發生；
• 等待狀態：在等待一段時間或者喚醒動做的發生，在程序等待進入同步區域的時候發生。

• 結束（Terminated）：線程已經結束執行

下圖是線程狀態之間的轉換：