Java 并發編程決議 | 如何正確理解Java領域中的記憶體模型，主要是解決了什么問題？

蒼穹之邊，浩瀚之摯，眰恦之美； 悟心悟性，善始善終，惟善惟道！ —— 朝槿《朝槿兮年說》

寫在開頭

這些年，隨著CPU、記憶體、I/O 設備都在不斷迭代，不斷朝著更快的方向努力，在這個快速發展的程序中，有一個核心矛盾一直存在，就是這三者的速度差異，CPU 和記憶體的速度差異可以形象地描述為：CPU 是天上一天，記憶體是地上一年（假設 CPU 執行一條普通指令需要一天，那么 CPU 讀寫記憶體得等待一年的時間），記憶體和 I/O 設備的速度差異就更大了，記憶體是天上一天，I/O 設備是地上十年，

我們都知道的是，程式里大部分陳述句都要訪問記憶體，有些還要訪問 I/O，根據木桶理論（一只水桶能裝多少水取決于它最短的那塊木板），程式整體的性能取決于最慢的操作——讀寫 I/O 設備，也就是說單方面提高 CPU 性能是無效的，

為了合理利用 CPU 的高性能，平衡這三者的速度差異，計算機體系結構、作業系統、編譯程式都做出了貢獻，主要體現為：

1. 現代計算機在CPU 增加了快取，以均衡與記憶體的速度差異
2. 作業系統增加了行程、執行緒，以分時復用 CPU，進而均衡 CPU 與 I/O 設備的速度差異
3. 編譯程式優化指令執行次序，使得快取能夠得到更加合理地利用

由此可見，雖然現在我們幾乎所有的程式都默默地享受著這些成果，但是實際應用程式設計和開發程序中，還是有很多詭異問題困擾著我們，

基本概述

每當提起Java性能優化，你是否有想過，真正需要我們優化的是什么？或者說，指導我們優化的方向和目標是否明確？甚至說，我們所做的一切，是否已經達到我們的期望了呢？接下來，我們來詳細探討一下，

性能優化根據優化的方向和目標來說，大致可以分為業務優化和技術優化，業務優化產生的影響是非常巨大的，一般最常見的就是業務需求變更和業務場景適配等，當然這是產品和專案管理的作業范疇，而對于我們開發人員來說，我們需要關注的和直接與我們相關的，主要是通過一系列的技術手段，來完成我們對既定目標的技術優化，其中，從技術手段方向來看，技術優化主要可以從復用優化，結果集合優化，高效實作優化，演算法優化，計算優化，資源沖突優化和JVM優化等七個方面著手，

一般來說，技術優化基本都集中在計算機資源和存盤資源的規劃上，最直接的就是對于服務器和業務應用程式相關的資源做具體的分析，在照顧性能的前提下，同時也兼顧業務需求的要求，從而達到資源利用最優的狀態，一味地強調利用空間換時間的方式，只看計算速度，不考慮復雜性和空間的問題，確實有點不可取，特別是在云原生時代下和無服務時代，雖然模糊和減少了開發對這些問題的距離，但是我們更加需要了解和關注這些問題的實質，

特別指出的是，JVM優化，由于使用Java撰寫的應用程式，本身Java是運行在JVM虛擬機上的，這就意味著它會受到JVM的制約，對于JVM虛擬機的優化，一定程度上會提升Java應用程式的性能，如果引數配置不當，導致記憶體溢位(OOM例外)等問題，甚至引發比這更嚴重的后果，

由此可見，正確認識和掌握JVM結構相關知識，對于我們何嘗不是一個進階的技術方向，當然，JVM虛擬機這一部分的內容，相對撰寫Java程式來說，更加比較枯燥無味，概念比較多且抽象，需要我們要有更多的耐心和細心，我們都知道，一顆不浮躁的心，做任何事都會識訓不一樣的精彩，

Java JVM虛擬機

在開始這一部分內容之前，我們先來看一下，在Java中，Java程式是如何運行的，最后又是如何交給JVM托管的？

1.Java 程式運行程序

作為一名 Java 程式員，你應該知道，Java 代碼有很多種不同的運行方式，比如說可以在開發工具中運行，可以雙擊執行 jar 檔案運行，也可以在命令列中運行，甚至可以在網頁中運行，當然，這些執行方式都離不開 JRE，也就是 Java 運行時環境，

實際上，JRE 僅包含運行 Java 程式的必需組件，包括 Java 虛擬機以及 Java 核心類別庫等，我們 Java 程式員經常接觸到的 JDK（Java 開發工具包）同樣包含了 JRE，并且還附帶了一系列開發、診斷工具，

然而，運行 C++ 代碼則無需額外的運行時，我們往往把這些代碼直接編譯成 CPU 所能理解的代碼格式，也就是機器碼，

Java 作為一門高級程式語言，它的語法非常復雜，抽象程度也很高，因此，直接在硬體上運行這種復雜的程式并不現實，所以呢，在運行 Java 程式之前，我們需要對其進行一番轉換，

這個轉換具體是怎么操作的呢？當前的主流思路是這樣子的，設計一個面向 Java 語言特性的虛擬機，并通過編譯器將 Java 程式轉換成該虛擬機所能識別的指令序列，也稱 Java 位元組碼，這里順便說一句，之所以這么取名，是因為 Java 位元組碼指令的操作碼（opcode）被固定為一個位元組，

并且，我們同樣可以將其反匯編為人類可讀的代碼格式（如下圖的最右列所示），不同的是，Java 版本的編譯結果相對精簡一些，這是因為 Java 虛擬機相對于物理機而言，抽象程度更高，

