第五部分 高效并發

第十二章 Java內存模型與線程

并發處理的廣泛應用是使得Amdahl定律代替摩爾定律成為計算機性能發展源動力的根本原因，也是人類“壓榨”計算機運算能力的最有力武器。

12.1 概述

• 多任務處理在現代計算機操作系統中幾乎已是一項必備的功能了；
• 除了充分利用計算機處理器的能力外，一個服務端同時對多個客戶端提供服務則是另一個更具體的并發應用場景；
• 服務端是Java語言最擅長的領域之一，不過如何寫好并發應用程序卻又是服務端程序開發的難點之一，處理好并發方面的問題通常需要更多的編碼經驗來支持，幸好Java語言和虛擬機提供了許多工具，把并發編碼的門檻降低了不少；

12.2 硬件的效率與一致性

• 絕大多數的運算任務不可能只靠處理器計算就能完成，處理器至少要與內存交互，所以現代計算機系統都不得不加入一層讀寫速度盡可能接近處理器運算速度的高速緩存來作為內存與處理器之間的緩沖：將運算需要使用到的數據復制到緩存中，讓運算能快速運行，當運算結束后再從緩存同步回內存之中，這樣處理器就無須等待緩慢的內存讀寫了；
• 基于高速緩存的存儲交互很好地解決了處理器與內存的速度矛盾，但是也為計算機系統帶來更高的復雜度，因為它引入了一個新的問題：緩存一致性；為了解決一致性的問題，需要各個處理器訪問緩存時都遵循一些協議，在讀寫時要根據協議來進行操作，這類協議有MSI、MESI、MOSI、Synapse、Firefly及Dragon Protocol等；
• 本章將會多次提到內存模型一詞，可以理解在特定的操作協議下，對特定的內存或高速緩存進行讀寫訪問的過程抽象；不同架構的物理機器可以擁有不一樣的內存模型，而Java虛擬機也有自己的內存模型，并且這里介紹的內存訪問操作與硬件的緩存訪問具有很高的可比性；
• 除了增加高速緩存之外，為了使得處理器內部的運算單元能盡量被充分利用，處理器可能會對輸入代碼進行亂序執行優化，處理器會在計算之后將亂序執行的結果重組，保證該結果與順序執行的結果是一致的；

12.3 Java內存模型

Java虛擬機規范中視圖定義一種Java內存模型（JMM）來屏蔽掉各種硬件和操作系統的內存訪問差異，以實現讓Java程序在各種平臺下都能達到一致的內存訪問效果。

12.3.1 主內存與工作內存

• Java內存模型的主要目標是定義程序中各個變量的訪問規則，即在虛擬機中將變量存儲到內存和從內存中取出變量這樣的底層細節；此處的變量與Java編程中所說的變量有所區別，它包括了實例字段、靜態字段和構成數組對象的元素，但不包括局部變量與方法參數，因為后者是線程私有的，不會被共享；
• Java內存模型規定了所有的變量都存儲在主內存中，每個線程還有自己的工作內存，線程的工作內存中保存了被該線程使用到的變量的主內存副本拷貝，線程對變量的所有操作都必須在工作內存中進行，而不能直接讀寫主內存中的變量；
• 這里所講的主內存、工作內存與第二章所講的Java內存區域中的Java堆、棧、方法區等并不是同一個層次的內存劃分，這兩者基本上是沒有關系的；線程、主內存和工作內存的關系如下所示：

12.3.2 內存間交互操作

關于主內存與工作內存之間具體的交互協議，即一個變量如何從主內存拷貝到工作內存、如何從工作內存同步回主內存之類的實現細節，Java內存模型中定義了以下八種操作來完成，虛擬機實現時必須保證下面提及的每一種操作都是原子的、不可再分的（對于double和long類型的變量的某些操作在某些平臺允許有例外）：

• lock
• unlock
• read
• load
• use
• assign
• store
• write

基于理解難度和嚴謹性考慮，最新的JSR-133文檔中，已經放棄采用這八種操作去定義Java內存模型的訪問協議了，后面將會介紹一個等效判斷原則 – 先行發生原則，用來確定一個訪問在并發環境下是否安全；

12.3.3 對于volatile型變量的特殊規則

