JVM相關知識

• 記憶體結構
•         第一部分:

• • 編譯器(將.java源檔案編譯為.class檔案)
  • 類加載器
    • 類加載實際上包括三部分:
      • 懶加載
      • 鏈接
      • 懶初始化
  • 第二部分:
    • 方法區(執行緒公有)：方法區實際上是JVM的一種規范，它在HotSpot虛擬機(HSDB，Hotspot Debugger除錯工具)中,在1.7之間存在于永久代中，在1.8中存在于元空間中,使用本地記憶體對這些資訊進行存盤
    • 堆記憶體(執行緒公有)：jvm調優的重點區域，jvm引數  -Xmx -Xms   -Xmn .主要分為伊甸園、幸存區（from、to）、老年代.   Minor GC、Mixed GC、Full GC
    • 程式計數器(執行緒私有)：程式計數器是唯一一個不存在記憶體溢位或記憶體泄漏的區域
    • 虛擬機堆疊(執行緒私有):虛擬機堆疊采用了堆疊的思想，分為多個堆疊幀，每一個堆疊幀對應一個方法，
      • 虛擬機堆疊中存在的記憶體泄漏有回圈終止條件沒有設計好，或者單個堆疊幀運行所需的空間足夠大
      • 本地方法堆疊(執行緒私有)：本地方法堆疊對應本地方法介面，呼叫本地方法中的引數，
  • 第三部分：執行引擎
    • 解釋器：將.class位元組碼檔案解釋為計算機運行的機器碼
    • 即時編譯器(JIT):即時編譯器會對熱點代碼的執行進行優化，并將優化后的存放在快取中
    • GC垃圾回收器:JVM調優的根本，Gc大大地解放了程式員自身對于記憶體的管理，但仍存在一些問題，
  • 第四部分: 本地方法介面(作業系統、C++實作)
• 記憶體模型
  • 記憶體模型實際上是jvm在多執行緒下和cpu之間互動的一種設計思想，主要體現為作業系統中的主記憶體和每個執行緒之間的高速緩沖區.第一次會從作業系統中讀到高速快取區中，下一次則直接從高速緩沖區中讀取，但是進行寫操作需要更新主記憶體后即時地更新(或洗掉)高速緩沖區的資料
• 類加載器、雙親委派機制
  • 類加載器包括引導類加載器（根類加載器  / jre/lib包下）、擴展類加載器（/jre/lib/ext）、應用程式類加載器（/classpath）、自定義類加載器，
  • 雙親委派模型指的是加載類時，向上拋出，逐個加載直到能夠加載則停止
• 垃圾回收GC
  • 3種垃圾回收演算法
    • 標記清除（速度快、會有記憶體碎片產生、現在的垃圾回收器已經棄用）
    • 標記整理(速度慢、沒有記憶體碎片產生)
    • 標記復制(沒有記憶體碎片產生、但是記憶體占用較大，且其中一份記憶體始終不存盤資料)
  • 3種垃圾回收器
    • Parallel并行，注重吞吐量
    • CMS(Concurrent Modify Sweep)垃圾回收(使用標記清除),該回收器已經被棄用,注重回應時間，
    • G1垃圾回收器，同時注重了吞吐量和回應時間
      • 把堆記憶體分為很多大小相等的記憶體空間(64份???)，每一份都能作為伊甸園、幸存區(合并了from to)、老年代
• 四種參考
  • GC root、可達性分析、三色標記演算法（標記過的、沒有被標記的，正在進行分析標記的）
    • 強參考：被強參考，即普通的new一個物件的參考在垃圾回收時，是不會被回收的，(包括直接飲用的其內部的成員變數)
    • 軟參考:  在第一次垃圾回收時，不會被回收，當再次垃圾回收的時候，就會被回收
    • 弱參考: 在第一次進行垃圾回收的時候，就會被回收，
    • 虛參考：在第一次進行垃圾回收的時候，就會被回收，
    • 參考佇列：對于軟參考、弱參考和虛參考來說，其創建的中間參考物件都可以加入到參考佇列中，然后開啟一個單獨的執行緒處理該參考佇列，其中虛參考是必須強制使用參考佇列的，
    • ThreadLocal的記憶體泄漏和弱參考：
      • ThreadLocal中的key被設計為弱參考，因此其key可以被進行垃圾回收，但是回收之后，我們就存在無法根據key去手動remove其對應的value，而value卻是強參考，此時就存在記憶體泄漏問題，
      • 其解決思路是：
      • 1.在使用完畢后，及時的手動移除value
      • 2.將弱參考加入到參考佇列中，其中存盤的是ThreadLocalMap中的Entry物件，通過將Entry物件置為null，實作key和value都被回收，
      • 3.Jdk9中對于2的實作原理進行了優化和封裝，使用Cleaner物件（運行時是一個守護執行緒）