Java 虛擬機可以由硬體實作[1]，但更為常見的是在各個現有平臺（如 Windows_x64、Linux_aarch64）上提供軟體實作，這么做的意義在于，一旦一個程式被轉換成 Java 位元組碼，那么它便可以在不同平臺上的虛擬機實作里運行，這也就是我們經常說的“一次撰寫，到處運行”，

虛擬機的另外一個好處是它帶來了一個托管環境（Managed Runtime），這個托管環境能夠代替我們處理一些代碼中冗長而且容易出錯的部分，其中最廣為人知的當屬自動記憶體管理與垃圾回收，這部分內容甚至催生了一波垃圾回收調優的業務，

除此之外，托管環境還提供了諸如陣列越界、動態型別、安全權限等等的動態檢測，使我們免于書寫這些無關業務邏輯的代碼，

2.Java 程式創建程序

從 class 檔案到記憶體中的類，按先后順序需要經過加載、鏈接以及初始化三大步驟，其中，鏈接程序中同樣需要驗證；而記憶體中的類沒有經過初始化，同樣不能使用，那么，是否所有的 Java 類都需要經過這幾步呢？

我們知道 Java 語言的型別可以分為兩大類：基本型別（primitive types）和參考型別（reference types），在上一篇中，我已經詳細介紹過了 Java 的基本型別，它們是由 Java 虛擬機預先定義好的，

至于另一大類參考型別，Java 將其細分為四種：類、介面、陣列類和泛型引數，由于泛型引數會在編譯程序中被擦除（我會在專欄的第二部分詳細介紹），因此 Java 虛擬機實際上只有前三種，在類、介面和陣列類中，陣列類是由 Java 虛擬機直接生成的，其他兩種則有對應的位元組流，

說到位元組流，最常見的形式要屬由 Java 編譯器生成的 class 檔案，除此之外，我們也可以在程式內部直接生成，或者從網路中獲取（例如網頁中內嵌的小程式 Java applet）位元組流，這些不同形式的位元組流，都會被加載到 Java 虛擬機中，成為類或介面，為了敘述方便，下面我就用“類”來統稱它們，

無論是直接生成的陣列類，還是加載的類，Java 虛擬機都需要對其進行鏈接和初始化，

其實，Java 虛擬機將位元組流轉化為 Java 類的程序，就是我們常說的Java類的創建程序，這個程序可分為加載、鏈接以及初始化三大步驟：

• 加載是指查找位元組流，并且據此創建類的程序，加載需要借助類加載器，在 Java 虛擬機中，類加載器使用了雙親委派模型，即接收到加載請求時，會先將請求轉發給父類加載器，
• 鏈接，是指將創建成的類合并至 Java 虛擬機中，使之能夠執行的程序，鏈接還分驗證、準備和決議三個階段，其中，決議階段為非必須的，
• 初始化，則是為標記為常量值的欄位賦值，以及執行 < clinit > 方法的程序，類的初始化僅會被執行一次，這個特性被用來實作單例的延遲初始化，

3.Java 程式加載程序

從虛擬機視角來看，執行 Java 代碼首先需要將它編譯而成的 class 檔案加載到 Java 虛擬機中，加載后的 Java 類會被存放于方法區（Method Area）中，實際運行時，虛擬機會執行方法區內的代碼，

如果你熟悉 X86 的話，你會發現這和段式記憶體管理中的代碼段類似，而且，Java 虛擬機同樣也在記憶體中劃分出堆和堆疊來存盤運行時資料，

不同的是，Java 虛擬機會將堆疊細分為面向 Java 方法的 Java 方法堆疊，面向本地方法（用 C++ 寫的 native 方法）的本地方法堆疊，以及存放各個執行緒執行位置的 PC 暫存器，

在運行程序中，每當呼叫進入一個 Java 方法，Java 虛擬機會在當前執行緒的 Java 方法堆疊中生成一個堆疊幀，用以存放區域變數以及位元組碼的運算元，這個堆疊幀的大小是提前計算好的，而且 Java 虛擬機不要求堆疊幀在記憶體空間里連續分布，

當退出當前執行的方法時，不管是正常回傳還是例外回傳，Java 虛擬機均會彈出當前執行緒的當前堆疊幀，并將之舍棄，

從硬體視角來看，Java 位元組碼無法直接執行，因此，Java 虛擬機需要將位元組碼翻譯成機器碼，

啟動類加載器是由 C++ 實作的，沒有對應的 Java 物件，因此在 Java 中只能用 null 來指代，
除了啟動類加載器之外，其他的類加載器都是 java.lang.ClassLoader 的子類，因此有對應的 Java 物件，這些類加載器需要先由另一個類加載器，比如說啟動類加載器，加載至 Java 虛擬機中，方能執行類加載，

在 Java 虛擬機中，這個潛規則有個特別的名字，叫雙親委派模型，每當一個類加載器接收到加載請求時，它會先將請求轉發給父類加載器，在父類加載器沒有找到所請求的類的情況下，該類加載器才會嘗試去加載，

在 Java 9 之前，啟動類加載器負責加載最為基礎、最為重要的類，比如存放在 JRE 的 lib 目錄下 jar 包中的類（以及由虛擬機引數 -Xbootclasspath 指定的類），除了啟動類加載器之外，另外兩個重要的類加載器是擴展類加載器（extension class loader）和應用類加載器（application class loader），均由 Java 核心類別庫提供，

擴展類加載器的父類加載器是啟動類加載器，它負責加載相對次要、但又通用的類，比如存放在 JRE 的 lib/ext 目錄下 jar 包中的類（以及由系統變數 java.ext.dirs 指定的類），

