架構師成長之路：如何保證消息隊列的高可用

問題一：描述一下 JVM 的內存區域

程序計數器（PC，Program Counter Register）。在 JVM 規範中，每一個線程都有它本身的程序計數器，而且任什麼時候間一個線程都只有一個方法在執行，也就是所謂的當前方法。程序計數器會存儲當前線程正在執行的 Java 方法的 JVM 指令地址；或者，若是是在執行本地方法，則是未指定值（undefined）。

Java 虛擬機棧（Java Virtual Machine Stack），早期也叫 Java 棧。每一個線程在建立時都會建立一個虛擬機棧，其內部保存一個個的棧幀（Stack Frame），對應着一次次的 Java 方法調用。前面談程序計數器時，提到了當前方法；同理，在一個時間點，對應的只會有一個活動的棧幀，一般叫做當前幀，方法所在的類叫做當前類。若是在該方法中調用了其餘方法，對應的新的棧幀會被建立出來，成爲新的當前幀，一直到它返回結果或者執行結束。JVM 直接對 Java 棧的操做只有兩個，就是對棧幀的壓棧和出棧。棧幀中存儲着局部變量表、操做數（operand）棧、動態連接、方法正常退出或者異常退出的定義等。

堆（Heap），它是 Java 內存管理的核心區域，用來放置 Java 對象實例，幾乎全部建立的Java 對象實例都是被直接分配在堆上。堆被全部的線程共享，在虛擬機啓動時，咱們指定的「Xmx」之類參數就是用來指定最大堆空間等指標。理所固然，堆也是垃圾收集器重點照顧的區域，因此堆內空間還會被不同的垃圾收集器進行進一步的細分，最有名的就是新生代、老年代的劃分。

方法區（Method Area）。這也是全部線程共享的一塊內存區域，用於存儲所謂的元（Meta）數據，例如類結構信息，以及對應的運行時常量池、字段、方法代碼等。因爲早期的 Hotspot JVM 實現，不少人習慣於將方法區稱爲永久代（Permanent Generation）。Oracle JDK 8 中將永久代移除，同時增長了元數據區（Metaspace）。

運行時常量池（Run-Time Constant Pool），這是方法區的一部分。若是仔細分析過反編譯的類文件結構，你能看到版本號、字段、方法、超類、接口等各類信息，還有一項信息就是常量池。Java 的常量池能夠存放各類常量信息，不管是編譯期生成的各類字面量，仍是須要在運行時決定的符號引用，因此它比通常語言的符號表存儲的信息更加寬泛。

本地方法棧（Native Method Stack）。它和 Java 虛擬機棧是很是類似的，支持對本地方法的調用，也是每一個線程都會建立一個。在 Oracle Hotspot JVM 中，本地方法棧和 Java 虛擬機棧是在同一起區域，這徹底取決於技術實現的決定，並未在規範中強制。

問題二：形成OOM的緣由有哪幾種？

堆內存不足是最多見的 OOM 緣由之一，拋出的錯誤信息是「java.lang.OutOfMemoryError:Java heap space」，緣由可能千奇百怪，例如，可能存在內存泄漏問題；也頗有可能就是堆的大小不合理，好比咱們要處理比較可觀的數據量，可是沒有顯式指定 JVM 堆大小或者指定數值偏小；或者出現 JVM 處理引用不及時，致使堆積起來，內存沒法釋放等。

虛擬機棧和本地方法棧，這里要稍微複雜一點。若是咱們寫一段程序不斷的進行遞歸調用，並且沒有退出條件，就會致使不斷地進行壓棧。相似這種狀況，JVM 實際會拋出StackOverFlowError；固然，若是 JVM 試圖去擴展棧空間的的時候失敗，則會拋出OutOfMemoryError。

對於老版本的 Oracle JDK，由於永久代的大小是有限的，而且 JVM 對永久代垃圾回收（如，常量池回收、卸載不再須要的類型）很是不積極，因此當咱們不斷添加新類型的時候，永久代出現OutOfMemoryError 也很是多見，尤爲是在運行時存在大量動態類型生成的場合；相似 Intern 字符串緩存佔用太多空間，也會致使 OOM 問題。對應的異常信息，會標記出來和永久代相關：「java.lang.OutOfMemoryError: PermGenspace

問題三：GC 算法

複製（Copying）算法，我前面講到的新生代 GC，基本都是基於複製算法，將活着的對象複製到 to 區域，拷貝過程當中將對象順序放置，就能夠避免內存碎片化。這麼作的代價是，既然要進行複製，既要提早預留內存空間，有必定的浪費；另外，對於 G1 這種分拆成爲大量 region 的 GC，複製而不是移動，意味着 GC 須要維護 region 之間對象引用關係，這個開銷也不小，不管是內存佔用或者時間開銷。

標記 - 清除（Mark-Sweep）算法，首先進行標記工做，標識出全部要回收的對象，而後進行清除。這麼作除了標記、清除過程效率有限，另外就是不可避免的出現碎片化問題，這就致使其不適合特別大的堆；不然，一旦出現 Full GC，暫停時間可能根本沒法接受。

標記 - 整理（Mark-Compact），相似於標記 - 清除，但爲避免內存碎片化，它會在清理過程當中將對象移動，以確保移動後的對象佔用連續的內存空間。

問題四： G1 垃圾回收器採用的是什麼垃圾回收算法？

