1、java中會存在內(nèi)存泄漏嗎，請簡單描述。

會。自己實(shí)現(xiàn)堆載的數(shù)據(jù)結(jié)構(gòu)時(shí)有可能會出現(xiàn)內(nèi)存泄露，可參看e?ective java.

2、64 位 JVM 中，int 的長度是多數(shù)？

Java 中，int 類型變量的長度是一個(gè)固定值，與平臺無關(guān)，都是 32 位。意思就是說，在 32 位 和 64 位 的 Java 虛擬機(jī)中，int 類型的長度是相同的。

3、Serial 與 Parallel GC 之間的不同之處？

Serial 與 Parallel 在 GC 執(zhí)行的時(shí)候都會引起 stop-the-world。它們之間主要不同 serial 收集器是默認(rèn) 的復(fù)制收集器，執(zhí)行 GC 的時(shí)候只有一個(gè)線程，而parallel 收集器使用多個(gè) GC 線程來執(zhí)行。

4、32 位和 64 位的 JVM，int 類型變量的長度是多數(shù)？

32 位和 64 位的 JVM 中，int 類型變量的長度是相同的，都是 32 位或者 4個(gè)字節(jié)。

5、Java 中 WeakReference 與 SoftReference 的區(qū)別？

雖然 WeakReference 與 SoftReference 都有利于提高 GC 和 內(nèi)存的效率，但是 WeakReference ，一 旦失去最后一個(gè)強(qiáng)引用，就會被 GC 回收，而軟引用雖然不能阻止被回收，但是可以延遲到 JVM 內(nèi)存不 足的時(shí)候。

6、JVM 選項(xiàng) -XX:+UseCompressedOops 有什么作用？為什么要 使用

當(dāng)你將你的應(yīng)用從 32 位的 JVM 遷移到 64 位的 JVM 時(shí)，由于對象的指針從32 位增加到了 64 位，因此 堆內(nèi)存會突然增加，差不多要翻倍。這也會對 CPU緩存（容量比內(nèi)存小很多）的數(shù)據(jù)產(chǎn)生不利的影響。 因?yàn)椋w移到 64 位的 JVM主要?jiǎng)訖C(jī)在于可以指定最大堆大小，通過壓縮 OOP 可以節(jié)省一定的內(nèi)存。 通過-XX:+UseCompressedOops 選項(xiàng)，JVM 會使用 32 位的 OOP，而不是 64 位的 OOP。

7、怎樣通過 Java 程序來判斷 JVM 是 32 位 還是 64位？

你可以檢查某些系統(tǒng)屬性如 sun.arch.data.model 或 os.arch 來獲取該信息。

8、32 位 JVM 和 64 位 JVM 的最大堆內(nèi)存分別是多數(shù)？

理論上說上 32 位的 JVM 堆內(nèi)存可以到達(dá) 2^32，即 4GB，但實(shí)際上會比這個(gè)小很多。不同操作系統(tǒng)之 間不同，如 Windows 系統(tǒng)大約 1.5 GB，Solaris 大約3GB。64 位 JVM 允許指定最大的堆內(nèi)存，理論上 可以達(dá)到 2^64，這是一個(gè)非常大的數(shù)字，實(shí)際上你可以指定堆內(nèi)存大小到 100GB。甚至有的 JVM，如 Azul，堆內(nèi)存到 1000G 都是可能的。

9、JRE、JDK、JVM 及 JIT 之間有什么不同？

JRE 代表 Java 運(yùn)行時(shí)（Java run-time），是運(yùn)行 Java 引用所必須的。JDK 代表 Java 開發(fā)工具（Java development kit），是 Java 程序的開發(fā)工具，如 Java編譯器，它也包含 JRE。JVM 代表 Java 虛擬機(jī) （Java virtual machine），它的責(zé)任是運(yùn)行 Java 應(yīng)用。JIT 代表即時(shí)編譯（Just In Time compilation），當(dāng)代碼執(zhí)行的次數(shù)超過一定的閾值時(shí)，會將 Java 字節(jié)碼轉(zhuǎn)換為本地代碼，如，主要的 熱點(diǎn)代碼會被準(zhǔn)換為本地代碼，這樣有利大幅度提高 Java 應(yīng)用的性能。

10、解釋 Java 堆空間及 GC？

當(dāng)通過 Java 命令啟動(dòng) Java 進(jìn)程的時(shí)候，會為它分配內(nèi)存。內(nèi)存的一部分用于創(chuàng)建堆空間，當(dāng)程序中創(chuàng) 建對象的時(shí)候，就從對空間中分配內(nèi)存。GC 是 JVM 內(nèi)部的一個(gè)進(jìn)程，回收無效對象的內(nèi)存用于將來的 分配。

11、JVM 內(nèi)存區(qū)域

JVM 內(nèi)存區(qū)域主要分為線程私有區(qū)域【程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法區(qū)】、線程共享區(qū)域【JAVA 堆、方法區(qū)】、直接內(nèi)存。
線程私有數(shù)據(jù)區(qū)域生命周期與線程相同, 依賴用戶線程的啟動(dòng)/結(jié)束 而 創(chuàng)建/銷毀(在 Hotspot VM 內(nèi), 每 個(gè)線程都與操作系統(tǒng)的本地線程直接映射, 因此這部分內(nèi)存區(qū)域的存/否跟隨本地線程的生/死對應(yīng))。
線程共享區(qū)域隨虛擬機(jī)的啟動(dòng)/關(guān)閉而創(chuàng)建/銷毀。
直接內(nèi)存并不是 JVM 運(yùn)行時(shí)數(shù)據(jù)區(qū)的一部分, 但也會被頻繁的使用: 在 JDK 1.4 引入的 NIO 提供了基于 Channel 與 Bu?er 的 IO 方式, 它可以使用 Native 函數(shù)庫直接分配堆外內(nèi)存, 然后使用 DirectByteBu?er 對象作為這塊內(nèi)存的引用進(jìn)行操作(詳見: Java I/O 擴(kuò)展), 這樣就避免了在 Java堆和 Native 堆中來回復(fù)制數(shù)據(jù), 因此在一些場景中可以顯著提高性能。

12、程序計(jì)數(shù)器(線程私有)

一塊較小的內(nèi)存空間, 是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器，每條線程都要有一個(gè)獨(dú)立的程序計(jì)數(shù) 器，這類內(nèi)存也稱為“線程私有” 的內(nèi)存。
正在執(zhí)行 java 方法的話，計(jì)數(shù)器記錄的是虛擬機(jī)字節(jié)碼指令的地址（當(dāng)前指令的地址） 。如果還是 Native 方法，則為空。
這個(gè)內(nèi)存區(qū)域是唯一一個(gè)在虛擬機(jī)中沒有規(guī)定任何 OutOfMemoryError 情況的區(qū)域。

13、虛擬機(jī)棧(線程私有)

是描述java方法執(zhí)行的內(nèi)存模型，每個(gè)方法在執(zhí)行的同時(shí)都會創(chuàng)建一個(gè)棧幀（Stack Frame）用于存儲 局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等信息。 每一個(gè)方法從調(diào)用直至執(zhí)行完成的過程，就對應(yīng) 著一個(gè)棧幀在虛擬機(jī)棧中入棧到出棧的過程。

棧幀（ Frame）是用來存儲數(shù)據(jù)和部分過程結(jié)果的數(shù)據(jù)結(jié)構(gòu)，同時(shí)也被用來處理動(dòng)態(tài)鏈接(Dynamic Linking)、 方法返回值和異常分派（ Dispatch Exception）。 棧幀隨著方法調(diào)用而創(chuàng)建，隨著方法結(jié)束 而銷毀——無論方法是正常完成還是異常完成（拋出了在方法內(nèi)未被捕獲的異常）都算作方法結(jié)束。

14、本地方法區(qū)(線程私有)

本地方法區(qū)和 Java Stack 作用類似, 區(qū)別是虛擬機(jī)棧為執(zhí)行 Java 方法服務(wù), 而本地方法棧則為Native 方 法服務(wù), 如果一個(gè) VM 實(shí)現(xiàn)使用 C-linkage 模型來支持 Native 調(diào)用, 那么該棧將會是一個(gè)C 棧，但 HotSpot VM 直接就把本地方法棧和虛擬機(jī)棧合二為一 。

