關于Jvm類加載機制，這一篇就夠了
前言
一個月沒更新了，這個月發生了太多的事情，導致更新的頻率大大降低，不管怎樣收拾心情，技術的研究不能落下!
什么是jvm
平常我們編寫代碼都是編寫的.java文件，怎么部署到機器上運行呢?通過打jar包或者war包，然后部署運行。
如果看過jar包的內容那么就能知道，我們寫的.java文件全部被編譯成了.class文件。
這里發生了很重要的一個步驟—— 編譯 ：將我們寫的程序翻譯成能被jvm讀懂的文件格式。
值得注意的是，每一個 類 都會被編譯成一個.class文件，包括內部類等。也就是說每一個.class文件都只對應我們代碼中的一個類。
類的生命周期
類被加載到jvm虛擬機內存開始，到卸載出內存為止，他的生命周期可以分為：加載->驗證->準備->解析->初始化->使用->卸載。
下面我們來對此一一說明：
加載
當生成一個jar包以后，我們編寫的程序就全部編編譯成了jvm能讀懂的.class格式。此時就需要加載了，將我們的編譯好的.class文件加載到jvm中。此時就會有一個“類加載器”的概念。如下圖。
接下來一個問題，類加載器何時會將一個.class加載帶jvm?也就是說什么情況下會加載一個類?
一個jar包運行的時候會指定一個main()方法作為入口方法。首先就會將main()方法所在的類加載到jvm，當代碼執行遇到new的時候又繼續將該對象加載到jvm。
所以總結來說，就是在 你的代碼中需要用到這個類的時候 ，就會將其加載到jvm中。
驗證
這個不需要理解的太深，很直白的道理，不能什么阿貓阿狗都能被加載到jvm中，要不就亂套了。所以該階段就是來校驗加載進來的.class文件是否符合指定的規則。
有一個很有趣的就是，每個.class文件都很浪漫，因為每一個.class文件都是以8個十六進制的 0×CAFEBABE,翻譯過來就是咖啡寶貝。浪漫吧?在驗證階段的第一步就是檢查.class文件是否以咖啡寶貝來開頭的。
所以我們的流程圖可以更新為
準備
當我們合法的把一個.class文件加載到jvm中后，此時就會進行一些準備工作。
首先為這個類分配內存空間，然后為類變量(被static修飾的變量)賦值一個默認的初始值。但是如果類變量同時被final修飾的話，就不是賦值初始值而是 具體的值
用下面兩種情況來說明：
- public class Student{
- private static int age = 18;
- }
- //此時就會為age變量分配內存空間并且為其賦值 0 這個初始值。
- public class Student{
- private static final int age = 18;
- }
- //age被final修飾，此時就會為age變量分配內存空間并且為其賦值為 18 。
所以我們的流程圖可以更新為
解析
解析階段就是jvm將常量池的符號引用替換為直接引用。
簡單的來說就是我們編寫的代碼中，當一個變量引用某個對象的時候，這個引用在.class文件中是以符號引用來存儲的。在解析階段就需要將其解析為直接引用。如果有了直接引用，那引用的目標必定已經在內存中存在。
所以我們的流程圖可以更新為
初始化
在準備階段我們已經為加載到jvm的類分配了內存空間并且為類變量賦予了初始值。
而到了初始化階段，才真正開始執行類中定義的java程序代碼。主要有以下步驟：
- 為類的靜態變量賦予正確的初始值。
- 執行類的靜態代碼塊。
按照順序自上而下運行類中的變量賦值語句和靜態語句，并且只有類或接口被Java程序首次主動使用時才初始化他們。如果有父類，則首先按照順序運行父類中的變量賦值語句和靜態語句。
所以我們的流程圖可以更新為
總結
在一個靜態方法中我們是不能直接使用非靜態變量的。當我們使用靜態方法的時候，僅僅是初始化了靜態方法所在的類，此時只有靜態變量是被賦了值而非靜態變量是沒有被賦值的。所以在靜態方法中是不能直接使用非靜態變量的。