• 關鍵字volatile可以說是Java虛擬機提供的最輕量級的同步機制；
• 當一個變量定義為volatile之后，它將具備兩種特性：第一是保證此變量對所有線程的可見性，這里的可見性是指當一個線程修改了這個變量的值，新的值對于其他線程來說是可以立即得知的，而普通的變量的值在線程間傳遞均需要通過主內存來完成；另外一個是禁止指令重排序優化，普通的變量僅僅會保證在該方法的執行過程中所有依賴賦值結果的地方都能獲取到正確的結果，而不能保證變量賦值操作的順序與程序代碼中的執行順序一致；
• volatile變量在各個線程的工作內存中不存在一致性問題，但是Java里面的運算并非原子操作，導致volatile變量的運算在并發下一樣是不安全的；
• 在不符合以下兩條規則的運算場景中，我們仍然要通過加鎖來保證原子性：運算結果并不依賴變量的當前值或者能夠確保只有單一的線程修改變量的值、變量不需要與其他的狀態變量共同參與不變約束；
• volatile變量讀操作的性能消耗與普通變量幾乎沒有任何差別，但是寫操作則可能會慢一些；不過大多數場景下volatile的總開銷仍然要比鎖低，我們在volatile與鎖之中選擇的唯一依據僅僅是volatile的語義能否滿足使用場景的需求；

12.3.4 對于long和double型變量的特殊規則

• 允許虛擬機將沒有被volatile修飾的64位數據的讀寫操作劃分為兩次32位的操作來進行，即允許虛擬機實現選擇可以不保證64位數據類型的load、store、read和write這4個操作的原子性，這點就是所謂的long和double的非原子性協定；
• 但允許虛擬機選擇把這些操作實現為具有原子性的操作，目前各種平臺下的商用虛擬機幾乎都選擇把64位數據的讀寫操作作為原子操作來對待；

12.3.5 原子性、可見性與有序性

• 原子性（Atomicity）：由Java內存模型來直接保證的原子性變量操作包括read、load、assign、use、store和write；在synchronized塊之間的操作也具備原子性；
• 可見性（Visibility）：是指當一個線程修改了共享變量的值，其他線程能夠立即得知這個修改；除了volatile之外，Java還有synchronized和final關鍵字能實現可見性；
• 有序性（Ordering）：如果在本線程內觀察，所有的操作都是有序的；如果在一個線程中觀察另一個線程，所有的操作都是無序的；Java語言提供了volatile和synchronized兩個關鍵字來保證線程之間操作的有序性；

12.3.6 先行發生原則

• 先行發生是Java內存模型中定義的兩項操作之間的偏序關系，如果說操作A先行發生于操作B，其實就是說在發生操作B之前，操作A產生的影響能被操作B觀察到，影響包括了修改了內存中共享變量的值、發送了消息、調用了方法等；
• 下面是Java內存模型下一些天然的先行發生關系：程序次序規則、管程鎖定規則、volatile變量規則、線程啟動規則、線程終止規則、線程中斷規則、對象終結規則、傳遞性；
• 時間先后順序與先行發生原則之間基本沒有太大的關系，所以我們衡量并發安全問題的時候不要受到時間順序的干擾，一切必須以先行發生原則為準；

12.4 Java與線程

12.4.1 線程的實現

• 線程是比進程更輕量級的調度執行單位，線程的引入可以把一個進程的資源分配和執行調度分開，各個線程既可以共享進程資源又可以獨立調度；
• Thread類與大部分的Java API有顯著的差別，它的所有關鍵方法都是聲明為Native的；
• 實現線程主要有三種方式：使用內核線程實現（系統調用代價相對較高、一個系統支持輕量級進程的數量是有限的）、使用用戶線程實現（優勢在于不需要系統內核支援，劣勢在于所有線程操作都需要用戶程序自己處理）和使用用戶線程加輕量級進程混合實現（用戶線程是完全建立在用戶空間中，因此用戶線程的創建、切換等操作依然廉價，并且可以支持大規模的用戶線程并發；而操作系統提供支持的輕量級進程則作為用戶線程和內核線程之間的橋梁，這樣可以使用內核提供的線程調度功能及處理器映射，并且用戶線程的系統調用要通過輕量級線程來完成，大大降低了整個進程被完全阻塞的風險）；
• 對于Sun JDK來說，它的Windows版與Linux版都是使用一對一的線程模型實現的，一條Java線程就映射到一條輕量級進程之中，因為Windows和Linux系統提供的線程模式就是一對一的；

12.4.2 Java線程調度

• 線程調度是指系統為線程分配處理器使用權的過程，主要調度方式有兩種，分別是協同式線程調度（線程的執行時間由線程本身來控制）和搶占式線程調度（線程由系統來分配執行時間，線程的切換不由線程本身來決定）；
• Java語言一共設置了10個級別的線程優先級，不過線程優先級并不是太靠譜，原因就是操作系統的線程優先級不見得總是與Java線程的優先級一一對應，另外優先級還可能被系統自行改變；

12.4.3 狀態轉換

• Java語言定義了五種線程狀態，在任意一個時間點，一個線程只能有且只有其中一種狀態，分別是新建（New）、運行（Runnable）、無限期等待（Waiting）、限期等待（Timed Waiting）、阻塞（Blocled）、結束（Terminated）。它們之間相互的轉換關系如下所示：