15、你能保證 GC 執(zhí)行嗎？

不能，雖然你可以調(diào)用 System.gc() 或者 Runtime.gc()，但是沒有辦法保證 GC的執(zhí)行。

16、怎么獲取 Java 程序使用的內(nèi)存？堆使用的百分比？

可以通過 java.lang.Runtime 類中與內(nèi)存相關(guān)方法來獲取剩余的內(nèi)存，總內(nèi)存及最大堆內(nèi)存。通過這些 方法你也可以獲取到堆使用的百分比及堆內(nèi)存的剩余空間。Runtime.freeMemory() 方法返回剩余空間 的字節(jié)數(shù)，Runtime.totalMemory()方法總內(nèi)存的字節(jié)數(shù)，Runtime.maxMemory() 返回最大內(nèi)存的字 節(jié)數(shù)。

17、Java 中堆和棧有什么區(qū)別？

JVM 中堆和棧屬于不同的內(nèi)存區(qū)域，使用目的也不同。棧常用于保存方法幀和局部變量，而對象總是在 堆上分配。棧通常都比堆小，也不會在多個(gè)線程之間共享，而堆被整個(gè) JVM 的所有線程共享。

18、描述一下 JVM 加載 class 文件的原理機(jī)制

JVM 中類的裝載是由類加載器（ClassLoader）和它的子類來實(shí)現(xiàn)的，Java 中的類加載器是一個(gè)重要的 Java 運(yùn)行時(shí)系統(tǒng)組件，它負(fù)責(zé)在運(yùn)行時(shí)查找和裝入類文件中的類。

由于 Java 的跨平臺性，經(jīng)過編譯的 Java 源程序并不是一個(gè)可執(zhí)行程序，而是一個(gè)或多個(gè)類文件。當(dāng) Java 程序需要使用某個(gè)類時(shí)，JVM 會確保這個(gè)類已經(jīng)被加載、連接（驗(yàn)證、準(zhǔn)備和解析）和初始化。類 的加載是指把類的.class 文件中的數(shù)據(jù)讀入到內(nèi)存中，通常是創(chuàng)建一個(gè)字節(jié)數(shù)組讀入.class 文件，然后 產(chǎn)生與所加載類對應(yīng)
的 Class 對象。

加載完成后，Class 對象還不完整，所以此時(shí)的類還不可用。當(dāng)類被加載后就進(jìn)入連接階段，這一階段 包括驗(yàn)證、準(zhǔn)備（為靜態(tài)變量分配內(nèi)存并設(shè)置默認(rèn)的初始值）和解析（將符號引用替換為直接引用）三 個(gè)步驟。最后 JVM 對
類進(jìn)行初始化，包括：1)如果類存在直接的父類并且這個(gè)類還沒有被初始化，那么就先初始化父類；2) 如果類中存在初始化語句，就依次執(zhí)行這些初始化語句。

類的加載是由類加載器完成的，類加載器包括：根加載器（BootStrap）、擴(kuò)展加載器（Extension）、 系統(tǒng)加載器（System）和用戶自定義類加載器（java.lang.ClassLoader 的子類）。

從 Java 2（JDK 1.2）開始，類加載過程采取了父親委托機(jī)制（PDM）。PDM 更好的保證了 Java 平臺 的安全性，在該機(jī)制中，JVM 自帶的 Bootstrap 是根加載器，其他的加載器都有且僅有一個(gè)父類加載 器。類的加載首先請求父類加載器加載，父類加載器無能為力時(shí)才由其子類加載器自行加載。JVM 不會 向 Java 程序提供對 Bootstrap 的引用。下面是關(guān)于幾個(gè)類
加載器的說明：
1、Bootstrap：一般用本地代碼實(shí)現(xiàn)，負(fù)責(zé)加載 JVM 基礎(chǔ)核心類庫（rt.jar）；
2、Extension：從 java.ext.dirs 系統(tǒng)屬性所指定的目錄中加載類庫，它的父加載器是 Bootstrap；
3、System：又叫應(yīng)用類加載器，其父類是 Extension。它是應(yīng)用最廣泛的類加載器。它從環(huán)境變量 classpath 或者系統(tǒng)屬性 java.class.path 所指定的目錄中記載類，是用戶自定義加載器的默認(rèn)父加 載器。

19、GC 是什么？為什么要有 GC？

GC 是垃 圾收 集的 意思 ，內(nèi)存 處理 是編 程人 員容 易出 現(xiàn)問 題的 地方 ，忘記 或者 錯(cuò)誤的內(nèi) 存回 收 會 導(dǎo)致 程序 或系 統(tǒng)的 不穩(wěn) 定甚 至崩 潰， Java 提供 的 GC 功能 可以 自動(dòng)監(jiān)測 對象 是否 超過 作用 域從 而達(dá) 到自 動(dòng)回 收內(nèi) 存的 目的 ，Java 語言 沒有 提供 釋放已分 配內(nèi) 存的 顯示 操作 方法 。Java 程序 員不 用擔(dān) 心內(nèi) 存管 理， 因?yàn)?垃圾 收集 器會自動(dòng) 進(jìn)行 管理 。要 請求 垃圾 收集 ，可 以調(diào) 用下 面的 方法 之一 ：System.gc() 或Runtime.getRuntime().gc() ，但 JVM 可以 屏蔽 掉顯 示的 垃圾 回收 調(diào)用 。
垃圾回收可以有效的防止內(nèi)存泄露，有效的使用可以使用的內(nèi)存。垃圾回收器通常是作為一個(gè)單獨(dú)的低 優(yōu)先級的線程運(yùn)行，不可預(yù)知的情況下對內(nèi)存堆中已經(jīng)死亡的或者長時(shí)間沒有使用的對象進(jìn)行清除和回 收，程序員不能實(shí)時(shí)的調(diào)用垃圾回收器對某個(gè)對象或所有對象進(jìn)行垃圾回收。在 Java 誕生初期，垃圾 回收是 Java最大的亮點(diǎn)之一，因?yàn)榉?wù)器端的編程需要有效的防止內(nèi)存泄露問題，然而時(shí)過境遷，如今 Java 的垃圾回收機(jī)制已經(jīng)成為被詬病的東。移動(dòng)智能終端用戶通常覺得 iOS 的系統(tǒng)比 Android 系統(tǒng)有 更好的用戶體驗(yàn)，其中一個(gè)深層次的原因就在于 Android 系統(tǒng)中垃圾回收的不可預(yù)知性。

20、堆（Heap-線程共享） -運(yùn)行時(shí)數(shù)據(jù)區(qū)

是被線程共享的一塊內(nèi)存區(qū)域， 創(chuàng)建的對象和數(shù)組都保存在 Java 堆內(nèi)存中，也是垃圾收集器進(jìn)行垃圾 收集的最重要的內(nèi)存區(qū)域。 由于現(xiàn)代 VM 采用分代收集算法, 因此 Java 堆從 GC 的角度還可以細(xì)分為: 新生代(Eden 區(qū)、 From Survivor 區(qū)和 To Survivor 區(qū))和老年代。

21、方法區(qū)/永久代（線程共享）

即我們常說的永久代(Permanent Generation), 用于存儲被 JVM 加載的類信息、 常量、 靜態(tài)變量、 即 時(shí)編譯器編譯后的代碼等數(shù)據(jù). HotSpot VM把GC分代收集擴(kuò)展至方法區(qū), 即使用Java堆的永久代來實(shí)現(xiàn) 方法區(qū), 這樣 HotSpot 的垃圾收集器就可以像管理 Java 堆一樣管理這部分內(nèi)存,而不必為方法區(qū)開發(fā)專 門的內(nèi)存管理器(永久帶的內(nèi)存回收的主要目標(biāo)是針對常量池的回收和類型的卸載, 因此收益一般很小) 。

