JIT：即時編譯器，把class中的字節碼翻譯成CPU上可以直接執行的二進制指令。新的JIT不僅是編譯，可以分析字節碼是否可以優化，它可以將那些經常執行的字節碼片段（熱點代碼）進行緩存。

java虛擬機規范 周志明
JVM是Java Virtual Machine（Java虛擬機）的縮寫，JVM是一種用于計算設備的規范，它是一個虛構出來的計算機，是通過在實際的計算機上仿真模擬各種計算機功能來實現的。Java語言的一個非常重要的特點就是與平臺的無關性。而使用Java虛擬機是實現這一特點的關鍵。一般的高級語言如果要在不同的平臺上運行，至少需要編譯成不同的目標代碼。而引入Java語言虛擬機后，Java語言在不同平臺上運行時不需要重新編譯。Java語言使用Java虛擬機屏蔽了與具體平臺相關的信息，使得Java語言編譯程序只需生成在Java虛擬機上運行的目標代碼（字節碼），就可以在多種平臺上不加修改地運行。Java虛擬機在執行字節碼時，把字節碼解釋成具體平臺上的機器指令執行。這就是Java的能夠一次編譯，到處運行 的原因。

* 執行引擎處于JVM的核心位置，在Java虛擬機規范中，它的行為是由指令集所決定的。盡管對于每條指令，規范很詳細地說明了當JVM執行字節碼遇到指令時，它的實現應該做什么，但對于怎么做卻言之甚少。Java虛擬機支持大約248個字節碼。每個字節碼執行一種基本的CPU運算，例如，把一個整數加到寄存器，子程序轉移等。Java指令集相當于Java程序的匯編語言。Java指令集中的指令包含一個單字節的操作符，用于指定要執行的操作，還有0個或多個操作數，提供操作所需的參數或數據。許多指令沒有操作數，僅由一個單字節的操作符構成。 * java的字節碼是由javac所編譯的，

Java中，字節碼是CPU構架（JVM）的具有可移植性的機器語言

Java中，字節碼是CPU構架（JVM）的具有可移植性的機器語言第一章 走近java
* 因為程序員把內存控制的權力交給了java虛擬機，編碼的時候享自動內存管理的諸多優勢。
* 提供了一個相對安全的內存管理和訪問機制，避免了絕大部分的內存泄漏和指針越界問題
* 但是也是會出現內存泄漏。
* Jdk進化史
* jdk 1.1 jdbc jar文件格式 jdk javabeans 語法的內部類 反射
* 1.2 java分為三個方向 j2ee(企業) j2se（桌面開發） j2me（手機移動終端）
* collections集合 math TimerAPI
* 1.3 類庫
* 1.4 正則表達式 異常鏈 nio xml 等
* 1.5 自動裝箱 泛型 動態注解 枚舉 可變長參數 遍歷（foreach） concurrent 并發包
* 1.6 鎖 垃圾收集 類加載 算法
* 普通對象指針壓縮功能 （-XX:+ userCompressedOops）不建議開啟 jvm自動管理開啟
* 開啟壓縮指針會增加執行代碼質量，java 堆 指向java堆內對象的指針都會被壓縮
* 1.7
* 1.8 lambda 表達式 map

* 第二章
* java 內存區域與內存溢出異常
* 方法區和堆 線程共享
* 剩下的線程隔離
* 程序計數器（program counter register）只占用了一塊比較小的內存空間{可以忽略不計}
* 可以看作是當前線程所執行的字節碼文件（class）的行號指示器。在虛擬機的世界中，字節碼解釋器就是通過改變計數器的值來選取下一條執行的字節碼指令，分支、循環、跳轉、異常處理、線程恢復都需要這玩意來實現的
* 多線程是通過線程輪流切換，并分配處理器執行時間的方式來實現的。
* 1個處理器執行一個線程 多核同時多個
* 每條線程都需要有一個獨立的程序計數器。各條線程之間計數器互不影響獨存儲。線程私有的內存。

