什么是HotSpot VM 提起HotSpot VM，相信所有Java程序員都知道，它是Sun JDK和OpenJDK中所帶的虛擬機，也是目前使用范圍最廣的Java虛擬機。 但不一定所有人都知道的是，這個目前看起來“血統純正”的虛擬機在最初并非由Sun公司開發，而是由一家名為“Longview Technologies”的小公司設計的； 甚至這個虛擬機最初并非是為Java語言而開發的，它來源于Strongtalk VM， 而這款虛擬機中相當多的技術又是來源于一款支持Self語言實現“達到C語言50%以上的執行效率”的目標而設計的虛擬機， Sun公司注意到了這款虛擬機在JIT編譯上有許多優秀的理念和實際效果，在1997年收購了Longview Technologies公司， 從而獲得了HotSpot VM。 HotSpot VM既繼承了Sun之前兩款商用虛擬機的優點（如前面提到的準確式內存管理），也有許多自己新的技術優勢， 如它名稱中的HotSpot指的就是它的熱點代碼探測技術（其實兩個VM基本上是同時期的獨立產品，HotSpot還稍早一些， HotSpot一開始就是準確式GC，而Exact VM之中也有與HotSpot幾乎一樣的熱點探測。 為了Exact VM和HotSpot VM哪個成為Sun主要支持的VM產品，在Sun公司內部還有過爭論，HotSpot打敗Exact并不能算 技術上的勝利）， HotSpot VM的熱點代碼探測能力可以通過執行計數器找出最具有編譯價值的代碼，然后通知JIT編譯器以方法為單位 進行編譯。 如果一個方法被頻繁調用，或方法中有效循環次數很多，將會分別觸發標準編譯和OSR（棧上替換）編譯動作。 通過編譯器與解釋器恰當地協同工作，可以在最優化的程序響應時間與最佳執行性能中取得平衡，而且無須等待本地 代碼輸出才能執行程序， 即時編譯的時間壓力也相對減小，這樣有助于引入更多的代碼優化技術，輸出質量更高的本地代碼。在2006年的JavaOne大會上，Sun公司宣布最終會把Java開源，并在隨后的一年，陸續將JDK的各個部分（其中當然也 包括了HotSpot VM）在GPL協議下公開了源碼， 并在此基礎上建立了OpenJDK。這樣，HotSpot VM便成為了Sun JDK和OpenJDK兩個實現極度接近的JDK項目的共同虛擬機。在2008年和2009年，Oracle公司分別收購了BEA公司和Sun公司，這樣Oracle就同時擁有了兩款優秀的Java虛擬機： JRockit VM和HotSpot VM。 Oracle公司宣布在不久的將來（大約應在發布JDK 8的時候）會完成這兩款虛擬機的整合工作，使之優勢互補。 整合的方式大致上是在HotSpot的基礎上，移植JRockit的優秀特性，譬如使用JRockit的垃圾回收器與MissionControl服務， 使用HotSpot的JIT編譯器與混合的運行時系統。 Java內存結構Java堆（Java Heap）java堆是java虛擬機所管理的內存中最大的一塊，是被所有線程共享的一塊內存區域，在虛擬機啟動時創建。此內存區域 的唯一目的就是存放對象實例，這一點在Java虛擬機規范中的描述是：所有的對象實例以及數組都要在堆上分配。 java堆是垃圾收集器管理的主要區域，因此也被成為“GC堆”（Garbage Collected Heap）。從內存回收角度來看java堆可分為： 新生代和老生代（當然還有更細致的劃分，在下一章會講到）。從內存分配的角度看，線程共享的Java堆中可能劃分出多個 線程私有的分配緩沖區（Thread Local Allocation Buffer，TLAB）。無論怎么劃分，都與存放內容無關，無論哪個區域， 存儲的都是對象實例，進一步的劃分都是為了更好的回收內存，或者更快的分配內存。 根據Java虛擬機規范的規定，java堆可以處于物理上不連續的內存空間中。當前主流的虛擬機都是可擴展的（ 通過 -Xmx 和 -Xms 控制）。如果堆中沒有內存完成實例分配，并且堆也無法再擴展時，將會拋出OutOfMemoryError異常。 Java虛擬機棧（Java Virtual Machine Stacks） java虛擬機也是線程私有的，它的生命周期和線程相同。虛擬機棧描述的是Java方法執行的內存模型：每個方法在執行的 同時都會創建一個棧幀（Stack Frame）用于存儲局部變量表、操作數棧、動態鏈接、方法出口等信息。 咱們常說的堆內存、棧內存中，棧內存指的就是虛擬機棧。局部變量表存放了編譯期可知的各種基本數據類型 （8個基本數據類型）、對象引用（地址指針）、returnAddress類型。 局部變量表所需的內存空間在編譯期間完成分配。在運行期間不會改變局部變量表的大小。 這個區域規定了兩種異常狀態：如果線程請求的棧深度大于虛擬機所允許的深度，則拋出StackOverflowError異常；如果 虛擬機棧可以動態擴展，在擴展是無法申請到足夠的內存，就會拋出OutOfMemoryError異常。 本地方法棧（Native Method Stack）本地方法棧與虛擬機棧所發揮作用非常相似，它們之間的區別不過是虛擬機棧為虛擬機執行Java方法（也就是字節碼）服務， 而本地方法棧則為虛擬機使用到的native方法服務。本地方法棧也是拋出兩個異常。 方法區（Method Area） 方法區與java堆一樣，是各個線程共享的內存區域，它用于存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的 代碼等數據。它有個別命叫Non-Heap（非堆）。當方法區無法滿足內存分配需求時，拋出OutOfMemoryError異常。 直接內存（Direct Memory）直接內存不是虛擬機運行時數據區的一部分，也不是java虛擬機規范中定義的內存區域。但這部分區域也唄頻繁使用，而且也 可能導致OutOfMemoryError異常 在JDK1.4中新加入的NIO（New Input/Output）類，引入了一種基于通道（Channel）與緩沖區（Buffer）的I/O方式，它可以使用 Native函數庫直接分配堆外內存，然后通過一個存儲在java堆中的DirectByteBuffer對象作為這塊內存的引用進行操作。 運行時常量池（Runtime Constant Pool）運行時常量池是方法區的一部分。Class文件中除了有類的版本、字段、方法、接口等描述信息外，還有一項信息是常量池， 用于存放編譯期生成的各種字面量和符號引用，這部分內容將在加載后進入方法區的運行時常量池中存放。 程序計數器（Program Counter Register） 程序計數器是一塊較小的內存空間，它可以看作是當前線程所執行的字節碼的行號指示器。 由于Java虛擬機的多線程是通過線程輪流切換并分配處理器執行時間的方式來實現的，一個處理器都只會執行一條線程中的指令。 因此，為了線程切換后能恢復到正確的執行位置，每條線程都有一個獨立的程序計數器，各個線程之間計數器互不影響，獨立存儲。 稱之為“線程私有”的內存。程序計數器內存區域是虛擬機中唯一沒有規定OutOfMemoryError情況的區域。 執行引擎 虛擬機核心的組件就是執行引擎，它負責執行虛擬機的字節碼，一般戶先進行編譯成機器碼后執行。 垃圾收集系統 垃圾收集系統是Java的核心，也是不可少的，Java有一套自己進行垃圾清理的機制，開發人員無需手工清理 垃圾回收機制算法分析 什么是垃圾回收機制 不定時去堆內存中清理不可達對象。不可達的對象并不會馬上就會直接回收， 垃圾收集器在一個Java程序中的執行是自動的， 不能強制執行，即使程序員能明確地判斷出有一塊內存已經無用了，是應該回收的，程序員也不能強制垃圾收集器回收該內存塊。 程序員唯一能做的就是通過調用System.gc 方法來"建議"執行垃圾收集器，但其是否可以執行，什么時候執行卻都是不可知的。 這也是垃圾收集器的最主要的缺點。當然相對于它給程序員帶來的巨大方便性而言，這個缺點是瑕不掩瑜的。 public class Test {public static void main(String[] args) {Test test = new Test();test = null;System.gc(); // 手動回收垃圾}@Overrideprotected void finalize() throws Throwable {// gc回收垃圾之前調用System.out.println("垃圾回收機制...");} }finalize方法作用 Java技術使用finalize()方法在垃圾收集器將對象從內存中清除出去前，做必要的清理工作。這個方法是由垃圾收集器在確定這個對象 沒有被引用時對這個對象調用的。它是在Object類中定義的，因此所有的類都繼承了它。子類覆蓋finalize()方法以整理系統資源或者 執行其他清理工作。finalize()方法是在垃圾收集器刪除對象之前對這個對象調用的。 新生代與老年代 Java 中的堆是 JVM 所管理的最大的一塊內存空間，主要用于存放各種類的實例對象。 在 Java 中，堆被劃分成兩個不同的區域：新生代 ( Young )、老年代 ( Old )。新生代 ( Young ) 又被劃分為三個區域：Eden、 From Survivor、To Survivor。 這樣劃分的目的是為了使 JVM 能夠更好的管理堆內存中的對象，包括內存的分配以及回收。 堆的內存模型大致為：（本人使用的是 JDK1.6，以下涉及的 JVM 默認值均以該版本為準。） 默認的，新生代 ( Young ) 與老年代 ( Old ) 的比例的值為 1:2 ( 該值可以通過參數 –XX:NewRatio 來指定 )，即：新生代 ( Young ) = 1/3 的堆空間大小。老年代 ( Old ) = 2/3 的堆空間大小。其中，新生代 ( Young ) 被細分為 Eden 和 兩個Survivor 區域，這兩個 Survivor 區域分別被命名為 from 和 to，以示區分。 默認的，Edem : from : to = 8 : 1 : 1 ( 可以通過參數 –XX:SurvivorRatio 來設定 )，即： Eden = 8/10 的新生代空間大小，from = to = 1/10 的新生代空間大小。根據垃圾回收機制的不同，Java堆有可能擁有不同的結構，最為常見的就是將整個Java堆分為 新生代和老年代。其中新生帶存放新生的對象或者年齡不大的對象，老年代則存放老年對象。 新生代分為den區、s0區、s1區，s0和s1也被稱為from和to區域，他們是兩塊大小相等并且可以互相角色的空間。 絕大多數情況下，對象首先分配在eden區，在新生代回收后，如果對象還存活，則進入s0或s1區，之后每經過一次 新生代回收，如果對象存活則它的年齡就加1，對象達到一定的年齡后，則進入老年代。如何判斷對象是否存活 引用計數法 概念 引用計數法就是如果一個對象沒有被任何引用指向，則可視之為垃圾。這種方法的缺點就是不能檢測到環的存在。 首先需要聲明，至少主流的Java虛擬機里面都沒有選用引用計數算法來管理內存。 什么是引用計數算法：給對象中添加一個引用計數器，每當有一個地方引用它時，計數器值加１；當引用失效時，計數器值減１. 任何時刻計數器值為０的對象就是不可能再被使用的。那為什么主流的Java虛擬機里面都沒有選用這種算法呢？其中最主要的原因 是它很難解決對象之間相互循環引用的問題。根搜索算法 概念 根搜索算法的基本思路就是通過一系列名為”GC Roots”的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為引用鏈 (Reference Chain)，當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的。 這個算法的基本思想是通過一系列稱為“GC Roots”的對象作為起始點，從這些節點向下搜索，搜索所走過的路徑稱為引用鏈， 當一個對象到GC Roots沒有任何引用鏈（即GC Roots到對象不可達）時，則證明此對象是不可用的。 那么問題又來了，如何選取GCRoots對象呢？在Java語言中，可以作為GCRoots的對象包括下面幾種： (1). 虛擬機棧（棧幀中的局部變量區，也叫做局部變量表）中引用的對象。 (2). 方法區中的類靜態屬性引用的對象。 (3). 方法區中常量引用的對象。 (4). 本地方法棧中JNI(Native方法)引用的對象。 下面給出一個GCRoots的例子，如下圖，為GCRoots的引用鏈。根搜索算法的基本思路就是通過一系列名為”GC Roots”的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為 引用鏈(Reference Chain)，當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的。 從上圖，reference1、reference2、reference3都是GC Roots，可以看出： reference1-> 對象實例1； reference2-> 對象實例2； reference3-> 對象實例4； reference3-> 對象實例4 -> 對象實例6； 可以得出對象實例1、2、4、6都具有GC Roots可達性，也就是存活對象，不能被GC回收的對象。 而對于對象實例3、5直接雖然連通，但并沒有任何一個GC Roots與之相連，這便是GC Roots不可達的對象，這就是GC需要 回收的垃圾對象。垃圾回收機制策略標記清除算法 概念 該算法有兩個階段。 1. 標記階段：找到所有可訪問的對象，做個標記 2. 清除階段：遍歷堆，把未被標記的對象回收 應用場景 該算法一般應用于老年代,因為老年代的對象生命周期比較長。 優缺點 標記清除算法的優點和缺點 1. 優點 - 是可以解決循環引用的問題 - 必要時才回收(內存不足時) 2. 缺點： - 回收時，應用需要掛起，也就是stop the world。 - 標記和清除的效率不高，尤其是要掃描的對象比較多的時候 - 會造成內存碎片(會導致明明有內存空間,但是由于不連續,申請稍微大一些的對象無法做到),復制算法 概念 如果jvm使用了coping算法，一開始就會將可用內存分為兩塊，from域和to域， 每次只是使用from域，to域則空閑著。當from域 內存不夠了，開始執行GC操作，這個時候，會把from域存活的對象拷貝到to域,然后直接把from域進行內存清理。應用場景 coping算法一般是使用在新生代中，因為新生代中的對象一般都是朝生夕死的，存活對象的數量并不多，這樣使用coping算法進行 拷貝時效率比較高。jvm將Heap 內存劃分為新生代與老年代，又將新生代劃分為Eden(伊甸園) 與2塊Survivor Space(幸存者區) , 然后在Eden –>Survivor Space 以及From Survivor Space 與To Survivor Space 之間實行Copying 算法。 不過jvm在應用coping算法時，并不是把內存按照1:1來劃分的，這樣太浪費內存空間了。一般的jvm都是8:1。 也即是說,Eden區:From區:To區域的比例是始終有90%的空間是可以用來創建對象的,而剩下的10%用來存放回收后存活的對象。1、當Eden區滿的時候,會觸發第一次young gc,把還活著的對象拷貝到Survivor From區；當Eden區再次觸發young gc的時候, 會掃描Eden區和From區域,對兩個區域進行垃圾回收,經過這次回收后還存活的對象,則直接復制到To區域,并將Eden和From 區域清空。 2、當后續Eden又發生young gc的時候,會對Eden和To區域進行垃圾回收,存活的對象復制到From區域,并將Eden和To區域清空。 3、可見部分對象會在From和To區域中復制來復制去,如此交換15次(由JVM參數MaxTenuringThreshold決定,這個參數默認是15), 最終如果還是存活,就存入到老年代 注意: 萬一存活對象數量比較多，那么To域的內存可能不夠存放，這個時候會借助老年代的空間。 優缺點 優點:在存活對象不多的情況下，性能高，能解決內存碎片和java垃圾回收算法之-標記清除 中導致的引用更新問題。 缺點: 會造成一部分的內存浪費。不過可以根據實際情況，將內存塊大小比例適當調整；如果存活對象的數量比較大， coping的性能會變得很差。 標記壓縮算法 標記清除算法和標記壓縮算法非常相同，但是標記壓縮算法在標記清除算法之上解決內存碎片化 概念壓縮算法簡單介紹 任意順序 : 即不考慮原先對象的排列順序，也不考慮對象之間的引用關系，隨意移動對象； 線性順序 : 考慮對象的引用關系，例如a對象引用了b對象，則盡可能將a和b移動到一塊； 滑動順序 : 按照對象原來在堆中的順序滑動到堆的一端。 優缺點 優點:解決內存碎片問題，缺點壓縮階段，由于移動了可用對象，需要去更新引用。 分代算法 概述 這種算法，根據對象的存活周期的不同將內存劃分成幾塊，新生代和老年代，這樣就可以根據各個年代的特點采用最適當的收集算法。 可以用抓重點的思路來理解這個算法。 新生代對象朝生夕死,對象數量多，只要重點掃描這個區域，那么就可以大大提高垃圾收集的效率。另外老年代對象存儲久，無需經常 掃描老年代，避免掃描導致的開銷。 新生代 在新生代，每次垃圾收集器都發現有大批對象死去，只有少量存活，采用復制算法，只需要付出少量存活對象的復制成本就可以完成收集； 可以參看我之前寫的java垃圾回收算法之-coping復制 老年代 而老年代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須“標記－清除-壓縮”算法進行回收。參看java垃圾回收算法之 -標記_清除壓縮 新創建的對象被分配在新生代，如果對象經過幾次回收后仍然存活，那么就把這個對象劃分到老年代。 老年代區存放Young區Survivor滿后觸發minor GC后仍然存活的對象，當Eden區滿后會將存活的對象放入Survivor區域， 如果Survivor區存不下這些對象，GC收集器就會將這些對象直接存放到Old區中，如果Survivor區中的對象足夠老， 也直接存放到Old區中。如果Old區滿了， 將會觸發Full GC回收整個堆內存。 JVM參數配置 JVM提供了諸多的參數進行JVM各個方面內存大小的設置，為Java應用進行優化提供了諸多的工具， 本文將會詳細分析各個參數的功能與使用。 常見參數配置 -XX:+PrintGC 每次觸發GC的時候打印相關日志 -XX:+UseSerialGC 串行回收 -XX:+PrintGCDetails 更詳細的GC日志 -Xms 堆初始值 -Xmx 堆最大可用值 -Xmn 新生代堆最大可用值 -XX:SurvivorRatio 用來設置新生代中eden空間和from/to空間的比例. -XX:NewRatio 配置新生代與老年代占比 1:2 含以-XX:SurvivorRatio=eden/from=den/to 總結:在實際工作中，我們可以直接將初始的堆大小與最大堆大小相等， 這樣的好處是可以減少程序運行時垃圾回收次數，從而提高效率。 -XX:SurvivorRatio 用來設置新生代中eden空間和from/to空間的比例. 堆內存大小配置 使用示例: -Xmx20m -Xms5m 說明： 當下Java應用最大可用內存為20M， 初始內存為5M // byte[] b = new byte[4 * 1024 * 1024]; // System.out.println("分配了4M空間給數組"); System.out.print("最大內存"); System.out.println(Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M"); System.out.print("可用內存"); System.out.println(Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M"); System.out.print("已經使用內存"); System.out.println(Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M");設置新生代比例參數 使用示例:-Xms20m -Xmx20m -Xmn1m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC 說明：堆內存初始化值20m,堆內存最大值20m，新生代最大值可用1m，eden空間和from/to空間的比例為2/1 byte[] b = null; for (int i = 0; i < 10; i++) { b = new byte[1 * 1024 * 1024]; } 設置新生代與老年代比例參數 使用示例: -Xms20m -Xmx20m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC -XX:NewRatio=2 說明：堆內存初始化值20m,堆內存最大值20m，新生代最大值可用1m，eden空間和from/to空間的比例為2/1 新生代和老年代的占比為1/2實戰OutOfMemoryError異常Java堆溢出 錯誤原因: java.lang.OutOfMemoryError: Java heap space 堆內存溢出 解決辦法:設置堆內存大小 // -Xms1m -Xmx10m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError // -Xms1m -Xmx10m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError List<Object> listObject = new ArrayList<>(); for (int i = 0; i < 10; i++) { System.out.println("i:" + i); Byte[] bytes = new Byte[1 * 1024 * 1024]; listObject.add(bytes); } System.out.println("添加成功...");虛擬機棧溢出 錯誤原因: java.lang.StackOverflowError 棧內存溢出 棧溢出 產生于遞歸調用，循環遍歷是不會的，但是循環方法里面產生遞歸調用， 也會發生棧溢出。 解決辦法:設置線程最大調用深度 -Xss5m 設置最大調用深度 public class JvmDemo04 {private static int count;public static void count(){try {count++;count(); } catch (Throwable e) {System.out.println("最大深度:"+count);e.printStackTrace();}}public static void main(String[] args) {count();} }內存溢出與內存泄漏區別 Java內存泄漏就是沒有及時清理內存垃圾，導致系統無法再給你提供內存資源（內存資源耗盡）； 而Java內存溢出就是你要求分配的內存超出了系統能給你的，系統不能滿足需求，于是產生溢出。 內存溢出，這個好理解，說明存儲空間不夠大。就像倒水倒多了，從杯子上面溢出了來了一樣。 內存泄漏，原理是，使用過的內存空間沒有被及時釋放，長時間占用內存，最終導致內存空間不足，而出現內存溢出。垃圾收集器 串行與并行收集器 串行回收: JDK1.5前的默認算法 缺點是只有一個線程，執行垃圾回收時程序停止的時間比較長 并行回收: 多個線程執行垃圾回收適合于吞吐量的系統，回收時系統會停止運行serial收集器 串行收集器是最古老，最穩定以及效率高的收集器，可能會產生較長的停頓，只使用一個線程去回收。新生代、老年代使用串行回收； 新生代復制算法、老年代標記-壓縮；垃圾收集的過程中會Stop The World（服務暫停）一個單線程的收集器，在進行垃圾收集時候，必須暫停其他所有的工作線程直到它收集結束。 特點：CPU利用率最高，停頓時間即用戶等待時間比較長。 適用場景：小型應用 通過JVM參數-XX:+UseSerialGC可以使用串行垃圾回收器。ParNew收集器ParNew收集器其實就是Serial收集器的多線程版本。新生代并行，老年代串行；新生代復制算法、老年代標記-壓縮 參數控制：-XX:+UseParNewGC ParNew收集器 -XX:ParallelGCThreads 限制線程數量 parallel 收集器 Parallel Scavenge收集器類似ParNew收集器，Parallel收集器更關注系統的吞吐量。可以通過參數來打開自適應調節策略， 虛擬機會根據當前系統的運行情況收集性能監控信息，動態調整這些參數以提供最合適的停頓時間或最大的吞吐量； 也可以通過參數控制GC的時間不大于多少毫秒或者比例；新生代復制算法、老年代標記-壓縮采用多線程來通過掃描并壓縮堆 特點：停頓時間短，回收效率高，對吞吐量要求高。 適用場景：大型應用，科學計算，大規模數據采集等。 通過JVM參數 XX:+USeParNewGC 打開并發標記掃描垃圾回收器。cms收集器 CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。 目前很大一部分的Java應用都集中在互聯網站或B/S系統的服務端上，這類應用尤其重視服務的響應速度， 希望系統停頓時間最短，以給用戶帶來較好的體驗。從名字（包含“Mark Sweep”）上就可以看出 CMS收集器是基于“標記-清除”算法實現的，它的運作過程相對于前面幾種收集器來說要更復雜一些， 整個過程分為4個步驟，包括： 初始標記（CMS initial mark） 并發標記（CMS concurrent mark） 重新標記（CMS remark） 并發清除（CMS concurrent sweep） 其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GC Roots能直接關聯到的對象， 速度很快，并發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正并發標記期間，因用戶程序繼續 運作而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比并發標記的時間短。 由于整個過程中耗時最長的并發標記和并發清除過程中，收集器線程都可以與用戶線程一起工作，所以總體上來說，CMS收集器的內存回收過程是與用戶線程一起并發地執行。老年代收集器（新生代使用ParNew）優點:并發收集、低停頓 缺點：產生大量空間碎片、并發階段會降低吞吐量采用“標記-清除”算法實現，使用多線程的算法去掃描堆，對發現未使用的對象進行回收。 （1）初始標記 （2）并發標記 （3）并發預處理 （4）重新標記 （5）并發清除 （6）并發重置 特點：響應時間優先，減少垃圾收集停頓時間 適應場景：大型服務器等。 通過JVM參數 -XX:+UseConcMarkSweepGC設置 g1收集器 在G1中，堆被劃分成 許多個連續的區域(region)。采用G1算法進行回收，吸收了CMS收集器特點。 特點：支持很大的堆，高吞吐量--支持多CPU和垃圾回收線程--在主線程暫停的情況下，使用并行收集--在主線程運行的情況下，使用并發收集 實時目標：可配置在N毫秒內最多只占用M毫秒的時間進行垃圾回收 通過JVM參數 -XX:+UseG1GC 使用G1垃圾回收器 注意: 并發是指一個處理器同時處理多個任務。 并行是指多個處理器或者是多核的處理器同時處理多個不同的任務。 并發是邏輯上的同時發生（simultaneous），而并行是物理上的同時發生。 來個比喻：并發是一個人同時吃三個饅頭，而并行是三個人同時吃三個饅頭。 Tomcat配置調優測試 Jmeter壓力測試工具 JMeter是一款在國外非常流行和受歡迎的開源性能測試工具，像LoadRunner 一樣，它也提供了一個利用本地Proxy Server （代理服務器）來錄制生成測試腳本的功能，但是這個功能并不好用。所以在本文中介紹一個更為常用的方法——使用 Badboy錄制生成 JMeter 腳本。簡單的介紹一下Badboy。Badboy是一款不錯的Web自動化測試工具，如果你將它用于非商業用途， 或者用于商業用途但是安裝Badboy 的機器數量不超過5臺，你是不需要為它支付任何費用的。也許是一種推廣策略， Badboy提供了將Web測試腳本直接導出生成JMeter 腳本的功能， 并且這個功能非常好用，也非常簡單。你可以跟著下面的試驗步驟來邁出你在開源世界的第一步。 1. 通過Badboy的官方網站下載Badboy的最新版本； 2. 安裝Badboy。安裝過程同一般的Windows 應用程序沒有什么區別，安裝完成后你可以在桌面和Windows開始菜單中 看到相應的快捷方式——如果找不到，可以找一下Badboy安裝目錄下的Badboy.exe 文件，直接雙擊啟動Badboy； 3. 啟動Badboy，你可以看到下面的界面。在地址欄（圖中紅色方框標注的部分）中輸入你需要錄制的Web應用的URL——這里我們以http://www.yahoo.com 為例， 并點擊GO 按鈕開始錄制。如果你用過LoadRunner之類的商業工具，對于這個操作一定不會陌生吧 ^_^ 4. 開始錄制后，你可以直接在Badboy內嵌的瀏覽器（主界面的右側）中對被測應用進行操作，所有的操作都會被記錄在 主界面左側的編輯窗口中——在這個試驗中，我們在Yahoo的搜索引擎中輸入 JMeter 進行搜索。不過你將看到，錄制下來的腳本 并不是一行行的代碼， 而是一個個Web對象——這就有點像LoadRunner的VuGen中的Tree View視圖； 5. 錄制完成后，點擊工具欄中的“停止錄制”按鈕，完成腳本的錄制； 6. 選擇“File -> Export to JMeter”菜單，填寫文件名“login_mantis.jmx”，將錄制好腳本導出為JMeter腳本格式。 也可以選擇“File -> Save”菜單保存為Badboy腳本； 7. 啟動JMeter并打開剛剛生成的測試腳本。 也許你已經急不可待的準備開始嘗試著用JMeter處理你手頭的工作了^_^ 在下面的幾節，我將繼續為大家介紹如何在 JMeter 中完成一個測試場景的設置和JMeter測試結果分析入門，以及如何參數化JMeter腳本。 當然，如果你的動手能力很強，幾分鐘你就可以熟悉這些內容。不過還是請允許我一點點由淺入深的來幫大家完成“JMeter 從入門到精通”的過程。 我相信在這個過程中你將會了解到更多有關性能測試的知識和經驗，甚至包括一些LoadRunner等商業測試工具所無法提供給 你的經驗。 什么是吞吐量 QPS：Queries Per Second意思是“每秒查詢率”，是一臺服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在 規定時間內所處理 流量多少的衡量標準。 測試串行吞吐量 -XX:+PrintGCDetails -Xmx32M -Xms1M -XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC -XX:PermSize=32M GC 回收次數25次 吞吐量4662 堆的初始值和堆的最大一致 加大初始堆內存大小-Xms1M 修改為32mGC 回收次數7次 吞吐量5144擴大堆的內存 -XX:+PrintGCDetails -Xmx512M -Xms32M -XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC -XX:PermSize=32MGC 回收次數6次 吞吐量5141 結論:垃圾回收次數和設置最大堆內存大小無關，只和初始內存有關系。 初始內存會影響吞吐量。調整初始堆 -XX:+PrintGCDetails -Xmx512M –Xms512M -XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC -XX:PermSize=32M GC回收次數0次 吞吐量6561次 結論：堆的初始值和最大堆內存一致，并且初始堆越大就會高。并行回收（UseParNewGC） -XX:+PrintGCDetails -Xmx512M -Xms512M -XX:+HeapDumpOnOutOfMemoryError -XX:+UseParNewGC -XX:PermSize=32M GC回收0次 吞吐量6800CMS收集器 -XX:+PrintGCDetails -Xmx512M -Xms512M -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:PermSize=32MG1回收方式 -XX:+PrintGCDetails -Xmx512M -Xms512M -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:PermSize=32M調優總結 初始堆值和最大堆內存內存越大，吞吐量就越高。 最好使用并行收集器,因為并行收集器速度比串行吞吐量高，速度快。 設置堆內存新生代的比例和老年代的比例最好為1:2或者1:3。 減少GC對老年代的回收。垃圾回收策略 理解gc日志 Minor GC和Full GC區別 概念：新生代 GC（Minor GC）：指發生在新生代的垃圾收集動作，因為 Java 對象大多都具 備朝生夕滅的特性，所以 Minor GC 非常頻繁，一般回收速度也比較快。老年代 GC（Major GC / Full GC）：指發生在老年代的 GC，出現了 Major GC，經常 會伴隨至少一次的 Minor GC（但非絕對的，在 ParallelScavenge 收集器的收集策略里 就有直接進行 Major GC 的策略選擇過程） 。MajorGC 的速度一般會比 Minor GC 慢 10 倍以上。 Minor GC觸發機制： 當年輕代滿時就會觸發Minor GC，這里的年輕代滿指的是Eden代滿，Survivor滿不會引發GCFull GC觸發機制： 當年老代滿時會引發Full GC，Full GC將會同時回收年輕代、年老代，當永久代滿時也會引發Full GC，會導致Class、Method 元信息的卸載其Minor 如下圖所示 虛擬機給每個對象定義了一個對象年齡（Age）計數器。如果對象在 Eden 出生并經過第一次 Minor GC 后仍然存活， 并且能被 Survivor 容納的話，將被移動到 Survivor 空間中，并將對象年齡設為 1。對象在 Survivor 區中每熬過一次 Minor GC，年齡就增加 1 歲，當它的年齡增加到一定程度（默認為 15 歲）時，就會被晉升到老年代中。 對象晉升老年代的年齡閾值，可以通過參數 -XX:MaxTenuringThreshold (閾值)來設置。 JVM的永久代中會發生垃圾回收么？ 垃圾回收不會發生在永久代，如果永久代滿了或者是超過了臨界值，會觸發完全垃圾回收(Full GC)。如果你仔細查看 垃圾收集器的輸出信息，就會發現永久代也是被回收的。這就是為什么正確的永久代大小對避免Full GC是非常重要的原因。 請參考下Java8：從永久代到元數據區 (注：Java8中已經移除了永久代，新加了一個叫做元數據區的native內存區) 對象優先在eden分配 大多數情況下，對象在新生代Eden區中分配。當Eden區沒有足夠的空間進行分配時，虛擬機將發起一次Minor GC。 虛擬機提供了-XX:+PrintGCDetails這個收集器日志參數，告訴虛擬機在發生垃圾收集行為時打印內存回收日志， 并且在進程退出的時候輸出當前內存各區域的分配情況。在實際應用中，內存回收日志一般是打印到文件后通過日志工具進行分析， 不過本實驗的日志并不多， 直接閱讀就能看得很清楚。public class Test00010 {private static final int _1MB = 1024 * 1024;// -Xms20m -Xmx20m -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails// -XX:+UseSerialGCpublic static void main(String[] args) {testAllocation();}public static void testAllocation() {byte[] allocation1, allocation2, allocation3, allocation4;allocation1 = new byte[2 * _1MB];allocation2 = new byte[2 * _1MB];allocation3 = new byte[2 * _1MB];allocation4 = new byte[4 * _1MB]; // 出現一次Minor GC} }大對象直接進入老年代 長期存活的對象將進入老年代 動態對象年齡判斷 空間分配擔保理解GC日志JDK命令行工具JDK可視化工具 垃圾收集器

?

總結

以上是生活随笔為你收集整理的Java内存结构与垃圾回收机制算法分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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