• finalize方法剖析
  • • finalize
      • 它是 Object 中的一個方法，如果子類重寫它，垃圾回收時此方法會被呼叫，可以在其中進行資源釋放和清理作業.
      • 但是將資源釋放和清理放在 finalize 方法中非常不好，非常影響性能，嚴重時甚至會引起 OOM，從 Java9 開始就被標注為 @Deprecated，不建議被使用了
      • finalize 原理
        • 對 finalize 方法進行處理的核心邏輯位于 java.lang.ref.Finalizer 類中，它包含了名為 unfinalized 的靜態變數（雙向鏈表結構），Finalizer 也可被視為另一種參考物件（地位與軟、弱、虛相當，只是不對外，無法直接使用）
        • 當重寫了 finalize 方法的物件，在構造方法呼叫之時，JVM 都會將其包裝成一個 Finalizer 物件，并加入 unfinalized 鏈表中
          • Finalizer 類中還有另一個重要的靜態變數，即 ReferenceQueue 參考佇列，剛開始它是空的，當狗物件可以被當作垃圾回收時，就會把這些狗物件對應的 Finalizer 物件加入此參考佇列
          • 但此時 Dog 物件還沒法被立刻回收，因為 unfinalized -> Finalizer 這一參考鏈還在參考它嘛，為的是【先別著急回收啊，等我調完 finalize 方法，再回收】
          • FinalizerThread 執行緒會從 ReferenceQueue 中逐一取出每個 Finalizer 物件，把它們從鏈表斷開并真正呼叫 finallize 方法
          • 由于整個 Finalizer 物件已經從 unfinalized 鏈表中斷開，這樣就會在下次 gc 時就被回收了
      • finalize 缺點
        • 無法保證資源釋放：FinalizerThread 是守護執行緒，代碼很有可能沒來得及執行完，執行緒就結束了
        • 無法判斷是否發生錯誤：執行 finalize 方法時，會吞掉任意例外（Throwable）
        • 記憶體釋放不及時：重寫了 finalize 方法的物件在第一次被 gc 時，并不能及時釋放它占用的記憶體，因為要等著 FinalizerThread 呼叫完 finalize，把它從 unfinalized 佇列移除后，第二次 gc 時才能真正釋放記憶體
        • 有的文章提到【Finalizer 執行緒會和我們的主執行緒進行競爭，不過由于它的優先級較低，獲取到的CPU時間較少，因此它永遠也趕不上主執行緒的步伐】這個顯然是錯誤的，FinalizerThread 的優先級較普通執行緒更高，原因應該是 finalize 串行執行慢等原因綜合導致
• 記憶體溢位的幾種情況
  • 典型情況
    • 誤用執行緒池導致的記憶體溢位
      • 使用了不推薦的執行緒池創建
        • 固定執行緒數的執行緒池(Executors.newFixedThreadPool,其中的作業佇列是近似沒有上限的(Integer的最大值))
        • 帶有快取的執行緒池(Executors.newCachedThreadPool,其中的核心執行緒數為0，全部都是救濟執行緒（Integer的最大值）
      • 單次查詢資料量太大（禁止呼叫查詢全表的資料介面）導致的記憶體溢位，進行分頁查詢(limit)
      • 動態生成類導致的記憶體溢位(動態生成的類使用了自定義的類加載器，其中的靜態成員變數是強參考，不能被垃圾回收，應該將靜態變數修改為成員變數)

標籤：Java

上一篇：分庫分表ShardingJDBC最佳實踐

下一篇：手擼圖片壓縮工具