java虛擬機棧
* 每個方法執行都會創建一個棧幀，用于存放局部變量表，操作棧，動態鏈接，方法出口等。每個方法從被調用，直到被執行完。對應著一個棧幀在虛擬機中從入棧到出棧的過程。
* 會有兩種異常StackOverFlowError和 OutOfMemoneyError。當線程請求棧深度大于虛擬機所允許的深度就會拋出StackOverFlowError錯誤；虛擬機棧動態擴展，當擴展無法申請到足夠的內存空間時候，拋出OutOfMemoneyError

* 每當一個java方法被執行時都會在虛擬機中新創建一個棧幀，方法調用結束后即被銷毀。 * 局部變量表中的變量作用域是當前調用的函數。函數調用結束后，隨著函數棧幀的銷毀。局部變量表也會隨之銷毀，釋放空間。 * 棧幀存儲空間為虛擬機棧，每一個棧幀都有自己的局部變量表、操作數棧和指向當前方法所屬的類引用。 * 當然方法調用其他的方法 新的棧幀 就會創建且控制權交給新的棧幀 * 而 JVM 的字節碼指令是這樣的： * iconst_1 //把整數 1 壓入操作數棧 * iconst_2 //把整數 2 壓入操作數棧 * iadd //棧頂的兩個數相加后出棧，結果入棧 * 局部變量表所需內存空間在編譯期間完成分配 當進入一個方法時，這個方法需要在棧幀中分配多大的局部變量空間是完全確定的，在方法運行期間不會改變局部變量表的大小。 * 局部變量區被組織為以一個字長為單位、從0開始計數的數組，類型為short、byte和char的值在存入數組前要被轉換成int值，而long和 double在數組中占據連續的兩項，在訪問局部變量中的long或double時，只需取出連續兩項的第一項的索引值即可,如某個long值在局部變量 區中占據的索引時3、4項，取值時，指令只需取索引為3的long值即可。 * 單位slot 8個數據類型基本上都是占用一個slot long duble 占用2個 加引用類型的數據指向一條虛擬機指令的操作碼 引用指針 或者對象句柄 * 虛擬機規范 boolean 虛擬機中int代替 boolean 數組 oracle 中為byte 數組 * true 為1 false 為0 * 局部變量表使用索引來進行訪問 首個局部變量的索引值為0 * 操作數棧是后進先出的棧

* 本地方法棧
* 什么是Native Method
* 簡單地講，一個Native Method就是一個java調用非java代碼的接口。一個Native Method是這樣一個java的方法：該方法的實現由非java語言實現，比如C。這個特征并非java所特有，很多其它的編程語言都有這一機制
* 與java環境外交互：
* 有時java應用需要與java外面的環境交互。這是本地方法存在的主要原因，你可以想想java需要與一些底層系統如操作系統或某些硬件交換信息時的情況。本地方法正是這樣一種交流機制：它為我們提供了一個非常簡潔的接口，而且我們無需去了解java應用之外的繁瑣的細節。
* 堆
* 是虛擬機中最大的一塊共享區域 在虛擬機啟動的時候創建 它存儲了自動內存管理系統 （gc垃圾收集器） 虛擬機實現者根據系統的實際需要來選擇自動內存管理技術
* 所有類實例和數組分配內存的區域
* 基本上采用分代收集算法

