【渣男小四】JVM系列(1)：雙親委派機制和沙箱安全機制

愿你生命中有夠多的云翳，造就一個美好的黃昏

歡迎關注公眾號【渣男小四】，一個喜歡技術更喜歡藝術的青年

一.介紹

JVM 是 Java Virtual Machine(Java 虛擬機)的縮寫,JVM 是一種用于計算設備的規范,它是一個虛構出來的計算機,是通過在實際的計算機上仿真模擬各種計算機功能來實作的，

二.架構和組成

　　JVM所處位置：從下圖可以看出JVM 是運行在作業系統之上的,與硬體沒有直接的互動

JVM結構圖體系

堆（Heap)

Java堆（Java Heap）是Java虛擬機所管理的記憶體中最大的一塊，Java堆是被所有執行緒共享的一塊記憶體區域，在虛擬機啟動時創建，此記憶體區域的唯一目的就是存放物件實體，幾乎所有的物件實體都在這里分配記憶體，Java堆是垃圾收集器管理的主要區域，因此很多時候也被稱做“GC堆”，如果從記憶體回收的角度看，由于現在收集器基本都是采用的分代收集演算法，所以Java堆中還可以細分為：新生代和老年代；再細致一點的有Eden空間、From Survivor空間、To Survivor空間等，根據Java虛擬機規范的規定，Java堆可以處于物理上不連續的記憶體空間中，只要邏輯上是連續的即可，就像我們的磁盤空間一樣，在實作時，既可以實作成固定大小的，也可以是可擴展的，不過當前主流的虛擬機都是按照可擴展來實作的（通過-Xmx和-Xms控制），如果在堆中沒有記憶體完成實體分配，并且堆也無法再擴展時，將會拋出OutOfMemoryError例外，

方法區（Method Area）

方法區（Method Area）與Java堆一樣，是各個執行緒共享的記憶體區域，它用于存盤已被虛擬機加載的類資訊、常量、靜態變數、即時編譯器編譯后的代碼等資料，雖然Java虛擬機規范把方法區描述為堆的一個邏輯部分，但是它卻有一個別名叫做Non-Heap（非堆），目的應該是與Java堆區分開來，對于習慣在HotSpot虛擬機上開發和部署程式的開發者來說，很多人愿意把方法區稱為“永久代”（Permanent Generation），本質上兩者并不等價，僅僅是因為HotSpot虛擬機的設計團隊選擇把GC分代收集擴展至方法區，或者說使用永久代來實作方法區而已，Java虛擬機規范對這個區域的限制非常寬松，除了和Java堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴展外，還可以選擇不實作垃圾收集，相對而言，垃圾收集行為在這個區域是比較少出現的，但并非資料進入了方法區就如永久代的名字一樣“永久”存在了，這個區域的記憶體回收目標主要是針對常量池的回收和對型別的卸載，一般來說這個區域的回收“成績”比較難以令人滿意，尤其是型別的卸載，條件相當苛刻，但是這部磁區域的回收確實是有必要的，根據Java虛擬機規范的規定，當方法區無法滿足記憶體分配需求時，將拋出OutOfMemoryError例外，

程式計數器（Program Counter Register）

程式計數器（Program Counter Register）是一塊較小的記憶體空間，它的作用可以看做是當前執行緒所執行的位元組碼的行號指示器，在虛擬機的概念模型里（僅是概念模型，各種虛擬機可能會通過一些更高效的方式去實作），位元組碼解釋器作業時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令，分支、回圈、跳轉、例外處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成， 由于Java虛擬機的多執行緒是通過執行緒輪流切換并分配處理器執行時間的方式來實作的，在任何一個確定的時刻，一個處理器（對于多核處理器來說是一個內核）只會執行一條執行緒中的指令，因此，為了執行緒切換后能恢復到正確的執行位置，每條執行緒都需要有一個獨立的程式計數器，各條執行緒之間的計數器互不影響，獨立存盤，我們稱這類記憶體區域為“執行緒私有”的記憶體，如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機位元組碼指令的地址；如果正在執行的是Natvie方法，這個計數器值則為空（Undefined），此記憶體區域是唯一一個在Java虛擬機規范中沒有規定任何OutOfMemoryError情況的區域，

　　JVM堆疊（JVM Stacks）

與程式計數器一樣，Java虛擬機堆疊（Java Virtual Machine Stacks）也是執行緒私有的，它的生命周期與執行緒相同，虛擬機堆疊描述的是Java方法執行的記憶體模型：每個方法被執行的時候都會同時創建一個堆疊幀（Stack Frame，如果沒有進入JVM叫方法，進入JVM的方法區后就叫堆疊幀）用于存盤區域變數表、操作堆疊、動態鏈接、方法出口等資訊，每一個方法被呼叫直至執行完成的程序，就對應著一個堆疊幀在虛擬機堆疊中從入堆疊到出堆疊的程序， 區域變數表存放了編譯期可知的各種基本資料型別（boolean、byte、char、short、int、float、long、double）、物件參考（reference型別，它不等同于物件本身，根據不同的虛擬機實作，它可能是一個指向物件起始地址的參考指標，也可能指向一個代表物件的句柄或者其他與此物件相關的位置）和returnAddress型別（指向了一條位元組碼指令的地址），其中64位長度的long和double型別的資料會占用2個區域變數空間（Slot），其余的資料型別只占用1個，區域變數表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在幀中分配多大的區域變數空間是完全確定的，在方法運行期間不會改變區域變數表的大小，在Java虛擬機規范中，對這個區域規定了兩種例外狀況：如果執行緒請求的堆疊深度大于虛擬機所允許的深度，將拋出StackOverflowError例外；如果虛擬機堆疊可以動態擴展（當前大部分的Java虛擬機都可動態擴展，只不過Java虛擬機規范中也允許固定長度的虛擬機堆疊），當擴展時無法申請到足夠的記憶體時會拋出OutOfMemoryError例外，

