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

寫在開頭

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

我們都知道的是，程序里大部分語句都要訪問內(nèi)存，有些還要訪問 I/O，根據(jù)木桶理論（一只水桶能裝多少水取決于它最短的那塊木板），程序整體的性能取決于最慢的操作——讀寫 I/O 設(shè)備，也就是說單方面提高 CPU 性能是無效的。

為了合理利用 CPU 的高性能，平衡這三者的速度差異，計算機體系結(jié)構(gòu)、操作系統(tǒng)、編譯程序都做出了貢獻，主要體現(xiàn)為：

1. 現(xiàn)代計算機在CPU 增加了緩存，以均衡與內(nèi)存的速度差異
2. 操作系統(tǒng)增加了進程、線程，以分時復用 CPU，進而均衡 CPU 與 I/O 設(shè)備的速度差異
3. 編譯程序優(yōu)化指令執(zhí)行次序，使得緩存能夠得到更加合理地利用

由此可見，雖然現(xiàn)在我們幾乎所有的程序都默默地享受著這些成果，但是實際應(yīng)用程序設(shè)計和開發(fā)過程中，還是有很多詭異問題困擾著我們。

基本概述

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

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

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

特別指出的是，JVM優(yōu)化。由于使用Java編寫的應(yīng)用程序，本身Java是運行在JVM虛擬機上的，這就意味著它會受到JVM的制約。對于JVM虛擬機的優(yōu)化。一定程度上會提升Java應(yīng)用程序的性能。如果參數(shù)配置不當，導致內(nèi)存溢出(OOM異常)等問題，甚至引發(fā)比這更嚴重的后果。

由此可見，正確認識和掌握JVM結(jié)構(gòu)相關(guān)知識，對于我們何嘗不是一個進階的技術(shù)方向。當然，JVM虛擬機這一部分的內(nèi)容，相對編寫Java程序來說，更加比較枯燥無味，概念比較多且抽象，需要我們要有更多的耐心和細心。我們都知道，一顆不浮躁的心，做任何事都會收獲不一樣的精彩。

Java JVM虛擬機

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

1.Java 程序運行過程

作為一名 Java 程序員，你應(yīng)該知道，Java 代碼有很多種不同的運行方式。比如說可以在開發(fā)工具中運行，可以雙擊執(zhí)行 jar 文件運行，也可以在命令行中運行，甚至可以在網(wǎng)頁中運行。當然，這些執(zhí)行方式都離不開 JRE，也就是 Java 運行時環(huán)境。

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

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

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

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

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

Java 虛擬機可以由硬件實現(xiàn)[1]，但更為常見的是在各個現(xiàn)有平臺（如 Windows_x64、Linux_aarch64）上提供軟件實現(xiàn)。這么做的意義在于，一旦一個程序被轉(zhuǎn)換成 Java 字節(jié)碼，那么它便可以在不同平臺上的虛擬機實現(xiàn)里運行。這也就是我們經(jīng)常說的“一次編寫，到處運行”。

虛擬機的另外一個好處是它帶來了一個托管環(huán)境（Managed Runtime）。這個托管環(huán)境能夠代替我們處理一些代碼中冗長而且容易出錯的部分。其中最廣為人知的當屬自動內(nèi)存管理與垃圾回收，這部分內(nèi)容甚至催生了一波垃圾回收調(diào)優(yōu)的業(yè)務(wù)。

除此之外，托管環(huán)境還提供了諸如數(shù)組越界、動態(tài)類型、安全權(quán)限等等的動態(tài)檢測，使我們免于書寫這些無關(guān)業(yè)務(wù)邏輯的代碼。

2.Java 程序創(chuàng)建過程

從 class 文件到內(nèi)存中的類，按先后順序需要經(jīng)過加載、鏈接以及初始化三大步驟。其中，鏈接過程中同樣需要驗證；而內(nèi)存中的類沒有經(jīng)過初始化，同樣不能使用。那么，是否所有的 Java 類都需要經(jīng)過這幾步呢？

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