* 方法區 * 各個線程共享的運行區域 * 存儲了每個類的結構信息 運行時常量池 字段 方法數據 構造函數 普通方法的字節碼內存 還有特殊方法 * oom * 方法區并不等于永久代 * hotspot 把gc 分代收集擴展到方法區 使用永久代來實現方法區 跟堆一樣管理內存 * 運行時常量池是方法區的一部分 具備動態性 可以編譯時候產生 class 文件常量池內容 運行區間產生新的 * 虛擬機指令不依賴類 接口 類實例 數組的布局 而是依賴常量池表中符號信息 * 在HotSpot虛擬機中，用永久代來實現方法區，將GC分代收集擴展至方法區，但是這樣容易遇到內存溢出的問題。 * 　　JDK1.7中，字符串常量池native（） * 　　JDK1.8撤銷永久代，引入元空間。 * 直接內存（堆外內存）并不是虛擬機運行時數據區的一部分，也不是Java 虛擬機規范中農定義的內存區域。在JDK1.4 中新加入了NIO(New Input/Output)類，引入了一種基于通道(Channel)與緩沖區（Buffer）的I/O 方式，它可以使用native 函數庫直接分配堆外內存，然后通脫一個存儲在Java堆中的DirectByteBuffer 對象作為這塊內存的引用進行操作。這樣能在一些場景中顯著提高性能，因為避免了在Java堆和Native堆中來回復制數據。 * 好處： 這樣做有兩方面的好處: * 減少GC管理內存:由于GCIH會從Old區“切出”一塊, 因此導致GC管理區域變小, 可以明顯降低GC工作量, 提高GC效率, 降低Full GC STW時間(且由于這部分內存仍屬于堆, 因此其訪問方式/速度不變- 不必付出序列化/反序列化的開銷). * GCIH內容進程間共享:由于這部分區域不再是JVM運行時數據的一部分, 因此GCIH內的對象可供對個JVM實例所共享(如一臺Server跑多個MR-Job可共享同一份Cache數據), 這樣一臺Server也就可以跑更多的VM實例. * 3、堆外內存的好處是： * (1)可以擴展至更大的內存空間。比如超過1TB甚至比主存還大的空間; * (2)理論上能減少GC暫停時間; * (3)可以在進程間共享，減少JVM間的對象復制，使得JVM的分割部署更容易實現; * (4)它的持久化存儲可以支持快速重啟，同時還能夠在測試環境中重現生產數據 * 本機直接內存的分配不會受到Java 堆大小的限制，受到本機總內存大小限制 * 配置虛擬機參數時，不要忽略直接內存 防止出現OutOfMemoryError異常 * Java內存模型規定了所有的變量都存儲在主內存中。每條線程中還有自己的工作內存，線程的工作內存中保存了被該線程所使用到的變量（這些變量是從主內存中拷貝而來）。線程對變量的所有操作（讀取，賦值）都必須在工作內存中進行。不同線程之間也無法直接訪問對方工作內存中的變量，線程間變量值的傳遞均需要通過主內存來完成。 * 基于此種內存模型，便產生了多線程編程中的數據“臟讀”等問題。

volatile變量是一種稍弱的同步機制在訪問volatile變量時不會執行加鎖操作，因此也就不會使執行線程阻塞，因此volatile變量是一種比synchronized關鍵字更輕量級的同步機制。讀取快 修改慢
* 1.volatile保證可見性
* 1）保證了不同線程對這個變量進行操作時的可見性，即一個線程修改了某個變量的值，這新值對其他線程來說是立即可見的。
* 2）禁止進行指令重排序。
* 編譯出來的只有一條字節碼指令，也不意味執行這條指令就是一個原子操作 一條字節碼指令在解釋
* 執行時，解釋器將要運行許多行代碼才能實現。
* 什么是指令重排？
* 指令重排是指JVM在編譯Java代碼的時候，或者CPU在執行JVM字節碼的時候，對現有的指令順序進行重新排序。
* 指令重排的目的是為了在不改變程序執行結果的前提下，優化程序的運行效率。需要注意的是，這里所說的不改變執行結果，指的是不改變單線程下的程序執行結果。
* 一個項目一個接口，每天調用1次，1s 1s 1s 以后都會是1s嗎？
* 如何使用volatile呢
* 運算結果并不依賴變量的當前值，后者能夠確保只有單一的線程修改變量的值

