走進JVM，淺水也能捉魚!
這不是一篇描述jvm是什么的文章，也不介紹jvm跨平臺的特性，也不是講述jvm安全特性的文章，更不是講解jvm指令操作，數(shù)據(jù)運算的文章， 本文重點講述類型的生命周期。
類型的生命周期涉及到：類的裝載、jvm體系結(jié)構(gòu)、垃圾回收機制。
為什么要講jvm體系結(jié)構(gòu)？ 因為類的裝載和垃圾回收機制都和jvm體系結(jié)構(gòu)息息相關(guān)。
那么什么是jvm體系結(jié)構(gòu)呢？
當(dāng)jvm運行起來的時候，它會向系統(tǒng)申請一片內(nèi)存區(qū)（不同的jvm實現(xiàn)可能不同，有些可以使用虛擬內(nèi)存），將這塊內(nèi)存分出一部分存儲許多東西，例如：程序創(chuàng)建的對象，傳遞給方法的參數(shù)，返回值，局部變量等等，我們將這塊內(nèi)存稱之為“運行時數(shù)據(jù)區(qū)”， 運行時數(shù)據(jù)區(qū)可以劃分成方法區(qū)、堆、java棧、pc寄存器、本地方法棧。
看到上面這幅圖，和這些解說你可能大概的明白jvm 體系是個啥樣子，但是你或許還不了解運行時數(shù)據(jù)區(qū)里面方法區(qū)等用來干嘛的。
- 方法區(qū)：當(dāng)虛擬機裝載一個class文件的時候，它會從這個class文件包含的二進制數(shù)據(jù)中解析類型信息。然這些類型信息放到方法區(qū)中。因為方法區(qū)是被所有線程共享的，所以必須考慮數(shù)據(jù)的線程安全。假如兩個線程都在試圖找lava的類，在lava類還沒有被加載的情況下，只應(yīng)該有一個線程去加載，而另一個線程等待。
- Pc寄存器：每個新線程產(chǎn)生都將得到自己的pc寄存器以及一個java棧幀。
- 堆：存放程序運行時產(chǎn)生的所有對象。堆是一個線程共享的內(nèi)存區(qū)，所以我們寫多線程程序的時候需要考慮并發(fā)。
Java棧：java棧由許多棧幀組成的，如圖，當(dāng)一個線程調(diào)用java方法時，虛擬機壓入一個新的棧幀到j(luò)ava棧中，當(dāng)方法返回的時候，這個棧幀被從java棧彈出并被拋棄。
那么現(xiàn)在你應(yīng)該可以想象到一些jvm是怎么工作的了，是不是應(yīng)該接著講具體工作原理了呢？。但是不急，先了解下類的裝載機制。
了解類的裝載機制之前先了解jvm里面的類裝載器：Bootstrap Loader、ExtClassLoader 、AppClassLoader；
ExtClassLoader （負責(zé)裝載jre下面的rt.jar, charsets.jar）和AppClassLoader(負責(zé)轉(zhuǎn)載classpath下面的類包)是ClassLoader（抽象類）的子類；
Bootstrap Loader（負責(zé)裝載jre核心類庫）是根裝載器是c/c++寫的在java里面看不到它。
這三個類裝載器存在父子關(guān)系， 根裝載器是 ExtClassLoader父裝載器，ExtClassLoader是AppClassLoader父裝載器；
Jvm中類的裝載也是安全機制沙箱模型的***道門檻。 Java裝載類使用“雙親委派模式”—即全盤負責(zé)委托機制。
好現(xiàn)在讓我們了解裝載大概流程；
當(dāng)裝載一個類的時候，若是由用戶指定一個類裝載器裝載的話，那么那個類裝載器會先委派給父類裝載器，一直委派到根裝載器，如果裝載的是一個 java.lang.String，由于它是核心類庫的而且已經(jīng)被裝載過了，那么就會直接返回一個class對象，那么如果是一個根裝載器找不到的類呢？接著就會交給子類（下一級父類）裝載器，如果還是沒有找到類文件，接著就會由之前用戶指定的那個類裝載器裝載。（這里沒有說明裝載超類的過程，請勿疏忽）。
如果是有人惡意的寫了一個基礎(chǔ)類java.lang.String，那么會影響虛擬機嗎？ 不會因為這個類最終會交由根裝載器裝載，而根裝載器只會去jre核心類庫加載，最終返回的class類型并不是 用戶寫的String，而且系統(tǒng)自帶的String，也就是說用戶寫String永遠不會被加載。
了解了類裝載器是怎么工作了之后，我們也需要了解下class文件格式；
- The ClassFile Structure
- ClassFile{
- u4 magic; //魔數(shù)
- u2 minor_version; //class 次版本號
- u2 major_version; //class 主版本號
- u2 constant_pool_count; //常量池計數(shù)
- cp_info constant_pool[constant_pool_count-1]; //常量池
- u2 access_flags; //修飾符
- u2 this_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[attrributes_count];
- }
我們需要了解的有很多，但是我們難以理解的就是 cp_info constant_pool 常量池；
一個常量池里面有很多表
- CONSTANT_Utf8 UTF-8編碼的Unicode字符串
- CONSTANT_Integer int類型的字面值
- CONSTANT_Float float類型的字面值
- CONSTANT_Long long類型的字面值
- CONSTANT_Double double類型的字面值
- CONSTANT_Class 對一個類或接口的符號引用
- CONSTANT_String String類型字面值的引用
- CONSTANT_Fieldref 對一個字段的符號引用
- CONSTANT_Methodref 對一個類中方法的符號引用
- CONSTANT_InterfaceMethodref 對一個接口中方法的符號引用
- CONSTANT_NameAndType 對一個字段或方法的部分符號引用
這些表結(jié)構(gòu)我也不解釋了，如果對class文件不夠了解也沒什么關(guān)系，知道個大概也行。那么我們了解了 jvm體系，類裝載器工作流程，那么我們細看下 類裝載器工作中 ，jvm運行時數(shù)據(jù)區(qū)的變化，方法區(qū)里面的結(jié)構(gòu)等等。
在類裝載的過程中， 每一個類裝載器都會在方法區(qū)里面形成一張表，這張表記載著該裝載器和對應(yīng)的類的權(quán)限定名。沒這么一張表就形成了jvm內(nèi)部的命名空間。同時在方法區(qū)里面還該類的常量池等信息。
那么說到這些，其實這個過程還是很模糊，而且很多知識也落下了，那么我們現(xiàn)在看一個詳細一點的裝載過程。
當(dāng)裝載一個普通的類的時候，即調(diào)用類裝載器的loadClass方法, 如果希望裝載的類還沒有被裝載到命名空間，那么jvm會傳遞一個該類型的全限定名給類裝載器，也就是常量池CONSTANT_Class_info（該表存儲著父類、類裝載器等信息）入口的裝載器，來試圖裝載被引用的類型，如果發(fā)起引用的類型是被jvm裝載器定義的，那么由jvm類裝載器裝載，否則由用戶自定義裝載器裝載，那么一旦被引用的類型被裝載了，jvm仔細檢查它的二進制數(shù)據(jù)，如果類是是一個類，并且不是java.lang.Object。 jvm根據(jù)數(shù)據(jù)得到它的全限定名進行裝載（遞歸的應(yīng)用了）這個過程還需要遞歸超接口。
裝載差不多講完了，一個完整的過程 是： 裝載—連接---初始化
那么連接和初始化就一帶而過了， 重點放在垃圾回收。
連接的過程主要是驗證（確認(rèn)類型符合java語言的語義，并且它不會危及虛擬機的完整性）、準(zhǔn)備（java 虛擬機為類變量分配內(nèi)存，設(shè)計默認(rèn)初始值）、解析（在類型的常量池中尋找類、接口、字段和方法的符合引用，把這些符號引用替換成直接引用的過程）。
初始化的時候，如果類存在直接超類，且超類還沒有被初始化，就先初始化直接超類。初始化接口并不需要初始化它的父接口。
補充：
Jvm當(dāng)運行某個方法的時候，先把這個方法壓入java棧中，里面包含局部變量等信息，那么對象放入哪里呢？ 壓入棧的是對象的引用， 即變量， 所有的對象都存儲在堆中。
為什么要把對象放入堆，把變量之類的數(shù)據(jù)放入棧呢？ 說白了，對象太大了，存入棧中運算麻煩。（當(dāng)然標(biāo)準(zhǔn)的回答不是這樣的，我這里僅僅是說明實質(zhì)）
了解了這么一個過程之后，我們必然要了解垃圾回收機制了。
基本回收算法
1. 引用計數(shù)：比較古老的回收算法。原理是此對象有一個引用，即增加一個計數(shù)，刪除一個引用則減少一個計數(shù)。垃圾回收時，只用收集計數(shù)為0的對象。此算法最致命的是無法處理循環(huán)引用的問題。
2. 標(biāo)記-清除：此算法執(zhí)行分兩階段。***階段從引用根節(jié)點開始標(biāo)記所有被引用的對象，第二階段遍歷整個堆，把未標(biāo)記的對象清除。此算法需要暫停整個應(yīng)用，同時，會產(chǎn)生內(nèi)存碎片。
3. 復(fù)制：此算法把內(nèi)存空間劃為兩個相等的區(qū)域，每次只使用其中一個區(qū)域。垃圾回收時，遍歷當(dāng)前使用區(qū)域，把正在使用中的對象復(fù)制到另外一個區(qū)域中。次算法每次只處理正在使用中的對象，因此復(fù)制成本比較小，同時復(fù)制過去以后還能進行相應(yīng)的內(nèi)存整理，不過出現(xiàn)“碎片”問題。當(dāng)然，此算法的缺點也是很明顯的，就是需要兩倍內(nèi)存空間。
4. 標(biāo)記-整理：此算法結(jié)合了“標(biāo)記-清除”和“復(fù)制”兩個算法的優(yōu)點。也是分兩階段，***階段從根節(jié)點開始標(biāo)記所有被引用對象，第二階段遍歷整個堆，把清除未標(biāo)記對象并且把存活對象“壓縮”到堆的其中一塊，按順序排放。此算法避免了“標(biāo)記-清除”的碎片問題，同時也避免了“復(fù)制”算法的空間問題。
5. 增量收集：實施垃圾回收算法，即：在應(yīng)用進行的同時進行垃圾回收。
6. 分代：基于對對象生命周期分析后得出的垃圾回收算法。把對象分為年青代、年老代、持久代，對不同生命周期的對象使用不同的算法（上述方式中的一個）進行回收。