運(yùn)行時(shí)常量池（Runtime Constant Pool）是方法區(qū)的一部分。 Class 文件中除了有類的版本、字段、 方法、接口等描述等信息外，還有一項(xiàng)信息是常量池 （Constant Pool Table），用于存放編譯期生成 的各種字面量和符號引用，這部分內(nèi)容將在類加載后存放到方法區(qū)的運(yùn)行時(shí)常量池中。 Java 虛擬機(jī)對 Class 文件的每一部分（自然也包括常量池）的格式都有嚴(yán)格的規(guī)定，每一個(gè)字節(jié)用于存儲哪種數(shù)據(jù)都 必須符合規(guī)范上的要求，這樣才會被虛擬機(jī)認(rèn)可、裝載和執(zhí)行。

22、JVM 運(yùn)行時(shí)內(nèi)存

Java 堆從 GC 的角度還可以細(xì)分為: 新生代(Eden 區(qū)、 From Survivor 區(qū)和 To Survivor 區(qū))和老年代。

23、新生代

是用來存放新生的對象。一般占據(jù)堆的 1/3 空間。由于頻繁創(chuàng)建對象，所以新生代會頻繁觸發(fā)MinorGC 進(jìn)行垃圾回收。新生代又分為 Eden 區(qū)、 ServivorFrom、 ServivorTo 三個(gè)區(qū)。
Eden 區(qū)
Java 新對象的出生地（如果新創(chuàng)建的對象占用內(nèi)存很大，則直接分配到老年代）。當(dāng) Eden 區(qū)內(nèi)存不夠 的時(shí)候就會觸發(fā) MinorGC，對新生代區(qū)進(jìn)行一次垃圾回收。
ServivorFrom
上一次 GC 的幸存者，作為這一次 GC 的被掃描者。
ServivorTo
保留了一次 MinorGC 過程中的幸存者。
MinorGC 的過程（復(fù)制->清空->互換）
MinorGC 采用復(fù)制算法。
1： eden、 servicorFrom 復(fù)制到 ServicorTo，年齡+1
首先，把 Eden 和 ServivorFrom 區(qū)域中存活的對象復(fù)制到 ServicorTo 區(qū)域（如果有對象的年齡以及達(dá) 到了老年的標(biāo)準(zhǔn)，則賦值到老年代區(qū)），同時(shí)把這些對象的年齡+1（如果 ServicorTo 不夠位置了就放 到老年區(qū)）；
2： 清空 eden、 servicorFrom
然后，清空 Eden 和 ServicorFrom 中的對象；
3： ServicorTo 和 ServicorFrom 互換
最后， ServicorTo 和 ServicorFrom 互換，原 ServicorTo 成為下一次 GC 時(shí)的 ServicorFrom區(qū)。

24、老年代

主要存放應(yīng)用程序中生命周期長的內(nèi)存對象。
老年代的對象比較穩(wěn)定，所以 MajorGC 不會頻繁執(zhí)行。在進(jìn)行 MajorGC 前一般都先進(jìn)行了一次 MinorGC，使得有新生代的對象晉身入老年代，導(dǎo)致空間不夠用時(shí)才觸發(fā)。當(dāng)無法找到足夠大的連續(xù)空 間分配給新創(chuàng)建的較大對象時(shí)也會提前觸發(fā)一次 MajorGC 進(jìn)行垃圾回收騰出空間。
MajorGC 采用標(biāo)記清除算法：首先掃描一次所有老年代，標(biāo)記出存活的對象，然后回收沒有標(biāo)記的對 象。 ajorGC 的耗時(shí)比較長，因?yàn)橐獟呙柙倩厥铡?MajorGC 會產(chǎn)生內(nèi)存碎片，為了減少內(nèi)存損耗，我們 一般需要進(jìn)行合并或者標(biāo)記出來方便下次直接分配。當(dāng)老年代也滿了裝不下的時(shí)候，就會拋出 OOM（Out of Memory）異常。

25、永久代

指內(nèi)存的永久保存區(qū)域，主要存放 Class 和 Meta（元數(shù)據(jù)）的信息,Class 在被加載的時(shí)候被放入永久 區(qū)域， 它和和存放實(shí)例的區(qū)域不同,GC 不會在主程序運(yùn)行期對永久區(qū)域進(jìn)行清理。所以這也導(dǎo)致了永久 代的區(qū)域會隨著加載的 Class 的增多而脹滿，最終拋出 OOM 異常。

26、JAVA8 與元數(shù)據(jù)

在 Java8 中， 永久代已經(jīng)被移除，被一個(gè)稱為“元數(shù)據(jù)區(qū)”（元空間）的區(qū)域所取代。元空間的本質(zhì)和永 久代類似，元空間與永久代之間最大的區(qū)別在于： 元空間并不在虛擬機(jī)中，而是使用本地內(nèi)存。因此， 默認(rèn)情況下，元空間的大小僅受本地內(nèi)存限制。 類的元數(shù)據(jù)放入 nativememory, 字符串池和類的靜態(tài) 變量放入 java 堆中， 這樣可以加載多少類的元數(shù)據(jù)就不再由MaxPermSize 控制, 而由系統(tǒng)的實(shí)際可用 空間來控制。

27、引用計(jì)數(shù)法

在 Java 中，引用和對象是有關(guān)聯(lián)的。如果要操作對象則必須用引用進(jìn)行。因此，很顯然一個(gè)簡單的辦 法是通過引用計(jì)數(shù)來判斷一個(gè)對象是否可以回收。簡單說，即一個(gè)對象如果沒有任何與之關(guān)聯(lián)的引用， 即他們的引用計(jì)數(shù)都不為 0， 則說明對象不太可能再被用到，那么這個(gè)對象就是可回收對象。

28、可達(dá)性分析

為了解決引用計(jì)數(shù)法的循環(huán)引用問題， Java 使用了可達(dá)性分析的方法。通過一系列的“GC roots”對象作 為起點(diǎn)搜索。如果在“GC roots”和一個(gè)對象之間沒有可達(dá)路徑，則稱該對象是不可達(dá)的。要注意的是， 不可達(dá)對象不等價(jià)于可回收對象， 不可達(dá)對象變?yōu)榭苫厥諏ο笾辽僖?jīng)過兩次標(biāo)記過程。兩次標(biāo)記后仍 然是可回收對象，則將面臨回收。

29、標(biāo)記清除算法（ Mark-Sweep）

最基礎(chǔ)的垃圾回收算法，分為兩個(gè)階段，標(biāo)注和清除。標(biāo)記階段標(biāo)記出所有需要回收的對象，清除階段 回收被標(biāo)記的對象所占用的空間。如圖

從圖中我們就可以發(fā)現(xiàn)，該算法最大的問題是內(nèi)存碎片化嚴(yán)重，后續(xù)可能發(fā)生大對象不能找到可利用空 間的問題。

30、復(fù)制算法（copying）

為了解決 Mark-Sweep 算法內(nèi)存碎片化的缺陷而被提出的算法。按內(nèi)存容量將內(nèi)存劃分為等大小的兩 塊。每次只使用其中一塊，當(dāng)這一塊內(nèi)存滿后將尚存活的對象復(fù)制到另一塊上去，把已使用的內(nèi)存清 掉，如圖：

31、標(biāo)記整理算法(Mark-Compact)

結(jié)合了以上兩個(gè)算法，為了避免缺陷而提出。標(biāo)記階段和 Mark-Sweep 算法相同， 標(biāo)記后不是清理對 象，而是將存活對象移向內(nèi)存的一端。然后清除端邊界外的對象。如圖：

32、分代收集算法

分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根據(jù)對象存活的不同生命周期將內(nèi)存劃分為 不同的域，一般情況下將 GC 堆劃分為老生代(Tenured/Old Generation)和新生代
(YoungGeneration)。老生代的特點(diǎn)是每次垃圾回收時(shí)只有少量對象需要被回收，新生代的特點(diǎn)是每次 垃圾回收時(shí)都有大量垃圾需要被回收，因此可以根據(jù)不同區(qū)域選擇不同的算法。

33、新生代與復(fù)制算法

目前大部分 JVM 的 GC 對于新生代都采取 Copying 算法，因?yàn)樾律忻看卫厥斩家厥沾蟛糠?對象，即要復(fù)制的操作比較少，但通常并不是按照 1： 1 來劃分新生代。一般將新生代劃分為一塊較大 的 Eden 空間和兩個(gè)較小的 Survivor 空間(From Space, To Space)，每次使用Eden 空間和其中的一塊 Survivor 空間，當(dāng)進(jìn)行回收時(shí)，將該兩塊空間中還存活的對象復(fù)制到另一塊 Survivor 空間中。