非原子操作加鎖 ++ 不能保證原子性 需要加synchronized 或者lock 第七章虛擬機類加載機制 * Java源代碼被編譯成class字節碼，最終需要加載到虛擬機中才能運行。整個生命周期包括：加載、驗證、準備、解析、初始化、使用和卸載7個階段。 * * 加載 驗證 準備 初始化 卸載5個階段的順序是確定的 * 加載 * 1、通過一個類的全限定名獲取描述此類的二進制字節流； * 2、將這個字節流所代表的靜態存儲結構保存為方法區的運行時數據結構； * 3、在java堆中生成一個代表這個類的java.lang.Class對象，作為訪問方法區的入口； * 類加載器 * 虛擬機設計團隊把加載動作放到JVM外部實現，以便讓應用程序決定如何獲取所需的類，實現這個動作的代碼稱為?°類加載器?±，JVM提供了3種類加載器： * 1、啟動類加載器（Bootstrap ClassLoader）：負責加載 JAVAHOME\lib 目錄中的，或通過-Xbootclasspath參數指定路徑中的，且被虛擬機認可（按文件名識別，如rt.jar）的類。 * 2、擴展類加載器（Extension ClassLoader）：負責加載 JAVAHOME\lib\ext 目錄中的，或通過java.ext.dirs系統變量指定路徑中的類庫。 * 3、應用程序類加載器（Application ClassLoader）：負責加載用戶路徑（classpath）上的類庫。 * JVM基于上述類加載器，通過雙親委派模型進行類的加載，當然我們也可以通過繼承java.lang.ClassLoader實現自定義的類加載器。

* 雙親委派模型工作過程：當一個類加載器收到類加載任務，優先交給其父類加載器去完成，因此最終加載任務都會傳遞到頂層的啟動類加載器，只有當父類加載器無法完成加載任務時，才會嘗試執行加載任務。 * 雙親委派模型有什么好處？ 比如位于rt.jar包中的類java.lang.Object，無論哪個加載器加載這個類，最終都是委托給頂層的啟動類加載器進行加載，確保了Object類在各種加載器環境中都是同一個類。 * 驗證 * 為了確保Class文件符合當前虛擬機要求，需要對其字節流數據進行驗證，主要包括格式驗證、元數據驗證、字節碼驗證和符號引用驗證。 * 格式驗證：驗證字節流是否符合class文件格式的規范，并且能被當前虛擬機處理，如是否以魔數0xCAFEBABE開頭、主次版本號是否在當前虛擬機處理范圍內、常量池是否有不支持的常量類型等。只有經過格式驗證的字節流，才會存儲到方法區的數據結構，剩余3個驗證都基于方法區的數據進行。 * 元數據驗證：對字節碼描述的數據進行語義分析，以保證符合Java語言規范，如是否繼承了final修飾的類、是否實現了父類的抽象方法、是否覆蓋了父類的final方法或final字段等。 * 字節碼驗證：對類的方法體進行分析，確保在方法運行時不會有危害虛擬機的事件發生，如保證操作數棧的數據類型和指令代碼序列的匹配、保證跳轉指令的正確性、保證類型轉換的有效性等。 * 符號引用驗證：為了確保后續的解析動作能夠正常執行，對符號引用進行驗證，如通過字符串描述的全限定名是都能找到對應的類、在指定類中是否存在符合方法的字段描述符等。

準備準備階段是正式為類變量分配內存并設置類變量初始值得階段，這些變量所使用的內存都講在方法區中進行分配。這時候進行內存分配的僅包括類變量（被static修飾的變量），而不包括實例變量，實例變量將會在對象實例化時隨著對象一起分配在Java堆中。
* 在準備階段，為類變量（static修飾）在方法區中分配內存并設置初始值。
* private static int var = 100;
* 準備階段完成后，var 值為0，而不是100。在初始化階段，才會把100賦值給val，但是有個特殊情況：
* private static final int VAL= 100;
* 在編譯階段會為VAL生成ConstantValue屬性，在準備階段虛擬機會根據ConstantValue屬性將VAL賦值為100。
* 初始化
* 初始化階段是執行類構造器方法的過程，方法由類變量的賦值動作和靜態語句塊按照在源文件出現的順序合并而成，該合并操作由編譯器完成。
* 開始執行java代碼（或者說字節碼）

查看JVM使用的默認的垃圾收集器

查看步驟
cmd執行命令：
java -XX:+PrintCommandLineFlags -version

jdk1.7 默認垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）

jdk1.8 默認垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）

jdk1.9 默認垃圾收集器G1

上邊新生代 下邊老年代

