金三銀四面試季節之Java 核心面試技術點 - JVM 小結

描述一下 JVM 的記憶體區域

程式計數?（PC，Program Counter Register），在 JVM 規范中，每個執行緒都有它自己的程式計數?，并且任何時間一個執行緒都只有一個方法在執行，也就是所謂的當前方法，程式計數?會存盤當前執行緒正在執行的 Java 方法的 JVM 指令地址；或者，如果是在執行本地方法，則是未指定值（undefined），

Java 虛擬機堆疊（Java Virtual Machine Stack），早期也叫 Java 堆疊，每個執行緒在創建時都會創建一個虛擬機堆疊，其內部保存一個個的堆疊幀（Stack Frame），對應著一次次的 Java 方法呼叫，前面談程式計數?時，提到了當前方法；同理，在一個時間點，對應的只會有一個活動的堆疊幀，通常叫作當前幀，方法所在的類叫作當前類，如果在該方法中呼叫了其他方法，對應的新的堆疊幀會被創建出來，成為新的當前幀，一直到它回傳結果或者執行結束，JVM 直接對 Java 堆疊的操作只有兩個，就是對堆疊幀的壓堆疊和出堆疊，堆疊幀中存盤著區域變數表、運算元（operand）堆疊、動態鏈接、方法正常退出或者例外退出的定義等，

堆（Heap），它是 Java 記憶體管理的核心區域，用來放置 Java 物件實體，幾乎所有創建的Java 物件實體都是被直接分配在堆上，堆被所有的執行緒共享，在虛擬機啟動時，我們指定的“Xmx”之類引數就是用來指定最大堆空間等指標，理所當然，堆也是垃圾收集?重點照顧的區域，所以堆內空間還會被不同的垃圾收集?進行進一步的細分，最有名的就是新生代、老年代的劃分，

方法區（Method Area），這也是所有執行緒共享的一塊記憶體區域，用于存盤所謂的元（Meta）資料，例如類結構資訊，以及對應的運行時常量池、欄位、方法代碼等，由于早期的 Hotspot JVM 實作，很多人習慣于將方法區稱為永久代（Permanent Generation），Oracle JDK 8 中將永久代移除，同時增加了元資料區（Metaspace），

運行時常量池（Run-Time Constant Pool），這是方法區的一部分，如果仔細分析過反編譯的類檔案結構，你能看到版本號、欄位、方法、超類、介面等各種資訊，還有一項資訊就是常量池，Java 的常量池可以存放各種常量資訊，不管是編譯期生成的各種字面量，還是需要在運行時決定的符號參考，所以它比一般語言的符號表存盤的資訊更加寬泛，

本地方法堆疊（Native Method Stack），它和 Java 虛擬機堆疊是非常相似的，支持對本地方法的呼叫，也是每個執行緒都會創建一個，在 Oracle Hotspot JVM 中，本地方法堆疊和 Java 虛擬機堆疊是在同一塊兒區域，這完全取決于技術實作的決定，并未在規范中強制，

造成OOM的原因有哪幾種？

堆記憶體不足是最常見的 OOM 原因之一，拋出的錯誤資訊是“java.lang.OutOfMemoryError:Java heap space”，原因可能千奇百怪，例如，可能存在記憶體泄漏問題；也很有可能就是堆的大小不合理，比如我們要處理比較可觀的資料量，但是沒有顯式指定 JVM 堆大小或者指定數值偏小；或者出現 JVM 處理參考不及時，導致堆積起來，記憶體無法釋放等，
虛擬機堆疊和本地方法堆疊，這里要稍微復雜一點，如果我們寫一段程式不斷的進行遞回呼叫，而且沒有退出條件，就會導致不斷地進行壓堆疊，類似這種情況，JVM 實際會拋出StackOverFlowError；當然，如果 JVM 試圖去擴展堆疊空間的的時候失敗，則會拋出OutOfMemoryError，
對于老版本的 Oracle JDK，因為永久代的大小是有限的，并且 JVM 對永久代垃圾回收（如，常量池回收、卸載不再需要的型別）非常不積極，所以當我們不斷添加新型別的時候，永久代出現OutOfMemoryError 也非常多見，尤其是在運行時存在大量動態型別生成的場合；類似 Intern 字串快取占用太多空間，也會導致 OOM 問題，對應的例外資訊，會標記出來和永久代相關：“java.lang.OutOfMemoryError: PermGenspace

GC 演算法