12.5 本章小結

本章我們首先了解了虛擬機Java內存模型的結構及操作，然后講解了原子性、可見性、有序性在Java內存模型中的體現，最后介紹了先行發生原則的規則及使用。另外，我們還了解了線程在Java語言之中是如何實現的。

在本章主要介紹了虛擬機如何實現并發，而在下一章我們主要關注點將是虛擬機如何實現高效，以及虛擬機對我們編寫的并發代碼提供了什么樣的優化手段。

第十三章 線程安全與鎖優化

13.1 概述

• 首先需要保證并發的正確性，然后在此基礎上實現高效；

13.2 線程安全

Brian Goetz對線程安全有一個比較恰當的定義：當多個線程訪問一個對象時，如果不用考慮這些線程在運行時環境下的調度和交替執行，也不需要進行額外的同步，或者在調用方進行任何其他的協調操作，調用這個對象的行為都可以獲得正確的結果，那這個對象是線程安全的。

13.2.1 Java語言中的線程安全

• 我們可以將Java語言中各個操作共享的數據分為以下五類：不可變、絕對線程安全、相對線程安全、線程兼容和線程對立；
• 不可變：不可變帶來的安全性是最簡單和最純粹的，如final的基本數據類型；如果共享的數據是一個對象，那就需要保證對象的行為不會對其狀態產生任何影響才行，比如String類的substring、replace方法；Number類型的大部分子類都符合不可變要求的類型，但是AtomicInteger和AtomicLong則并非不可變的；
• 線程絕對安全：Java API中標注自己是線程安全的類，大多數都不是絕對的線程安全；比如java.util.Vector，不意味著調用它的是時候永遠都不再需要同步手段了；
• 線程相對安全：是我們通常意義上所講的線程安全，在Java語言中，大部分的線程安全類都屬于這種類型；
• 線程兼容：指對象本身并不是線程安全的，但是可以通過在調用端正確地使用同步手段來保證對象在并發環境中可以安全地使用；我們說一個類不是線程安全的，絕大多數時候指的是這一種情況；
• 線程對立：無論調用端是否采取了同步措施，都無法在多線程環境中并發使用的代碼，Java語言中很少出現；

13.2.2 線程安全的實現方法

• 互斥同步：同步是指在多個線程并發訪問共享數據時，保證共享數據在同一個時刻只被一個線程使用，而互斥是實現同步的一種手段，臨界區、互斥量和信號量都是主要的互斥實現方式；Java中最基本的互斥同步手段就是synchronized關鍵字，它對同一個線程來說是可重入的且會阻塞后面其他線程的進入；另外還可以使用java.util.concurrent包中的重入鎖（ReentrantLock）來實現同步，相比synchronized關鍵字ReentrantLock增加了一些高級功能：等待可中斷、可實現公平鎖以及鎖可以綁定多個條件；
• 非阻塞同步：互斥同步最主要的問題就是進行線程阻塞和喚醒帶來的性能問題，其屬于一種悲觀的并發策略；隨著硬件指令集的發展，我們有了另外一個選擇即基于沖突檢測的樂觀并發策略，就是先進行操作，如果沒有其他線程爭用共享數據那就操作成功了，如果有爭用產生了沖突，那就再采取其他的補償措施（最常見的就是不斷重試直至成功），這種同步操作稱為非阻塞同步；Java并發包的整數原子類，其中的compareAndSet和getAndIncrement等方法都使用了Unsafe類的CAS操作；
• 無同步方案：要保證線程安全，并不是一定就要進行同步；有一些代碼天生就是線程安全的，比如可重入代碼和線程本地存儲的代碼；

13.3 鎖優化

13.3.1 自旋鎖與自適應自旋

• 互斥同步對性能最大的影響是阻塞的實現，掛起線程和恢復線程的操作都需要轉入內核態中完成，這些操作給系統的并發性能帶來了很大的壓力；另外在共享數據的鎖定狀態只會持續很短的一段時間，為了這段時間去掛起和恢復線程并不值得，如果讓兩個或以上的線程同時并行執行，讓后面請求鎖的那個線程稍等一下，但不放棄處理器的執行時間，看看持有鎖的線程是否很快就會釋放鎖；為了讓線程等待，我們只需讓線程執行一個忙循環，這些技術就是所謂的自旋鎖；
• 在JDK 1.6已經默認開啟自旋鎖；如果鎖被占用的時間很短自旋等待的效果就會非常好，反之則會白白消耗處理器資源；
• 在JDK 1.6中引入了自適應的自旋鎖，這意味著自旋的時間不再固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定；

13.3.2 鎖消除

• 鎖消除是指虛擬機即時編譯器在運行時，對一些代碼上要求同步，但是被檢測到不可能存在共享數據競爭的鎖進行消除；
• 鎖消除的主要判斷依據來源于逃逸分析的數據支持；