應用類加載器的父類加載器則是擴展類加載器，它負責加載應用程式路徑下的類，（這里的應用程式路徑，便是指虛擬機引數 -cp/-classpath、系統變數 java.class.path 或環境變數 CLASSPATH 所指定的路徑，）默認情況下，應用程式中包含的類便是由應用類加載器加載的，

Java 9 引入了模塊系統，并且略微更改了上述的類加載器1，擴展類加載器被改名為平臺類加載器（platform class loader），Java SE 中除了少數幾個關鍵模塊，比如說 java.base 是由啟動類加載器加載之外，其他的模塊均由平臺類加載器所加載，

除了由 Java 核心類別庫提供的類加載器外，我們還可以加入自定義的類加載器，來實作特殊的加載方式，舉例來說，我們可以對 class 檔案進行加密，加載時再利用自定義的類加載器對其解密，

除了加載功能之外，類加載器還提供了命名空間的作用，在 Java 虛擬機中，類的唯一性是由類加載器實體以及類的全名一同確定的，即便是同一串位元組流，經由不同的類加載器加載，也會得到兩個不同的類，在大型應用中，我們往往借助這一特性，來運行同一個類的不同版本，

4.Java 程式編譯程序

在 HotSpot 里面，上述翻譯程序有兩種形式：

• 第一種是解釋執行，即逐條將位元組碼翻譯成機器碼并執行；
• 第二種是即時編譯（Just-In-Time compilation，JIT），即將一個方法中包含的所有位元組碼編譯成機器碼后再執行，

前者的優勢在于無需等待編譯，而后者的優勢在于實際運行速度更快，HotSpot 默認采用混合模式，綜合了解釋執行和即時編譯兩者的優點，它會先解釋執行位元組碼，而后將其中反復執行的熱點代碼，以方法為單位進行即時編譯，

HotSpot 采用了多種技術來提升啟動性能以及峰值性能，剛剛提到的即時編譯便是其中最重要的技術之一，

即時編譯建立在程式符合二八定律的假設上，也就是百分之二十的代碼占據了百分之八十的計算資源，

對于占據大部分的不常用的代碼，我們無需耗費時間將其編譯成機器碼，而是采取解釋執行的方式運行；另一方面，對于僅占據小部分的熱點代碼，我們則可以將其編譯成機器碼，以達到理想的運行速度，

理論上講，即時編譯后的 Java 程式的執行效率，是可能超過 C++ 程式的，這是因為與靜態編譯相比，即時編譯擁有程式的運行時資訊，并且能夠根據這個資訊做出相應的優化，

舉個例子，我們知道虛方法是用來實作面向物件語言多型性的，對于一個虛方法呼叫，盡管它有很多個目標方法，但在實際運行程序中它可能只呼叫其中的一個，這個資訊便可以被即時編譯器所利用，來規避虛方法呼叫的開銷，從而達到比靜態編譯的 C++ 程式更高的性能，

為了滿足不同用戶場景的需要，HotSpot 內置了多個即時編譯器：C1、C2 和 Graal，

• Graal 是 Java 10 正式引入的實驗性即時編譯器，在專欄的第四部分我會詳細介紹，這里暫不做討論，之所以引入多個即時編譯器，是為了在編譯時間和生成代碼的執行效率之間進行取舍，
• C1 又叫做 Client 編譯器，面向的是對啟動性能有要求的客戶端 GUI 程式，采用的優化手段相對簡單，因此編譯時間較短，
• C2 又叫做 Server 編譯器，面向的是對峰值性能有要求的服務器端程式，采用的優化手段相對復雜，因此編譯時間較長，但同時生成代碼的執行效率較高，

從 Java 7 開始，HotSpot 默認采用分層編譯的方式：熱點方法首先會被 C1 編譯，而后熱點方法中的熱點會進一步被 C2 編譯，
為了不干擾應用的正常運行，HotSpot 的即時編譯是放在額外的編譯執行緒中進行的，HotSpot 會根據 CPU 的數量設定編譯執行緒的數目，并且按 1:2 的比例配置給 C1 及 C2 編譯器，

在計算資源充足的情況下，位元組碼的解釋執行和即時編譯可同時進行，編譯完成后的機器碼會在下次呼叫該方法時啟用，以替換原本的解釋執行，

5.Java 虛擬機結構

從組成結構上看，一個Java 虛擬機(HotSpot 為例)，主要包括指令集合，指令決議器，程式執行指令 等3個方面，其中：

• 指令集合：指的是我們常說的位元組碼(Byte Code),主要指將源檔案代碼(Source File Code) 編譯運行生成的,比如在Java中是通過javac命令編譯(.java)檔案生成，而在Python中是通過jython命令來編譯(.py)檔案生成，
• 指令決議器：主要是指位元組碼解釋器(Byte Code Interpreter)和即時編譯器(JIT Compiler)，比如一個Java 虛擬機(HotSpot 為例)，就有一個位元組碼解釋器和兩個即時編譯器(Server編譯器和Client 編譯器)，
• 程式執行指令： 主要是指操作記憶體區域，以裝載和執行，一般是JVM負責 將 位元組碼 解釋成具體的機器指令來執行，

一般來說，任何一個Java虛擬機都會包含這三個方面的，但是具體的有各有所不同：