復制（Copying）演算法，我前面講到的新生代 GC，基本都是基于復制演算法，將活著的物件復制到 to 區域，拷貝程序中將物件順序放置，就可以避免記憶體碎片化，這么做的代價是，既然要進行復制，既要提前預留記憶體空間，有一定的浪費；另外，對于 G1 這種分拆成為大量 region 的 GC，復制而不是移動，意味著 GC 需要維護 region 之間物件參考關系，這個開銷也不小，不管是記憶體占用或者時間開銷，

標記 - 清除（Mark-Sweep）演算法，首先進行標記作業，標識出所有要回收的物件，然后進行清除，這么做除了標記、清除程序效率有限，另外就是不可避免的出現碎片化問題，這就導致其不適合特別大的堆；否則，一旦出現 Full GC，暫停時間可能根本無法接受，

標記 - 整理（Mark-Compact），類似于標記 - 清除，但為避免記憶體碎片化，它會在清理程序中將物件移動，以確保移動后的物件占用連續的記憶體空間，

G1 垃圾回收器采用的是什么垃圾回收演算法？

從 GC 演算法的角度，G1 選擇的是復合演算法，可以簡化理解為：

在新生代，G1 采用的仍然是并行的復制演算法，所以同樣會發生 Stop-The-World 的暫停，
在老年代，大部分情況下都是并發標記，而整理（Compact）則是和新生代 GC 時捎帶進行，并且不是整體性的整理，而是增量進行的，

GC 調優思路

從性能的角度看，通常關注三個方面，記憶體占用（footprint）、延時（latency）和吞吐量（throughput），大多數情況下調優會側重于其中一個或者兩個方面的目標，很少有情況可以兼顧三個不同的角度，當然，除了上面通常的三個方面，也可能需要考慮其他 GC 相關的場景，例如，OOM 也可能與不合理的 GC 相關引數有關；或者，應用啟動速度方面的需求，GC 也會是個考慮的方面，
基本的調優思路可以總結為：

• 理解應用需求和問題，確定調優目標，假設，我們開發了一個應用服務，但發現偶爾會出現性能抖動，出現較長的服務停頓，評估用戶可接受的回應時間和業務量，將目標簡化為，希望 GC 暫停盡量控制在 200ms 以內，并且保證一定標準的吞吐量，
• 掌握 JVM 和 GC 的狀態，定位具體的問題，確定真的有 GC 調優的必要，具體有很多方法，比如，通過 jstat 等工具查看 GC 等相關狀態，可以開啟 GC 日志，或者是利用作業系統提供的診斷工具等，例如，通過追蹤 GC 日志，就可以查找是不是 GC 在特定時間發生了長時間的暫停，進而導致了應用回應不及時，
• 選擇的 GC 型別是否符合我們的應用特征，如果是，具體問題表現在哪里，是 Minor GC 過長，還是 Mixed GC 等出現例外停頓情況；如果不是，考慮切換到什么型別，如 CMS 和 G1 都是更側重于低延遲的 GC 選項，

通過分析確定具體調整的引數或者軟硬體配置，驗證是否達到調優目標，如果達到目標，即可以考慮結束調優；否則，重復完成分析、調整、驗證這個程序，

如何提高JVM的性能？

1.新物件預留在年輕代 通過設定一個較大的年輕代預留新物件，設定合理的 Survivor 區并且提供 Survivor 區的使用率，可以將年輕物件保存在年輕代，

2.大物件進入年老代 使用引數-XX:PetenureSizeThreshold 設定大物件直接進入年老代的閾值

3.設定物件進入年老代的年齡 這個閾值的最大值可以通過引數-XX:MaxTenuringThreshold 來設定，默認值是 15

4. 穩定的 Java 堆 獲得一個穩定的堆大小的方法是使-Xms 和-Xmx 的大小一致，即最大堆和最小堆 (初始堆) 一樣，

5.增大吞吐量提升系統性能 –Xmx380m –Xms3800m：設定 Java 堆的最大值和初始值，一般情況下，為了避免堆記憶體的頻繁震蕩，導致系統性能下降，我們的做法是設定最大堆等于最小堆，假設這里把最小堆減少為最大堆的一半，即 1900m，那么 JVM 會盡可能在 1900MB 堆空間中運行，如果這樣，發生 GC 的可能性就會比較高； -Xss128k：減少執行緒堆疊的大小，這樣可以使剩余的系統記憶體支持更多的執行緒；-Xmn2g：設定年輕代區域大小為 2GB；–XX:+UseParallelGC：年輕代使用并行垃圾回收收集器，這是一個關注吞吐量的收集器，可以盡可能地減少 GC 時間，–XX:ParallelGC-Threads：設定用于垃圾回收的執行緒數，通常情況下，可以設定和 CPU 數量相等，但在 CPU 數量比較多的情況下，設定相對較小的數值也是合理的；–XX:+UseParallelOldGC：設定年老代使用并行回收收集器，