標記-清除算法
復制算法
標記-整理算法
新生代 單線程
ParNew
新生代多線程
Parallel ScaVenge
新生代 復制算法 可控制的吞吐量 吞吐量優先
Serial old
老年代 單線程標記-整理算法
Parallel Old 多線程 標記-整理算法
cms
最短停頓時間為目標（快）
標記-清除 再整理
Serial old是cms的后備方案

算法過程：

Eden+S0可分配新生對象；

對Eden+S0進行垃圾收集，存活對象復制到S1。清理Eden+S0。一次新生代GC結束。

Eden+S1可分配新生對象；

對Eden+S1進行垃圾收集，存活對象復制到S0。清理Eden+S1。二次新生代GC結束。

goto 1。
1.S0與S1的區間明顯較小，有效新生代空間為Eden+S0/S1，因此有效空間就大，增加了內存使用率
2.有利于對象代的計算，當一個對象在S0/S1中達到設置的XX:MaxTenuringThreshold值后，會將其分到老年代中，設想一下，如果沒有S0/S1,直接分成兩個區，該如何計算對象經過了多少次GC還沒被釋放,你可能會說，在對象里加一個計數器記錄經過的GC次數，或者存在一張映射表記錄對象和GC次數的關系，是的，可以，但是這樣的話，會掃描整個新生代中的對象, 有了S0/S1我們就可以只掃描S0/S1區了

在年輕代中經歷了N次（可配置）垃圾回收后仍然存活的對象，就會被復制到年老代中。因此，可以認為年老代中存放的都是一些生命周期較長的對象。
針對年老代的垃圾回收即Full GC。

Jvm查看
對象的內布局
對象頭 實例數據 對象填充
對象頭 mark word 存儲 64位或者32位指針
25 哈希嗎
4 分代年齡
2 鎖標志
輕量級 重量級 gc標志 可偏向
top
ps -ef | grep java
jps 條件 pid -q –m –l -v
jstat 條件 pid
-class -gc –gccapacity –gcutil –gccause -gcnew
-gcnewcapacity –gcold –gcoldcapacity -gcpermcapacity
-compiler -printcompilation
jmap 條件 pid
-dump –finalizerinfo –heap –histo –permstat -F

jvm dump 分析

mat 英文 memory analyzer tool
jvm dump 分析工具 （MAT）
Memory Analyzer tool
Histogram 所有實例的分配情況
Dominator Tree 堆的最大對象
Leak Suspecks 列出懷疑的內存泄漏處

-gc (jstat -gc pid 1000 5 )
S0C: Survivor0(幸存區0)大小（KB）
S1C: Survivor1(幸存區1)1大小（KB）
S0U: Survivor0(幸存區0)已使用大小（KB）
S1U: Survivor1(幸存區1)已使用大小（KB）
EC : Eden（伊甸區）大小（KB）
EU : Eden（伊甸區）已使用大小（KB）
OC ：老年代大小（KB）
OU : 老年代已使用大小（KB）
PC : Perm永久代大小（KB）
PU : Perm永久代已使用大小（KB）
YGC：新生代GC個數
YGCT：新生代GC的耗時（秒）
FGC ：Full GC次數
FGCT：Full GC耗時（秒）
GCT ：GC總耗時（秒）

常用 jvm tomcat 配置參數

與串行回收器相關的參數
-XX:+UseSerialGC:在新生代和老年代使用串行回收器。
-XX:+SuivivorRatio:設置 eden 區大小和 survivor 區大小的比例。
-XX:+PretenureSize :設置大對象直接進入老年代的閾值。當對象的大小超過這個值時，將直接在老年代分配 默認15。
-XX:MaxTenuringThreshold:設置對象進入老年代的年齡的最大值。每一次 Minor GC 后，對象年齡就加 1。任何大于這個年齡的對象，一定會進入老年代。