　　本地方法堆疊（Native Method Stacks）

本地方法堆疊（Native Method Stacks）與虛擬機堆疊所發揮的作用是非常相似的，其區別不過是虛擬機堆疊為虛擬機執行Java方法（也就是位元組碼）服務，而本地方法堆疊則是為虛擬機使用到的Native方法服務，虛擬機規范中對本地方法堆疊中的方法使用的語言、使用方式與資料結構并沒有強制規定，因此具體的虛擬機可以自由實作它，甚至有的虛擬機（譬如Sun HotSpot虛擬機）直接就把本地方法堆疊和虛擬機堆疊合二為一，與虛擬機堆疊一樣，本地方法堆疊區域也會拋出StackOverflowError和OutOfMemoryError例外，

　　類裝載器 ClassLoader,執行引擎 ExecutionEngine

類裝載器 ClassLoader

　　類裝載器負責加載 .class 檔案,class 檔案在檔案開頭有特定的檔案標示(cafe babe),將.class檔案加載到記憶體中，將其放在運行時資料區的方法區（放類的描述資訊）內，然后在堆區創建一個java.lang.Class物件，用來封裝類在方法區內的資料結構， ClassLoader 只負責 class 檔案的加載,至于它是否可以運行,則由 Execution Engine 決定，ClassLoader有多個

　　ClassLoader:　　

啟動類加載器：Bootstrap ClassLoader，負責加載存放在JDK\jre\lib(JDK代表JDK的安裝目錄，下同)下，或被-Xbootclasspath引數指定的路徑中的，并且能被虛擬機識別的類別庫（如rt.jar，所有的java.*開頭的類均被Bootstrap ClassLoader加載），啟動類加載器是無法被Java程式直接參考的，

　　擴展類加載器：Extension ClassLoader，該加載器由sun.misc.Launcher$ExtClassLoader實作，它負責加載DK\jre\lib\ext目錄中，或者由java.ext.dirs系統變數指定的路徑中的所有類別庫（如javax.*開頭的類），開發者可以直接使用擴展類加載器，

　　應用程式類加載器：Application ClassLoader，該類加載器由sun.misc.Launcher$AppClassLoader來實作，它負責加載用戶類路徑（ClassPath）所指定的類，開發者可以直接使用該類加載器，如果應用程式中沒有自定義過自己的類加載器，一般情況下這個就是程式中默認的類加載器，

　　例子：證明類是被那個加載器加載的　

從上圖能看出第一個輸出null,第二個報了空指標例外，為什么會這樣呢？

因為Object是jdk自帶的，所以在加載的時候是走Bootstrap啟動類加載器，而Bootstrap加載器是C++語言寫的，所以在查的時候是null,Object已經是祖先了，因為它屬于Boostrap，所以它已經沒有祖先了，它就是最大的，就好比人家的祖墳已經是最大了，你還要去刨人家的祖墳看看人家的祖先是誰，那肯定沒有啊，因為祖墳已經是最大的了，所以報了NullPointException();

接著：

從上可以看出第一個用的是應用程式加載器（AppClassLoader）,第二個是擴展類加載器（ExtClassLoader),第三個是啟動類加載器（BootstrapClassLoader),第四個為空，因為Bootstrap是最高的了，所以頂上沒有了，

　 加載順序：

　　例如當我們要使用某個類的時候，順序是這樣的，首先先去啟動類加載器bootstrap找，如果有就直接用，如果沒有就去擴展類加載器找，如果擴展類加載器沒有，就去應用程式加載器找，如果還是沒有，就報ClassNotFoundException例外，世紀上就是雙親委派機制，下面就說

　　雙親委派機制：

　 如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把請求委托給父加載器去完成，依次向上，因此，所有的類加載請求最終都應該被傳遞到頂層的啟動類加載器（Bootstrap ClassLoader)中，只有當父加載器在它的搜索范圍中沒有找到所需的類時，即無法完成該加載，子加載器才會嘗試自己去加載該類，

　　具體流程：

　　　　1.當AppClassLoader加載一個class時，它不會嘗試加載這個類，而是把類加載請求委派給父類加載器ExtClassLoader去完成，

　　　　2.當父類ExtClassLoader加載到這個.class時，他也不會嘗試加載這個類，而是把類加載請求委派給父類加載器BootstrapClassLoader，

　　　　3.當BootstrapClassLoader加載到這個.class時，它會查找該類是否存在，如果不存在，就往下傳遞，交給ExtClassLoader，如果ExtClassLoader在自己相應的包中也沒找到對應的類，就交給AppClassLoader來加載，如果AppClassLoader也沒有，就報ClassNotFoundException();

　　沙箱安全：防止惡意代碼污染java源代碼

比如我定義了一個類名為String所在包為java.lang，因為這個類本來是屬于jdk的，如果沒有沙箱安全機制的話，這個類將會污染到我所有的String,但是由于沙箱安全機制，所以就委托頂層的bootstrap加載器查找這個類，如果沒有的話就委托extsion,extsion沒有就到aapclassloader，但是由于String就是jdk的源代碼，所以在bootstrap那里就加載到了，先找到先使用，所以就使用bootstrap里面的String,后面的一概不能使用，這就保證了不被惡意代碼污染