1. 位元組碼指令：JVM 具有針對以下任務組的位元組碼指令規范：加載和存盤，算術，型別轉換，物件創建和操作，運算元堆疊管理（push/pop），控制轉移（分支），方法呼叫和回傳，拋出例外，基于監視器的并發，被加載到JVM后可以被執行，其中位元組碼是實作跨平臺的基礎，
2. 位元組碼解釋器：用于將位元組碼決議成計算機能執行的語言，一臺計算機有了 Java 位元組碼解釋器后，它就可以運行任何 Java 位元組碼程式，同樣的 Java 程式就可以在具有了這種解釋器的硬體架構的計算機上運行,實作了“跨平臺”，
3. JIT即時編譯器：JIT 編譯器可以在執行程式時將 Java 位元組碼翻譯成本地機器語言，一般來講，Java 位元組碼經過 位元組碼解釋器執行時，執行速度總是比編譯成本地機器語言的同一程式的執行速度慢，而 即時編譯器 在執行程式時將 Java 位元組碼翻譯成本地機器語言，以顯著加快整體執行時間，
4. JVM 操作記憶體：JVM 有一個堆( heap )用于存盤物件和陣列，垃圾回收器要在這里作業，代碼、常量和其他類資料存盤在方法區( method area )中，每個 JVM 執行緒也有自己的呼叫堆疊( JVM stack )，用于存盤 “幀”，每次呼叫方法時都會創建一個新的 幀(放到堆疊里)，并在該方法退出時銷毀該幀，每個幀提供一個運算元堆疊 ( operand stack)和一個區域變數陣列 ( local variables )，運算元堆疊用于計算運算元和接收被呼叫方法的 "回傳值"，而區域變數資料用于傳遞“方法引數”，

除此之外，每個特定的主機作業系統都需要自己的 JVM 和運行時實作，

6.Java GC垃圾回收

Java 虛擬機提供了一系列的垃圾回識訓制(Garbage Collection),又或者說是垃圾回收器(Garbage Collector),其中常見的垃圾回收器如下：

• Serial GC(Serial Garbage Collection)：第一代GC，是1999年在JDK1.3中發布的串行方式的單執行緒GC，一般適用于 最小化地使用記憶體和并行開銷的場景，
• Parallel GC(Parallel Garbage Collection)：第二代GC，是2002年在JDK1.4.2中發布的，相比Serial GC，基于多執行緒方式加速運行垃圾回收，在JDK6版本之后成為Hotspot VM的默認GC，一般是最大化應用程式的吞吐量，
• CMS GC(Concurrent Mark Sweep Garbage Collection )：第二代GC，是2002年在JDK1.4.2中發布的，相比Serial GC，基于多執行緒方式加速運行垃圾回收，可以讓應用程式和GC分享處理器資源的GC，一般是最小化GC的中斷和停頓時間的場景，
• G1 GC (Garbage First Garbage Collection)：第三代GC，是JDK7版本中誕生的一個并行回收器，主要是針對“垃圾優先”的原則而誕生的GC，也是時下我們比較新的GC，

在常見的垃圾回收中，我們一般采用參考計數法和可達性分析兩種方式來確定垃圾是否產生，其中：

• 參考計數法：在Java中，參考和物件是有關聯的，如果要操作物件則必須用參考進行，因此，很顯然一個簡單的辦法是通過參考計數來判斷一個物件是否可以回收，簡單說，即一個物件如果沒有任何與之關聯的參考，即他們的參考計數都不為0，則說明物件不太可能再被用到，那么這個物件就是可回收物件，
• 可達性分析(根搜索演算法)：為了解決參考計數法的回圈參考問題，Java使用了可達性分析的方法，通過一系列的“GC roots”物件作為起點搜索，如果在“GC roots”和一個物件之間沒有可達路徑，則稱該物件是不可達的，要注意的是，不可達物件不等價于可回收物件，不可達物件變為可回收物件至少要經過兩次標記程序，兩次標記后仍然是可回收物件，則將面臨回收，

一般來說，當成功區分出記憶體中存活物件和死亡物件之后，GC接著就會執行垃圾回收，釋放掉無用物件所占用的記憶體空間，以便有足夠可用的記憶體空間為新的物件分配記憶體，

目前，在JVM中采用的垃圾收集演算法主要有：

• 標記-清除演算法(Mark-Sweep ): 最基礎的垃圾回收演算法，分為兩個階段，標注和清除，標記階段標記出所有需要回收的物件，清除階段回收被標記的物件所占用的空間，該演算法最大的問題是記憶體碎片化嚴重，后續可能發生大物件不能找到可利用空間的問題，
• 復制演算法(Copying): 為了解決Mark-Sweep演算法記憶體碎片化的缺陷而被提出的演算法，按記憶體容量將記憶體劃分為等大小的兩塊，每次只使用其中一塊，當這一塊記憶體滿后將尚存活的物件復制到另一塊上去，把已使用的記憶體清掉，這種演算法雖然實作簡單，記憶體效率高，不易產生碎片，但是最大的問題是可用記憶體被壓縮到了原本的一半，且存活物件增多的話，Copying演算法的效率會大大降低，
• 標記-壓縮演算法(Mark-Compact): 為了避免缺陷而提出，標記階段和Mark-Sweep演算法相同，標記后不是清理物件，而是將存活物件移向記憶體的一端，然后清除端邊界外的物件，
• 增量演算法(Incremental Collecting): 也可以成為磁區收集演算法(Region Collenting)，將整個堆空間劃分為連續的不同小區間, 每個小區間獨立使用, 獨立回收. 這樣做的好處是可以控制一次回收多少個小區間 , 根據目標停頓時間, 每次合理地回收若干個小區間(而不是整個堆), 從而減少一次GC所產生的停頓，
• 分代收集演算法(Generational Collenting): 是目前大部分JVM所采用的方法，其核心思想是根據物件存活的不同生命周期將記憶體劃分為不同的域，一般情況下將GC堆劃分為老生代(Tenured/Old Generation)和新生代(Young Generation)，老生代的特點是每次垃圾回收時只有少量物件需要被回收，新生代的特點是每次垃圾回收時都有大量垃圾需要被回收，因此可以根據不同區域選擇不同的演算法，

7.Java JVM 調優

