Java提升篇——JVM加載class文件的原理機制

  在面試java工程師的時候，這道題常常被問到，故需特別注意。

一、JVM 簡介

　　JVM 是咱們Javaer 的最基本功底了，剛開始學Java 的時候，通常都是從「Hello World 」開始的，而後會寫個複雜點class ，而後再找一些開源框架，好比Spring ，Hibernate 等等，再而後就開發企業級的應用，好比網站、企業內部應用、實時交易系統等等，直到某一天忽然發現作的系統咋就這麼慢呢，並且時不時還來個內存溢出什麼的，今天是交易系統報了StackOverflowError ，明天是網站系統報了個OutOfMemoryError ，這種錯誤又很難重現，只有分析Javacore 和dump 文件，運氣好點還能分析出個結果，運行遭的點，就直接去廟裏燒香吧！天天接客戶的電話都是戰戰兢兢的，生怕再出什麼幺蛾子了。我想Java 作的久一點的都有這樣的經歷，那這些問題的最終根結是在哪呢？—— JVM 。

　　JVM 全稱是Java Virtual Machine ，Java 虛擬機，也就是在計算機上再虛擬一個計算機，這和咱們使用 VMWare不同，那個虛擬的東西你是能夠看到的，這個JVM 你是看不到的，它存在內存中。咱們知道計算機的基本構成是：運算器、控制器、存儲器、輸入和輸出設備，那這個JVM 也是有這成套的元素，運算器是固然是交給硬件CPU 還處理了，只是爲了適應「一次編譯，隨處運行」的狀況，須要作一個翻譯動做，因而就用了JVM 本身的命令集，這與彙編的命令集有點相似，每一種彙編命令集針對一個系列的CPU ，好比8086 系列的彙編也是能夠用在8088 上的，可是就不能跑在8051 上，而JVM 的命令集則是能夠處處運行的，由於JVM 作了翻譯，根據不一樣的CPU ，翻譯成不一樣的機器語言。

　　JVM 中咱們最須要深刻理解的就是它的存儲部分，存儲？硬盤？NO ，NO ， JVM 是一個內存中的虛擬機，那它的存儲就是內存了，咱們寫的全部類、常量、變量、方法都在內存中，這決定着咱們程序運行的是否健壯、是否高效，接下來的部分就是重點介紹之。

二、JVM 的組成部分

咱們先把JVM 這個虛擬機畫出來，以下圖所示：

 

從這個圖中能夠看到，JVM 是運行在操做系統之上的，它與硬件沒有直接的交互。咱們再來看下JVM 有哪些組成部分，以下圖所示：

該圖參考了網上廣爲流傳的JVM 構成圖，你們看這個圖，整個JVM 分爲四部分：

## Class Loader 類加載器 

類加載器的做用是加載類文件到內存，好比編寫一個HelloWord.java 程序，而後經過javac 編譯成class 文件，那怎麼才能加載到內存中被執行呢？Class Loader 承擔的就是這個責任，那不可能隨便創建一個.class 文件就能被加載的，Class Loader 加載的class 文件是有格式要求，在《JVM Specification 》中式這樣定義Class 文件的結構：

  ClassFile {
      u4 magic;
      u2 minor_version;
       u2 major_version;
      u2 constant_pool_count;
      cp_info constant_pool[constant_pool_count-1];
      u2 access_flags;
      u2 this_class;
      u2 super_class;
      u2 interfaces_count;
      u2 interfaces[interfaces_count];
      u2 fields_count;
      field_info fields[fields_count];
      u2 methods_count;
      method_info methods[methods_count];
      u2 attributes_count;
      attribute_info attributes[attributes_count];
    }

須要詳細瞭解的話，能夠仔細閱讀《JVM Specification 》的第四章「The class File Format 」，這裏再也不詳細說明。

友情提示：Class Loader 只管加載，只要符合文件結構就加載，至於說能不能運行，則不是它負責的，那是由Execution Engine 負責的。

## Execution Engine 執行引擎 

執行引擎也叫作解釋器(Interpreter) ，負責解釋命令，提交操做系統執行。

## Native Interface 本地接口

