Java記憶體區域
說一下 JVM 的主要組成部分及其作用？
JVM包含兩個子系統和兩個組件，兩個子系統為Class loader(類裝載)、Execution engine(執行引擎)；兩個組件為Runtime data area(運行時資料區)、Native Interface(本地介面)，
●Class loader(類裝載)：根據給定的全限定名類名(如：java.lang.Object)來裝載class檔案到Runtime data area中的method area，
●Execution engine（執行引擎）：執行classes中的指令，
●Native Interface(本地介面)：與native libraries互動，是其它編程語言互動的介面，
●Runtime data area(運行時資料區域)：這就是我們常說的JVM的記憶體，
作用 ：首先通過編譯器把 Java 代碼轉換成位元組碼，類加載器（ClassLoader）再把位元組碼加載到記憶體中，將其放在運行時資料區（Runtime data area）的方法區內，而位元組碼檔案只是 JVM 的一套指令集規范，并不能直接交給底層作業系統去執行，因此需要特定的命令決議器執行引擎（Execution Engine），將位元組碼翻譯成底層系統指令，再交由 CPU 去執行，而這個程序中需要呼叫其他語言的本地庫介面（Native Interface）來實作整個程式的功能，
下面是Java程式運行機制詳細說明
Java程式運行機制步驟
●首先利用IDE集成開發工具撰寫Java源代碼，源檔案的后綴為.java；
●再利用編譯器(javac命令)將源代碼編譯成位元組碼檔案，位元組碼檔案的后綴名為.class；
●運行位元組碼的作業是由解釋器(java命令)來完成的，
從上圖可以看，java檔案通過編譯器變成了.class檔案，接下來類加載器又將這些.class檔案加載到JVM中，
其實可以一句話來解釋：類的加載指的是將類的.class檔案中的二進制資料讀入到記憶體中，將其放在運行時資料區的方法區內，然后在堆區創建一個 java.lang.Class物件，用來封裝類在方法區內的資料結構，
說一下 JVM 運行時資料區
Java 虛擬機在執行 Java 程式的程序中會把它所管理的記憶體區域劃分為若干個不同的資料區域，這些區域都有各自的用途，以及創建和銷毀的時間，有些區域隨著虛擬機行程的啟動而存在，有些區域則是依賴執行緒的啟動和結束而建立和銷毀，Java 虛擬機所管理的記憶體被劃分為如下幾個區域：
不同虛擬機的運行時資料區可能略微有所不同，但都會遵從 Java 虛擬機規范， Java 虛擬機規范規定的區域分為以下 5 個部分：
●程式計數器（Program Counter Register）：當前執行緒所執行的位元組碼的行號指示器，位元組碼決議器的作業是通過改變這個計數器的值，來選取下一條需要執行的位元組碼指令，分支、回圈、跳轉、例外處理、執行緒恢復等基礎功能，都需要依賴這個計數器來完成；
●Java 虛擬機堆疊（Java Virtual Machine Stacks）：用于存盤區域變數表、運算元堆疊、動態鏈接、方法出口等資訊；
●本地方法堆疊（Native Method Stack）：與虛擬機堆疊的作用是一樣的，只不過虛擬機堆疊是服務 Java 方法的，而本地方法堆疊是為虛擬機呼叫 Native 方法服務的；
●Java 堆（Java Heap）：Java 虛擬機中記憶體最大的一塊，是被所有執行緒共享的，幾乎所有的物件實體都在這里分配記憶體；
●方法區（Methed Area）：用于存盤已被虛擬機加載的類資訊、常量、靜態變數、即時編譯后的代碼等資料，
深拷貝和淺拷貝
淺拷貝（shallowCopy）只是增加了一個指標指向已存在的記憶體地址，
深拷貝（deepCopy）是增加了一個指標并且申請了一個新的記憶體，使這個增加的指標指向這個新的記憶體，
使用深拷貝的情況下，釋放記憶體的時候不會因為出現淺拷貝時釋放同一個記憶體的錯誤，
淺復制：僅僅是指向被復制的記憶體地址，如果原地址發生改變，那么淺復制出來的物件也會相應的改變，
深復制：在計算機中開辟一塊新的記憶體地址用于存放復制的物件，
說一下堆疊的區別？
物理地址
堆的物理地址分配對物件是不連續的，因此性能慢些，在GC的時候也要考慮到不連續的分配，所以有各種演算法，比如，標記-消除，復制，標記-壓縮，分代（即新生代使用復制演算法，老年代使用標記——壓縮）
堆疊使用的是資料結構中的堆疊，先進后出的原則，物理地址分配是連續的，所以性能快，
記憶體分別
堆因為是不連續的，所以分配的記憶體是在運行期確認的，因此大小不固定，一般堆大小遠遠大于堆疊，
堆疊是連續的，所以分配的記憶體大小要在編譯期就確認，大小是固定的，
存放的內容
堆存放的是物件的實體和陣列，因此該區更關注的是資料的存盤
堆疊存放：區域變數，運算元堆疊，回傳結果，該區更關注的是程式方法的執行，
PS：
1靜態變數放在方法區
2靜態的物件還是放在堆，
程式的可見度
堆對于整個應用程式都是共享、可見的，
堆疊只對于執行緒是可見的，所以也是執行緒私有，他的生命周期和執行緒相同，
佇列和堆疊是什么？有什么區別？
佇列和堆疊都是被用來預存盤資料的，
●操作的名稱不同，佇列的插入稱為入隊，佇列的洗掉稱為出隊，堆疊的插入稱為進堆疊，堆疊的洗掉稱為出堆疊，
●可操作的方式不同，佇列是在隊尾入隊，隊頭出隊，即兩邊都可操作，而堆疊的進堆疊和出堆疊都是在堆疊頂進行的，無法對堆疊底直接進行操作，
●操作的方法不同，佇列是先進先出（FIFO），即佇列的修改是依先進先出的原則進行的，新來的成員總是加入隊尾（不能從中間插入），每次離開的成員總是佇列頭上（不允許中途離隊），而堆疊為后進先出（LIFO）,即每次洗掉（出堆疊）的總是當前堆疊中最新的元素，即最后插入（進堆疊）的元素，而最先插入的被放在堆疊的底部，要到最后才能洗掉，
HotSpot虛擬機物件探秘
物件的創建
說到物件的創建，首先讓我們看看 Java 中提供的幾種物件創建方式：
下面是物件創建的主要流程:
虛擬機遇到一條new指令時，先檢查常量池是否已經加載相應的類，如果沒有，必須先執行相應的類加載，類加載通過后，接下來分配記憶體，若Java堆中記憶體是絕對規整的，使用“指標碰撞“方式分配記憶體；如果不是規整的，就從空閑串列中分配，叫做”空閑串列“方式，劃分記憶體時還需要考慮一個問題-并發，也有兩種方式: CAS同步處理，或者本地執行緒分配緩沖(Thread Local Allocation Buffer, TLAB)，然后記憶體空間初始化操作，接著是做一些必要的物件設定(元資訊、哈希碼…)，最后執行
為物件分配記憶體
類加載完成后，接著會在Java堆中劃分一塊記憶體分配給物件，記憶體分配根據Java堆是否規整，有兩種方式：
●指標碰撞：如果Java堆的記憶體是規整，即所有用過的記憶體放在一邊，而空閑的的放在另一邊，分配記憶體時將位于中間的指標指示器向空閑的記憶體移動一段與物件大小相等的距離，這樣便完成分配記憶體作業，
●空閑串列：如果Java堆的記憶體不是規整的，則需要由虛擬機維護一個串列來記錄那些記憶體是可用的，這樣在分配的時候可以從串列中查詢到足夠大的記憶體分配給物件，并在分配后更新串列記錄，
選擇哪種分配方式是由 Java 堆是否規整來決定的，而 Java 堆是否規整又由所采用的垃圾收集器是否帶有壓縮整理功能決定，
處理并發安全問題
物件的創建在虛擬機中是一個非常頻繁的行為，哪怕只是修改一個指標所指向的位置，在并發情況下也是不安全的，可能出現正在給物件 A 分配記憶體，指標還沒來得及修改，物件 B 又同時使用了原來的指標來分配記憶體的情況，解決這個問題有兩種方案：
●對分配記憶體空間的動作進行同步處理（采用 CAS + 失敗重試來保障更新操作的原子性）；
●把記憶體分配的動作按照執行緒劃分在不同的空間之中進行，即每個執行緒在 Java 堆中預先分配一小塊記憶體，稱為本地執行緒分配緩沖（Thread Local Allocation Buffer, TLAB），哪個執行緒要分配記憶體，就在哪個執行緒的 TLAB 上分配，只有 TLAB 用完并分配新的 TLAB 時，才需要同步鎖，通過-XX:+/-UserTLAB引數來設定虛擬機是否使用TLAB，
物件的訪問定位
Java程式需要通過 JVM 堆疊上的參考訪問堆中的具體物件，物件的訪問方式取決于 JVM 虛擬機的實作，目前主流的訪問方式有 句柄 和 直接指標 兩種方式，
指標： 指向物件，代表一個物件在記憶體中的起始地址，
句柄： 可以理解為指向指標的指標，維護著物件的指標，句柄不直接指向物件，而是指向物件的指標（句柄不發生變化，指向固定記憶體地址），再由物件的指標指向物件的真實記憶體地址，
句柄訪問
Java堆中劃分出一塊記憶體來作為句柄池，參考中存盤物件的句柄地址，而句柄中包含了物件實體資料與物件型別資料各自的具體地址資訊，具體構造如下圖所示：
優勢：參考中存盤的是穩定的句柄地址，在物件被移動（垃圾收集時移動物件是非常普遍的行為）時只會改變句柄中的實體資料指標，而參考本身不需要修改，
直接指標
如果使用直接指標訪問，參考 中存盤的直接就是物件地址，那么Java堆物件內部的布局中就必須考慮如何放置訪問型別資料的相關資訊，
優勢：速度更快，節省了一次指標定位的時間開銷，由于物件的訪問在Java中非常頻繁，因此這類開銷積少成多后也是非常可觀的執行成本，HotSpot 中采用的就是這種方式，
記憶體溢位例外
Java會存在記憶體泄漏嗎？請簡單描述
記憶體泄漏是指不再被使用的物件或者變數一直被占據在記憶體中，理論上來說，Java是有GC垃圾回識訓制的，也就是說，不再被使用的物件，會被GC自動回收掉，自動從記憶體中清除，
但是，即使這樣，Java也還是存在著記憶體泄漏的情況，java導致記憶體泄露的原因很明確：長生命周期的物件持有短生命周期物件的參考就很可能發生記憶體泄露，盡管短生命周期物件已經不再需要，但是因為長生命周期物件持有它的參考而導致不能被回收，這就是java中記憶體泄露的發生場景，
垃圾收集器
簡述Java垃圾回識訓制
在java中，程式員是不需要顯示的去釋放一個物件的記憶體的，而是由虛擬機自行執行，在JVM中，有一個垃圾回收執行緒，它是低優先級的，在正常情況下是不會執行的，只有在虛擬機空閑或者當前堆記憶體不足時，才會觸發執行，掃面那些沒有被任何參考的物件，并將它們添加到要回收的集合中，進行回收，
GC是什么？為什么要GC
GC 是垃圾收集的意思（Gabage Collection）,記憶體處理是編程人員容易出現問題的地方，忘記或者錯誤的記憶體
回識訓導致程式或系統的不穩定甚至崩潰，Java 提供的 GC 功能可以自動監測物件是否超過作用域從而達到自動
回收記憶體的目的，Java 語言沒有提供釋放已分配記憶體的顯示操作方法，
垃圾回收的優點和原理，并考慮2種回識訓制
java語言最顯著的特點就是引入了垃圾回識訓制，它使java程式員在撰寫程式時不再考慮記憶體管理的問題，
由于有這個垃圾回識訓制，java中的物件不再有“作用域”的概念，只有參考的物件才有“作用域”，
垃圾回識訓制有效的防止了記憶體泄露，可以有效的使用可使用的記憶體，
垃圾回收器通常作為一個單獨的低級別的執行緒運行，在不可預知的情況下對記憶體堆中已經死亡的或很長時間沒有用過的物件進行清除和回收，
程式員不能實時的對某個物件或所有物件呼叫垃圾回收器進行垃圾回收，
垃圾回收有分代復制垃圾回收、標記垃圾回收、增量垃圾回收，
垃圾回收器的基本原理是什么？垃圾回收器可以馬上回收記憶體嗎？有什么辦法主動通知虛擬機進行垃圾回收？
對于GC來說，當程式員創建物件時，GC就開始監控這個物件的地址、大小以及使用情況，
通常，GC采用有向圖的方式記錄和管理堆(heap)中的所有物件，通過這種方式確定哪些物件是"可達的"，哪些物件是"不可達的"，當GC確定一些物件為"不可達"時，GC就有責任回收這些記憶體空間，
可以，程式員可以手動執行System.gc()，通知GC運行，但是Java語言規范并不保證GC一定會執行，
Java 中都有哪些參考型別？
●強參考：發生 gc 的時候不會被回收，
●軟參考：有用但不是必須的物件，在發生記憶體溢位之前會被回收，
●弱參考：有用但不是必須的物件，在下一次GC時會被回收，
●虛參考（幽靈參考/幻影參考）：無法通過虛參考獲得物件，用 PhantomReference 實作虛參考，虛參考的用途是在 gc 時回傳一個通知，
怎么判斷物件是否可以被回收？
垃圾收集器在做垃圾回收的時候，首先需要判定的就是哪些記憶體是需要被回收的，哪些物件是「存活」的，是不可以被回收的；哪些物件已經「死掉」了，需要被回收，
一般有兩種方法來判斷：
●參考計數器法：為每個物件創建一個參考計數，有物件參考時計數器 +1，參考被釋放時計數 -1，當計數器為 0 時就可以被回收，它有一個缺點不能解決回圈參考的問題；
●可達性分析演算法：從 GC Roots 開始向下搜索，搜索所走過的路徑稱為參考鏈，當一個物件到 GC Roots 沒有任何參考鏈相連時，則證明此物件是可以被回收的，
在Java中，物件什么時候可以被垃圾回收
當物件對當前使用這個物件的應用程式變得不可觸及的時候，這個物件就可以被回收了，
垃圾回收不會發生在永久代，如果永久代滿了或者是超過了臨界值，會觸發完全垃圾回收(Full GC)，如果你仔細查看垃圾收集器的輸出資訊，就會發現永久代也是被回收的，這就是為什么正確的永久代大小對避免Full GC是非常重要的原因，
JVM中的永久代中會發生垃圾回收嗎
垃圾回收不會發生在永久代，如果永久代滿了或者是超過了臨界值，會觸發完全垃圾回收(Full GC)，如果你仔細查看垃圾收集器的輸出資訊，就會發現永久代也是被回收的，這就是為什么正確的永久代大小對避免Full GC是非常重要的原因，請參考下Java8：從永久代到元資料區
(譯者注：Java8中已經移除了永久代，新加了一個叫做元資料區的native記憶體區)
說一下 JVM 有哪些垃圾回收演算法？
●標記-清除演算法：標記無用物件，然后進行清除回收，缺點：效率不高，無法清除垃圾碎片，
●復制演算法：按照容量劃分二個大小相等的記憶體區域，當一塊用完的時候將活著的物件復制到另一塊上，然后再把已使用的記憶體空間一次清理掉，缺點：記憶體使用率不高，只有原來的一半，
●標記-整理演算法：標記無用物件，讓所有存活的物件都向一端移動，然后直接清除掉端邊界以外的記憶體，
●分代演算法：根據物件存活周期的不同將記憶體劃分為幾塊，一般是新生代和老年代，新生代基本采用復制演算法，老年代采用標記整理演算法，
標記-清除演算法
標記無用物件，然后進行清除回收，
標記-清除演算法（Mark-Sweep）是一種常見的基礎垃圾收集演算法，它將垃圾收集分為兩個階段：
●標記階段：標記出可以回收的物件，
●清除階段：回收被標記的物件所占用的空間，
標記-清除演算法之所以是基礎的，是因為后面講到的垃圾收集演算法都是在此演算法的基礎上進行改進的，
優點：實作簡單，不需要物件進行移動，
缺點：標記、清除程序效率低，產生大量不連續的記憶體碎片，提高了垃圾回收的頻率，
標記-清除演算法的執行的程序如下圖所示
復制演算法
為了解決標記-清除演算法的效率不高的問題，產生了復制演算法，它把記憶體空間劃為兩個相等的區域，每次只使用其中一個區域，垃圾收集時，遍歷當前使用的區域，把存活物件復制到另外一個區域中，最后將當前使用的區域的可回收的物件進行回收，
優點：按順序分配記憶體即可，實作簡單、運行高效，不用考慮記憶體碎片，
缺點：可用的記憶體大小縮小為原來的一半，物件存活率高時會頻繁進行復制，
復制演算法的執行程序如下圖所示
標記-整理演算法
在新生代中可以使用復制演算法，但是在老年代就不能選擇復制演算法了，因為老年代的物件存活率會較高，這樣會有較多的復制操作，導致效率變低，標記-清除演算法可以應用在老年代中，但是它效率不高，在記憶體回收后容易產生大量記憶體碎片，因此就出現了一種標記-整理演算法（Mark-Compact）演算法，與標記-整理演算法不同的是，在標記可回收的物件后將所有存活的物件壓縮到記憶體的一端，使他們緊湊的排列在一起，然后對端邊界以外的記憶體進行回收，回收后，已用和未用的記憶體都各自一邊，
優點：解決了標記-清理演算法存在的記憶體碎片問題，
缺點：仍需要進行區域物件移動，一定程度上降低了效率，
標記-整理演算法的執行程序如下圖所示
分代收集演算法
當前商業虛擬機都采用分代收集的垃圾收集演算法，分代收集演算法，顧名思義是根據物件的存活周期將記憶體劃分為幾塊，一般包括年輕代、老年代 和 永久代，如圖所示：
說一下 JVM 有哪些垃圾回收器？
如果說垃圾收集演算法是記憶體回收的方法論，那么垃圾收集器就是記憶體回收的具體實作，下圖展示了7種作用于不同分代的收集器，其中用于回收新生代的收集器包括Serial、PraNew、Parallel Scavenge，回收老年代的收集器包括Serial Old、Parallel Old、CMS，還有用于回收整個Java堆的G1收集器，不同收集器之間的連線表示它們可以搭配使用，
●Serial收集器（復制演算法): 新生代單執行緒收集器，標記和清理都是單執行緒，優點是簡單高效；
●ParNew收集器 (復制演算法): 新生代收并行集器，實際上是Serial收集器的多執行緒版本，在多核CPU環境下有著比Serial更好的表現；
●Parallel Scavenge收集器 (復制演算法): 新生代并行收集器，追求高吞吐量，高效利用 CPU，吞吐量 = 用戶執行緒時間/(用戶執行緒時間+GC執行緒時間)，高吞吐量可以高效率的利用CPU時間，盡快完成程式的運算任務，適合后臺應用等對互動相應要求不高的場景；
●Serial Old收集器 (標記-整理演算法): 老年代單執行緒收集器，Serial收集器的老年代版本；
●Parallel Old收集器 (標記-整理演算法)： 老年代并行收集器，吞吐量優先，Parallel Scavenge收集器的老年代版本；
●CMS(Concurrent Mark Sweep)收集器（標記-清除演算法）： 老年代并行收集器，以獲取最短回收停頓時間為目標的收集器，具有高并發、低停頓的特點，追求最短GC回收停頓時間，
●G1(Garbage First)收集器 (標記-整理演算法)： Java堆并行收集器，G1收集器是JDK1.7提供的一個新收集器，G1收集器基于“標記-整理”演算法實作，也就是說不會產生記憶體碎片，此外，G1收集器不同于之前的收集器的一個重要特點是：G1回收的范圍是整個Java堆(包括新生代，老年代)，而前六種收集器回收的范圍僅限于新生代或老年代，
詳細介紹一下 CMS 垃圾回收器？
CMS 是英文 Concurrent Mark-Sweep 的簡稱，是以犧牲吞吐量為代價來獲得最短回收停頓時間的垃圾回收器，對于要求服務器回應速度的應用上，這種垃圾回收器非常適合，在啟動 JVM 的引數加上“-XX:+UseConcMarkSweepGC”來指定使用 CMS 垃圾回收器，
CMS 使用的是標記-清除的演算法實作的，所以在 gc 的時候回產生大量的記憶體碎片，當剩余記憶體不能滿足程式運行要求時，系統將會出現 Concurrent Mode Failure，臨時 CMS 會采用 Serial Old 回收器進行垃圾清除，此時的性能將會被降低，
新生代垃圾回收器和老年代垃圾回收器都有哪些？有什么區別？
●新生代回收器：Serial、ParNew、Parallel Scavenge
●老年代回收器：Serial Old、Parallel Old、CMS
●整堆回收器：G1
新生代垃圾回收器一般采用的是復制演算法，復制演算法的優點是效率高，缺點是記憶體利用率低；老年代回收器一般采用的是標記-整理的演算法進行垃圾回收，
簡述分代垃圾回收器是怎么作業的？
分代回收器有兩個磁區：老生代和新生代，新生代默認的空間占比總空間的 1/3，老生代的默認占比是 2/3，
新生代使用的是復制演算法，新生代里有 3 個磁區：Eden、To Survivor、From Survivor，它們的默認占比是 8:1:1，它的執行流程如下：
●把 Eden + From Survivor 存活的物件放入 To Survivor 區；
●清空 Eden 和 From Survivor 磁區；
●From Survivor 和 To Survivor 磁區交換，From Survivor 變 To Survivor，To Survivor 變 From Survivor，
每次在 From Survivor 到 To Survivor 移動時都存活的物件，年齡就 +1，當年齡到達 15（默認配置是 15）時，升級為老生代，大物件也會直接進入老生代，
老生代當空間占用到達某個值之后就會觸發全域垃圾識訓，一般使用標記整理的執行演算法，以上這些回圈往復就構成了整個分代垃圾回收的整體執行流程，
記憶體分配策略
簡述java記憶體分配與回收策率以及Minor GC和Major GC
所謂自動記憶體管理，最終要解決的也就是記憶體分配和記憶體回收兩個問題，前面我們介紹了記憶體回收，這里我們再來聊聊記憶體分配，
物件的記憶體分配通常是在 Java 堆上分配（隨著虛擬機優化技術的誕生，某些場景下也會在堆疊上分配，后面會詳細介紹），物件主要分配在新生代的 Eden 區，如果啟動了本地執行緒緩沖，將按照執行緒優先在 TLAB 上分配，少數情況下也會直接在老年代上分配，總的來說分配規則不是百分百固定的，其細節取決于哪一種垃圾收集器組合以及虛擬機相關引數有關，但是虛擬機對于記憶體的分配還是會遵循以下幾種「普世」規則：
物件優先在 Eden 區分配
多數情況，物件都在新生代 Eden 區分配，當 Eden 區分配沒有足夠的空間進行分配時，虛擬機將會發起一次 Minor GC，如果本次 GC 后還是沒有足夠的空間，則將啟用分配擔保機制在老年代中分配記憶體，
這里我們提到 Minor GC，如果你仔細觀察過 GC 日常，通常我們還能從日志中發現 Major GC/Full GC，
●Minor GC 是指發生在新生代的 GC，因為 Java 物件大多都是朝生夕死，所有 Minor GC 非常頻繁，一般回收速度也非常快；
●Major GC/Full GC 是指發生在老年代的 GC，出現了 Major GC 通常會伴隨至少一次 Minor GC，Major GC 的速度通常會比 Minor GC 慢 10 倍以上，
大物件直接進入老年代
所謂大物件是指需要大量連續記憶體空間的物件，頻繁出現大物件是致命的，會導致在記憶體還有不少空間的情況下提前觸發 GC 以獲取足夠的連續空間來安置新物件，
前面我們介紹過新生代使用的是標記-清除演算法來處理垃圾回收的，如果大物件直接在新生代分配就會導致 Eden 區和兩個 Survivor 區之間發生大量的記憶體復制，因此對于大物件都會直接在老年代進行分配，
長期存活物件將進入老年代
虛擬機采用分代收集的思想來管理記憶體，那么記憶體回收時就必須判斷哪些物件應該放在新生代，哪些物件應該放在老年代，因此虛擬機給每個物件定義了一個物件年齡的計數器，如果物件在 Eden 區出生，并且能夠被 Survivor 容納，將被移動到 Survivor 空間中，這時設定物件年齡為 1，物件在 Survivor 區中每「熬過」一次 Minor GC 年齡就加 1，當年齡達到一定程度（默認 15） 就會被晉升到老年代，
虛擬機類加載機制
簡述java類加載機制?
虛擬機把描述類的資料從Class檔案加載到記憶體，并對資料進行校驗，決議和初始化，最終形成可以被虛擬機直接使用的java型別，
描述一下JVM加載Class檔案的原理機制
Java中的所有類，都需要由類加載器裝載到JVM中才能運行，類加載器本身也是一個類，而它的作業就是把class檔案從硬碟讀取到記憶體中，在寫程式的時候，我們幾乎不需要關心類的加載，因為這些都是隱式裝載的，除非我們有特殊的用法，像是反射，就需要顯式的加載所需要的類，
類裝載方式，有兩種 ：
1.隱式裝載， 程式在運行程序中當碰到通過new 等方式生成物件時，隱式呼叫類裝載器加載對應的類到jvm中，
2.顯式裝載， 通過class.forname()等方法，顯式加載需要的類
Java類的加載是動態的，它并不會一次性將所有類全部加載后再運行，而是保證程式運行的基礎類(像是基類)完全加載到jvm中，至于其他類，則在需要的時候才加載，這當然就是為了節省記憶體開銷，
什么是類加載器，類加載器有哪些?
實作通過類的權限定名獲取該類的二進制位元組流的代碼塊叫做類加載器，
主要有一下四種類加載器:
1啟動類加載器(Bootstrap ClassLoader)用來加載java核心類別庫，無法被java程式直接參考，
2擴展類加載器(extensions class loader):它用來加載 Java 的擴展庫，Java 虛擬機的實作會提供一個擴展庫目錄，該類加載器在此目錄里面查找并加載 Java 類，
3系統類加載器（system class loader）：它根據 Java 應用的類路徑（CLASSPATH）來加載 Java 類，一般來說，Java 應用的類都是由它來完成加載的，可以通過 ClassLoader.getSystemClassLoader()來獲取它，
4用戶自定義類加載器，通過繼承 java.lang.ClassLoader類的方式實作，
說一下類裝載的執行程序？
類裝載分為以下 5 個步驟：
●加載：根據查找路徑找到相應的 class 檔案然后匯入；
●驗證：檢查加載的 class 檔案的正確性；
●準備：給類中的靜態變數分配內存空間；
●決議：虛擬機將常量池中的符號參考替換成直接參考的程序，符號參考就理解為一個標示，而在直接參考直接指向記憶體中的地址；
●初始化：對靜態變數和靜態代碼塊執行初始化作業，
什么是雙親委派模型？
在介紹雙親委派模型之前先說下類加載器，對于任意一個類，都需要由加載它的類加載器和這個類本身一同確立在 JVM 中的唯一性，每一個類加載器，都有一個獨立的類名稱空間，類加載器就是根據指定全限定名稱將 class 檔案加載到 JVM 記憶體，然后再轉化為 class 物件，
類加載器分類：
●啟動類加載器（Bootstrap ClassLoader），是虛擬機自身的一部分，用來加載Java_HOME/lib/目錄中的，或者被 -Xbootclasspath 引數所指定的路徑中并且被虛擬機識別的類別庫；
●其他類加載器：
●擴展類加載器（Extension ClassLoader）：負責加載\lib\ext目錄或Java. ext. dirs系統變數指定的路徑中的所有類別庫；
●應用程式類加載器（Application ClassLoader），負責加載用戶類路徑（classpath）上的指定類別庫，我們可以直接使用這個類加載器，一般情況，如果我們沒有自定義類加載器默認就是用這個加載器，
雙親委派模型：如果一個類加載器收到了類加載的請求，它首先不會自己去加載這個類，而是把這個請求委派給父類加載器去完成，每一層的類加載器都是如此，這樣所有的加載請求都會被傳送到頂層的啟動類加載器中，只有當父加載無法完成加載請求（它的搜索范圍中沒找到所需的類）時，子加載器才會嘗試去加載類，
當一個類收到了類加載請求時，不會自己先去加載這個類，而是將其委派給父類，由父類去加載，如果此時父類不能加載，反饋給子類，由子類去完成類的加載，
JVM調優
說一下 JVM 調優的工具？
JDK 自帶了很多監控工具，都位于 JDK 的 bin 目錄下，其中最常用的是 jconsole 和 jvisualvm 這兩款視圖監控工具，
●jconsole：用于對 JVM 中的記憶體、執行緒和類等進行監控；
●jvisualvm：JDK 自帶的全能分析工具，可以分析：記憶體快照、執行緒快照、程式死鎖、監控記憶體的變化、gc 變化等，
常用的 JVM 調優的引數都有哪些？
●-Xms2g：初始化推大小為 2g；
●-Xmx2g：堆最大記憶體為 2g；
●-XX:NewRatio=4：設定年輕的和老年代的記憶體比例為 1:4；
●-XX:SurvivorRatio=8：設定新生代 Eden 和 Survivor 比例為 8:2；
●–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器組合；
●-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器組合；
●-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器組合；
●-XX:+PrintGC：開啟列印 gc 資訊；
●-XX:+PrintGCDetails：列印 gc 詳細資訊，
青山不改，綠水常流，謝謝大家支持！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/548897.html
標籤：其他