13.3.3 鎖粗化

• 原則上總是推薦將同步塊的作用范圍限制得盡量小 – 只有在共享數據的實際作用域中才進行同步，這樣是為了使得需要同步的操作數量盡可能變小，如果存在鎖競爭，那等待鎖的線程也能盡快拿到鎖；
• 但是如果一系列的連續操作都對同一個對象反復加鎖和解鎖，甚至加鎖操作是出現在循環體中的，那即使沒有線程競爭，頻繁地進行互斥同步操作也會導致不必要的性能損耗；

13.3.4 輕量級鎖

• 輕量級鎖是JDK 1.6之中加入的新型鎖機制，它是相對于使用操作系統互斥量來實現的傳統鎖而言的；它并不是用來代替重量級鎖的，它的本意是在沒有多線程競爭的前提下，減少傳統的重量級鎖使用操作系統互斥量產生的性能消耗；
• 要理解輕量級鎖，以及后面會講到的偏向鎖的原理和運作過程，必須從HotSpot虛擬機的對象的內存布局開始介紹；HotSpot虛擬機的對象頭分為兩部分信息：第一部分用于存儲對象自身的運行時數據，如哈希碼、GC分代年齡等，這部分官方稱之為Mark Word，是實現輕量級鎖和偏向鎖的關鍵，另外一部分用于存儲指向方法區對象類型數據的指針； Mark Word被設計成一個非固定的數據結構以便在極小的空間存儲盡量多的信息，在32位的HotSpot虛擬機中對象未被鎖定的狀態下，25bit用于存儲對象哈希碼，4bit用于存儲對象分代年齡，2bit用于存儲鎖標志位，1bit固定為0；在其他狀態（輕量級鎖定、重量級鎖定、GC標志、可偏向）下對象的存儲內容如下：

• 在代碼進入同步塊的時候，如果此同步對象沒有被鎖定，虛擬機首先將在當前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲對象目前的Mark Word的拷貝（官方稱之為Displaced Mark Word）；然后虛擬機將使用CAS操作嘗試將對象的Mark Word更新為指向Lock Record的指針，如果更新成功了那么這個線程就擁有了該對象的鎖，并且對象Mark Word的鎖標志位將轉變為“00”，即表示此對象處于輕量級鎖定狀態；如果這個更新操作失敗了，虛擬機首先會檢查對象的Mark Word是否指向當前線程的棧幀，如果是就可以直接進入同步塊繼續執行，否則說明這個鎖對象已經被其他線程搶占了；如果有兩條以上的線程爭用同一個鎖，那輕量級鎖就不再有效，要膨脹為重量級鎖，鎖標志的狀態值變為“10”，Mark Word中存儲的就是指向重量級鎖的指針，后面等待鎖的線程也要進行阻塞狀態；
• 輕量級鎖能提升程序同步性能的依據是“對于絕大部分的鎖，在整個同步周期內都是不存在競爭的”，這是一個經驗數據；

13.3.5 偏向鎖

• 偏向鎖也是JDK 1.6中引入的一項鎖優化，它的目的是消除數據在無競爭情況下的同步原語，進一步提高程序的運行性能；如果說輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把整個同步都消除掉，連CAS操作都不做了；
• 偏向鎖會偏向于第一個獲得它的線程，如果在接下來的執行過程中，該鎖沒有被其他的線程獲取，則持有偏向鎖的線程將永遠不需要再進行同步；
• 假設當前虛擬機啟動了偏向鎖，那么當鎖對象第一次被線程獲取的時候，虛擬機將會把對象頭中的標志位設為“01”，即偏向模式；同時使用CAS操作把獲取到這個鎖的線程ID記錄在對象的Mark Word之中；如果CAS操作成功，持有偏向鎖的線程以后每次進入這個鎖相關的同步塊時，虛擬機都可以不再進行任何同步操作；當有另外一個線程去嘗試獲取這個鎖時，偏向模式就宣告結束，根據鎖對象目前是否被鎖定的狀態，撤銷偏向后恢復到未鎖定或輕量級鎖定的狀態，后續的同步操作就如上面介紹的輕量級鎖那樣執行；偏向鎖、輕量級鎖的狀態轉化以及對象Mark Work的關系如下圖所示：

• 偏向鎖可以提高帶有同步但無競爭的程序性能，它同樣是一個帶有效益權衡性質的優化；

本章小結

本章介紹了線程安全所涉及的概念和分類、同步實現的方式及虛擬機的底層運行原理，并且介紹了虛擬機為了實現高效并發所采取的一系列鎖優化措施。

from:?https://www.javazhiyin.com/39284.html?

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的《深入理解Java虚拟机》笔记6——高效并发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。