至于另一大類引用類型，Java 將其細分為四種：類、接口、數(shù)組類和泛型參數(shù)。由于泛型參數(shù)會在編譯過程中被擦除（我會在專欄的第二部分詳細介紹），因此 Java 虛擬機實際上只有前三種。在類、接口和數(shù)組類中，數(shù)組類是由 Java 虛擬機直接生成的，其他兩種則有對應(yīng)的字節(jié)流。

說到字節(jié)流，最常見的形式要屬由 Java 編譯器生成的 class 文件。除此之外，我們也可以在程序內(nèi)部直接生成，或者從網(wǎng)絡(luò)中獲?。ɡ缇W(wǎng)頁中內(nèi)嵌的小程序 Java applet）字節(jié)流。這些不同形式的字節(jié)流，都會被加載到 Java 虛擬機中，成為類或接口。為了敘述方便，下面我就用“類”來統(tǒng)稱它們。

無論是直接生成的數(shù)組類，還是加載的類，Java 虛擬機都需要對其進行鏈接和初始化。

其實，Java 虛擬機將字節(jié)流轉(zhuǎn)化為 Java 類的過程，就是我們常說的Java類的創(chuàng)建過程。這個過程可分為加載、鏈接以及初始化三大步驟：

• 加載是指查找字節(jié)流，并且據(jù)此創(chuàng)建類的過程。加載需要借助類加載器，在 Java 虛擬機中，類加載器使用了雙親委派模型，即接收到加載請求時，會先將請求轉(zhuǎn)發(fā)給父類加載器。
• 鏈接，是指將創(chuàng)建成的類合并至 Java 虛擬機中，使之能夠執(zhí)行的過程。鏈接還分驗證、準備和解析三個階段。其中，解析階段為非必須的。
• 初始化，則是為標記為常量值的字段賦值，以及執(zhí)行 < clinit > 方法的過程。類的初始化僅會被執(zhí)行一次，這個特性被用來實現(xiàn)單例的延遲初始化。

3.Java 程序加載過程

從虛擬機視角來看，執(zhí)行 Java 代碼首先需要將它編譯而成的 class 文件加載到 Java 虛擬機中。加載后的 Java 類會被存放于方法區(qū)（Method Area）中。實際運行時，虛擬機會執(zhí)行方法區(qū)內(nèi)的代碼。

如果你熟悉 X86 的話，你會發(fā)現(xiàn)這和段式內(nèi)存管理中的代碼段類似。而且，Java 虛擬機同樣也在內(nèi)存中劃分出堆和棧來存儲運行時數(shù)據(jù)。

不同的是，Java 虛擬機會將棧細分為面向 Java 方法的 Java 方法棧，面向本地方法（用 C++ 寫的 native 方法）的本地方法棧，以及存放各個線程執(zhí)行位置的 PC 寄存器。

在運行過程中，每當調(diào)用進入一個 Java 方法，Java 虛擬機會在當前線程的 Java 方法棧中生成一個棧幀，用以存放局部變量以及字節(jié)碼的操作數(shù)。這個棧幀的大小是提前計算好的，而且 Java 虛擬機不要求棧幀在內(nèi)存空間里連續(xù)分布。

當退出當前執(zhí)行的方法時，不管是正常返回還是異常返回，Java 虛擬機均會彈出當前線程的當前棧幀，并將之舍棄。

從硬件視角來看，Java 字節(jié)碼無法直接執(zhí)行。因此，Java 虛擬機需要將字節(jié)碼翻譯成機器碼。

啟動類加載器是由 C++ 實現(xiàn)的，沒有對應(yīng)的 Java 對象，因此在 Java 中只能用 null 來指代。
除了啟動類加載器之外，其他的類加載器都是 java.lang.ClassLoader 的子類，因此有對應(yīng)的 Java 對象。這些類加載器需要先由另一個類加載器，比如說啟動類加載器，加載至 Java 虛擬機中，方能執(zhí)行類加載。

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

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

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