6.嘗試使用大的記憶體分頁
–XX:+LargePageSizeInBytes：設定大頁的大小，
記憶體分頁 (Paging) 是在使用 MMU 的基礎上，提出的一種記憶體管理機制，它將虛擬地址和物理地址按固定大小（4K）分割成頁 (page) 和頁幀 (page frame)，并保證頁與頁幀的大小相同，這種機制，從資料結構上，保證了訪問記憶體的高效，并使 OS 能支持非連續性的記憶體分配，

7.使用非占有的垃圾回收器
為降低應用軟體的垃圾回收時的停頓，首先考慮的是使用關注系統停頓的 CMS 回收器，其次，為了減少 Full GC 次數，應盡可能將物件預留在年輕代，

system.gc() 的作用是什么？

gc()函式的作用只是提醒虛擬機：程式員希望進行一次垃圾回收，但是它不能保證垃圾回收一定會進行，而且具體什么時候進行是取決于具體的虛擬機的，不同的虛擬機有不同的對策，

Parallel GC、CMS GC、ZGC、Azul Pauseless GC最主要的不同是？背后的原理也請簡單描述下？

Parallel GC的Young區采用的是Mark-Copy演算法，Old區采用的是Mark-Sweep-Compact來實作，Parallel執行，所以決定了Parallel GC在執行YGC、FGC時都會Stop-The-World，但完成GC的速度也會比較快，
CMS GC的Young區采用的也是Mark-Copy，Old區采用的是Concurrent Mark-Sweep，所以決定了CMS GC在對old區回收時造成的STW時間會更短，避免對應用產生太大的時延影響，
G1 GC采用了Garbage First演算法，比較復雜，實作的好呢，理論上是會比CMS GC可以更高效，同時對應用的影響也很小，
ZGC、Azul Pauseless GC采用的演算法很不一樣，尤其是Pauseless GC，其中的很重要的一個技巧是通過增加Read Barrier來更好的識別對GC而言最關鍵的references變化的情況，

什么時候執行ygc，fullgc？

當young gen中的eden區分配滿的時候觸發young gc，當年老代記憶體不足時，將執行Major GC，也叫 Full GC，

gc()函式的作用只是提醒虛擬機：程式員希望進行一次垃圾回收，但是它不能保證垃圾回收一定會進行，而且具體什么時候進行是取決于具體的虛擬機的，不同的虛擬機有不同的對策，

強參考、軟參考、弱參考、幻象參考有什么區別？具體使用場景是什么？

不同的參考型別，主要體現的是物件不同的可達性（reachable）狀態和對垃圾收集的影響，

所謂強參考（“Strong” Reference），就是我們最常見的普通物件參考，只要還有強參考指向一個物件，就能表明物件還“活著”，垃圾收集器不會碰這種物件，對于一個普通的物件，如果沒有其他的參考關系，只要超過了參考的作用域或者顯式地將相應（強）參考賦值為 null，就是可以被垃圾收集的了，當然具體回收時機還是要看垃圾收集策略，

軟參考（SoftReference），是一種相對強參考榷訓一些的參考，可以讓物件豁免一些垃圾收集，只有當 JVM 認為記憶體不足時，才會去試圖回收軟參考指向的物件，JVM 會確保在拋出OutOfMemoryError 之前，清理軟參考指向的物件，軟參考通常用來實作記憶體敏感的快取，如果還有空閑記憶體，就可以暫時保留快取，當記憶體不足時清理掉，這樣就保證了使用快取的同時，不會耗盡記憶體，

SoftReference 在“弱參考WeakReference”中屬于最強的參考，SoftReference 所指向的物件，當沒有強參考指向它時，會在記憶體中停留一段的時間，垃圾回收器會根據 JVM 記憶體的使用情況（記憶體的緊缺程度）以及 SoftReference 的 get() 方法的呼叫情況來決定是否對其進行回收，

對于幻象參考（PhantomReference ），有時候也翻譯成虛參考，你不能通過它訪問物件，幻象參考僅僅是提供了一種確保物件被 finalize 以后，做某些事情的機制，比如，通常用來做所謂的 Post-Mortem 清理機制，如 Java 平臺自身 Cleaner 機制等，也有人利用幻象參考監控物件的創建和銷毀，