JVM調優涉及到兩個很重要的概念：吞吐量和回應時間，jvm調優主要是針對他們進行調整優化，達到一個理想的目標，根據業務確定目標是吞吐量優先還是回應時間優先，

• 吞吐量：用戶代碼執行時間/(用戶代碼執行時間+GC執行時間)，
• 回應時間：整個介面的回應時間(用戶代碼執行時間+GC執行時間)，stw時間越短，回應時間越短，

調優的前提是熟悉業務場景，先判斷出當前業務場景是吞吐量優先還是回應時間優先，調優需要建立在監控之上，由壓力測驗來判斷是否達到業務要求和性能要求， 調優的步驟大致可以分為：

1. 熟悉業務場景，了解當前業務系統的要求，是吞吐量優先還是回應時間優先；

2. 選擇合適的垃圾回收器組合，如果是吞吐量優先，則選擇ps+po組合；如果是回應時間優先，在1.8以后選擇G1，在1.8之前選擇ParNew+CMS組合；

3. 規劃記憶體需求，只能進行大致的規劃，

4. CPU選擇，在預算之內性能越高越好；

5. 根據實際情況設定升級年齡，最大年齡為15；

6. 根據需要設定相關的JVM日志引數：

      -Xloggc:/path/name-gc-%t.log 
    	-XX:+UseGCLogFileRotation 
    	-XX:NumberOfGCLogs=5
    	-XX:GCLogFileSize=20M 
    	-XX:+PrintGCDetails
    	-XX:+PrintGCDateStamps 
    	-XX:+PrintGCCauses
   

   其中需要注意的是：

      -XX:+UseGCLogFileRotation：GC檔案回圈使用
      -XX:NumberOfGCLogs=5：使用5個GC檔案
      -XX:GCLogFileSize=20M：每個GC檔案的大小
   

上面這三個引數放在一起代表的含義是：5個GC檔案回圈使用，每個GC檔案20M，總共使用100M存盤日志檔案，當5個GC檔案都使用完畢以后，覆寫第一個GC日志檔案，生成新的GC檔案，

當cpu經常飆升到100%的使用率，那么證明有執行緒長時間占用系統資源不進行釋放，需要定位到具體是哪個執行緒在占用，定位問題的步驟如下(linux系統)：
1.使用top命令常看當前服務器中所有行程（jps命令可以查看當前服務器運行java行程）,找到當前cpu使用率最高的行程，獲取到對應的pid；
2.然后使用top -Hp pid，查看該行程中的各個執行緒資訊的cpu使用，找到占用cpu高的執行緒pid
3.使用jstack pid列印它的執行緒資訊，需要注意的是，通過jstack命令列印的執行緒號和通過top -Hp列印的執行緒號進制不一樣，需要進行轉換才能進行匹配，jstack中的執行緒號為16進制，而top -Hp列印的是10進制，

當記憶體飆高一般都是堆中物件無法回收造成，因為java中的物件大部分存盤在堆記憶體中，其實也就是常見的oom問題(Out Of Memory)，一般：
1.jinfo pid，可以查看當前進行虛擬機的相關資訊列舉出來
2.jstat -gc pid ms，多長毫秒列印一次gc資訊，列印資訊如下，里面包含gc測驗，年輕代/老年帶gc資訊等
3. jmap -histo pid | head -20，查找當前行程堆中的物件資訊，加上管道符后面的資訊以后，代表查詢物件數量最多的20個
4. jmap -dump:format=b,file=xxx pid，可以生成堆資訊的檔案，但是這個命令不建議在生產環境使用，因為當記憶體較大時，執行該命令會占用大量系統資源，甚至造成卡頓，建議在專案啟動時添加下面的命令，在發生oom時自動生成堆資訊檔案：-XX:+HeapDumpOnOutOfMemory，如果需要在線上進行堆資訊分析，如果當前服務存在多個節點，可以下線一個節點，生成堆資訊，或者使用第三方工具，阿里的arthas，

除此之外，我們還可以使用 jvisualvm是jdk自帶的圖形化分析工具，可以對運行行程的執行緒，堆進行詳細分析，但是這種分析工具可以對本地代碼或者測驗環境進行監控分析，不建議在線上環境使用該工具，因為它會占用系統資源，如果必須要在線上執行，建議當前服務存在多個節點，然后下線其中一個節點進行問題分析，也可以使用第三方收費的圖形分析界面jprofiler，

??[注意事項] ：
在日常JVM調優常用引數主要如下：

• 通用GC常用引數：

  -Xmn：年輕代大小
  
  -Xms：堆初始大小
  
  -Xmx：堆最大大小
  
  -Xss：堆疊大小
  
  -XX:+UseTlab：使用tlab，默認打開，涉及到物件分配問題
  
  -XX:+PrintTlab：列印tlab使用情況
  
  -XX:+TlabSize：設定Tlab大小
  
  -XX:+DisabledExplictGC：java代碼中的System.gc()不再生效，防止代碼中誤寫，導致頻繁觸動GC，默認不起用，
  
  -XX:+PrintGC(+PrintGCDetails/+PrintGCTimeStamps) : 列印GC資訊(列印GC詳細資訊/列印GC執行時間)
  
  -XX:+PrintHeapAtGC列印GC時的堆資訊
  
  -XX:+PrintGCApplicationConcurrentTime: 列印應用程式的時間
  
  -XX:+PrintGCApplicationStopedTime: 列印應用程式暫停時間
  
  -XX:+PrintReferenceGC: 列印回收多少種參考型別的參考
  
  -verboss:class : 類加載詳細程序
  
  -XX:+PrintVMOptions : 列印JVM運行引數
  
  -XX:+PrintFlagsFinal(+PrintFlagsInitial) -version | grep : 查找想要了解的命令
  
  -X:loggc:/opt/gc/log/path : 輸出gc資訊到檔案
  
  -XX:MaxTenuringThreshold : 設定gc升到年齡，最大值為15
  