應(yīng)用類加載器的父類加載器則是擴展類加載器。它負責加載應(yīng)用程序路徑下的類。（這里的應(yīng)用程序路徑，便是指虛擬機參數(shù) -cp/-classpath、系統(tǒng)變量 java.class.path 或環(huán)境變量 CLASSPATH 所指定的路徑。）默認情況下，應(yīng)用程序中包含的類便是由應(yīng)用類加載器加載的。

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

除了由 Java 核心類庫提供的類加載器外，我們還可以加入自定義的類加載器，來實現(xiàn)特殊的加載方式。舉例來說，我們可以對 class 文件進行加密，加載時再利用自定義的類加載器對其解密。

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

4.Java 程序編譯過程

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

• 第一種是解釋執(zhí)行，即逐條將字節(jié)碼翻譯成機器碼并執(zhí)行；
• 第二種是即時編譯（Just-In-Time compilation，JIT），即將一個方法中包含的所有字節(jié)碼編譯成機器碼后再執(zhí)行。

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

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

即時編譯建立在程序符合二八定律的假設(shè)上，也就是百分之二十的代碼占據(jù)了百分之八十的計算資源。

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

理論上講，即時編譯后的 Java 程序的執(zhí)行效率，是可能超過 C++ 程序的。這是因為與靜態(tài)編譯相比，即時編譯擁有程序的運行時信息，并且能夠根據(jù)這個信息做出相應(yīng)的優(yōu)化。

舉個例子，我們知道虛方法是用來實現(xiàn)面向?qū)ο笳Z言多態(tài)性的。對于一個虛方法調(diào)用，盡管它有很多個目標方法，但在實際運行過程中它可能只調(diào)用其中的一個。這個信息便可以被即時編譯器所利用，來規(guī)避虛方法調(diào)用的開銷，從而達到比靜態(tài)編譯的 C++ 程序更高的性能。

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

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

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

在計算資源充足的情況下，字節(jié)碼的解釋執(zhí)行和即時編譯可同時進行。編譯完成后的機器碼會在下次調(diào)用該方法時啟用，以替換原本的解釋執(zhí)行。

5.Java 虛擬機結(jié)構(gòu)

從組成結(jié)構(gòu)上看，一個Java 虛擬機(HotSpot 為例)，主要包括指令集合，指令解析器，程序執(zhí)行指令 等3個方面，其中：

• 指令集合：指的是我們常說的字節(jié)碼(Byte Code),主要指將源文件代碼(Source File Code) 編譯運行生成的,比如在Java中是通過javac命令編譯(.java)文件生成，而在Python中是通過jython命令來編譯(.py)文件生成。
• 指令解析器：主要是指字節(jié)碼解釋器(Byte Code Interpreter)和即時編譯器(JIT Compiler)，比如一個Java 虛擬機(HotSpot 為例)，就有一個字節(jié)碼解釋器和兩個即時編譯器(Server編譯器和Client 編譯器)。
• 程序執(zhí)行指令： 主要是指操作內(nèi)存區(qū)域，以裝載和執(zhí)行，一般是JVM負責 將 字節(jié)碼 解釋成具體的機器指令來執(zhí)行。

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