34、老年代與標(biāo)記復(fù)制算法

而老年代因?yàn)槊看沃换厥丈倭繉ο?，因而采?Mark-Compact 算法。

1. JAVA 虛擬機(jī)提到過的處于方法區(qū)的永生代(Permanet Generation)， 它用來存儲 class 類，常量， 方法描述等。對永生代的回收主要包括廢棄常量和無用的類。
2. 對象的內(nèi)存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目前存 放對象的那一塊)，少數(shù)情況會直接分配到老生代。
3. 當(dāng)新生代的 Eden Space 和 From Space 空間不足時(shí)就會發(fā)生一次 GC，進(jìn)行 GC 后， EdenSpace 和 From Space 區(qū)的存活對象會被挪到 To Space，然后將 Eden Space 和 FromSpace 進(jìn)行清理。
4. 如果 To Space 無法足夠存儲某個(gè)對象，則將這個(gè)對象存儲到老生代。
5. 在進(jìn)行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反復(fù)循環(huán)。
6. 當(dāng)對象在 Survivor 區(qū)躲過一次 GC 后，其年齡就會+1。 默認(rèn)情況下年齡到達(dá) 15 的對象會被移到 老生代中。

35、JAVA 強(qiáng)引用

在 Java 中最常見的就是強(qiáng)引用， 把一個(gè)對象賦給一個(gè)引用變量，這個(gè)引用變量就是一個(gè)強(qiáng)引用。當(dāng)一 個(gè)對象被強(qiáng)引用變量引用時(shí)，它處于可達(dá)狀態(tài)，它是不可能被垃圾回收機(jī)制回收的，即使該對象以后永 遠(yuǎn)都不會被用到 JVM 也不會回收。因此強(qiáng)引用是造成 Java 內(nèi)存泄漏的主要原因之一。

36、JAVA軟引用

軟引用需要用 SoftReference 類來實(shí)現(xiàn)，對于只有軟引用的對象來說，當(dāng)系統(tǒng)內(nèi)存足夠時(shí)它不會被回 收，當(dāng)系統(tǒng)內(nèi)存空間不足時(shí)它會被回收。軟引用通常用在對內(nèi)存敏感的程序中。

37、JAVA弱引用

弱引用需要用 WeakReference 類來實(shí)現(xiàn)，它比軟引用的生存期更短，對于只有弱引用的對象來說，只 要垃圾回收機(jī)制一運(yùn)行，不管 JVM 的內(nèi)存空間是否足夠，總會回收該對象占用的內(nèi)存。

38、JAVA虛引用

虛引用需要 PhantomReference 類來實(shí)現(xiàn)，它不能單獨(dú)使用，必須和引用隊(duì)列聯(lián)合使用。 虛引用的主 要作用是跟蹤對象被垃圾回收的狀態(tài)。

39、分代收集算法

當(dāng)前主流 VM 垃圾收集都采用”分代收集” (Generational Collection)算法, 這種算法會根據(jù)對象存活周期 的不同將內(nèi)存劃分為幾塊, 如 JVM 中的 新生代、老年代、永久代， 這樣就可以根據(jù)各年代特點(diǎn)分別采用 最適當(dāng)?shù)?GC 算法

40、在新生代-復(fù)制算法

每次垃圾收集都能發(fā)現(xiàn)大批對象已死, 只有少量存活. 因此選用復(fù)制算法, 只需要付出少量存活對象的復(fù) 制成本就可以完成收集

41、在老年代-標(biāo)記整理算法

因?yàn)閷ο蟠婊盥矢?、沒有額外空間對它進(jìn)行分配擔(dān)保, 就必須采用“標(biāo)記—清理”或“標(biāo)記—整理” 算法來進(jìn) 行回收, 不必進(jìn)行內(nèi)存復(fù)制, 且直接騰出空閑內(nèi)存。

42、分區(qū)收集算法

分區(qū)算法則將整個(gè)堆空間劃分為連續(xù)的不同小區(qū)間, 每個(gè)小區(qū)間獨(dú)立使用, 獨(dú)立回收. 這樣做的好處是可 以控制一次回收多少個(gè)小區(qū)間 , 根據(jù)目標(biāo)停頓時(shí)間, 每次合理地回收若干個(gè)小區(qū)間(而不是整個(gè)堆), 從而 減少一次 GC 所產(chǎn)生的停頓。

43、GC 垃圾收集器

Java 堆內(nèi)存被劃分為新生代和年老代兩部分，新生代主要使用復(fù)制和標(biāo)記-清除垃圾回收算法；年老代 主要使用標(biāo)記-整理垃圾回收算法，因此 java 虛擬中針對新生代和年老代分別提供了多種不同的垃圾收 集器， JDK1.6 中 Sun HotSpot 虛擬機(jī)的垃圾收集器如下：

44、Serial 垃圾收集器（單線程、 復(fù)制算法）

Serial（英文連續(xù)） 是最基本垃圾收集器，使用復(fù)制算法，曾經(jīng)是JDK1.3.1 之前新生代唯一的垃圾收集 器。 Serial 是一個(gè)單線程的收集器，它不但只會使用一個(gè) CPU 或一條線程去完成垃圾收集工作，并且 在進(jìn)行垃圾收集的同時(shí)，必須暫停其他所有的工作線程，直到垃圾收集結(jié)束。
Serial 垃圾收集器雖然在收集垃圾過程中需要暫停所有其他的工作線程，但是它簡單高效，對于限定單 個(gè) CPU 環(huán)境來說，沒有線程交互的開銷，可以獲得最高的單線程垃圾收集效率，因此 Serial垃圾收集 器依然是 java 虛擬機(jī)運(yùn)行在 Client 模式下默認(rèn)的新生代垃圾收集器。

45、ParNew 垃圾收集器（Serial+多線程）

ParNew 垃圾收集器其實(shí)是 Serial 收集器的多線程版本，也使用復(fù)制算法，除了使用多線程進(jìn)行垃圾收 集之外，其余的行為和 Serial 收集器完全一樣， ParNew 垃圾收集器在垃圾收集過程中同樣也要暫停所 有其他的工作線程。
ParNew 收集器默認(rèn)開啟和 CPU 數(shù)目相同的線程數(shù)，可以通過-XX:ParallelGCThreads 參數(shù)來限制垃圾 收集器的線程數(shù)。 【Parallel：平行的】
ParNew 雖然是除了多線程外和Serial 收集器幾乎完全一樣，但是ParNew垃圾收集器是很多 java虛擬 機(jī)運(yùn)行在 Server 模式下新生代的默認(rèn)垃圾收集器。

46、Parallel Scavenge 收集器（多線程復(fù)制算法、高效）

Parallel Scavenge 收集器也是一個(gè)新生代垃圾收集器，同樣使用復(fù)制算法，也是一個(gè)多線程的垃圾收集 器， 它重點(diǎn)關(guān)注的是程序達(dá)到一個(gè)可控制的吞吐量（Thoughput， CPU 用于運(yùn)行用戶代碼的時(shí)間/CPU 總消耗時(shí)間，即吞吐量=運(yùn)行用戶代碼時(shí)間/(運(yùn)行用戶代碼時(shí)間+垃圾收集時(shí)間)），高吞吐量可以最高效 率地利用 CPU 時(shí)間，盡快地完成程序的運(yùn)算任務(wù)，主要適用于在后臺運(yùn)算而不需要太多交互的任務(wù)。 自適應(yīng)調(diào)節(jié)策略也是 ParallelScavenge 收集器與 ParNew 收集器的一個(gè)重要區(qū)別。

47、Serial Old 收集器（單線程標(biāo)記整理算法 ）

Serial Old 是 Serial 垃圾收集器年老代版本，它同樣是個(gè)單線程的收集器，使用標(biāo)記-整理算法，這個(gè)收 集器也主要是運(yùn)行在 Client 默認(rèn)的 java 虛擬機(jī)默認(rèn)的年老代垃圾收集器。在 Server 模式下，主要有兩 個(gè)用途：

1. 在 JDK1.5 之前版本中與新生代的 Parallel Scavenge 收集器搭配使用。