Object counter = new Object();
ReferenceQueue refQueue = new ReferenceQueue<>();
PhantomReference<Object> p = new PhantomReference<>(counter, refQueue);
counter = null;
System.gc();
try {
    // Remove 是一個阻塞方法，可以指定 timeout，或者選擇一直阻塞
    Reference<Object> ref = refQueue.remove(1000L);
    if (ref != null) {
        // do something
    }
} catch (InterruptedException e) {
    // Handle it
}

JVM類加載程序

一般來說，我們把 Java 的類加載程序分為三個主要步驟：加載、鏈接、初始化，首先是加載階段（Loading），它是 Java 將位元組碼資料從不同的資料源讀取到 JVM 中，并映射為 JVM 認可的資料結構（Class 物件），這里的資料源可能是各種各樣的形態，如 jar 檔案、class 檔案，甚至是網路資料源等；如果輸入資料不是 ClassFile 的結構，則會拋出 ClassFormatError，加載階段是用戶參與的階段，我們可以自定義類加載?，去實作自己的類加載程序，

第二階段是鏈接（Linking），這是核心的步驟，簡單說是把原始的類定義資訊平滑地轉化入 JVM 運行的程序中，這里可進一步細分為三個步驟：
1.驗證（Verification），這是虛擬機安全的重要保障，JVM 需要核驗位元組資訊是符合 Java 虛擬機規范的，否則就被認為是 VerifyError，這樣就防止了惡意資訊或者不合規的資訊危害 JVM 的運行，驗證階段有可能觸發更多 class 的加載，

2.準備（Preparation），創建類或介面中的靜態變數，并初始化靜態變數的初始值，但這里的“初始化”和下面的顯式初始化階段是有區別的，側重點在于分配所需要的記憶體空間，不會去執行更進一步的 JVM 指令，

3.決議（Resolution），在這一步會將常量池中的符號參考（symbolic reference）替換為直接參考，

最后是初始化階段（initialization），這一步真正去執行類初始化的代碼邏輯，包括靜態欄位賦值的動作，以及執行類定義中的靜態初始化塊內的邏輯，編譯?在編譯階段就會把這部分邏輯整理好，父型別的初始化邏輯優先于當前型別的邏輯，

什么是雙親委派模型？

簡單說就是當類加載?（Class-Loader）試圖加載某個型別的時候，除非父加載?找不到相應型別，否則盡量將這個任務代理給當前加載?的父加載?去做，使用委派模型的目的是避免重復加載 Java 型別，

類加載器的型別

• 啟動類加載?（Bootstrap Class-Loader），加載 jre/lib 下面的 jar 檔案，如 rt.jar，它是個超級公民，即使是在開啟了 Security Manager 的時候，JDK 仍賦予了它加載的程式 AllPermission，
• 擴展類加載?（Extension or Ext Class-Loader），負責加載我們放到 jre/lib/ext/ 目錄下面的 jar 包，這就是所謂的 extension 機制，該目錄也可以通過設定 “java.ext.dirs”來覆寫，
• 應用類加載?（Application or App Class-Loader），就是加載我們最熟悉的 classpath

背景關系類加載器

Java 提供了很多服務提供者介面（Service Provider Interface，SPI），允許第三方為這些介面提供實作，常見的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等，這些 SPI 的介面由 Java 核心庫來提供，而這些 SPI 的實作代碼則是作為 Java 應用所依賴的 jar 包被包含進類路徑（CLASSPATH）里，SPI介面中的代碼經常需要加載具體的實作類，那么問題來了，SPI的介面是Java核心庫的一部分，是由**啟動類加載器(Bootstrap Classloader)來加載的；SPI的實作類是由系統類加載器(System ClassLoader)**來加載的，引導類加載器是無法找到 SPI 的實作類的，因為依照雙親委派模型，BootstrapClassloader無法委派AppClassLoader來加載類，而執行緒背景關系類加載器破壞了“雙親委派模型”，可以在執行執行緒中拋棄雙親委派加載鏈模式，使程式可以逆向使用類加載器，

ServiceLoader 的加載代碼：

public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

ContextClassLoader默認存放了AppClassLoader的參考，由于它是在運行時被放在了執行緒中，所以不管當前程式處于何處（BootstrapClassLoader或是ExtClassLoader等），在任何需要的時候都可以用Thread.currentThread().getContextClassLoader()取出應用程式類加載器來完成需要的操作，

自定義類加載器

自定義類加載?，常見的場景有：

• 實作類似行程內隔離，類加載?實際上用作不同的命名空間，以提供類似容?、模塊化的效果，例如，兩個模塊依賴于某個類別庫的不同版本，如果分別被不同的容?加載，就可以互不干擾，這個方面的集大成者是Java EE和OSGI、JPMS等框架，
• 應用需要從不同的資料源獲取類定義資訊，例如網路資料源，而不是本地檔案系統，
• 需要自己操縱位元組碼，動態修改或者生成型別