1. 字節(jié)碼指令：JVM 具有針對以下任務(wù)組的字節(jié)碼指令規(guī)范：加載和存儲，算術(shù)，類型轉(zhuǎn)換，對象創(chuàng)建和操作，操作數(shù)棧管理（push/pop），控制轉(zhuǎn)移（分支），方法調(diào)用和返回，拋出異常，基于監(jiān)視器的并發(fā)。被加載到JVM后可以被執(zhí)行，其中字節(jié)碼是實現(xiàn)跨平臺的基礎(chǔ)。
2. 字節(jié)碼解釋器：用于將字節(jié)碼解析成計算機能執(zhí)行的語言，一臺計算機有了 Java 字節(jié)碼解釋器后，它就可以運行任何 Java 字節(jié)碼程序。同樣的 Java 程序就可以在具有了這種解釋器的硬件架構(gòu)的計算機上運行,實現(xiàn)了“跨平臺”。
3. JIT即時編譯器：JIT 編譯器可以在執(zhí)行程序時將 Java 字節(jié)碼翻譯成本地機器語言。一般來講，Java 字節(jié)碼經(jīng)過 字節(jié)碼解釋器執(zhí)行時，執(zhí)行速度總是比編譯成本地機器語言的同一程序的執(zhí)行速度慢。而 即時編譯器 在執(zhí)行程序時將 Java 字節(jié)碼翻譯成本地機器語言，以顯著加快整體執(zhí)行時間。
4. JVM 操作內(nèi)存：JVM 有一個堆( heap )用于存儲對象和數(shù)組。垃圾回收器要在這里工作。代碼、常量和其他類數(shù)據(jù)存儲在方法區(qū)( method area )中。每個 JVM 線程也有自己的調(diào)用棧( JVM stack )，用于存儲 “幀”。每次調(diào)用方法時都會創(chuàng)建一個新的 幀(放到棧里)，并在該方法退出時銷毀該幀。每個幀提供一個操作數(shù)堆棧 ( operand stack)和一個局部變量數(shù)組 ( local variables )。操作數(shù)棧用于計算操作數(shù)和接收被調(diào)用方法的 "返回值"，而局部變量數(shù)據(jù)用于傳遞“方法參數(shù)”。

除此之外，每個特定的主機操作系統(tǒng)都需要自己的 JVM 和運行時實現(xiàn)。

6.Java GC垃圾回收

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

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

在常見的垃圾回收中，我們一般采用引用計數(shù)法和可達性分析兩種方式來確定垃圾是否產(chǎn)生，其中：

• 引用計數(shù)法：在Java中，引用和對象是有關(guān)聯(lián)的。如果要操作對象則必須用引用進行。因此，很顯然一個簡單的辦法是通過引用計數(shù)來判斷一個對象是否可以回收。簡單說，即一個對象如果沒有任何與之關(guān)聯(lián)的引用，即他們的引用計數(shù)都不為0，則說明對象不太可能再被用到，那么這個對象就是可回收對象。
• 可達性分析(根搜索算法)：為了解決引用計數(shù)法的循環(huán)引用問題，Java使用了可達性分析的方法。通過一系列的“GC roots”對象作為起點搜索。如果在“GC roots”和一個對象之間沒有可達路徑，則稱該對象是不可達的。要注意的是，不可達對象不等價于可回收對象，不可達對象變?yōu)榭苫厥諏ο笾辽僖?jīng)過兩次標記過程。兩次標記后仍然是可回收對象，則將面臨回收。

一般來說，當成功區(qū)分出內(nèi)存中存活對象和死亡對象之后，GC接著就會執(zhí)行垃圾回收，釋放掉無用對象所占用的內(nèi)存空間，以便有足夠可用的內(nèi)存空間為新的對象分配內(nèi)存。

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

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

7.Java JVM 調(diào)優(yōu)

JVM調(diào)優(yōu)涉及到兩個很重要的概念：吞吐量和響應(yīng)時間。jvm調(diào)優(yōu)主要是針對他們進行調(diào)整優(yōu)化，達到一個理想的目標，根據(jù)業(yè)務(wù)確定目標是吞吐量優(yōu)先還是響應(yīng)時間優(yōu)先。

• 吞吐量：用戶代碼執(zhí)行時間/(用戶代碼執(zhí)行時間+GC執(zhí)行時間)。
• 響應(yīng)時間：整個接口的響應(yīng)時間(用戶代碼執(zhí)行時間+GC執(zhí)行時間)，stw時間越短，響應(yīng)時間越短。

調(diào)優(yōu)的前提是熟悉業(yè)務(wù)場景，先判斷出當前業(yè)務(wù)場景是吞吐量優(yōu)先還是響應(yīng)時間優(yōu)先。調(diào)優(yōu)需要建立在監(jiān)控之上，由壓力測試來判斷是否達到業(yè)務(wù)要求和性能要求。 調(diào)優(yōu)的步驟大致可以分為：

1. 熟悉業(yè)務(wù)場景，了解當前業(yè)務(wù)系統(tǒng)的要求，是吞吐量優(yōu)先還是響應(yīng)時間優(yōu)先；

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