2. 作為年老代中使用 CMS 收集器的后備垃圾收集方案。新生代 Serial 與年老代 Serial Old 搭配垃圾 收集過程圖：
   
   

   新生代 Parallel Scavenge 收集器與 ParNew 收集器工作原理類似，都是多線程的收集器，都使用的是 復(fù)制算法，在垃圾收集過程中都需要暫停所有的工作線程。新生代 ParallelScavenge/ParNew 與年老
   

   代 Serial Old 搭配垃圾收集過程圖：

48、Parallel Old 收集器（多線程標(biāo)記整理算法）

Parallel Old 收集器是Parallel Scavenge的年老代版本，使用多線程的標(biāo)記-整理算法，在 JDK1.6才開始 提供。
在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，只能保證 新生代的吞吐量優(yōu)先，無法保證整體的吞吐量， Parallel Old 正是為了在年老代同樣提供吞吐量優(yōu)先的 垃圾收集器， 如果系統(tǒng)對吞吐量要求比較高，可以優(yōu)先考慮新生代 Parallel Scavenge和年老代 Parallel Old 收集器的搭配策略。

新生代 Parallel Scavenge 和年老代 Parallel Old 收集器搭配運(yùn)行過程圖

49、CMS 收集器（多線程標(biāo)記清除算法）

Concurrent mark sweep(CMS)收集器是一種年老代垃圾收集器，其最主要目標(biāo)是獲取最短垃圾回收停 頓時(shí)間， 和其他年老代使用標(biāo)記-整理算法不同，它使用多線程的標(biāo)記-清除算法。最短的垃圾收集停頓 時(shí)間可以為交互比較高的程序提高用戶體驗(yàn)。CMS 工作機(jī)制相比其他的垃圾收集器來說更復(fù)雜。整個(gè) 過程分為以下 4 個(gè)階段：
初始標(biāo)記
只是標(biāo)記一下 GC Roots 能直接關(guān)聯(lián)的對象，速度很快，仍然需要暫停所有的工作線程。
并發(fā)標(biāo)記
進(jìn)行 GC Roots 跟蹤的過程，和用戶線程一起工作，不需要暫停工作線程。
重新標(biāo)記
為了修正在并發(fā)標(biāo)記期間，因用戶程序繼續(xù)運(yùn)行而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對象的標(biāo)記記錄，仍然 需要暫停所有的工作線程。
并發(fā)清除
清除 GC Roots 不可達(dá)對象，和用戶線程一起工作，不需要暫停工作線程。由于耗時(shí)最長的并發(fā)標(biāo)記和 并發(fā)清除過程中，垃圾收集線程可以和用戶現(xiàn)在一起并發(fā)工作， 所以總體上來看CMS 收集器的內(nèi)存回 收和用戶線程是一起并發(fā)地執(zhí)行。CMS 收集器工作過程

50、G1 收集器

Garbage ?rst 垃圾收集器是目前垃圾收集器理論發(fā)展的最前沿成果，相比與 CMS 收集器， G1 收 集器兩個(gè)最突出的改進(jìn)是：

1. 基于標(biāo)記-整理算法，不產(chǎn)生內(nèi)存碎片。
2. 可以非常精確控制停頓時(shí)間，在不犧牲吞吐量前提下，實(shí)現(xiàn)低停頓垃圾回收。G1 收集器避免全區(qū) 域垃圾收集，它把堆內(nèi)存劃分為大小固定的幾個(gè)獨(dú)立區(qū)域，并且跟蹤這些區(qū)域的垃圾收集進(jìn)度，同時(shí)在后臺維護(hù)一個(gè)優(yōu)先級列表，每次根據(jù)所允許的收集時(shí)間， 優(yōu)先回收垃圾最多的區(qū)域。區(qū)域劃 分和優(yōu)先級區(qū)域回收機(jī)制，確保 G1 收集器可以在有限時(shí)間獲得最高的垃圾收集效率

51、JVM 類加載機(jī)制

JVM 類加載機(jī)制分為五個(gè)部分：加載，驗(yàn)證，準(zhǔn)備，解析，初始化，下面我們就分別來看一下這五個(gè)過 程。

加載
加載是類加載過程中的一個(gè)階段， 這個(gè)階段會在內(nèi)存中生成一個(gè)代表這個(gè)類的 java.lang.Class 對象， 作為方法區(qū)這個(gè)類的各種數(shù)據(jù)的入口。注意這里不一定非得要從一個(gè) Class 文件獲取，這里既可以從 ZIP 包中讀取（比如從 jar 包和 war 包中讀?。?，也可以在運(yùn)行時(shí)計(jì)算生成（動(dòng)態(tài)代理），也可以由其 它文件生成（比如將 JSP 文件轉(zhuǎn)換成對應(yīng)的 Class 類）。
驗(yàn)證
這一階段的主要目的是為了確保 Class 文件的字節(jié)流中包含的信息是否符合當(dāng)前虛擬機(jī)的要求，并且不 會危害虛擬機(jī)自身的安全。
準(zhǔn)備
準(zhǔn)備階段是正式為類變量分配內(nèi)存并設(shè)置類變量的初始值階段，即在方法區(qū)中分配這些變量所使用的內(nèi) 存空間。注意這里所說的初始值概念，比如一個(gè)類變量定義為：
實(shí)際上變量 v 在準(zhǔn)備階段過后的初始值為 0 而不是 8080， 將 v 賦值為 8080 的 put static 指令是 程序被編譯后， 存放于類構(gòu)造器方法之中。
但是注意如果聲明為：
public static ?nal int v = 8080;
在編譯階段會為 v 生成 ConstantValue 屬性，在準(zhǔn)備階段虛擬機(jī)會根據(jù) ConstantValue 屬性將 v 賦值為 8080。
解析
解析階段是指虛擬機(jī)將常量池中的符號引用替換為直接引用的過程。符號引用就是 class 文件中 的：
public static int v = 8080;
實(shí)際上變量 v 在準(zhǔn)備階段過后的初始值為 0 而不是 8080， 將 v 賦值為 8080 的 put static 指令是程序 被編譯后， 存放于類構(gòu)造器方法之中。但是注意如果聲明為：
在編譯階段會為 v 生成 ConstantValue 屬性，在準(zhǔn)備階段虛擬機(jī)會根據(jù) ConstantValue 屬性將 v 賦值為 8080。
解析
解析階段是指虛擬機(jī)將常量池中的符號引用替換為直接引用的過程。符號引用就是 class 文件中 的：
public static final int v = 8080;
在編譯階段會為 v 生成 ConstantValue 屬性，在準(zhǔn)備階段虛擬機(jī)會根據(jù) ConstantValue 屬性將 v賦值
為 8080。
解析
解析階段是指虛擬機(jī)將常量池中的符號引用替換為直接引用的過程。符號引用就是 class 文件中的：

1. CONSTANT_Class_info
2. CONSTANT_Field_info
3. CONSTANT_Method_info
   等類型的常量。
   符號引用
   符號引用與虛擬機(jī)實(shí)現(xiàn)的布局無關(guān)， 引用的目標(biāo)并不一定要已經(jīng)加載到內(nèi)存中。 各種虛擬機(jī)實(shí)現(xiàn)的內(nèi) 存布局可以各不相同，但是它們能接受的符號引用必須是一致的，因?yàn)榉栆玫淖置媪啃问矫鞔_定義 在 Java 虛擬機(jī)規(guī)范的 Class 文件格式中。
   直接引用
   直接引用可以是指向目標(biāo)的指針，相對偏移量或是一個(gè)能間接定位到目標(biāo)的句柄。如果有了直接引用， 那引用的目標(biāo)必定已經(jīng)在內(nèi)存中存在。
   初始化
   初始化階段是類加載最后一個(gè)階段，前面的類加載階段之后，除了在加載階段可以自定義類加載器以 外，其它操作都由 JVM 主導(dǎo)。到了初始階段，才開始真正執(zhí)行類中定義的 Java 程序代碼。
   類構(gòu)造器
   初始化階段是執(zhí)行類構(gòu)造器方法的過程。 方法是由編譯器自動(dòng)收集類中的類變量的賦值操作和靜態(tài)語句 塊中的語句合并而成的。虛擬機(jī)會保證子方法執(zhí)行之前，父類的方法已經(jīng)執(zhí)行完畢， 如果一個(gè)類中沒有 對靜態(tài)變量賦值也沒有靜態(tài)語句塊，那么編譯器可以不為這個(gè)類生成()方法。注意以下幾種情況不會執(zhí) 行類初始化：
   1、 通過子類引用父類的靜態(tài)字段，只會觸發(fā)父類的初始化，而不會觸發(fā)子類的初始化。
   2、定義對象數(shù)組，不會觸發(fā)該類的初始化。
   3、 常量在編譯期間會存入調(diào)用類的常量池中，本質(zhì)上并沒有直接引用定義常量的類，不會觸 發(fā)定義常量所在的類。
   4、 通過類名獲取 Class 對象，不會觸發(fā)類的初始化。
   5、 通過 Class.forName 加載指定類時(shí)，如果指定參數(shù) initialize 為 false 時(shí)，也不會觸發(fā)類初 始化，其實(shí)這個(gè)參數(shù)是告訴虛擬機(jī)，是否要對類進(jìn)行初始化。
   6、 通過 ClassLoader 默認(rèn)的 loadClass 方法，也不會觸發(fā)初始化動(dòng)作。

