浮点数例外 (核心已转储)_15000 字梳理 JVM 的核心知识
前言
隨著cpu運(yùn)行速度的提高和內(nèi)存的增大，我們的應(yīng)用程序的用戶響應(yīng)時(shí)間和系統(tǒng)吞吐量也發(fā)生了質(zhì)的提高。但是只有硬件設(shè)備的提高是不行的，軟件的性能和運(yùn)行在硬件上的虛擬機(jī)的各項(xiàng)參數(shù)都影響著系統(tǒng)的質(zhì)量。在越來越多的大廠面試中，jvm逐漸成為面試官青睞的考點(diǎn)。
本文講解了運(yùn)行時(shí)數(shù)據(jù)區(qū)域，內(nèi)存溢出，如何判斷對象是否存活，垃圾回收算法和垃圾收集器，類加載機(jī)制和雙親委派模型以及對象的創(chuàng)建存儲和訪問幾個(gè)方面，涵蓋jvm的核心考點(diǎn)，希望你有所收獲。
運(yùn)行時(shí)數(shù)據(jù)區(qū)域
java虛擬機(jī)運(yùn)行時(shí)有哪些數(shù)據(jù)區(qū)域，他們都有什么用途？
有程序計(jì)數(shù)器、java虛擬機(jī)棧、本地方法棧、堆和方法區(qū)五大模塊。請看下圖：
程序計(jì)數(shù)器
程序計(jì)數(shù)器是一塊較小的內(nèi)存空間，他可以看做是當(dāng)期線程所執(zhí)行的字節(jié)碼的行號指令器。字節(jié)碼解釋器工作時(shí)就是通過改變這個(gè)計(jì)數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令。在任何一個(gè)確定的時(shí)刻，一個(gè)處理器都只會(huì)執(zhí)行一條線程中的指令。因此，為了線程切換后能恢復(fù)到正確的執(zhí)行位置，每條線程都需要有一個(gè)獨(dú)立的程序計(jì)數(shù)器，各個(gè)線程之間互不影響，獨(dú)立存儲，所以程序計(jì)數(shù)器是“線程私有的”。另外，程序計(jì)數(shù)器是唯一一個(gè)在java虛擬機(jī)規(guī)范中沒有規(guī)定OOM的區(qū)域。
Java虛擬機(jī)棧
Java虛擬機(jī)棧也是線程私有的，它的生命周期與線程相同，虛擬機(jī)棧描述的是Java方法執(zhí)行的內(nèi)存模型，每個(gè)方法在執(zhí)行的同時(shí)都會(huì)創(chuàng)建一個(gè)棧幀用于存儲局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等信息。每個(gè)方法從調(diào)用直至執(zhí)行完成的過程，對應(yīng)著一個(gè)棧幀在虛擬機(jī)棧中入棧到出棧的過程。（程序員經(jīng)常會(huì)把Java內(nèi)存劃分為堆內(nèi)存和棧內(nèi)存，這種說法比較粗糙，其中的棧內(nèi)存就是指虛擬機(jī)棧，或者說是虛擬機(jī)棧中的局部變量表的部分）
在Java虛擬機(jī)規(guī)范中，對這個(gè)區(qū)域規(guī)定了兩種異常：如果線程請求的棧深度大于虛擬機(jī)所允許的深度，將拋出StackOverFlowError異常。如果虛擬機(jī)棧可以動(dòng)態(tài)擴(kuò)展，如果擴(kuò)展時(shí)無法申請到足夠的內(nèi)存，就會(huì)拋出OOM異常。
本地方法棧
本地方法棧與虛擬機(jī)棧作用類似，他們之間的區(qū)別不過是虛擬機(jī)棧是為虛擬機(jī)執(zhí)行Java方法（也就是字節(jié)碼）服務(wù)，而本地方法棧則為虛擬機(jī)使用到的Native方法服務(wù)。與虛擬機(jī)棧一樣，本地方法棧也會(huì)拋出StackOverFlowError異常和OOM異常。
堆
Java堆是Java虛擬機(jī)管理的最大的一塊內(nèi)存，是所有線程共享的區(qū)域，在虛擬機(jī)啟動(dòng)時(shí)就創(chuàng)建。堆用來存放對象實(shí)例，幾乎所有的對象實(shí)例都在這里分配內(nèi)存（注意是幾乎所有）。這一點(diǎn)在Java虛擬機(jī)規(guī)范中描述為：所有的對象實(shí)例以及數(shù)組都要在堆上分配，但隨著JIT編譯器的發(fā)展和逃逸分析技術(shù)的成熟，棧上分配、標(biāo)量替換技術(shù)將會(huì)導(dǎo)致一些微妙的變化發(fā)生，所有對象都分配在堆上也不是那么絕對了。
如果在堆中沒有內(nèi)存完成實(shí)例分配，并且堆也無法再擴(kuò)展時(shí)，將會(huì)拋出OOM異常。
方法區(qū)
方法區(qū)與Java堆一樣，是各個(gè)線程共享的區(qū)域，它用來存儲已被虛擬機(jī)加載的類信息、常量、靜態(tài)變量、即時(shí)編譯器編譯后的代碼等數(shù)據(jù)。根據(jù)Java虛擬機(jī)規(guī)范，當(dāng)方法區(qū)無法滿足內(nèi)存分配的 需求時(shí)，將拋出OOM異常。
運(yùn)行時(shí)常量池是方法區(qū)的一部分，用于存放編譯器生成的各種字面量和符號引用。運(yùn)行時(shí)常量池相對于Class文件常量池的另外一個(gè)重要特征就是具備動(dòng)態(tài)性。也就是說運(yùn)行期間也可能將新的常量 放入池中，這種特性被利用的比較多的就是String類的intern()方法。
直接內(nèi)存
直接內(nèi)存并不是運(yùn)行時(shí)數(shù)據(jù)區(qū)的一部分，也不是Java虛擬機(jī)定義的內(nèi)存區(qū)域。本機(jī)直接內(nèi)存的分配不受Java堆大小的限制，但是受本機(jī)總內(nèi)存大小以及處理器尋址空間的限制。
內(nèi)存溢出
堆內(nèi)存溢出
Java堆用于存儲對象實(shí)例，只要不斷創(chuàng)建對象，并且保證GC Roots到對象之間有可達(dá)路徑來避免垃圾回收機(jī)制清除這些對象，那么在對象數(shù)量達(dá)到最大堆容量限制后就會(huì)OOM。（輕易不要運(yùn)行）
public class HeapOOMTest {static class OOMObject {}public static void main(String [] args) {List<OOMObject> list = new ArrayList<>();while (true) {list.add(new OOMObject());}} }Java堆內(nèi)存的OOM異常是實(shí)際應(yīng)用中最常見的內(nèi)存溢出，當(dāng)出現(xiàn)了咋辦？一般的手段是先通過內(nèi)存映像分析工具對Dump出來的堆轉(zhuǎn)儲快照進(jìn)行分析，重點(diǎn)是確認(rèn)內(nèi)存中的對象是否是必要的，也就是確認(rèn)是內(nèi)存泄露還是內(nèi)存溢出。
如果是內(nèi)存泄露，可進(jìn)一步通過工具查看泄露對象到GCRoots的引用鏈，找到為什么垃圾收集器無法回收它們。如果不存在泄露，就是內(nèi)存中的對象必須都存活，那就要檢查虛擬機(jī)的堆內(nèi)存是否可以調(diào)大，從代碼上檢查是否某些對象生命周期過長，減少內(nèi)存消耗，優(yōu)化代碼。
虛擬機(jī)棧溢出
關(guān)于虛擬機(jī)棧，在java虛擬機(jī)規(guī)范中描述了兩種異常：
（1）如果線程請求的棧深度大于虛擬機(jī)所允許的最大深度，將拋出StackOverFlowError異常。
（2）如果虛擬機(jī)在擴(kuò)展棧時(shí)無法申請到足夠的內(nèi)存空間，則拋出OutOdMemoryError異常。
這里描述的兩種情況實(shí)際上有些重疊：當(dāng)?？臻g無法繼續(xù)分配的時(shí)候，到底是內(nèi)存太小導(dǎo)致的，還是已使用的?？臻g太大，本質(zhì)上是一樣的。
public class StackSOFTest {private int stackLength = -1;public void stackLeak() {stackLength++;stackLeak();}public static void main(String [] args) throws Throwable {StackSOFTest oom = new StackSOFTest();try {oom.stackLeak();} catch (Throwable e) {System.out.println("stack length:"+oom.stackLength);throw e;}} }運(yùn)行結(jié)果：
stack length:13980 Exception in thread "main" java.lang.StackOverflowErrorat oom.StackSOFTest.stackLeak(StackSOFTest.java:14)at oom.StackSOFTest.stackLeak(StackSOFTest.java:14)at oom.StackSOFTest.stackLeak(StackSOFTest.java:14)...后續(xù)省略實(shí)驗(yàn)結(jié)果表明：在單個(gè)線程下，無論是由于棧幀太大還是虛擬機(jī)棧容量太小，當(dāng)內(nèi)存無法分配時(shí)，虛擬機(jī)拋出的都是StackOverflowError異常。
對象是“生”是“死”
對象的四種引用
引用分為強(qiáng)引用，軟引用，弱引用和虛引用四種，這四種引用強(qiáng)度依次逐漸減弱。
1、強(qiáng)引用就是指在程序代碼中普遍存在的，是指創(chuàng)建一個(gè)對象并把這個(gè)對象賦給一個(gè)引用變量，類似Object obj = new Object()這類的引用，只要強(qiáng)引用還存在，垃圾收集器就永遠(yuǎn)不會(huì)回收被引用的對象。如果想中斷強(qiáng)引用和某個(gè)對象之間的關(guān)聯(lián)，可以顯示的將引用賦值為null，這樣jvm在合適的時(shí)間就會(huì)回收該對象。
2、軟引用是用來描述一些還有用但并非必需的對象。對于軟引用關(guān)聯(lián)著的對象，在系統(tǒng)將會(huì)發(fā)生內(nèi)存溢出異常之前，將會(huì)把這些對象列進(jìn)回收范圍之中進(jìn)行第二次回收。SoftReference的特點(diǎn)是它的一個(gè)實(shí)例保存對一個(gè)Java對象的軟引用，該軟引用的存在不妨礙垃圾收集器線程對該Java對象的回收。
3、弱引用也是用來描述非必需對象的。當(dāng)JVM進(jìn)行垃圾回收時(shí)，無論內(nèi)存是否充足，都會(huì)回收被弱引用關(guān)聯(lián)的對象。在java中，用java.lang.ref.WeakReference類來表示。
4、虛引用和前面的軟引用和弱引用不同，它并不影響對象的生命周期。在java中使用PhantomReference類來表示。如果一個(gè)對象與虛引用關(guān)聯(lián)，跟沒有引用與之關(guān)聯(lián)一樣，任何時(shí)候都可能被回收。要注意的是，虛引用必須和引用隊(duì)列關(guān)聯(lián)使用。當(dāng)垃圾收集器準(zhǔn)備回收一個(gè)對象時(shí)，如果發(fā)現(xiàn)它還有虛引用，就會(huì)把這個(gè)虛引用加入到與之關(guān)聯(lián)的引用隊(duì)列中。為對象設(shè)置虛引用的唯一目的就是能在這個(gè)對象被垃圾收集器回收時(shí)收到一個(gè)系統(tǒng)通知。
引用計(jì)數(shù)法的缺陷
引用計(jì)數(shù)法就是給對象添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用它時(shí)，計(jì)數(shù)器值就加1.當(dāng)引用失效時(shí)，計(jì)數(shù)器的值就減一。任何時(shí)刻計(jì)數(shù)器值為0的對象就是不可能再被使用的。
優(yōu)缺點(diǎn)：實(shí)現(xiàn)簡單，判斷效率高，大部分情況下是個(gè)很不錯(cuò)的算法。但是致命問題是沒辦法解決對象之間相互循環(huán)引用的問題。
觀察GC日志可以看出GC發(fā)生了內(nèi)存回收，意味著虛擬機(jī)并沒有因?yàn)檫@兩個(gè)對象相互引用就不回收它們，這也從側(cè)面說明虛擬機(jī)并沒有采用引用計(jì)數(shù)法來判斷對象是否存活。
可達(dá)性分析
這個(gè)算法的基本思想是通過一系列被稱為“GC Roots”的對象作為起始點(diǎn)，從這些節(jié)點(diǎn)開始向下搜索，搜索走過的路徑叫做引用鏈，當(dāng)一個(gè)對象到GC Roots沒有任何引用鏈相連 （用圖論的話來說就是從GC Roots到這個(gè)對象不可達(dá)），則證明此對象是不可用的。
在 Java語言中，可作為GC Roots的對象包括以下幾種
（1）虛擬機(jī)棧（棧幀中的本地變量表）中引用的對象。
（2）方法區(qū)中類靜態(tài)屬性引用的對象。
（3）方法區(qū)中常量引用的對象。
（4）本地方法棧中JNI（即一般說的Native方法）引用的對象。
對象是生存還是死亡？
即使在可達(dá)性分析法中不可達(dá)的對象，也并非“非死不可”，他們還有拯救自己的機(jī)會(huì)。要宣告一個(gè)對象死亡，至少要經(jīng)歷兩次標(biāo)記過程：如果對象在進(jìn)行可達(dá)性分析后沒有與GC Roots的引用鏈，那么它將會(huì)被第一次標(biāo)記，并且此時(shí)需要判斷是否有必要執(zhí)行finalize()方法。沒有必要的話，那么這個(gè)對象就宣告死亡，可以回收了。
如果有必要執(zhí)行，那么這個(gè)對象會(huì)被放置在一個(gè)叫做F-Queue的隊(duì)列中，并在稍后由虛擬機(jī)自動(dòng)建立的低優(yōu)先級的Finalizer線程去執(zhí)行它。finalize()是對象拯救自己的最后一次機(jī)會(huì)-只要重新與引用鏈上的 任何一個(gè)對象建立關(guān)聯(lián)即可（譬如把自己賦值給某個(gè)類變量或者對象的成員變量），那么在第二次標(biāo)記時(shí)它將被移除“可回收”的集合，如果對象還沒有逃脫，基本上就真的被回收了。
具體的過程見下圖：
垃圾收集算法
標(biāo)記清除算法
標(biāo)記-清除算法是最基礎(chǔ)的算法，分為“標(biāo)記”和“清除”兩個(gè)階段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后統(tǒng)一回收。
它的主要不足有兩個(gè)：一是效率問題，標(biāo)記和清除兩個(gè)過程的效率都不高；另一個(gè)是空間問題，標(biāo)記清楚之后會(huì)產(chǎn)生大量不連續(xù)的內(nèi)存碎片。
標(biāo)記-清除算法的執(zhí)行過程見下圖：
復(fù)制算法
為了解決效率問題，“復(fù)制”算法出現(xiàn)了。它將內(nèi)存空間劃分為大小相等的兩塊，每次只使用其中的一塊，當(dāng)這一塊的內(nèi)存用完了，就將還存活的對象復(fù)制到另外一塊上，然后再把已使用的的內(nèi)存空間一次性清理掉。
這樣每次都是對整個(gè)半?yún)^(qū)進(jìn)行內(nèi)存回收，內(nèi)存分配時(shí)也就不用考慮內(nèi)存碎片等復(fù)雜情況，只要移動(dòng)堆頂指針，按順序分配內(nèi)存即可，實(shí)現(xiàn)簡單，運(yùn)行高效。但是這種算法的代碼是將內(nèi)存空間縮小為原來的一半。
復(fù)制算法的執(zhí)行過程見下圖：
標(biāo)記-整理算法
標(biāo)記過程仍然與標(biāo)記-清除算法一樣，但后續(xù)步驟不是直接對可回收對象進(jìn)行清理，而是讓所有存活的對象都向一端移動(dòng)，然后直接清理掉邊界以外的內(nèi)存。
標(biāo)記-整理算法的執(zhí)行過程見下圖：
分代收集算法
當(dāng)前商業(yè)虛擬機(jī)的垃圾收集都采用“分代收集”的算法，這種算法只是根據(jù)對象存活周期的不同將內(nèi)存劃分為幾塊，一般是把Java堆分為新生代和老年代，這樣就可以根據(jù)各個(gè)年代的特點(diǎn)采用最適當(dāng)?shù)氖占惴ā?/p>
在新生代中，每次垃圾收集都發(fā)現(xiàn)有大批對象死去，只有少量存活，那就選用“復(fù)制算法“，只需要付出少量存活對象的復(fù)制成本就可以完成收集。而老年代中因?yàn)閷ο蟠婊盥矢?#xff0c;沒有額外空間對它進(jìn)行分配擔(dān)保，就必須使用”標(biāo)記-清理“算法或者”標(biāo)記-整理“算法。
垃圾收集器
堆內(nèi)存是垃圾收集器主要回收垃圾對象的地方，堆內(nèi)存可以根據(jù)對象生命周期的不同分為新生代和老年代，分代收集，新生代使用復(fù)制算法，老年代使用標(biāo)記清除或者標(biāo)記整理算法。
HotSpot虛擬機(jī)提供了7中垃圾收集器，其中新生代三種：Serial/ParNew/Parallel Scavenge收集器，老年代三種：Serial Old/Parallel Old/CMS，都適用的是G1收集器。所有垃圾收集器組合 情況如下圖：
Serial收集器
最基本也是發(fā)展歷史最長的垃圾收集器，在進(jìn)行垃圾收集時(shí)，必須Stop The World(暫停其他工作線程)，直到收集結(jié)束。只使用一條線程完成垃圾收集，但是效率高，因?yàn)闆]有線程交互的開銷，擁有更高的單線程收集效率。發(fā)生在新生代區(qū)域，使用復(fù)制算法。
ParNew收集器
Serial收集器的多線程版本。在進(jìn)行垃圾收集時(shí)同樣需要Stop The World（暫停其他工作線程），直到收集結(jié)束。使用多條線程進(jìn)行垃圾收集（由于存在線程交互的開銷，所以在單CPU的環(huán)境下，性能差于Serial收集器）。目前，只有Parnew收集器能與CMS收集器配合工作。發(fā)生在新生代區(qū)域，使用復(fù)制算法。
Parallel Scavenge收集器
ParNew收集器的升級版，具備ParNew收集器并發(fā)多線程收集的特點(diǎn)，以達(dá)到可控制吞吐量為目標(biāo)。（吞吐量：CPU用于運(yùn)行用戶代碼的時(shí)間與CPU總消耗時(shí)間（運(yùn)行用戶代碼時(shí)間+垃圾收集時(shí)間）的比值）。該垃圾收集器能根據(jù)當(dāng)前系統(tǒng)運(yùn)行情況，動(dòng)態(tài)調(diào)整自身參數(shù)，從而達(dá)到最大吞吐量的目標(biāo)。（該特性成為GC自適應(yīng)的調(diào)節(jié)策略）。發(fā)生在新生代，使用復(fù)制算法。
Serial Old收集器
Serial 收集器應(yīng)用在老年代的版本。并發(fā)、單線程、效率高。使用標(biāo)記整理算法。
Parallel Old收集器
是Parallel Scavenge應(yīng)用在老年代的版本，以達(dá)到可控制吞吐量、自適應(yīng)調(diào)節(jié)和多線程收集為目標(biāo)，使用標(biāo)記整理算法。
CMS收集器
CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時(shí)間為目標(biāo)的收集器。使用這類收集器的應(yīng)用重視服務(wù)的響應(yīng)速度，希望系統(tǒng)停頓時(shí)間最短，以帶來更好的用戶體驗(yàn)。
使用標(biāo)記清除算法，一共四個(gè)步驟：初始標(biāo)記、并發(fā)標(biāo)記、重新標(biāo)記和并發(fā)清除。詳情見下表：
下面說下CMS的優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)：（1）并行：用戶線程和垃圾收集線程同時(shí)進(jìn)行。
（2）單線程收集：只使用一條線程完成垃圾收集。
（3）垃圾收集停頓時(shí)間短：獲取最短的回收停頓時(shí)間，即希望系統(tǒng)停頓的時(shí)間最短，提高響應(yīng)速度。
缺點(diǎn)：
（1）總吞吐量會(huì)降低：因?yàn)樵撌占鲗PU資源非常敏感，在并發(fā)階段不會(huì)導(dǎo)致停頓用戶線程，但會(huì)因?yàn)檎加貌糠志€程（CPU資源）導(dǎo)致應(yīng)用程序變慢，總吞吐量會(huì)降低。
（2）無法處理浮動(dòng)垃圾：由于并發(fā)清理時(shí)用戶線程還在運(yùn)行，所以會(huì)有新的垃圾不斷產(chǎn)生，只能等到下一次GC時(shí)再清理。（因?yàn)檫@一部分垃圾出現(xiàn)在標(biāo)記過程之后，所以CMS 無法在當(dāng)次GC中處理他們，因此CMS無法等到老年代填滿再進(jìn)行Full GC，CMS需要預(yù)留一部分空間）。
（3）垃圾收集后會(huì)產(chǎn)生大量的內(nèi)存碎片：因?yàn)镃MS收集器是使用標(biāo)記-清除算法的。
下面一張圖了解下CMS的工作過程：
G1收集器
G1收集器是最新最前沿的垃圾收集器。特點(diǎn)如下：
（1）并行：用戶線程和垃圾收集線程同時(shí)進(jìn)行。
（2）多線程：即使用多條垃圾收集線程進(jìn)行垃圾回收。（并發(fā)和并行充分利用多CPU和多核環(huán)境的硬件優(yōu)勢來縮短垃圾收集的停頓時(shí)間）
（3）垃圾收集效率高：G1收集器是針對性對Java堆內(nèi)存區(qū)域進(jìn)行垃圾收集，而非每次都對整個(gè)區(qū)域進(jìn)行收集。即G1除了將Java堆內(nèi)存分為新生代和老年代之外，還會(huì)細(xì)分為許多個(gè) 大小相等的獨(dú)立區(qū)域（Region），然后G1收集器會(huì)跟蹤每個(gè)Region里的垃圾代價(jià)值大小，并在后臺維護(hù)一個(gè)列表。每次回收時(shí)，會(huì)根據(jù)允許的垃圾收集時(shí)間優(yōu)先回收價(jià)值最大的 Region，從而避免了對整個(gè)Java堆內(nèi)存區(qū)域的回收，提高了效率。因?yàn)樯鲜鰴C(jī)制，G1收集器還能建立可預(yù)測的時(shí)間模型：即讓使用者明確執(zhí)行一個(gè)長度為M毫秒的時(shí)間片段，消耗在 垃圾收集上的時(shí)間不得超出N毫秒。即具備實(shí)時(shí)性。
（4）不會(huì)產(chǎn)生內(nèi)存碎片。從整理上看，G1收集器是基于標(biāo)記-整理算法的，從局部看是基于復(fù)制算法的。在新生代使用復(fù)制算法，在老年代使用標(biāo)記-整理算法。
下面了解下工作流程，跟CMS有點(diǎn)像。
下面是G1的工作過程：
類加載過程
在java中編譯并不進(jìn)行鏈接工作，類型的加載、鏈接和初始化工作都是在jvm執(zhí)行過程中進(jìn)行的。在Java程序啟動(dòng)時(shí)，jvm通過加載指定的類，然后調(diào)用該類的main方法而啟動(dòng)。在JVM啟動(dòng)過程中， 外部class字節(jié)碼文件會(huì)經(jīng)過一系列過程轉(zhuǎn)化為JVM中執(zhí)行的數(shù)據(jù)，這一系列過程我們稱為類加載過程。
類加載整體流程
從類被JVM加載到內(nèi)存開始到卸載出內(nèi)存為止，整個(gè)生命周期包括：加載、鏈接、初始化、使用和卸載五個(gè)過程。其中鏈接又包括驗(yàn)證、準(zhǔn)備和解析三個(gè)過程。如下圖所示：
類加載時(shí)機(jī)
java虛擬機(jī)規(guī)范通過對初始化階段進(jìn)行嚴(yán)格規(guī)定，來保證初始化的完成，而作為其之前的必須啟動(dòng)的過程，加載、驗(yàn)證、準(zhǔn)備也需要在此之前開始。
Java虛擬機(jī)規(guī)定，以下五種情況必須對類進(jìn)行初始化：1、虛擬機(jī)在用戶指定包含main方法的主類后啟動(dòng)時(shí)，必須先對主類進(jìn)行初始化。
2、當(dāng)使用new關(guān)鍵字對類進(jìn)行實(shí)例化時(shí)、讀取或者寫入類的靜態(tài)字段時(shí)、調(diào)用類的靜態(tài)方法時(shí)，必須先觸發(fā)對該類的實(shí)例化。
3、使用反射對類進(jìn)行反射調(diào)用時(shí)，如果該類沒有初始化先對其進(jìn)行初始化。
4、初始化一個(gè)類，而該類的父類還未初始化，需要先對其父類進(jìn)行初始化。
5、在JDK1.7之后的版本中使用動(dòng)態(tài)語言支持，java.lang.invoke.MethodHandle實(shí)例解析的結(jié)果是REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，而該句柄對應(yīng)的類 還未初始化，必須先觸發(fā)其實(shí)例化。
加載
在加載階段，虛擬機(jī)需要完成三件事：
1、通過一個(gè)類的全限定名來獲取此類的class字節(jié)碼二進(jìn)制流。
2.將這個(gè)字節(jié)碼二進(jìn)制流中的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)中的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)。
3、在內(nèi)存中生成一個(gè)代表該類的java.lang.Class對象，作為方法區(qū)中這個(gè)類的各種數(shù)據(jù)的訪問入口。
對于Class對象，Java虛擬機(jī)規(guī)范并沒有規(guī)定要存儲在堆中，HotSpot虛擬機(jī)將其存放在方法區(qū)中。
驗(yàn)證
驗(yàn)證作為鏈接的第一步，大致會(huì)完成四個(gè)階段的檢驗(yàn)：
1、文件格式驗(yàn)證：該階段主要在字節(jié)流轉(zhuǎn)化為方法區(qū)中的運(yùn)行時(shí)數(shù)據(jù)時(shí)，負(fù)責(zé)檢查字節(jié)流是否符合Class文件規(guī)范，保證其可以正確的被解析并存儲在方法區(qū)中。后面的檢查都是基于方法區(qū)的 存儲結(jié)構(gòu)進(jìn)行檢驗(yàn)，不會(huì)再直接操作字節(jié)流。
2、元數(shù)據(jù)驗(yàn)證：該階段負(fù)責(zé)分析存儲于方法區(qū)的結(jié)構(gòu)是否符合Java語言規(guī)范。此階段進(jìn)行數(shù)據(jù)類型的校驗(yàn)，保證符合不存在非法的元數(shù)據(jù)信息。
3、字節(jié)碼驗(yàn)證：元數(shù)據(jù)驗(yàn)證保證了字節(jié)碼中的數(shù)據(jù)符合語言的規(guī)范，該階段則負(fù)責(zé)分析數(shù)據(jù)流和控制流，確定方法體的合法性，保證被校驗(yàn)的方法在運(yùn)行時(shí)不會(huì)危害虛擬機(jī)的運(yùn)行。
4、符號引用驗(yàn)證：在解析階段會(huì)將虛擬機(jī)中的符號引用轉(zhuǎn)化為直接引用，該階段則負(fù)責(zé)對各種符號引用進(jìn)行匹配性校驗(yàn)，保證外部依賴真實(shí)存在，并且符合外部依賴類、字段、方法的訪問性。
準(zhǔn)備
準(zhǔn)備階段正式為類的字段變量（被static修飾的類變量）分配內(nèi)存并設(shè)置初始值。這些變量存儲在方法區(qū)中。當(dāng)類字段為常量類型（即被static final修飾），由于字段的值已經(jīng)確定，并不會(huì)在后面修改，此時(shí)會(huì)直接賦值為指定的值。
解析
解析階段將常量池中的符號引用替換為直接引用。在字節(jié)碼文件中，類、接口、字段、方法等類型都是由一組符號來表示。其形式由java虛擬機(jī)規(guī)范中的Class文件格式定義。在虛擬機(jī)執(zhí)行 指定指令之前，需要將符號引用轉(zhuǎn)化為目標(biāo)的指針、相對偏移量或者句柄，這樣可以通過此類直接引用在內(nèi)存中定位調(diào)用的具體位置。
初始化
在類的class文件中。包含兩個(gè)特殊的方法：clinit和init，這兩方法由編譯器自動(dòng)生成，分別代表類構(gòu)造器和構(gòu)造函數(shù)，其中構(gòu)造函數(shù)編程實(shí)現(xiàn)，初始化階段就是負(fù)責(zé)調(diào)用類構(gòu)造器，來初始化 變量和資源。
clinit方法由編譯器自動(dòng)收集類的賦值動(dòng)作和靜態(tài)語句塊（static）中的語句合并生成的，有以下特點(diǎn)：
1、編譯器收集順序又代碼順序決定，靜態(tài)語句塊只能訪問它之前定義的變量，在它之后定義的變量只能進(jìn)行賦值不能訪問。
2、虛擬機(jī)保證在子類的clinit方法執(zhí)行前，父類的clinit已經(jīng)執(zhí)行完畢。
3、clinit不是必須的，如果一個(gè)類或接口沒有變量賦值和靜態(tài)代碼塊，則編譯器可以不生成clinit。
4、虛擬機(jī)會(huì)保證clinit方法在多線程中被正確的加鎖和同步。如果多個(gè)線程同時(shí)初始化一個(gè)類，那么只有一個(gè)線程執(zhí)行clinit，其他線程會(huì)被阻塞。
雙親委派模型
類加載器
1、定義：實(shí)現(xiàn)類加載階段的“通過一個(gè)里的全限定名來獲取描述此類的二進(jìn)制字節(jié)流”的動(dòng)作的代碼模塊成為“類加載器”。對于任意一個(gè)類，都需要由加載它的類加載器和這個(gè)類本身一同確立其在java虛擬機(jī)中的唯一性，每一個(gè)類加載器，都擁有一個(gè)獨(dú)立的類名稱空間。比較兩個(gè)類是否“相等”，只有在這兩個(gè)類是同一個(gè)類加載器加載的前提下才有意義。
2、類加載器種類
從Java虛擬機(jī)的角度只有兩種類加載器：
（1）啟動(dòng)類加載器（BootStrap ClassLoader），這個(gè)類加載器使用C++語言實(shí)現(xiàn)，是虛擬機(jī)自身的一部分。
（2）另一種就是所有其他類的加載器，這些類加載器都是由Java語言實(shí)現(xiàn)，獨(dú)立于虛擬機(jī)外部，并且都繼承自抽象類java.lang.ClassLoader。
從Java開發(fā)人員的角度，類加載器還可分為3種系統(tǒng)提供的類加載器和用戶自定義的類加載器。
（1）啟動(dòng)類加載器（BootStrap ClassLoader）：負(fù)責(zé)加載存放java_homelib目錄中的，或者被-Xbootclasspath參數(shù)所指定的路徑中的類。
（2）擴(kuò)展類加載器（Extension ClassLoader）：這個(gè)加載器sun.misc.LauncherExtClassLoader實(shí)現(xiàn)，它負(fù)責(zé)加載javahomelibext目錄中的，或者被java.ext.dirs系統(tǒng)變量所指定的路徑中的所有類庫，開發(fā)者可以直接使用擴(kuò)展類加載器。
（3）應(yīng)用程序類加載器（ApplicationClassLoader）：這個(gè)類加載器由sun.misc.LauncherExtClassLoader實(shí)現(xiàn)，它負(fù)責(zé)加載java_homelibext目錄中的，或者被java.ext.dirs系統(tǒng)變量所指定的路徑中的所有類庫，開發(fā)者可以直接使用擴(kuò)展類加載器。 如果應(yīng)用程序中沒有自定義的類加載器，一般情況下 這個(gè)就是程序中默認(rèn)的類加載器。
（4）自定義類加載器（User ClassLoader）：用戶自定義的類加載器。用戶在編寫自己定義的類加載器時(shí)，如果需要把請求委派給引導(dǎo)類加載器，那直接使用numm代替即可。要?jiǎng)?chuàng)建用戶自己 的類加載器，只需要繼承java.lang.ClassLoader，然后覆蓋它的findClass(String name)方法即可。如果要符合雙親委派模型，則重寫findClass()方法。如果要破壞的話，則重寫 loadClass()方法。
雙親委派模型
上圖展示的類加載器之間的這種層次關(guān)系稱為類加載器的雙親委派模型。1、雙親委派模型要求除了頂層的啟動(dòng)類加載器之外，其余的類加載器都應(yīng)當(dāng)有自己的父類加載器。
2、類加載器的雙親委派模型在jdk1.2被引入，但它不是一個(gè)強(qiáng)制性的約束模型，而是Java設(shè)計(jì)者推薦給開發(fā)者的一種類加載器的實(shí)現(xiàn)方式。
雙親委派模型的工作過程如下：
1、如果一個(gè)類加載器收到了類加載的請求，它首先不會(huì)自己去嘗試加載這個(gè)類，而是把這個(gè)請求委派給父類加載器去完成。
2、每一層的類加載器都重復(fù)第一步，因此所有的類加載請求最終都傳送到了頂層的類加載器中。
3、只有父類加載器返回自己無法完成這個(gè)加載請求，子加載器才會(huì)嘗試自己去加載。
對象的創(chuàng)建、存儲和訪問
對象的創(chuàng)建
1、類加載檢查：虛擬機(jī)遇到一條new指令，首先檢查這個(gè)指令的參數(shù)是否能在常量池中（Class文件的靜態(tài)常量池）定位到這個(gè)類的符號引用，并且檢查這個(gè)符號引用代表的類是否 已經(jīng)被加載、解析和初始化過。如果沒有，那必須先執(zhí)行相應(yīng)的類加載過程。
2、分配內(nèi)存：對象所需內(nèi)存大小在類加載完成后便可完全確定，為對象分配空間的任務(wù)等同于把一塊確定大小的內(nèi)存從Java堆中劃分出來。但是不同垃圾回收器的算法會(huì)導(dǎo)致堆內(nèi)存存在兩種情況：絕對規(guī)整和相互交錯(cuò)。（比如標(biāo)記清楚算法和標(biāo)記整理算法）
（1）指針碰撞：假設(shè)Java堆內(nèi)存是絕對規(guī)整的，所有用過的內(nèi)存都存放在一起，空閑的內(nèi)存存放在另一邊，中間放著一個(gè)指示器作為分界點(diǎn)的指示器，所分配的內(nèi)存就僅僅是把那個(gè)指針向空閑空間那邊挪動(dòng)一段與對象大小相等的距離，這種分配方式成為”指針碰撞“。
（2）空閑列表：如果是相互交錯(cuò)的，那么虛擬機(jī)會(huì)維護(hù)一個(gè)列表，記錄哪些內(nèi)存塊是可用的，在分配的時(shí)候從列表中找到一塊足夠大的空間劃給對象實(shí)例，并更新列表上的記錄。這種分配方式成為”空閑列表“。
3、分配內(nèi)存的并發(fā)問題：即使是僅僅修改一個(gè)指針?biāo)赶虻奈恢?#xff0c;在并發(fā)情況下也不是線程安全的，可能出現(xiàn)正在給對象A分配內(nèi)存，指針還沒來得及修改，對象B又同時(shí)使用了原來的 指針來分配內(nèi)存的情況。針對這個(gè)問題有兩種解決方案：
（1）失敗重試：對分配內(nèi)存空間的動(dòng)作進(jìn)行同步處理，虛擬機(jī)采用CAS和失敗重試機(jī)制保證更新操作的原子性。
（2）本地線程分配緩存：哪個(gè)線程要分配內(nèi)存，就在哪個(gè)線程的TLAB（Thread Local Allocation Buffer）上分配，只有TLAB用完并分配新的TLAB時(shí)，才需要同步鎖定。
4、內(nèi)存空間初始化零值：內(nèi)存分配完成后，虛擬機(jī)需要將分配到的內(nèi)存空間都初始化零值，這一步操作保證了對象的實(shí)例字段（成員變量）在Java代碼中可以不賦值就直接使用，程序能夠訪問到這些字段的數(shù)據(jù)類型所對應(yīng)的零值。
5、對象設(shè)置：接下來虛擬機(jī)會(huì)對對象進(jìn)行必要的設(shè)置，例如這個(gè)對象是哪個(gè)類的實(shí)例，如何才能找到類的元數(shù)據(jù)信息、對象的哈希嗎、對象的GC分代年齡等信息。這些信息存放在對象頭中。至此一個(gè)新的對象產(chǎn)生了。
6、實(shí)例構(gòu)造器的init方法：雖然對象產(chǎn)生了，但是init方法并沒有執(zhí)行，所欲字段還需要賦值（包括成員變量賦值，普通語句塊執(zhí)行，構(gòu)造函數(shù)執(zhí)行等。）
Clinit和init
Clinit
類構(gòu)造器的方法，與類的初始化有關(guān)。例如靜態(tài)變量（類變量）和靜態(tài)對象賦值，靜態(tài)語句塊的執(zhí)行。如果一個(gè)類中沒有靜態(tài)語句塊，也沒有靜態(tài)變量或靜態(tài)對象的賦值， 那么編譯器可以不為這個(gè)類生成方法。
init
實(shí)例構(gòu)造器（即成員變量，成員對象等），例如成員變量和成員對象的賦值，普通語句塊的執(zhí)行，構(gòu)造函數(shù)的執(zhí)行。
對象的內(nèi)存布局
在HotSpot虛擬機(jī)中，對象在內(nèi)存中存儲的布局可以分為三個(gè)區(qū)域：對象頭、實(shí)例數(shù)據(jù)和對齊填充。
對象頭
對象頭包括兩部分信息：運(yùn)行時(shí)數(shù)據(jù)和類型指針。
運(yùn)行時(shí)數(shù)據(jù)
第一部分用于存儲對象自身的運(yùn)行時(shí)數(shù)據(jù)，如哈希嗎（HashCode）、GC分代年齡、鎖狀態(tài)標(biāo)志、線程持有的鎖、偏向線程ID、偏向時(shí)間戳等。
下面是HotSpot虛擬機(jī)對象頭Mark Word：
類型指針
對象頭的另一部分是類型指針，即對象指向他元數(shù)據(jù)的指針，虛擬機(jī)可以通過這個(gè)指針確定這個(gè)對象是哪個(gè)類的實(shí)例。但是如果對象是一個(gè)Java數(shù)組，那么在對象頭中還必須有一塊用于記錄數(shù)據(jù)長度的數(shù)據(jù)。
對象的實(shí)例數(shù)據(jù)
接著數(shù)據(jù)頭的是對象的實(shí)例數(shù)據(jù)，這部分是真正存儲的有效信息。無論是從父類中繼承下來的還是在子類中定義的，都需要記錄下來。
對齊填充
最后一部分對齊填充并不是必然存在的，也沒有特別的含義，僅僅起著占位符的作用。由于HotSpot虛擬機(jī)的自動(dòng)內(nèi)存管理系統(tǒng)要求對象的起始地址必須是8字節(jié)的整數(shù)倍，也就是 對象的大小必須是8字節(jié)的整數(shù)倍。而對象頭部分是8字節(jié)的倍數(shù)，當(dāng)實(shí)例數(shù)據(jù)沒有對齊的時(shí)候，需要對齊填充湊夠8字節(jié)的整數(shù)倍。
對象的訪問定位
建立對象是為了使用對象，我們的Java程序需要通過棧上的引用數(shù)據(jù)來操作堆上的具體對象。對象的訪問方式取決于虛擬機(jī)的實(shí)現(xiàn)，目前主流的訪問方式有使用句柄和直接指針兩種。
句柄引用和直接引用不同在于：使用句柄引用的話，那么Java對堆中將會(huì)劃分出一塊內(nèi)存來作為句柄池，引用中存儲的就是對象的句柄地址，但是直接引用引用中存儲的直接就是對象地址。Java使用的是直接指針訪問對象的方式，因?yàn)樗畲蟮暮锰幘褪撬俣雀?#xff0c;它節(jié)省了一次指針定位的時(shí)間開銷，由于對象的訪問在Java中非常頻繁，因此這類開銷積少成多后也是一項(xiàng) 非?？捎^的執(zhí)行成本。
下面是通過直接指針訪問對象
總結(jié)
本文講解了運(yùn)行時(shí)數(shù)據(jù)區(qū)域，內(nèi)存溢出，如何判斷對象是否存活，垃圾回收算法和垃圾收集器，類加載機(jī)制和雙親委派模型以及對象的創(chuàng)建存儲和訪問幾個(gè)方面，涵蓋jvm的核心考點(diǎn)，希望你有所收獲。
來源：掘金
作者：堅(jiān)持就是勝利
鏈接：https://juejin.im/user/1943592288657022
總結(jié)
以上是生活随笔為你收集整理的浮点数例外 (核心已转储)_15000 字梳理 JVM 的核心知识的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mybatisplus or查询_Myb
- 下一篇： filesaver.js 保存文件路径_