• Parallel GC 常用引數:

  -XX:PreTenureSizeThreshold 多大的物件判定為大物件，直接晉升老年代
  
  -XX:+ParallelGCThreads 用于并發垃圾回收的執行緒
  
  -XX:+UseAdaptiveSizePolicy 自動選擇各區比例
  

• CMS GC 常用引數:

  -XX:+UseConcMarkSweepGC :使用CMS垃圾回收器
  
  -XX:parallelCMSThreads : CMS執行緒數量
  
  -XX:CMSInitiatingOccupancyFraction : 占用多少比例的老年代時開始CMS回收，默認值68%，如果頻繁發生serial old，適當調小該比例，降低FGC頻率
  
  -XX:+UseCMSCompactAtFullCollection : 進行壓縮整理
  -XX:CMSFullGCBeforeCompaction :多少次FGC以后進行壓縮整理
  
  -XX:+CMSClassUnloadingEnabled :回收永久代
  
  -XX:+CMSInitiatingPermOccupancyFraction :達到什么比例時進行永久代回收
  
  -XX:GCTimeTatio : 設定GC時間占用程式運行時間的百分比，該引數只能是盡量達到該百分比，不是肯定達到
  
  -XX:MaxGCPauseMills : GCt停頓時間，該引數也是盡量達到，而不是肯定達到
  

• G1 GC 常用引數：

  -XX:+UseG1 : 使用G1垃圾回收器
  
  -XX:MaxGCPauseMills : GCt停頓時間，該引數也是盡量達到，G1會調整yong區的塊數來達到這個值
  
  -XX:+G1HeapRegionSize : 磁區大小，范圍為1M~32M，必須是2的n次冪，size越大，GC回收間隔越大，但是GC所用時間越長
  

JVM 記憶體區域

在Java虛擬機中，JVM 記憶體區域主要分為執行緒私有、執行緒共享、直接記憶體三個區域，具體詳情如下：

• 執行緒私有(Theard Local Region): 資料區域生命周期與執行緒相同, 依賴用戶執行緒的啟動/結束 而 創建/銷毀(在Hotspot VM內, 每個執行緒都與作業系統的本地執行緒直接映射, 因此這部分記憶體區域的存/否跟隨本地執行緒的生/死對應)，
• 執行緒共享(Theard Shared Region): 隨虛擬機的啟動/關閉而創建/銷毀
• 直接記憶體(Direct Memory) : 非Java 虛擬機中JVM運行時資料區的一部分, 但也會被頻繁的使用: 在JDK 1.4引入的NIO提供了基于Channel與Buffer的IO方式, 它可以使用Native函式庫直接分配堆外記憶體, 然后使用DirectByteBuffer物件作為這塊記憶體的參考進行操作(詳見: Java I/O 擴展), 這樣就避免了在Java堆和Native堆中來回復制資料, 因此在一些場景中可以顯著提高性能

由此可見，在Java 虛擬機JVM運行時資料區中,【程式計數器、虛擬機堆疊、本地方法區】屬于執行緒私有區域,【 JAVA 堆、方法區】屬于執行緒共享區域，都需要JVM GC管理的，而直接記憶體不受JVM GC管理的，

首先，對于執行緒私有區域中的【程式計數器、虛擬機堆疊、本地方法區】,主要詳情如下：

• 程式計數器：一塊較小的記憶體空間, 是當前執行緒所執行的位元組碼的行號指示器，每條執行緒都要有一個獨立的程式計數器，這類記憶體也稱為“執行緒私有”的記憶體，正在執行java方法的話，計數器記錄的是虛擬機位元組碼指令的地址（當前指令的地址），如果還是Native方法，則為空，這個記憶體區域是唯一一個在虛擬機中沒有規定任何OutOfMemoryError情況的區域，
• 虛擬機堆疊：是描述java方法執行的記憶體模型，每個方法在執行的同時都會創建一個堆疊幀（Stack Frame）用于存盤區域變數表、運算元堆疊、動態鏈接、方法出口等資訊，每一個方法從呼叫直至執行完成的程序，就對應著一個堆疊幀在虛擬機堆疊中入堆疊到出堆疊的程序，堆疊幀（ Frame）是用來存盤資料和部分程序結果的資料結構，同時也被用來處理動態鏈接 (Dynamic Linking)、 方法回傳值和例外分派（ Dispatch Exception），堆疊幀隨著方法呼叫而創建，隨著方法結束而銷毀——無論方法是正常完成還是例外完成（拋出了在方法內未被捕獲的例外）都算作方法結束，
• 本地方法區：本地方法區和Java Stack作用類似, 區別是虛擬機堆疊為執行Java方法服務, 而本地方法堆疊則為Native方法服務, 如果一個VM實作使用C-linkage模型來支持Native呼叫, 那么該堆疊將會是一個C堆疊，但HotSpot VM直接就把本地方法堆疊和虛擬機堆疊合二為一，

其次，對于執行緒共享區域中的【 JAVA 堆、方法區】,主要詳情如下：