3. 規(guī)劃內(nèi)存需求，只能進行大致的規(guī)劃。

4. CPU選擇，在預算之內(nèi)性能越高越好；

5. 根據(jù)實際情況設(shè)置升級年齡，最大年齡為15；

6. 根據(jù)需要設(shè)定相關(guān)的JVM日志參數(shù)：

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

   其中需要注意的是：

      -XX:+UseGCLogFileRotation：GC文件循環(huán)使用
      -XX:NumberOfGCLogs=5：使用5個GC文件
      -XX:GCLogFileSize=20M：每個GC文件的大小
   

上面這三個參數(shù)放在一起代表的含義是：5個GC文件循環(huán)使用，每個GC文件20M，總共使用100M存儲日志文件，當5個GC文件都使用完畢以后，覆蓋第一個GC日志文件，生成新的GC文件。

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

當內(nèi)存飆高一般都是堆中對象無法回收造成，因為java中的對象大部分存儲在堆內(nèi)存中。其實也就是常見的oom問題(Out Of Memory)，一般：
1.jinfo pid，可以查看當前進行虛擬機的相關(guān)信息列舉出來
2.jstat -gc pid ms，多長毫秒打印一次gc信息，打印信息如下，里面包含gc測試，年輕代/老年帶gc信息等

3. jmap -histo pid | head -20，查找當前進程堆中的對象信息，加上管道符后面的信息以后，代表查詢對象數(shù)量最多的20個
4. jmap -dump:format=b,file=xxx pid，可以生成堆信息的文件，但是這個命令不建議在生產(chǎn)環(huán)境使用，因為當內(nèi)存較大時，執(zhí)行該命令會占用大量系統(tǒng)資源，甚至造成卡頓。建議在項目啟動時添加下面的命令，在發(fā)生oom時自動生成堆信息文件：-XX:+HeapDumpOnOutOfMemory。如果需要在線上進行堆信息分析，如果當前服務(wù)存在多個節(jié)點，可以下線一個節(jié)點，生成堆信息，或者使用第三方工具，阿里的arthas。

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

??[注意事項] ：
在日常JVM調(diào)優(yōu)常用參數(shù)主要如下：

• 通用GC常用參數(shù)：

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

• Parallel GC 常用參數(shù):

  -XX:PreTenureSizeThreshold 多大的對象判定為大對象，直接晉升老年代
  
  -XX:+ParallelGCThreads 用于并發(fā)垃圾回收的線程
  
  -XX:+UseAdaptiveSizePolicy 自動選擇各區(qū)比例
  

• CMS GC 常用參數(shù):

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

• G1 GC 常用參數(shù)：

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

JVM 內(nèi)存區(qū)域

file

在Java虛擬機中，JVM 內(nèi)存區(qū)域主要分為線程私有、線程共享、直接內(nèi)存三個區(qū)域，具體詳情如下：

• 線程私有(Theard Local Region): 數(shù)據(jù)區(qū)域生命周期與線程相同, 依賴用戶線程的啟動/結(jié)束 而 創(chuàng)建/銷毀(在Hotspot VM內(nèi), 每個線程都與操作系統(tǒng)的本地線程直接映射, 因此這部分內(nèi)存區(qū)域的存/否跟隨本地線程的生/死對應(yīng))。
• 線程共享(Theard Shared Region): 隨虛擬機的啟動/關(guān)閉而創(chuàng)建/銷毀
• 直接內(nèi)存(Direct Memory) : 非Java 虛擬機中JVM運行時數(shù)據(jù)區(qū)的一部分, 但也會被頻繁的使用: 在JDK 1.4引入的NIO提供了基于Channel與Buffer的IO方式, 它可以使用Native函數(shù)庫直接分配堆外內(nèi)存, 然后使用DirectByteBuffer對象作為這塊內(nèi)存的引用進行操作(詳見: Java I/O 擴展), 這樣就避免了在Java堆和Native堆中來回復制數(shù)據(jù), 因此在一些場景中可以顯著提高性能