與并行 GC 相關的參數
-XX:+UseParNewGC: 在新生代使用并行收集器。
-XX:+UseParallelOldGC: 老年代使用并行回收收集器。
-XX:ParallelGCThreads：設置用于垃圾回收的線程數。通常情況下可以和 CPU 數量相等。但在 CPU 數量比較多的情況下，設置相對較小的數值也是合理的。
-XX:MaxGCPauseMills：設置最大垃圾收集停頓時間。它的值是一個大于 0 的整數。收集器在工作時，會調整 Java 堆大小或者其他一些參數，盡可能地把停頓時間控制在 MaxGCPauseMills 以內。
-XX:GCTimeRatio:設置吞吐量大小，它的值是一個 0-100 之間的整數。假設 GCTimeRatio 的值為 n，那么系統將花費不超過 1/(1+n) 的時間用于垃圾收集。
-XX:+UseAdaptiveSizePolicy:打開自適應 GC 策略。在這種模式下，新生代的大小，eden 和 survivor 的比例、晉升老年代的對象年齡等參數會被自動調整，以達到在堆大小、吞吐量和停頓時間之間的平衡點。

與 CMS 回收器相關的參數
-XX:+UseConcMarkSweepGC: 新生代使用并行收集器，老年代使用 CMS+串行收集器。
-XX:+ParallelCMSThreads: 設定 CMS 的線程數量。

滴滴面試問到的 68 是什么的比例

XX:+CMSInitiatingOccupancyFraction:設置 CMS 收集器在老年代空間被使用多少后觸發，默認為 68%。

XX:+UseFullGCsBeforeCompaction:設定進行多少次 CMS 垃圾回收后，進行一次內存壓縮。
-XX:+CMSClassUnloadingEnabled:允許對類元數據進行回收。
-XX:+CMSParallelRemarkEndable:啟用并行重標記。
-XX:CMSInitatingPermOccupancyFraction:當永久區占用率達到這一百分比后，啟動 CMS 回收 (前提是-XX:+CMSClassUnloadingEnabled 激活了)。
-XX:UseCMSInitatingOccupancyOnly:表示只在到達閾值的時候，才進行 CMS 回收。
-XX:+CMSIncrementalMode:使用增量模式，比較適合單 CPU。
4. 與 G1 回收器相關的參數
-XX:+UseG1GC：使用 G1 回收器。
-XX:+UnlockExperimentalVMOptions:允許使用實驗性參數。
-XX:+MaxGCPauseMills:設置最大垃圾收集停頓時間。
-XX:+GCPauseIntervalMills:設置停頓間隔時間。

1.手動調整

Xmn
-Xms
-XX:NewRatio=N
手動指定堆內存大小和代空間比例，一般要多次試驗

2.自動參數調整

XX:MaxGCPauseMillis=N 可接受最大停頓時間
-XX:GCTimeRatio=N 可接受GC時間占比（目標吞吐量） 吞吐量=1-1/(1+N)
步驟：
1.MaxGCPauseMillis優先級高，JVM會自動調整堆大小和代空間值，以期滿足MaxGCPauseMillis
2.當MaxGCPauseMillis滿足后，JVM會增大堆大小，直到滿足GCTimeRatio
3.當MaxGCPauseMillis和GCTimeRadio都滿足后，JVM會盡可能以最小堆大小來實現這兩個指標參數

Full GC原因：

并發模式失效：新生代發生GC時，老年代沒有足夠內存容納晉升對象
晉升失敗：老年代雖然有足夠容納晉升對象的內存，但內存都是碎片，導致晉升失敗
*參數調整：避免并發模式失效和晉升失敗
-XX:+UseCMSInitiatingOccupancyOnly 根據Old內存使用閾值決定何時CMS, 默認是false，會用更復雜的算法決定何時CMS
-XX:CMSInitingOccupancyFraction=N default N=70，老年代內存使用70%時就發生CMS
N設置太大，容易并發模式失效；N太小，CMS過于頻繁，而CMS也會導致stop-the-world
-XX:ConGCThreads=N GC的線程會100%占用CPU，如果發生并發模式失敗，而N還小于CPU核心數，此時可以增加N。
如果沒有發生并發模式失敗，此時可以減少N，以讓應用程序有更多CPU執行
Perm持久代GC調優
持久代內存滿了會引發Full GC
持久代GC調優主要是讓持久代也進行CMS收集
-XX:+CMSPermGenSweepingEnable 使持久代使用CMS收集器
-XX:+CMSClassUnloadingEnable 使持久代能真正釋放不再被使用的類。默認是不會釋放類的元數據的
增量式CMS:普通CMS線程會占用100%的cpu負載，增量式CMS會讓出一定CPU負載給應用線程
這適合在單核CPU使用，顯然已經沒啥用處了