52、類加載器

虛擬機(jī)設(shè)計(jì)團(tuán)隊(duì)把加載動(dòng)作放到 JVM 外部實(shí)現(xiàn)，以便讓應(yīng)用程序決定如何獲取所需的類， JVM 提供了
3 種類加載器：
**啟動(dòng)類加載器(Bootstrap ClassLoader) **
負(fù)責(zé)加載 JAVA_HOME\lib 目錄中的， 或通過-Xbootclasspath 參數(shù)指定路徑中的， 且被虛擬機(jī)認(rèn)可 （按文件名識別， 如 rt.jar） 的類。
擴(kuò)展類加載器(Extension ClassLoader)
負(fù)責(zé)加載 JAVA_HOME\lib\ext 目錄中的，或通過 java.ext.dirs 系統(tǒng)變量指定路徑中的類庫。
應(yīng)用程序類加載器(Application ClassLoader)：
負(fù)責(zé)加載用戶路徑（classpath）上的類庫。JVM 通過雙親委派模型進(jìn)行類的加載， 當(dāng)然我們也可以通 過繼承 java.lang.ClassLoader實(shí)現(xiàn)自定義的類加載器。

53、雙親委派

當(dāng)一個(gè)類收到了類加載請求，他首先不會嘗試自己去加載這個(gè)類，而是把這個(gè)請求委派給父類去完成， 每一個(gè)層次類加載器都是如此，因此所有的加載請求都應(yīng)該傳送到啟動(dòng)類加載其中，只有當(dāng)父類加載器 反饋?zhàn)约簾o法完成這個(gè)請求的時(shí)候（在它的加載路徑下沒有找到所需加載的Class）， 子類加載器才會 嘗試自己去加載。

采用雙親委派的一個(gè)好處是比如加載位于 rt.jar 包中的類 java.lang.Object，不管是哪個(gè)加載器加載這 個(gè)類，最終都是委托給頂層的啟動(dòng)類加載器進(jìn)行加載，這樣就保證了使用不同的類加載器最終得到的都 是同樣一個(gè) Object 對象

54、OSGI（ 動(dòng)態(tài)模型系統(tǒng)）

OSGi(Open Service Gateway Initiative)，是面向 Java 的動(dòng)態(tài)模型系統(tǒng)，是 Java 動(dòng)態(tài)化模塊化系統(tǒng)的 一系列規(guī)范。

55、動(dòng)態(tài)改變構(gòu)造

OSGi 服務(wù)平臺提供在多種網(wǎng)絡(luò)設(shè)備上無需重啟的動(dòng)態(tài)改變構(gòu)造的功能。為了最小化耦合度和促使這些 耦合度可管理， OSGi 技術(shù)提供一種面向服務(wù)的架構(gòu)，它能使這些組件動(dòng)態(tài)地發(fā)現(xiàn)對方。

56、模塊化編程與熱插拔

OSGi 旨在為實(shí)現(xiàn) Java 程序的模塊化編程提供基礎(chǔ)條件，基于 OSGi 的程序很可能可以實(shí)現(xiàn)模塊級的熱 插拔功能，當(dāng)程序升級更新時(shí)，可以只停用、重新安裝然后啟動(dòng)程序的其中一部分，這對企業(yè)級程序開 發(fā)來說是非常具有誘惑力的特性。
OSGi 描繪了一個(gè)很美好的模塊化開發(fā)目標(biāo)，而且定義了實(shí)現(xiàn)這個(gè)目標(biāo)的所需要服務(wù)與架構(gòu)，同時(shí)也有 成熟的框架進(jìn)行實(shí)現(xiàn)支持。但并非所有的應(yīng)用都適合采用 OSGi 作為基礎(chǔ)架構(gòu)，它在提供強(qiáng)大功能同 時(shí)，也引入了額外的復(fù)雜度，因?yàn)樗蛔袷亓祟惣虞d的雙親委托模型。

57、JVM內(nèi)存模型

線程獨(dú)占:棧,本地方法棧,程序計(jì)數(shù)器
線程共享:堆,方法區(qū)

58、棧

又稱方法棧,線程私有的,線程執(zhí)行方法是都會創(chuàng)建一個(gè)棧陣,用來存儲局部變量表,操作棧,動(dòng)態(tài)鏈接,方法 出口等信息.調(diào)用方法時(shí)執(zhí)行入棧,方法返回式執(zhí)行出棧.

59、本地方法棧

與棧類似,也是用來保存執(zhí)行方法的信息.執(zhí)行Java方法是使用棧,執(zhí)行Native方法時(shí)使用本地方法棧.

60、程序計(jì)數(shù)器

保存著當(dāng)前線程執(zhí)行的字節(jié)碼位置,每個(gè)線程工作時(shí)都有獨(dú)立的計(jì)數(shù)器,只為執(zhí)行Java方法服務(wù),執(zhí)行 Native方法時(shí),程序計(jì)數(shù)器為空.

61、堆

JVM內(nèi)存管理最大的一塊,對被線程共享,目的是存放對象的實(shí)例,幾乎所欲的對象實(shí)例都會放在這里,當(dāng)堆 沒有可用空間時(shí),會拋出OOM異常.根據(jù)對象的存活周期不同,JVM把對象進(jìn)行分代管理,由垃圾回收器進(jìn)行 垃圾的回收管理

62、方法區(qū)

又稱非堆區(qū),用于存儲已被虛擬機(jī)加載的類信息,常量,靜態(tài)變量,即時(shí)編譯器優(yōu)化后的代碼等數(shù)據(jù).1.7的永 久代和1.8的元空間都是方法區(qū)的一種實(shí)現(xiàn)。

63、分代回收

分代回收基于兩個(gè)事實(shí):大部分對象很快就不使用了,還有一部分不會立即無用,但也不會持續(xù)很長時(shí)間

年輕代->標(biāo)記-復(fù)制
老年代->標(biāo)記-清除

64、堆和棧的區(qū)別

棧是運(yùn)行時(shí)單位，代表著邏輯，內(nèi)含基本數(shù)據(jù)類型和堆中對象引用，所在區(qū)域連續(xù)，沒有碎片；堆是存 儲單位，代表著數(shù)據(jù)，可被多個(gè)棧共享（包括成員中基本數(shù)據(jù)類型、引用和引用對象），所在區(qū)域不連 續(xù)，會有碎片。
1、功能不同
棧內(nèi)存用來存儲局部變量和方法調(diào)用，而堆內(nèi)存用來存儲Java中的對象。無論是成員變量，局部變量， 還是類變量，它們指向的對象都存儲在堆內(nèi)存中。
2、共享性不同
棧內(nèi)存是線程私有的。
堆內(nèi)存是所有線程共有的。
3、異常錯(cuò)誤不同
如果棧內(nèi)存或者堆內(nèi)存不足都會拋出異常。
?？臻g不足：java.lang.StackOverFlowError。 堆空間不足：java.lang.OutOfMemoryError。
4、空間大小
棧的空間大小遠(yuǎn)遠(yuǎn)小于堆的