• Java 堆(Java Heap): 是Java 虛擬機JVM運行時資料區中，被執行緒共享的一塊記憶體區域，創建的物件和陣列都保存在Java堆記憶體中，也是垃圾收集器進行垃圾收集的最重要的記憶體區域，由于現代VM采用分代收集演算法, 因此Java堆從GC的角度還可以細分為: 新生代(Eden區、From Survivor區和To Survivor區)和老年代，
• 方法區(Method Area)/永久代(Permanent Generation)：我們常說的永久代, 用于存盤被JVM加載的類資訊、常量、靜態變數、即時編譯器編譯后的代碼等資料. HotSpot VM把GC分代收集擴展至方法區, 即使用Java堆的永久代來實作方法區, 這樣HotSpot的垃圾收集器就可以像管理Java堆一樣管理這部分記憶體, 而不必為方法區開發專門的記憶體管理器(永久帶的記憶體回收的主要目標是針對常量池的回收和型別的卸載, 因此收益一般很小)，運行時常量池（Runtime Constant Pool）是方法區的一部分，Class檔案中除了有類的版本、欄位、方法、介面等描述等資訊外，還有一項資訊是常量池（Constant Pool Table），用于存放編譯期生成的各種字面量和符號參考，這部分內容將在類加載后存放到方法區的運行時常量池中， Java虛擬機對Class檔案的每一部分（自然也包括常量池）的格式都有嚴格的規定，每一個位元組用于存盤哪種資料都必須符合規范上的要求，這樣才會被虛擬機認可、裝載和執行，

其中對于Java虛擬機JVM中的Java 堆主要分為【 新生代 、老年代 、永久代、元資料區】：

1. 新生代(Young Generation)：用來存放新生的物件，一般占據堆的1/3空間，由于頻繁創建物件，所以新生代會頻繁觸發MinorGC進行垃圾回收，新生代又分為 Eden區、ServivorFrom、ServivorTo三個區，
2. 老年代(Old Generation)：主要存放應用程式中生命周期長的記憶體物件，老年代的物件比較穩定，所以MajorGC不會頻繁執行，在進行MajorGC前一般都先進行了一次MinorGC，使得有新生代的物件晉身入老年代，導致空間不夠用時才觸發，當無法找到足夠大的連續空間分配給新創建的較大物件時也會提前觸發一次MajorGC進行垃圾回收騰出空間，MajorGC采用標記清除演算法：首先掃描一次所有老年代，標記出存活的物件，然后回收沒有標記的物件，MajorGC的耗時比較長，因為要掃描再回收，MajorGC會產生記憶體碎片，為了減少記憶體損耗，我們一般需要進行合并或者標記出來方便下次直接分配，當老年代也滿了裝不下的時候，就會拋出OOM（Out of Memory）例外，
3. 永久代(Permanent Generation)：指記憶體的永久保存區域，主要存放Class和Meta（元資料）的資訊,Class在被加載的時候被放入永久區域，它和和存放實體的區域不同,GC不會在主程式運行期對永久區域進行清理，所以這也導致了永久代的區域會隨著加載的Class的增多而脹滿，最終拋出OOM例外，
4. 元資料區(Metaspace): 在Java8中，永久代已經被移除，被一個稱為“元資料區”（元空間）的區域所取代，元空間的本質和永久代類似，元空間與永久代之間最大的區別在于：元空間并不在虛擬機中，而是使用本地記憶體，因此，默認情況下，元空間的大小僅受本地記憶體限制，類的元資料放入 native memory, 字串池和類的靜態變數放入java堆中，這樣可以加載多少類的元資料就不再由MaxPermSize控制, 而由系統的實際可用空間來控制，

Java 記憶體模型

你已經知道，導致可見性的原因是快取，導致有序性的原因是編譯優化，那解決可見性、有序性最直接的辦法就是禁用快取和編譯優化，但是這樣問題雖然解決了，我們程式的性能可就堪憂了，

合理的方案應該是按需禁用快取以及編譯優化，那么，如何做到“按需禁用”呢？對于并發程式，何時禁用快取以及編譯優化只有程式員知道，那所謂“按需禁用”其實就是指按照程式員的要求來禁用，所以，為了解決可見性和有序性問題，只需要提供給程式員按需禁用快取和編譯優化的方法即可，

Java 記憶體模型是個很復雜的規范，可以從不同的視角來解讀，站在我們這些程式員的視角，本質上可以理解為，Java 記憶體模型規范了 JVM 如何提供按需禁用快取和編譯優化的方法，具體來說，這些方法包括 volatile、synchronized 和 final 三個關鍵字，

Java 的記憶體模型是并發編程領域的一次重要創新，之后 C++、C#、Golang 等高級語言都開始支持記憶體模型，Java 記憶體模型里面，最晦澀的部分就是 Happens-Before 規則，接下來我們詳細介紹一下，

Happens-Before 規則

在了解完Java 記憶體模型之后，我們再來具體學習一下針對于這些問題提出的Happens-Before 規則，如何理解 Happens-Before 呢？如果望文生義（很多網文也都愛按字面意思翻譯成“先行發生”），那就南轅北轍了，Happens-Before 并不是說前面一個操作發生在后續操作的前面，它真正要表達的是：前面一個操作的結果對后續操作是可見的，就像有心靈感應的兩個人，雖然遠隔千里，一個人心之所想，另一個人都看得到，Happens-Before 規則就是要保證執行緒之間的這種“心靈感應”，所以比較正式的說法是：Happens-Before 約束了編譯器的優化行為，雖允許編譯器優化，但是要求編譯器優化后一定遵守 Happens-Before 規則，

Happens-Before 規則應該是 Java 記憶體模型里面最晦澀的內容了，和程式員相關的規則一共有如下六項，都是關于可見性的，具體如下：