1. -Xms128m 2. -Xmx128m 3. -XX:NewSize=64m 4. -XX:PermSize=64m 5. -XX:+UseConcMarkSweepGC 6. -XX:CMSInitiatingOccupancyFraction=78 7. -XX:ThreadStackSize=128-Xloggc:logs/gc.log 8. -Dsun.rmi.dgc.server.gcInterval=3600000 9. -Dsun.rmi.dgc.client.gcInterval=3600000 10. -Dsun.rmi.server.exceptionTrace=true

老年代(Old Generation)

老年代(Old Generation)老年代的GC實現要復雜得多。老年代內存空間通常會更大，里面的對象是垃圾的概率也更小。
老年代GC發生的頻率比年輕代小很多。同時, 因為預期老年代中的對象大部分是存活的, 所以不再使用標記和復制(Mark and Copy)算法。而是采用移動對象的方式來實現最小化內存碎片。老年代空間的清理算法通常是建立在不同的基礎上的。原則上,會執行以下這些步驟:

通過標志位(marked bit),標記所有通過 GC roots 可達的對象.
刪除所有不可達對象
整理老年代空間中的內容，方法是將所有的存活對象復制,從老年代空間開始的地方,依次存放。

Minor GC vs Major GC vs Full GC

垃圾收集事件(Garbage Collection events)通常分為: 小型GC(Minor GC) - 大型GC(Major GC) - 和完全GC(Full GC) 。

小型GC(Minor GC)

年輕代內存的垃圾收集事件稱為小型GC。這個定義既清晰又得到廣泛共識。對于小型GC事件,有一些有趣的事情你應該了解一下:
1. 當JVM無法為新對象分配內存空間時總會觸發 Minor GC,比如 Eden 區占滿時。所以(新對象)分配頻率越高, Minor GC 的頻率就越高。
2. Minor GC 事件實際上忽略了老年代。從老年代指向年輕代的引用都被認為是GC Root。而從年輕代指向老年代的引用在標記階段全部被忽略。
3. 與一般的認識相反, Minor GC 每次都會引起全線停頓(stop-the-world ), 暫停所有的應用線程。對大多數程序而言,暫停時長基本上是可以忽略不計的, 因為 Eden 區的對象基本上都是垃圾, 也不怎么復制到存活區/老年代。如果情況不是這樣, 大部分新創建的對象不能被垃圾回收清理掉, 則 Minor GC的停頓就會持續更長的時間。
所以 Minor GC 的定義很簡單 —— Minor GC 清理的就是年輕代。

Major GC vs Full GC

沒有明確的定義
Major GC(大型GC) 清理的是老年代空間(Old space)。
Full GC(完全GC)清理的是整個堆, 包括年輕代和老年代空間。

很多 Major GC 是由 Minor GC 觸發的, 所以很多情況下這兩者是不可分離的。另一方面, 像G1這樣的垃圾收集算法執行的是部分區域垃圾回收 回收區分也不是很明確
這也讓我們認識到,不應該去操心是叫 Major GC 呢還是叫 Full GC, 我們應該關注的是: 某次GC事件 是否停止所有線程,或者是與其他線程并發執行。

一個線程OOM，進程里其他線程還能運行么？

正常linux 項目啟動 oom error 就會造成項目停止
這問題正常也是回答 其他線程也會停止，總感覺oom 出問題都會停止

但是這個線程有時候真是特殊，一個線程oom并不一定其他的線程也停止。
既然一個線程oom，那它就會觸發gc，gc回收后如果有足夠的空間，并不會造成其他的線程停止。

https://cloud.tencent.com/developer/article/1614156
https://blog.csdn.net/qq_40298351/article/details/121256296

總結

以上是生活随笔為你收集整理的深入理解java虚拟机 （周志明）JVM个人总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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