從本地路徑 load class 的例子:

public class CustomClassLoader extends ClassLoader {
 
    @Override
    public Class findClass(String name) throws ClassNotFoundException {
        byte[] b = loadClassFromFile(name);
        return defineClass(name, b, 0, b.length);
    }
 
    private byte[] loadClassFromFile(String fileName)  {
        InputStream inputStream = getClass().getClassLoader().getResourceAsStream(
                fileName.replace('.', File.separatorChar) + ".class");
        byte[] buffer;
        ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
        int nextValue = 0;
        try {
            while ( (nextValue = inputStream.read()) != -1 ) {
                byteStream.write(nextValue);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        buffer = byteStream.toByteArray();
        return buffer;
    }
}

動態代理的原理？

反射機制是 Java 語言提供的一種基礎功能，賦予程式在運行時自省（introspect，官方用語）的能力，通過反射我們可以直接操作類或者物件，比如獲取某個物件的類定義，獲取類宣告的屬性和方法，呼叫方法或者構造物件，甚至可以運行時修改類定義， 動態代理是一種方便運行時動態構建代理、動態處理代理方法呼叫的機制，很多場景都是利用類似機制做到的，比如用來包裝 RPC 呼叫、面向切面的編程（AOP）， 實作動態代理的方式很多，比如 JDK 自身提供的動態代理，就是主要利用了上面提到的反射機制，還有其他的實作方式，比如利用傳說中更高性能的位元組碼操作機制，類似 ASM、cglib（基于 ASM）、Javassist 等，

如何使用JDK動態代理？

public class MyDynamicProxy {
    public static  void main (String[] args) {
        HelloImpl hello = new HelloImpl();
        MyInvocationHandler handler = new MyInvocationHandler(hello);
        // 構造代碼實體
        Hello proxyHello = (Hello) Proxy.newProxyInstance(HelloImpl.class.getClassLoader(), HelloImpl.class.getInterfaces(), handler);
        // 呼叫代理方法
        proxyHello.sayHello();
    }
}
interface Hello {
    void sayHello();
}
class HelloImpl implements  Hello {
    @Override
    public void sayHello() {
        System.out.println("Hello World");
    }
}
class MyInvocationHandler implements InvocationHandler {
    private Object target;
    public MyInvocationHandler(Object target) {
        this.target = target;
    }
    @Override
    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        System.out.println("Invoking sayHello");
        Object result = method.invoke(target, args);
        return result;
    }
}

動態代理：JDK動態代理和CGLIB代理的區別？

JDK動態代理只能對實作了介面的類生成代理，而不能針對類，CGLIB是針對類實作代理，主要是對指定的類生成一個子類，覆寫其中的方法（繼承），
JDK Proxy 的優勢：
1.最小化依賴關系，減少依賴意味著簡化開發和維護，JDK 本身的支持，可能比 cglib 更加可靠，
2.平滑進行 JDK 版本升級，而位元組碼類別庫通常需要進行更新以保證在新版 Java 上能夠使用，
3.代碼實作簡單，

基于類似 cglib 框架的優勢：

1.有的時候呼叫目標可能不便實作額外介面，從某種角度看，限定呼叫者實作介面是有些侵入性的實踐，類似 cglib 動態代理就沒有這種限制，
2.只操作我們關心的類，而不必為其他相關類增加作業量，
3.高性能，

Spring在選擇用JDK還是CGLiB的依據是什么？

(1)當Bean實作介面時，Spring就會用JDK的動態代理
(2)當Bean沒有實作介面時，Spring使用CGlib是實作
(3)可以強制使用CGlib（在spring配置中加入<aop:aspectj-autoproxy proxy-target-class=“true”/>）

CGlib比JDK快？

(1)使用CGLib實作動態代理，CGLib底層采用ASM位元組碼生成框架，使用位元組碼技術生成代理類，比使用Java反射效率要高，唯一需要注意的是，CGLib不能對宣告為final的方法進行代理，因為CGLib原理是動態生成被代理類的子類，但是JDK也在升級，開始引入很多位元組碼技術來實作部分動態代理的功能，所以在某些測驗下不一定是CGLib更快，

Java 中操作位元組碼的技術

ASM、Javassist、CGLib、Byte Budy，

讀者福利

感謝你看到了這里！
我這邊整理很多2020最新Java面試題（含答案）和Java學習筆記，如下圖

有需要的話可以免費獲取！
點擊免費領取

如果喜歡本篇文章，歡迎轉發、點贊，
記得關注我！