從 GC 算法的角度，G1 選擇的是複合算法，能夠簡化理解爲：

在新生代，G1 採用的仍然是並行的複製算法，因此一樣會發生 Stop-The-World 的暫停。

在老年代，大部分狀況下都是併發標記，而整理（Compact）則是和新生代 GC 時捎帶進行，而且不是總體性的整理，而是增量進行的。

問題五：GC 調優思路

從性能的角度看，一般關注三個方面，內存佔用（footprint）、延時（latency）和吞吐量（throughput），大多數狀況下調優會側重於其中一個或者兩個方面的目標，不多有狀況能夠兼顧三個不同的角度。固然，除了上面一般的三個方面，也可能須要考慮其餘 GC 相關的場景，例如，OOM 也可能與不合理的 GC 相關參數有關；或者，應用啓動速度方面的需求，GC 也會是個考慮的方面。 基本的調優思路能夠總結爲：

理解應用需求和問題，肯定調優目標。假設，咱們開發了一個應用服務，但發現偶爾會出現性能抖動，出現較長的服務停頓。評估用戶可接受的響應時間和業務量，將目標簡化爲，但願 GC 暫停盡量控制在 200ms 之內，而且保證必定標準的吞吐量。

掌握 JVM 和 GC 的狀態，定位具體的問題，肯定真的有 GC 調優的必要。具體有不少方法，好比，經過 jstat 等工具查看 GC 等相關狀態，能夠開啓 GC 日誌，或者是利用操做系統提供的診斷工具等。例如，經過追蹤 GC 日誌，就能夠查找是不是 GC 在特定時間發生了長時間的暫停，進而致使了應用響應不及時。

選擇的 GC 類型是否符合咱們的應用特徵，若是是，具體問題表如今哪里，是 Minor GC 過長，仍是 Mixed GC 等出現異常停頓狀況；若是不是，考慮切換到什麼類型，如 CMS 和 G1 都是更側重於低延遲的 GC 選項。

經過分析肯定具體調整的參數或者軟硬件配置。驗證是否達到調優目標，若是達到目標，便可以考慮結束調優；不然，重複完成分析、調整、驗證這 個過程。

問題六：如何提升JVM的性能？

新對象預留在年輕代 經過設置一個較大的年輕代預留新對象，設置合理的 Survivor 區而且提供 Survivor 區的使用率，能夠將年輕對象保存在年輕代。

大對象進入年老代 使用參數-XX:PetenureSizeThreshold 設置大對象直接進入年老代的閾值

設置對象進入年老代的年齡 這個閾值的最大值能夠經過參數-XX:MaxTenuringThreshold 來設置，默認值是 15

穩定的 Java 堆 得到一個穩定的堆大小的方法是使-Xms 和-Xmx 的大小一致，即最大堆和最小堆 (初始堆) 同樣。

增大吞吐量提高系統性能 –Xmx380m –Xms3800m：設置 Java 堆的最大值和初始值。通常狀況下，爲了不堆內存的頻繁震盪，致使系統性能降低，咱們的作法是設置最大堆等於最小堆。假設這裏把最小堆減小爲最大堆的一半，即 1900m，那麼 JVM 會盡量在 1900MB 堆空間中運行，若是這樣，發生 GC 的可能性就會比較高； -Xss128k：減小線程棧的大小，這樣可使剩餘的系統內存支持更多的線程； -Xmn2g：設置年輕代區域大小爲 2GB； –XX:+UseParallelGC：年輕代使用並行垃圾回收收集器。這是一個關注吞吐量的收集器，能夠儘量地減小 GC 時間。 –XX:ParallelGC-Threads：設置用於垃圾回收的線程數，一般狀況下，能夠設置和 CPU 數量相等。但在 CPU 數量比較多的狀況下，設置相對較小的數值也是合理的； –XX:+UseParallelOldGC：設置年老代使用並行回收收集器。

嘗試使用大的內存分頁 –XX:+LargePageSizeInBytes：設置大頁的大小。 內存分頁 (Paging) 是在使用 MMU 的基礎上，提出的一種內存管理機制。它將虛擬地址和物理地址按固定大小（4K）分割成頁 (page) 和頁幀 (page frame)，並保證頁與頁幀的大小相同。這種機制，從數據結構上，保證了訪問內存的高效，並使 OS 能支持非連續性的內存分配。

使用非佔有的垃圾回收器 爲下降應用軟件的垃圾回收時的停頓，首先考慮的是使用關注系統停頓的 CMS 回收器，其次，爲了減小 Full GC 次數，應儘量將對象預留在年輕代。

問題七：system.gc() 的做用是什麼？

問題八：JVM類加載過程

問題九：類加載器的類型

問題十一：上下文類加載器

問題十二：自定義類加載器

問題十三：動態代理的原理

問題十四:動態代理：JDK動態代理和CGLIB代理的區別？

問題十五：CGlib比JDK快？

總結

因爲篇幅過長的緣由，爲了避免影響你們的閱讀效果，文中沒有給到全部的答案。我這裏以文件的形式整理好了，須要借閱的程序員朋友能夠免費來領取。還有個人JVM學習筆記Xmind文件也免費分享給有須要朋友！（縮略圖未展開）

 

分享免費架構學習資料

 

歡迎工做一到五年的Java工程師朋友們加入Java高級架構：705127209

裏面提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）

合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！