由此可見，在Java 虛擬機JVM運行時數(shù)據(jù)區(qū)中,【程序計數(shù)器、虛擬機棧、本地方法區(qū)】屬于線程私有區(qū)域,【 JAVA 堆、方法區(qū)】屬于線程共享區(qū)域，都需要JVM GC管理的，而直接內(nèi)存不受JVM GC管理的。

首先，對于線程私有區(qū)域中的【程序計數(shù)器、虛擬機棧、本地方法區(qū)】,主要詳情如下：

• 程序計數(shù)器：一塊較小的內(nèi)存空間, 是當前線程所執(zhí)行的字節(jié)碼的行號指示器，每條線程都要有一個獨立的程序計數(shù)器，這類內(nèi)存也稱為“線程私有”的內(nèi)存。正在執(zhí)行java方法的話，計數(shù)器記錄的是虛擬機字節(jié)碼指令的地址（當前指令的地址）。如果還是Native方法，則為空。這個內(nèi)存區(qū)域是唯一一個在虛擬機中沒有規(guī)定任何OutOfMemoryError情況的區(qū)域。
• 虛擬機棧：是描述java方法執(zhí)行的內(nèi)存模型，每個方法在執(zhí)行的同時都會創(chuàng)建一個棧幀（Stack Frame）用于存儲局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口等信息。每一個方法從調(diào)用直至執(zhí)行完成的過程，就對應(yīng)著一個棧幀在虛擬機棧中入棧到出棧的過程。棧幀（ Frame）是用來存儲數(shù)據(jù)和部分過程結(jié)果的數(shù)據(jù)結(jié)構(gòu)，同時也被用來處理動態(tài)鏈接 (Dynamic Linking)、 方法返回值和異常分派（ Dispatch Exception）。棧幀隨著方法調(diào)用而創(chuàng)建，隨著方法結(jié)束而銷毀——無論方法是正常完成還是異常完成（拋出了在方法內(nèi)未被捕獲的異常）都算作方法結(jié)束。
• 本地方法區(qū)：本地方法區(qū)和Java Stack作用類似, 區(qū)別是虛擬機棧為執(zhí)行Java方法服務(wù), 而本地方法棧則為Native方法服務(wù), 如果一個VM實現(xiàn)使用C-linkage模型來支持Native調(diào)用, 那么該棧將會是一個C棧，但HotSpot VM直接就把本地方法棧和虛擬機棧合二為一。

其次，對于線程共享區(qū)域中的【 JAVA 堆、方法區(qū)】,主要詳情如下：

• Java 堆(Java Heap): 是Java 虛擬機JVM運行時數(shù)據(jù)區(qū)中，被線程共享的一塊內(nèi)存區(qū)域，創(chuàng)建的對象和數(shù)組都保存在Java堆內(nèi)存中，也是垃圾收集器進行垃圾收集的最重要的內(nèi)存區(qū)域。由于現(xiàn)代VM采用分代收集算法, 因此Java堆從GC的角度還可以細分為: 新生代(Eden區(qū)、From Survivor區(qū)和To Survivor區(qū))和老年代。
• 方法區(qū)(Method Area)/永久代(Permanent Generation)：我們常說的永久代, 用于存儲被JVM加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù). HotSpot VM把GC分代收集擴展至方法區(qū), 即使用Java堆的永久代來實現(xiàn)方法區(qū), 這樣HotSpot的垃圾收集器就可以像管理Java堆一樣管理這部分內(nèi)存, 而不必為方法區(qū)開發(fā)專門的內(nèi)存管理器(永久帶的內(nèi)存回收的主要目標是針對常量池的回收和類型的卸載, 因此收益一般很小)。運行時常量池（Runtime Constant Pool）是方法區(qū)的一部分。Class文件中除了有類的版本、字段、方法、接口等描述等信息外，還有一項信息是常量池（Constant Pool Table），用于存放編譯期生成的各種字面量和符號引用，這部分內(nèi)容將在類加載后存放到方法區(qū)的運行時常量池中。 Java虛擬機對Class文件的每一部分（自然也包括常量池）的格式都有嚴格的規(guī)定，每一個字節(jié)用于存儲哪種數(shù)據(jù)都必須符合規(guī)范上的要求，這樣才會被虛擬機認可、裝載和執(zhí)行。