1. 程式的順序性規則：指在一個執行緒中，按照程式順序，前面的操作 Happens-Before 于后續的任意操作，
2. volatile 變數規則：指對一個 volatile 變數的寫操作， Happens-Before 于后續對這個 volatile 變數的讀操作，
3. 傳遞性規則：指如果 A Happens-Before B，且 B Happens-Before C，那么 A Happens-Before C，
4. 管程中鎖的規則：指對一個鎖的解鎖 Happens-Before 于后續對這個鎖的加鎖，管程是一種通用的同步原語，在 Java 中指的就是 synchronized，synchronized 是 Java 里對管程的實作，管程中的鎖在 Java 里是隱式實作的，在進入同步塊之前，會自動加鎖，而在代碼塊執行完會自動釋放鎖，加鎖以及釋放鎖都是編譯器幫我們實作的，
5. 執行緒 start() 規則：關于執行緒啟動的，它是指主執行緒 A 啟動子執行緒 B 后，子執行緒 B 能夠看到主執行緒在啟動子執行緒 B 前的操作，換句話說就是，如果執行緒 A 呼叫執行緒 B 的 start() 方法（即在執行緒 A 中啟動執行緒 B），那么該 start() 操作 Happens-Before 于執行緒 B 中的任意操作，
6. 執行緒 join() 規則：關于執行緒等待的，它是指主執行緒 A 等待子執行緒 B 完成（主執行緒 A 通過呼叫子執行緒 B 的 join() 方法實作），當子執行緒 B 完成后（主執行緒 A 中 join() 方法回傳），主執行緒能夠看到子執行緒的操作，當然所謂的“看到”，指的是對共享變數的操作，換句話說就是，如果在執行緒 A 中，呼叫執行緒 B 的 join() 并成功回傳，那么執行緒 B 中的任意操作 Happens-Before 于該 join() 操作的回傳，

在 Java 語言里面，Happens-Before 的語意本質上是一種可見性，A Happens-Before B 意味著 A 事件對 B 事件來說是可見的，無論 A 事件和 B 事件是否發生在同一個執行緒里，例如 A 事件發生在執行緒 1 上，B 事件發生在執行緒 2 上，Happens-Before 規則保證執行緒 2 上也能看到 A 事件的發生，

Java 記憶體模型主要分為兩部分，一部分面向你我這種撰寫并發程式的應用開發人員，另一部分是面向 JVM 的實作人員的，我們可以重點關注前者，也就是和撰寫并發程式相關的部分，這部分內容的核心就是 Happens-Before 規則，

代碼設計原則

對于一個開發人員來說，了解上述知識只是一個開始，更多的是我們在實際作業中如何運用，個人覺得，了解一些設計原則，并掌握這些設計原則，才能幫助我們寫出高質量的代碼，

當然，設計原則是代碼設計時的一些經驗總結，最大的一問題就就是：設計原則看起來比較抽象，其定義也比較模糊，不同的人對于同一個設計原則都會有不同的感悟，如果，我們只是單純的抽象記憶這些定義，對于我們編程技術和代碼設計的能力來說，并不會有什么實質性的幫助，

針對于每一個設計原則，我們需要掌握它能幫助我們解決什么問題和可以適合什么樣的應用場景，可以這樣說，設計原則是心法，設計模式是招式，而編程是實實在在的運用，常見的設計原則有：

• 單一職責原則(Single Responsibility Principle, SRP原則)： 一個類(Class) 和模塊(Module)只負責完成一個職責(Principle)或者功能(Funtion).
• 開閉原則(Open Closed Principle, OCP原則)：軟體物體，比如模塊，類，方法等需要支撐 "對擴展開發，對修改關閉"的原則，
• 里氏替代原則(Liskov Substitution Principle, LSP原則)：子類物件能夠替代程式中的父類物件出現的任何地方，并且保證原有邏輯行為不變和正確性不被破壞，
• 介面隔離原則(Interface Segregation Principle, ISP原則)：介面呼叫方和使用者只關心自己相關的，不用依賴于自己不需要的介面，
• 依賴反轉原則(Dependency Inversion Principle，DIP 原則)：高模塊不用依賴低模塊，不用關注其細節，需要通過抽象來互相依賴，
• KISS原則(Keep it Simple and Stupid Principle, KISS原則)：保持代碼可讀和可維護的原則，
• YAGNI原則(You Ai Not Gonna Need It Principle,YAGNI原則)：避免過度設計的原則，不用去設計用不到的功能和不用去撰寫用不到的代碼，
• DRY原則(Do Not Repeat Yourself Principle,DRY原則)： 減少撰寫重復的代碼的原則，提高代碼復用，
• 迪米特原則(Law of Demeter Principle, LoD原則 )： 就是我們常說的“高內聚，低耦合”的最佳參考原則，不應該存在直接依賴關系的類之間不要有依賴，

綜上所述，前面五種原則就是我們常說的SOLID原則，其他四種原則也是我們最常用的原則，這些設計原則都是我們的編程方法論，

寫在最后

Java 記憶體模型通過定義了一系列的 Happens-Before 操作，讓應用程式開發者能夠輕易地表達不同執行緒的操作之間的記憶體可見性，

在遵守 Java 記憶體模型的前提下，即時編譯器以及底層體系架構能夠調整記憶體訪問操作，以達到性能優化的效果，如果開發者沒有正確地利用 Happens-Before 規則，那么將可能導致資料競爭，

Java 記憶體模型是通過記憶體屏障來禁止重排序的，對于即時編譯器來說，記憶體屏障將限制它所能做的重排序優化，對于處理器來說，記憶體屏障會導致快取的重繪操作，

在設計Java代碼的時候，遵循一些必要的設計原則，也能更好地幫助我們寫出好的代碼，減少記憶體開銷，對于我們自我提升也有更好的幫助，

著作權宣告：本文為博主原創文章，遵循相關著作權協議，如若轉載或者分享請附上原文出處鏈接和鏈接來源，

標籤：其他

上一篇：設計模式 08 代理模式

下一篇：從RabbitMQ平滑遷移到RocketMQ技術實戰