本地接口的做用是融合不一樣的編程語言爲Java 所用，它的初衷是融合C/C++ 程序，Java 誕生的時候是C/C++ 橫行的時候，要想立足，必須有一個聰明的、睿智的調用C/C++ 程序，因而就在內存中專門開闢了一塊區域處理標記爲native 的代碼，它的具體作法是Native Method Stack 中登記native 方法，在Execution Engine 執行時加載native libraies 。目前該方法使用的是愈來愈少了，除非是與硬件有關的應用，好比經過Java 程序驅動打印機，或者Java 系統管理生產設備，在企業級應用中已經比較少見，由於如今的異構領域間的通訊很發達，好比可使用Socket 通訊，也可使用Web Service 等等，很少作介紹。

## Runtime data area 運行數據區 

運行數據區是整個JVM 的重點。咱們全部寫的程序都被加載到這裏，以後纔開始運行，Java 生態系統如此的繁榮，得益於該區域的優良自治。

 

整個JVM 框架由加載器加載文件，而後執行器在內存中處理數據，須要與異構系統交互是能夠經過本地接口進行，瞧，一個完整的系統誕生了！

三、JVM加載class文件的原理機制 

　　 Java中的全部類，都須要由類加載器裝載到JVM中才能運行。類加載器自己也是一個類，而它的工做就是把class文件從硬盤讀取到內存中。在寫程序的時候，咱們幾乎不須要關心類的加載，由於這些都是隱式裝載的，除非咱們有特殊的用法，像是反射，就須要顯式的加載所須要的類。

　　類裝載方式，有兩種 
    　　1.隱式裝載， 程序在運行過程當中當碰到經過new 等方式生成對象時，隱式調用類裝載器加載對應的類到jvm中，
    　　2.顯式裝載， 經過class.forname()等方法，顯式加載須要的類 
  　　隱式加載與顯式加載的區別：二者本質是同樣? 

     Java類的加載是動態的，它並不會一次性將全部類所有加載後再運行，而是保證程序運行的基礎類(像是基類)徹底加載到jvm中，至於其餘類，則在須要的時候才加載。這固然就是爲了節省內存開銷。

  　Java的類加載器有三個，對應Java的三種類:（java中的類大體分爲三種：   1.系統類   2.擴展類 3.由程序員自定義的類 ）

     Bootstrap Loader  // 負責加載系統類 (指的是內置類，像是String，對應於C#中的System類和C/C++標準庫中的類)
            | 
          - - ExtClassLoader   // 負責加載擴展類(就是繼承類和實現類)
                          | 
                      - - AppClassLoader   // 負責加載應用類(程序員自定義的類)

 三個加載器各自完成本身的工做，但它們是如何協調工做呢？哪個類該由哪一個類加載器完成呢？爲了解決這個問題，Java採用了委託模型機制。

委託模型機制的工做原理很簡單：當類加載器須要加載類的時候，先請示其Parent(即上一層加載器)在其搜索路徑載入，若是找不到，纔在本身的搜索路徑搜索該類。這樣的順序其實就是加載器層次上自頂而下的搜索，由於加載器必須保證基礎類的加載。之因此是這種機制，還有一個安全上的考慮：若是某人將一個惡意的基礎類加載到jvm，委託模型機制會搜索其父類加載器，顯然是不可能找到的，天然就不會將該類加載進來。

      咱們能夠經過這樣的代碼來獲取類加載器:

ClassLoader loader = ClassName.class.getClassLoader();
ClassLoader ParentLoader = loader.getParent();

注意一個很重要的問題，就是Java在邏輯上並不存在BootstrapKLoader的實體！由於它是用C++編寫的，因此打印其內容將會獲得null。
      

前面是對類加載器的簡單介紹，它的原理機制很是簡單，就是下面幾個步驟:

1.裝載:查找和導入class文件;

2.鏈接:

      (1)檢查:檢查載入的class文件數據的正確性;

      (2)準備:爲類的靜態變量分配存儲空間;

      (3)解析:將符號引用轉換成直接引用(這一步是可選的)

3.初始化:初始化靜態變量，靜態代碼塊。

      這樣的過程在程序調用類的靜態成員的時候開始執行，因此靜態方法main()纔會成爲通常程序的入口方法。類的構造器也會引起該動做。