其中對于Java虛擬機JVM中的Java 堆主要分為【 新生代 、老年代 、永久代、元數(shù)據(jù)區(qū)】：

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

Java 內(nèi)存模型

你已經(jīng)知道，導致可見性的原因是緩存，導致有序性的原因是編譯優(yōu)化，那解決可見性、有序性最直接的辦法就是禁用緩存和編譯優(yōu)化，但是這樣問題雖然解決了，我們程序的性能可就堪憂了。

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

Java 內(nèi)存模型是個很復雜的規(guī)范，可以從不同的視角來解讀，站在我們這些程序員的視角，本質(zhì)上可以理解為，Java 內(nèi)存模型規(guī)范了 JVM 如何提供按需禁用緩存和編譯優(yōu)化的方法。具體來說，這些方法包括 volatile、synchronized 和 final 三個關(guān)鍵字。

Java 的內(nèi)存模型是并發(fā)編程領(lǐng)域的一次重要創(chuàng)新，之后 C++、C#、Golang 等高級語言都開始支持內(nèi)存模型。Java 內(nèi)存模型里面，最晦澀的部分就是 Happens-Before 規(guī)則，接下來我們詳細介紹一下。

Happens-Before 規(guī)則

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

Happens-Before 規(guī)則應(yīng)該是 Java 內(nèi)存模型里面最晦澀的內(nèi)容了，和程序員相關(guān)的規(guī)則一共有如下六項，都是關(guān)于可見性的，具體如下：

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

在 Java 語言里面，Happens-Before 的語義本質(zhì)上是一種可見性，A Happens-Before B 意味著 A 事件對 B 事件來說是可見的，無論 A 事件和 B 事件是否發(fā)生在同一個線程里。例如 A 事件發(fā)生在線程 1 上，B 事件發(fā)生在線程 2 上，Happens-Before 規(guī)則保證線程 2 上也能看到 A 事件的發(fā)生。

Java 內(nèi)存模型主要分為兩部分，一部分面向你我這種編寫并發(fā)程序的應(yīng)用開發(fā)人員，另一部分是面向 JVM 的實現(xiàn)人員的，我們可以重點關(guān)注前者，也就是和編寫并發(fā)程序相關(guān)的部分，這部分內(nèi)容的核心就是 Happens-Before 規(guī)則。

代碼設(shè)計原則

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

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

針對于每一個設(shè)計原則，我們需要掌握它能幫助我們解決什么問題和可以適合什么樣的應(yīng)用場景?？梢赃@樣說，設(shè)計原則是心法，設(shè)計模式是招式，而編程是實實在在的運用。常見的設(shè)計原則有：

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

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

寫在最后

Java 內(nèi)存模型通過定義了一系列的 Happens-Before 操作，讓應(yīng)用程序開發(fā)者能夠輕易地表達不同線程的操作之間的內(nèi)存可見性。

在遵守 Java 內(nèi)存模型的前提下，即時編譯器以及底層體系架構(gòu)能夠調(diào)整內(nèi)存訪問操作，以達到性能優(yōu)化的效果。如果開發(fā)者沒有正確地利用 Happens-Before 規(guī)則，那么將可能導致數(shù)據(jù)競爭。

Java 內(nèi)存模型是通過內(nèi)存屏障來禁止重排序的。對于即時編譯器來說，內(nèi)存屏障將限制它所能做的重排序優(yōu)化。對于處理器來說，內(nèi)存屏障會導致緩存的刷新操作。

在設(shè)計Java代碼的時候，遵循一些必要的設(shè)計原則，也能更好地幫助我們寫出好的代碼，減少內(nèi)存開銷，對于我們自我提升也有更好的幫助。

版權(quán)聲明：本文為博主原創(chuàng)文章，遵循相關(guān)版權(quán)協(xié)議，如若轉(zhuǎn)載或者分享請附上原文出處鏈接和鏈接來源。