65、什么時(shí)候會觸發(fā)FullGC

除直接調(diào)用System.gc外，觸發(fā)Full GC執(zhí)行的情況有如下四種。
1、舊生代空間不足
舊生代空間只有在新生代對象轉(zhuǎn)入及創(chuàng)建為大對象、大數(shù)組時(shí)才會出現(xiàn)不足的現(xiàn)象，當(dāng)執(zhí)行Full GC后空間仍然不足，則拋出如下錯(cuò)誤：
java.lang.OutOfMemoryError: Java heap space
為避免以上兩種狀況引起的FullGC，調(diào)優(yōu)時(shí)應(yīng)盡量做到讓對象在Minor GC階段被回收、讓對象在 新生代多存活一段時(shí)間及不要?jiǎng)?chuàng)建過大的對象及數(shù)組。
2、 Permanet Generation空間滿
PermanetGeneration中存放的為一些class的信息等，當(dāng)系統(tǒng)中要加載的類、反射的類和調(diào)用的 方法較多時(shí)，Permanet Generation可能會被占滿，在未配置為采用CMS GC的情況下會執(zhí)行Full GC。如果經(jīng)過Full GC仍然回收不了，那么JVM會拋出如下錯(cuò)誤信息：
java.lang.OutOfMemoryError: PermGen space
為避免Perm Gen占滿造成Full GC現(xiàn)象，可采用的方法為增大Perm Gen空間或轉(zhuǎn)為使用CMS GC。
3、 CMS GC時(shí)出現(xiàn)promotion failed和concurrent mode failure
對于采用CMS進(jìn)行舊生代GC的程序而言，尤其要注意GC日志中是否有promotion failed和 concurrent mode failure兩種狀況，當(dāng)這兩種狀況出現(xiàn)時(shí)可能會觸發(fā)Full GC。
promotionfailed是在進(jìn)行Minor GC時(shí)，survivor space放不下、對象只能放入舊生代，而此時(shí)舊 生代也放不下造成的；concurrent mode failure是在執(zhí)行CMS GC的過程中同時(shí)有對象要放入舊生 代，而此時(shí)舊生代空間不足造成的。
應(yīng)對措施為：增大survivorspace、舊生代空間或調(diào)低觸發(fā)并發(fā)GC的比率，但在JDK 5.0+、6.0+的 版本中有可能會由于JDK的bug29導(dǎo)致CMS在remark完畢后很久才觸發(fā)sweeping動(dòng)作。對于這種 狀況，可通過設(shè)置-XX:CMSMaxAbortablePrecleanTime=5（單位為ms）來避免。
4、 統(tǒng)計(jì)得到的Minor GC晉升到舊生代的平均大小大于舊生代的剩余空間
這是一個(gè)較為復(fù)雜的觸發(fā)情況，Hotspot為了避免由于新生代對象晉升到舊生代導(dǎo)致舊生代空間不 足的現(xiàn)象，在進(jìn)行Minor GC時(shí)，做了一個(gè)判斷，如果之前統(tǒng)計(jì)所得到的Minor GC晉升到舊生代的 平均大小大于舊生代的剩余空間，那么就直接觸發(fā)Full GC。
例如程序第一次觸發(fā)MinorGC后，有6MB的對象晉升到舊生代，那么當(dāng)下一次Minor GC發(fā)生時(shí)， 首先檢查舊生代的剩余空間是否大于6MB，如果小于6MB，則執(zhí)行Full GC。
當(dāng)新生代采用PSGC時(shí)，方式稍有不同，PS GC是在Minor GC后也會檢查，例如上面的例子中第一 次Minor GC后，PS GC會檢查此時(shí)舊生代的剩余空間是否大于6MB，如小于，則觸發(fā)對舊生代的 回收。除了以上4種狀況外，對于使用RMI來進(jìn)行RPC或管理的Sun JDK應(yīng)用而言，默認(rèn)情況下會一 小時(shí)執(zhí)行一次Full GC?？赏ㄟ^在啟動(dòng)時(shí)通過- java-Dsun.rmi.dgc.client.gcInterval=3600000來設(shè) 置Full GC執(zhí)行的間隔時(shí)間或通過-XX:+ DisableExplicitGC來禁止RMI調(diào)用System.gc

66、什么是Java虛擬機(jī)？為什么Java被稱作是“平臺無關(guān)的編程語 言”？

Java虛擬機(jī)是一個(gè)可以執(zhí)行Java字節(jié)碼的虛擬機(jī)進(jìn)程。Java源文件被編譯成能被Java虛擬機(jī)執(zhí)行的字節(jié) 碼文件。 Java被設(shè)計(jì)成允許應(yīng)用程序可以運(yùn)行在任意的平臺，而不需要程序員為每一個(gè)平臺單獨(dú)重寫或 者是重新編譯。Java虛擬機(jī)讓這個(gè)變?yōu)榭赡?，因?yàn)樗赖讓佑布脚_的指令長度和其他特性。

67、對象分配規(guī)則

1. 對象優(yōu)先分配在Eden區(qū)，如果Eden區(qū)沒有足夠的空間時(shí)，虛擬機(jī)執(zhí)行一次Minor GC。
2. 大對象直接進(jìn)入老年代（大對象是指需要大量連續(xù)內(nèi)存空間的對象）。這樣做的目的是避免在 Eden區(qū)和兩個(gè)Survivor區(qū)之間發(fā)生大量的內(nèi)存拷貝（新生代采用復(fù)制算法收集內(nèi)存）。
3. 長期存活的對象進(jìn)入老年代。虛擬機(jī)為每個(gè)對象定義了一個(gè)年齡計(jì)數(shù)器，如果對象經(jīng)過了1次 Minor GC那么對象會進(jìn)入Survivor區(qū)，之后每經(jīng)過一次Minor GC那么對象的年齡加1，知道達(dá)到 閥值對象進(jìn)入老年區(qū)。
4. 動(dòng)態(tài)判斷對象的年齡。如果Survivor區(qū)中相同年齡的所有對象大小的總和大于Survivor空間的一 半，年齡大于或等于該年齡的對象可以直接進(jìn)入老年代。
5. 空間分配擔(dān)保。每次進(jìn)行Minor GC時(shí)，JVM會計(jì)算Survivor區(qū)移至老年區(qū)的對象的平均大小，如 果這個(gè)值大于老年區(qū)的剩余值大小則進(jìn)行一次Full GC，如果小于檢查HandlePromotionFailure設(shè) 置，如果true則只進(jìn)行Monitor GC,如果false則進(jìn)行Full GC

68、描述一下JVM加載class文件的原理機(jī)制？

JVM中類的裝載是由類加載器（ClassLoader）和它的子類來實(shí)現(xiàn)的，Java中的類加載器是一個(gè)重要的 Java運(yùn)行時(shí)系統(tǒng)組件，它負(fù)責(zé)在運(yùn)行時(shí)查找和裝入類文件中的類。
由于Java的跨平臺性，經(jīng)過編譯的Java源程序并不是一個(gè)可執(zhí)行程序，而是一個(gè)或多個(gè)類文件。當(dāng)Java 程序需要使用某個(gè)類時(shí)，JVM會確保這個(gè)類已經(jīng)被加載、連接（驗(yàn)證、準(zhǔn)備和解析）和初始化。
類的加載是指把類的.class文件中的數(shù)據(jù)讀入到內(nèi)存中，通常是創(chuàng)建一個(gè)字節(jié)數(shù)組讀入.class文件，然后 產(chǎn)生與所加載類對應(yīng)的Class對象。加載完成后，Class對象還不完整，所以此時(shí)的類還不可用。
當(dāng)類被加載后就進(jìn)入連接階段，這一階段包括驗(yàn)證、準(zhǔn)備（為靜態(tài)變量分配內(nèi)存并設(shè)置默認(rèn)的初始值） 和解析（將符號引用替換為直接引用）三個(gè)步驟。最后JVM對類進(jìn)行初始化，
包括：
1)如果類存在直接的父類并且這個(gè)類還沒有被初始化，那么就先初始化父類；
2)如果類中存在初始化語句，就依次執(zhí)行這些初始化語句。 類的加載是由類加載器完成的，類加載器包 括：根加載器（BootStrap）、擴(kuò)展加載器（Extension）、系統(tǒng)加載器（System）和用戶自定義類加 載器（java.lang.ClassLoader的子類）。
從Java 2（JDK 1.2）開始，類加載過程采取了父親委托機(jī)制（PDM）。PDM更好的保證了Java平臺的 安全性，在該機(jī)制中，JVM自帶的Bootstrap是根加載器，其他的加載器都有且僅有一個(gè)父類加載器。 類的加載首先請求父類加載器加載，父類加載器無能為力時(shí)才由其子類加載器自行加載。JVM不會向 Java程序提供對Bootstrap的引用。下面是關(guān)于幾個(gè)類加載器的說明
Bootstrap：一般用本地代碼實(shí)現(xiàn)，負(fù)責(zé)加載JVM基礎(chǔ)核心類庫（rt.jar）；
Extension：從java.ext.dirs系統(tǒng)屬性所指定的目錄中加載類庫，它的父加載器是Bootstrap； System：又叫應(yīng)用類加載器，其父類是Extension。它是應(yīng)用最廣泛的類加載器。它從環(huán)境變量 classpath或者系統(tǒng)屬性java.class.path所指定的目錄中記載類，是用戶自定義加載器的默認(rèn)父加載器。

69、Java對象創(chuàng)建過程

1.JVM遇到一條新建對象的指令時(shí)首先去檢查這個(gè)指令的參數(shù)是否能在常量池中定義到一個(gè)類的符號引 用。然后加載這個(gè)類（類加載過程在后邊講）
2.為對象分配內(nèi)存。一種辦法“指針碰撞”、一種辦法“空閑列表”，最終常用的辦法“本地線程緩沖分配
(TLAB)”
3.將除對象頭外的對象內(nèi)存空間初始化為0
4.對對象頭進(jìn)行必要設(shè)置

70、簡述Java的對象結(jié)構(gòu)

Java對象由三個(gè)部分組成：對象頭、實(shí)例數(shù)據(jù)、對齊填充。
對象頭由兩部分組成，第一部分存儲對象自身的運(yùn)行時(shí)數(shù)據(jù)：哈希碼、GC分代年齡、鎖標(biāo)識狀態(tài)、線 程持有的鎖、偏向線程ID（一般占32/64 bit）。第二部分是指針類型，指向?qū)ο蟮念愒獢?shù)據(jù)類型（即對 象代表哪個(gè)類）。如果是數(shù)組對象，則對象頭中還有一部分用來記錄數(shù)組長度。
實(shí)例數(shù)據(jù)用來存儲對象真正的有效信息（包括父類繼承下來的和自己定義的）
對齊填充：JVM要求對象起始地址必須是8字節(jié)的整數(shù)倍（8字節(jié)對齊 )

71、如何判斷對象可以被回收

判斷對象是否存活一般有兩種方式：
引用計(jì)數(shù)：每個(gè)對象有一個(gè)引用計(jì)數(shù)屬性，新增一個(gè)引用時(shí)計(jì)數(shù)加1，引用釋放時(shí)計(jì)數(shù)減1，計(jì)數(shù)為0時(shí) 可以回收。此方法簡單，無法解決對象相互循環(huán)引用的問題。
可達(dá)性分析（Reachability Analysis）：從GC Roots開始向下搜索，搜索所走過的路徑稱為引用鏈。當(dāng) 一個(gè)對象到GC Roots沒有任何引用鏈相連時(shí)，則證明此對象是不可用的，不可達(dá)對象。

72、JVM的永久代中會發(fā)生垃圾回收么

垃圾回收不會發(fā)生在永久代，如果永久代滿了或者是超過了臨界值，會觸發(fā)完全垃圾回收(Full GC)。如 果你仔細(xì)查看垃圾收集器的輸出信息，就會發(fā)現(xiàn)永久代也是被回收的。這就是為什么正確的永久代大小 對避免Full GC是非常重要的原因。請參考下Java8：從永久代到元數(shù)據(jù)區(qū) (注：Java8中已經(jīng)移除了永久 代，新加了一個(gè)叫做元數(shù)據(jù)區(qū)的native內(nèi)存區(qū))

73、垃圾收集算法

GC最基礎(chǔ)的算法有三種： 標(biāo)記 -清除算法、復(fù)制算法、標(biāo)記-壓縮算法，我們常用的垃圾回收器一般都 采用分代收集算法。
標(biāo)記 -清除算法，“標(biāo)記-清除”（Mark-Sweep）算法，如它的名字一樣，算法分為“標(biāo)記”和“清除”兩個(gè)階 段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后統(tǒng)一回收掉所有被標(biāo)記的對象。
復(fù)制算法，“復(fù)制”（Copying）的收集算法，它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用 其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對象復(fù)制到另外一塊上面，然后再把已使用過的 內(nèi)存空間一次清理掉。
標(biāo)記-壓縮算法，標(biāo)記過程仍然與“標(biāo)記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進(jìn)行清理， 而是讓所有存活的對象都向一端移動(dòng)，然后直接清理掉端邊界以外的內(nèi)存
分代收集算法，“分代收集”（Generational Collection）算法，把Java堆分為新生代和老年代，這樣就 可以根據(jù)各個(gè)年代的特點(diǎn)采用最適當(dāng)?shù)氖占惴?/p>

74、調(diào)優(yōu)命令有哪些？

Sun JDK監(jiān)控和故障處理命令有jps jstat jmap jhat jstack jinfo

1. jps，JVM Process Status Tool,顯示指定系統(tǒng)內(nèi)所有的HotSpot虛擬機(jī)進(jìn)程。
2. jstat，JVM statistics Monitoring是用于監(jiān)視虛擬機(jī)運(yùn)行時(shí)狀態(tài)信息的命令，它可以顯示出虛擬機(jī) 進(jìn)程中的類裝載、內(nèi)存、垃圾收集、JIT編譯等運(yùn)行數(shù)據(jù)。
3. jmap，JVM Memory Map命令用于生成heap dump文件
4. jhat，JVM Heap Analysis Tool命令是與jmap搭配使用，用來分析jmap生成的dump，jhat內(nèi)置了 一個(gè)微型的HTTP/HTML服務(wù)器，生成dump的分析結(jié)果后，可以在瀏覽器中查看
5. jstack，用于生成java虛擬機(jī)當(dāng)前時(shí)刻的線程快照。
6. jinfo，JVM Con?guration info 這個(gè)命令作用是實(shí)時(shí)查看和調(diào)整虛擬機(jī)運(yùn)行參數(shù)

75、調(diào)優(yōu)工具

常用調(diào)優(yōu)工具分為兩類,jdk自帶監(jiān)控工具：jconsole和jvisualvm，第三方有：MAT(Memory Analyzer Tool)、GChisto。

1. jconsole，Java Monitoring and Management Console是從java5開始，在JDK中自帶的java監(jiān)控 和管理控制臺，用于對JVM中內(nèi)存，線程和類等的監(jiān)控
2. jvisualvm，jdk自帶全能工具，可以分析內(nèi)存快照、線程快照；監(jiān)控內(nèi)存變化、GC變化等。
3. MAT，Memory Analyzer Tool，一個(gè)基于Eclipse的內(nèi)存分析工具，是一個(gè)快速、功能豐富的 Javaheap分析工具，它可以幫助我們查找內(nèi)存泄漏和減少內(nèi)存消耗
4. GChisto，一款專業(yè)分析gc日志的工具

76、Minor GC與Full GC分別在什么時(shí)候發(fā)生？

新生代內(nèi)存不夠用時(shí)候發(fā)生MGC也叫YGC，JVM內(nèi)存不夠的時(shí)候發(fā)生FGC

77、你知道哪些JVM性能調(diào)優(yōu)

設(shè)定堆內(nèi)存大小
-Xmx：堆內(nèi)存最大限制。
設(shè)定新生代大小。 新生代不宜太小，否則會有大量對象涌入老年代
-XX:NewSize：新生代大小
-XX:NewRatio 新生代和老生代占比
-XX:SurvivorRatio：伊甸園空間和幸存者空間的占比
設(shè)定垃圾回收器 年輕代用 -XX:+UseParNewGC 年老代用-XX:+UseConcMarkSweepGC