? 適配人群：中高級 Java 開發(fā) / 資深開發(fā) / 技術專家，校招拔高 / 社招跳槽通用，覆蓋大廠 95% 高頻考點

? 內容分級：Java核心進階(25%) → 并發(fā)編程核心(30%) → JVM虛擬機深度(20%) → 分布式&框架源碼(15%) → 項目架構&實戰(zhàn)方案(10%)

? 答案特點：全部是面試高分精簡版，分點清晰、突出核心考點 + 坑點 + 加分項，無冗余內容，背完直接用，兼顧原理 + 實戰(zhàn) + 調優(yōu)，直擊高薪面試核心

一、Java 核心進階（高級開發(fā)必問，基礎拔高，25%）

1. HashMap JDK7 vs JDK8 底層實現(xiàn)及核心區(qū)別？【必考?高頻天花板】

答案要點（面試滿分版，分點必背）

• JDK7 底層結構：數(shù)組 + 鏈表，哈希表采用 拉鏈法 解決哈希沖突。
• JDK8 底層結構：數(shù)組 + 鏈表 + 紅黑樹，是 JDK7 的優(yōu)化版，核心區(qū)別如下：
  1. 哈希沖突解決：當鏈表長度 >=8 且 數(shù)組長度 >=64 時，鏈表轉為紅黑樹；紅黑樹節(jié)點數(shù) <=6 時，退化為鏈表。（優(yōu)化原因：鏈表查詢 O (n)，紅黑樹查詢 O (logn)，解決長鏈表查詢慢問題）
  2. 哈希算法優(yōu)化：JDK8 的哈希值計算更高效，減少哈希碰撞概率。
  3. 擴容機制優(yōu)化：JDK7 擴容是頭插法，并發(fā)下會導致鏈表成環(huán)、數(shù)據丟失；JDK8 擴容是尾插法，并發(fā)下不會成環(huán)，且擴容時紅黑樹會拆分為鏈表 / 紅黑樹。
  4. put 方法流程：JDK7 先擴容后插入；JDK8 先插入后擴容。
• ? 核心面試坑點：HashMap 是線程不安全的，并發(fā)場景下會出現(xiàn)死循環(huán)、數(shù)據覆蓋，解決方案：使用 ConcurrentHashMap 替代。
• ? 加分回答：HashMap 默認初始容量 16，負載因子 0.75，擴容是 2 倍擴容；初始容量必須是 2 的冪次，目的是通過位運算替代取模，提升哈希尋址效率。

2. ConcurrentHashMap JDK7 vs JDK8 實現(xiàn)原理及線程安全保證？【必考】

答案要點

核心結論：ConcurrentHashMap 是 HashMap 的線程安全版，高并發(fā)場景下的首選 Map，JDK7 和 JDK8 實現(xiàn)完全不同，面試必問兩者區(qū)別

1. JDK7 實現(xiàn)：分段鎖（Segment）+ 數(shù)組 + 鏈表

   • 底層是一個 Segment 數(shù)組，每個 Segment 是一個 HashMap，Segment 繼承了 ReentrantLock；
   • 線程安全：通過分段鎖機制，只鎖住當前操作的 Segment，其他 Segment 可并發(fā)操作，鎖粒度是Segment 級別；
   • 缺點：分段鎖的粒度還是偏大，并發(fā)量高時性能一般。

2. JDK8 實現(xiàn)：CAS + synchronized + 數(shù)組 + 鏈表 + 紅黑樹

   • 徹底拋棄分段鎖，底層和 HashMap 結構一致（數(shù)組 + 鏈表 + 紅黑樹）；
   • 線程安全：雙重加鎖機制
     • ? 無沖突時：用 CAS 原子操作保證并發(fā)安全，無鎖開銷，性能極高；
     • ? 有沖突時：用 synchronized 鎖住當前哈希桶的首節(jié)點，鎖粒度是節(jié)點級別（JDK8 的 synchronized 做了重量級鎖→輕量級鎖→偏向鎖優(yōu)化，性能不輸 ReentrantLock）；
   • 優(yōu)點：鎖粒度極小，并發(fā)性能遠超 JDK7 版本，是生產環(huán)境的最優(yōu)解。

3. ArrayList 和 LinkedList 的區(qū)別？擴容機制？為什么 ArrayList 查詢快、增刪慢？【高頻】

答案要點

? 核心區(qū)別（底層 + 性能 + 適用場景）

1. 底層結構：ArrayList 是動態(tài)數(shù)組，基于數(shù)組實現(xiàn)；LinkedList 是雙向鏈表，基于鏈表實現(xiàn)。
2. 性能差異（核心）：
   • 查詢 / 隨機訪問：ArrayList 快（數(shù)組下標尋址，O (1)），LinkedList 慢（鏈表遍歷，O (n)）；
   • 增刪操作：ArrayList 慢（數(shù)組擴容 + 元素移位，O (n)），LinkedList 快（鏈表節(jié)點修改指針，O (1)）；
   • 注意：ArrayList 的尾部增刪是 O (1)，效率和 LinkedList 持平。
3. 內存占用：ArrayList 內存連續(xù)，浪費少量空間（擴容預留）；LinkedList 每個節(jié)點存儲數(shù)據 + 指針，內存開銷更大。
4. 適用場景：讀多寫少用 ArrayList，寫多讀少用 LinkedList。

? ArrayList 擴容機制

1. 初始容量：無參構造 JDK7 是 10，JDK8 是懶加載，第一次 add 時才初始化容量為 10；
2. 擴容閾值：當元素個數(shù) >= 容量
3. 擴容規(guī)則：默認擴容為原容量的 1.5 倍，擴容時會創(chuàng)建新數(shù)組，復制原數(shù)組元素，是耗時操作；
4. 優(yōu)化建議：提前指定初始容量 new ArrayList<>(1000)，避免頻繁擴容。

4. equals 和 hashCode 的關系？為什么重寫 equals 必須重寫 hashCode？【必考?坑點】

答案要點（面試標準答案，背會即可）

1. 默認實現(xiàn)（Object 類）：

   • equals：比較兩個對象的內存地址，只有同一對象才返回 true；
   • hashCode：返回對象的內存地址哈希值，同一對象的 hashCode 一定相同。

2. 核心約定（Java 官方規(guī)定，必須遵守）：

   • ? 若 a.equals(b) = true，則 a.hashCode() 必須等于 b.hashCode()；

   • ? 若 a.hashCode() = b.hashCode()，則 a.equals(b) 不一定為 true（哈希碰撞）；

   • ? 若 a.equals(b) = false，則 a.hashCode() 可以相同 / 不同。

3. 為什么重寫 equals 必須重寫 hashCode？【核心】

   • 場景：當對象存入 HashMap/HashSet 等哈希集合時，會先通過 hashCode 定位哈希桶，再通過 equals 比較元素；
   • 后果：只重寫 equals 不重寫 hashCode，會導致兩個邏輯相等的對象，hashCode 不同，存入哈希集合時會被當成兩個不同元素，出現(xiàn)數(shù)據重復，違背集合的去重原則。

5. Java8 核心新特性有哪些？為什么說 Java8 是里程碑式的版本？【必考】

? 核心：Java8 是 Java 史上最重要的版本，新增特性解決了 Java 函數(shù)式編程、并發(fā)效率、代碼簡潔性的痛點，高級開發(fā)必須吃透，回答時分點說核心特性 + 應用場景答案要點（高頻必答的 6 個核心特性）

1. Lambda 表達式：簡化匿名內部類的寫法，實現(xiàn)函數(shù)式編程，代碼更簡潔，如 list.forEach(x -> System.out.println(x))；
2. 函數(shù)式接口：只有一個抽象方法的接口（如 Consumer、Supplier、Function），是 Lambda 的基礎，配合注解@FunctionalInterface；
3. Stream 流式編程：對集合進行高效的聚合操作（過濾、映射、分組、統(tǒng)計），支持串行 / 并行，大幅簡化集合處理代碼，性能遠超傳統(tǒng) for 循環(huán)；
4. Optional 類：解決空指針異常 (NPE) 的終極方案，通過鏈式調用避免層層判空，如 optional.ifPresent().orElse().orElseGet()；
5. 默認方法 & 靜態(tài)方法：接口中可以定義帶實現(xiàn)的default方法和static方法，解決接口的版本兼容問題（新增方法不影響實現(xiàn)類）；
6. 時間日期 API：java.time 包下的 LocalDateTime、LocalDate 等，線程安全、API 友好，徹底替代線程不安全的 SimpleDateFormat/Date。

• 加分項：還新增了 CompletableFuture（異步編程）、方法引用、重復注解等特性。

6. 泛型的作用？什么是泛型擦除？有什么問題？【高頻】

答案要點

1. 泛型的核心作用：① 編譯期類型安全檢查，避免類型轉換錯誤；② 消除代碼中的強制類型轉換，代碼更簡潔。
2. 泛型擦除：Java 的泛型是偽泛型，泛型信息只在編譯期有效，編譯后字節(jié)碼文件中會擦除泛型類型，替換為原生類型（Object），運行時無法獲取泛型的具體類型。
3. 泛型擦除帶來的問題：
   1. ? 無法獲取泛型的 Class 對象，如 List<String>.class 編譯報錯；
   2. ? 無法創(chuàng)建泛型數(shù)組，如 new ArrayList<String>[10] 編譯報錯；
   3. ? 泛型方法的重載可能失效，因為擦除后類型相同。
4. 解決方案：通過反射 + 類型令牌 (TypeToken) 可以獲取泛型的具體類型，如 Spring 的 ResolvableType。

二、Java 并發(fā)編程（重中之重，高級開發(fā)核心分水嶺，30%）

? 核心說明：并發(fā)編程是 Java 高級開發(fā)面試的絕對核心，占比最高、區(qū)分度最大，大廠面試必問，從基礎的線程、鎖到進階的 AQS、CAS、線程池，全部是高頻考點，必須吃透！

1. 創(chuàng)建線程的方式有哪些？哪種最好？【基礎必問】

答案要點（標準答案，4 種方式，按推薦度排序）

1. 繼承 Thread 類：重寫 run () 方法，缺點：Java 單繼承，無法繼承其他類，耦合度高；
2. 實現(xiàn) Runnable 接口：實現(xiàn) run () 方法，優(yōu)點：支持多繼承，解耦，推薦；
3. 實現(xiàn) Callable 接口 + FutureTask：實現(xiàn) call () 方法，支持返回值 + 拋出異常，這是和 Runnable 的核心區(qū)別，適合需要獲取異步執(zhí)行結果的場景；
4. 線程池創(chuàng)建（ThreadPoolExecutor）：生產環(huán)境最優(yōu)選擇 ?，優(yōu)點：① 復用線程，避免頻繁創(chuàng)建銷毀線程的開銷；② 控制并發(fā)數(shù)，避免 OOM；③ 提供豐富的任務管理（核心線程、最大線程、隊列、拒絕策略）；

• 面試結論：優(yōu)先使用線程池創(chuàng)建線程，避免手動創(chuàng)建線程；Callable 適合有返回值的場景，Runnable 適合無返回值的場景。

2. volatile 關鍵字的作用？原理？能保證原子性嗎？【必考?高頻】

答案要點（面試滿分版，分點必背）

? volatile 核心三大作用（Java 并發(fā)的基石）

1. 保證可見性：當一個線程修改了 volatile 修飾的變量，其他線程能立即看到修改后的值，解決了線程間的內存可見性問題；
2. 禁止指令重排序：編譯器和 CPU 不會對 volatile 修飾的變量進行指令重排序，保證代碼的執(zhí)行順序和編寫順序一致，解決了單例模式 DCL 的指令重排序問題；
3. 不保證原子性：這是面試核心坑點，必須重點強調！

? volatile 實現(xiàn)原理

底層通過內存屏障 (Memory Barrier) 實現(xiàn)：

• 寫屏障：對 volatile 變量寫操作后，會插入寫屏障，強制將變量的修改刷新到主內存，其他線程可見；
• 讀屏障：對 volatile 變量讀操作前，會插入讀屏障，強制從主內存讀取變量的最新值，而非線程工作內存的緩存值。

? 為什么 volatile 不能保證原子性？

原子性是指「一個操作要么全部執(zhí)行成功，要么全部失敗」，volatile 只能保證可見性和有序性，無法保證復合操作的原子性。

• 例子：i++ 是復合操作（讀 i→加 1→寫 i），即使 i 被 volatile 修飾，多線程下依然會出現(xiàn)線程安全問題，最終結果小于預期值；
• 解決方案：保證原子性的方式 → synchronized / ReentrantLock / AtomicInteger（CAS 原子類）。

? volatile vs synchronized 核心區(qū)別【必考】

1. 作用范圍：volatile 修飾變量；synchronized 修飾方法 / 代碼塊；
2. 保證特性：volatile 保證可見性 + 有序性，不保證原子性；synchronized 保證可見性 + 有序性 + 原子性；
3. 鎖機制：volatile 是無鎖，無性能開銷；synchronized 是有鎖，有性能開銷（JDK8 已優(yōu)化）；
4. 適用場景：volatile 適合單寫多讀的場景（如狀態(tài)標記位）；synchronized 適合多寫多讀的場景。

3. CAS 是什么？原理？優(yōu)點缺點？ABA 問題及解決方案？【必考?高薪考點】

答案要點（CAS 是并發(fā)編程的核心，必須吃透）

? CAS 定義

        CAS = Compare And Swap（比較并交換），是一種無鎖的原子操作，是 Java 并發(fā)包（java.util.concurrent.atomic）的底層實現(xiàn)原理，核心思想是「無鎖并發(fā)，樂觀鎖思想」。

? CAS 核心原理

CAS 有 3 個核心參數(shù)：內存地址V、舊的預期值A、新值B。

• 執(zhí)行邏輯：線程從內存地址 V 讀取值 A，修改為新值 B，在寫入內存前，再次判斷內存地址 V 的值是否還是 A；如果是，則寫入 B，操作成功；如果不是（被其他線程修改），則放棄寫入，自旋重試。
• 底層支持：CAS 是 CPU 的原生指令（cmpxchg），由硬件保證原子性，性能遠超鎖機制。

? CAS 的優(yōu)點 & 缺點

        ? 優(yōu)點：無鎖機制，無需加鎖釋放鎖，沒有線程上下文切換的開銷，并發(fā)量低時性能極高；? 缺點：

1. 自旋重試開銷：并發(fā)量高時，大量線程自旋重試，會占用 CPU 資源，導致性能下降；
2. 只能保證單個變量的原子性：無法保證復合操作的原子性；
3. ABA 問題：CAS 的核心缺陷，面試必問！

? ABA 問題 & 解決方案【核心】

1. ABA 問題定義：線程 1 讀取內存值為 A，準備修改為 B；此時線程 2 將內存值從 A 修改為 C，再修改回 A；線程 1 再次判斷時，發(fā)現(xiàn)內存值還是 A，誤以為未被修改，執(zhí)行 CAS 操作成功，這就是 ABA 問題。
2. ABA 問題的危害：在簡單場景下無影響，但在鏈表、棧等有狀態(tài)的數(shù)據結構中，會導致數(shù)據結構的邏輯錯誤（如鏈表成環(huán)）。
3. 解決方案：原子引用 + 版本號（時間戳） → Java 提供 AtomicStampedReference 和 AtomicMarkableReference，在 CAS 時不僅比較值，還比較版本號 / 標記位，只有值和版本號都一致時，才執(zhí)行 CAS 操作，徹底解決 ABA 問題。

4. ThreadLocal 是什么？作用？內存泄漏問題及解決方案？【必考?高頻坑點】

答案要點（面試滿分版，分點必背，坑點必答）

? ThreadLocal 核心定義 & 作用

        ThreadLocal = 線程本地變量，核心作用是：為每個線程創(chuàng)建一個獨立的變量副本，線程之間的變量互不干擾，徹底解決多線程下的變量共享問題。

• 核心思想：空間換時間，用內存的開銷換取線程安全，無鎖機制，性能極高；
• 典型應用場景：① Spring 的事務管理器（綁定當前線程的數(shù)據庫連接）；② 日志跟蹤的 TraceId；③ 日期格式化工具類（SimpleDateFormat 線程不安全，用 ThreadLocal 封裝）。

? ThreadLocal 底層原理

1. Thread 類中有一個 ThreadLocalMap 成員變量，ThreadLocalMap 的 key 是弱引用的 ThreadLocal 對象，value 是線程的變量副本；
2. 每個線程的 ThreadLocalMap 是獨立的，線程只能訪問自己的 ThreadLocalMap，從而實現(xiàn)線程隔離。

? ThreadLocal 內存泄漏問題【核心坑點，面試必問】

1. 內存泄漏的原因：
   1. ? ThreadLocalMap 的 key 是弱引用，當 ThreadLocal 對象被 GC 回收后，key 變?yōu)?null，而 value 是強引用，依然指向變量副本；
   2. ? 如果線程一直存活（如線程池的核心線程），value 永遠不會被 GC 回收，導致內存泄漏。
2. 解決方案（生產必做，背會）：
   1. ? 核心方案：使用完 ThreadLocal 后，必須手動調用 remove() 方法，刪除當前線程的變量副本；
   2. ? 規(guī)范寫法：try { ... } finally { threadLocal.remove(); }，保證無論是否異常，都會執(zhí)行 remove；
   3. ? 補充：ThreadLocalMap 本身有過期清理機制，會在 get/set 時清理 key 為 null 的 entry，但不能依賴，手動 remove 是最優(yōu)解。

5. 線程池的核心參數(shù)？拒絕策略？如何合理配置線程池？【必考?實戰(zhàn)核心】

? 核心：線程池是生產環(huán)境的標配，面試必問核心參數(shù) + 拒絕策略 + 配置方案，體現(xiàn)你的實戰(zhàn)能力，這是加分項！

? 一、ThreadPoolExecutor 7 個核心參數(shù)（必背，按順序說）

public ThreadPoolExecutor(int corePoolSize,    // 核心線程數(shù)
                          int maximumPoolSize, // 最大線程數(shù)
                          long keepAliveTime,  // 空閑線程存活時間
                          TimeUnit unit,       // 時間單位
                          BlockingQueue<Runnable> workQueue, // 任務隊列
                          ThreadFactory threadFactory, // 線程工廠
                          RejectedExecutionHandler handler) // 拒絕策略

1. 核心線程數(shù) (corePoolSize)：線程池的常駐線程數(shù)，核心線程不會被回收，即使空閑；
2. 最大線程數(shù) (maximumPoolSize)：線程池能創(chuàng)建的最大線程數(shù)，核心線程 + 非核心線程的總數(shù)上限；
3. 空閑線程存活時間 (keepAliveTime)：非核心線程空閑超過該時間，會被回收，節(jié)省資源；
4. 任務隊列 (workQueue)：存放等待執(zhí)行的任務，核心線程滿了后，任務會進入隊列排隊；
5. 拒絕策略 (handler)：當線程池滿（線程數(shù) = 最大線程數(shù)，隊列已滿），新任務會觸發(fā)拒絕策略。

? 二、4 種默認拒絕策略（必背，生產常用）

1. AbortPolicy（默認）：直接拋出 RejectedExecutionException 異常，拒絕任務，生產中不推薦，會導致業(yè)務報錯；
2. CallerRunsPolicy：由提交任務的主線程執(zhí)行該任務，不會拋出異常，能有效緩沖流量，生產推薦 ?；
3. DiscardPolicy：直接丟棄任務，不拋出異常，無任何提示，慎用；
4. DiscardOldestPolicy：丟棄隊列中最老的任務，將新任務加入隊列，慎用。

? 三、線程池的任務執(zhí)行流程（必背）

1. 當任務提交時，若核心線程數(shù)未滿，創(chuàng)建核心線程執(zhí)行任務；
2. 核心線程滿了，任務進入任務隊列排隊；
3. 任務隊列滿了，創(chuàng)建非核心線程執(zhí)行任務；
4. 非核心線程數(shù)達到最大線程數(shù)，觸發(fā)拒絕策略。

? 四、如何合理配置線程池參數(shù)？【實戰(zhàn)核心，面試加分】

? 核心原則：根據任務類型來配置，任務分為「CPU 密集型」和「IO 密集型」，兩者配置完全不同

1. CPU 密集型任務（如計算、排序、加密）：任務消耗 CPU 資源，線程數(shù)過多會導致 CPU 上下文切換頻繁，性能下降；
   • 配置：核心線程數(shù) = CPU核心數(shù) + 1（最優(yōu)值）；
   • 隊列：使用無界隊列（如 LinkedBlockingQueue），避免拒絕任務。
2. IO 密集型任務（如數(shù)據庫查詢、Redis 調用、網絡請求）：任務大部分時間在等待 IO，CPU 空閑，線程數(shù)可以多配置；
   • 配置：核心線程數(shù) = CPU核心數(shù) * 2 或 CPU核心數(shù) / (1 - 阻塞系數(shù))（阻塞系數(shù) 0.8~0.9）；
   • 隊列：使用有界隊列（如 ArrayBlockingQueue），避免隊列無限擴容導致 OOM。
3. 生產規(guī)范：禁止使用 Executors 創(chuàng)建線程池（如 newFixedThreadPool、newCachedThreadPool），會導致 OOM；必須手動創(chuàng)建 ThreadPoolExecutor，指定核心參數(shù)和拒絕策略。

6. AQS 是什么？核心原理？有哪些基于 AQS 實現(xiàn)的類？【高薪必考?源碼級】

答案要點（精簡版，面試夠用，體現(xiàn)原理功底）

1. AQS 定義：AQS = AbstractQueuedSynchronizer，是 Java 并發(fā)包的核心基類，是一個抽象的同步隊列框架，所有的鎖和同步工具類都是基于 AQS 實現(xiàn)的。
2. AQS 核心原理：
   1. ? 核心思想：用一個 volatile 的 int 變量表示同步狀態(tài)（state），通過 CAS 修改狀態(tài)，保證原子性；
   2. ? 等待隊列：維護一個雙向鏈表的同步隊列，所有獲取鎖失敗的線程會加入隊列，阻塞等待；
   3. ? 獨占 / 共享模式：AQS 支持兩種模式，① 獨占模式（一把鎖只能被一個線程持有，如 ReentrantLock）；② 共享模式（一把鎖能被多個線程持有，如 CountDownLatch、Semaphore）。
3. 基于 AQS 實現(xiàn)的類（必背）：ReentrantLock、CountDownLatch、Semaphore、CyclicBarrier、ReentrantReadWriteLock。

• ? 面試加分：AQS 是 Java 并發(fā)的基石，掌握 AQS 的原理，就能理解所有鎖和同步工具的實現(xiàn)邏輯。

7. 公平鎖和非公平鎖的區(qū)別？ReentrantLock 是公平還是非公平？【高頻】

答案要點

1. 公平鎖：線程獲取鎖的順序，和線程排隊的順序一致，先到先得，不會出現(xiàn)插隊現(xiàn)象；
   • 優(yōu)點：公平，無饑餓問題；缺點：性能低，因為需要維護隊列的順序。
2. 非公平鎖：線程獲取鎖時，先嘗試插隊（直接 CAS 獲取鎖），插隊失敗后，再加入隊列排隊；
   • 優(yōu)點：性能高，因為減少了隊列的調度開銷；缺點：可能出現(xiàn)線程饑餓（某些線程一直拿不到鎖）。
3. ReentrantLock：默認是非公平鎖，構造方法傳入true可以指定為公平鎖：new ReentrantLock(true)；
4. synchronized：底層是非公平鎖，且無法改為公平鎖。

三、JVM 虛擬機（高薪分水嶺，高級開發(fā)必考，調優(yōu)是核心，20%）

? 核心說明：JVM 是 Java 高級開發(fā)的高薪門檻，初級開發(fā)問基礎，中高級開發(fā)問內存模型 + 垃圾回收 + 調優(yōu) + 內存泄漏，大廠面試必問，能答出 JVM 調優(yōu)的人，薪資至少上浮 20%！

1. JVM 運行時數(shù)據區(qū)（內存模型）劃分？各區(qū)域的作用？【必考?基礎】

        答案要點（JDK8 版本，必背，分點清晰，面試滿分）JVM 運行時數(shù)據區(qū)分為 線程私有區(qū)域 和 線程共享區(qū)域，JDK8 移除了永久代，用元空間 (Metaspace) 替代，這是核心考點！

? 一、線程私有區(qū)域（每個線程獨立創(chuàng)建，互不干擾）

1. 程序計數(shù)器 (PC Register)：存儲當前線程執(zhí)行的字節(jié)碼指令地址，線程切換時恢復執(zhí)行位置，無 OOM，是 JVM 中唯一不會內存溢出的區(qū)域；
2. 虛擬機棧 (VM Stack)：存儲方法的調用棧幀（局部變量表、操作數(shù)棧、返回地址等），方法調用入棧，方法執(zhí)行完成出棧；
   • 異常：棧深度過大→StackOverflowError；棧內存不足→OutOfMemoryError(OOM)；
3. 本地方法棧 (Native Method Stack)：和虛擬機棧類似，只是為native 本地方法服務，同樣會拋出棧溢出和 OOM 異常。

? 二、線程共享區(qū)域（所有線程共用，是 GC 的核心區(qū)域，面試重點）

1. 堆 (Heap)：JVM 中最大的內存區(qū)域，存儲所有對象實例和數(shù)組，是垃圾回收（GC）的主要戰(zhàn)場，也是 OOM 的高發(fā)區(qū)；
   • 堆的劃分：新生代（Eden 區(qū) + Survivor 區(qū) S0/S1） + 老年代，新生代存放年輕對象，老年代存放存活時間長的對象；
   • 核心：堆內存的大小可以通過 -Xms(初始堆內存) 和 -Xmx(最大堆內存) 配置，生產中建議兩者設置為相同值，避免頻繁擴容。
2. 元空間 (Metaspace，JDK8+)：替代 JDK7 的永久代，存儲類的元數(shù)據、常量池、方法區(qū)信息，元空間的內存是直接使用物理內存，默認無上限，可通過 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 配置；
   • 異常：元空間內存不足→OutOfMemoryError: Metaspace。

2. 什么是 GC？GC 的回收對象？判斷對象存活的算法有哪些？【必考】

答案要點

1. GC 定義：GC = 垃圾回收 (Garbage Collection)，是 JVM 的自動內存管理機制，自動回收堆中不再使用的對象，釋放內存，無需程序員手動管理，是 Java 的核心優(yōu)勢之一。
2. GC 的回收對象：堆內存中的對象實例，虛擬機棧、程序計數(shù)器等線程私有區(qū)域不會被 GC 回收；
3. 判斷對象存活的兩大核心算法：
   1. ? 引用計數(shù)法：給對象添加引用計數(shù)器，有引用時 + 1，引用失效時 - 1，計數(shù)器為 0 則對象死亡；
      • 缺點：無法解決循環(huán)引用問題（如 A 引用 B，B 引用 A），導致對象無法被回收，Java 不使用該算法；
   2. ? 可達性分析算法（Java 使用）：以「GC Roots」為根節(jié)點，向下遍歷對象的引用鏈，若對象到 GC Roots 沒有任何引用鏈，則對象被判定為死亡，可被 GC 回收；
      • GC Roots 包括：虛擬機棧中的局部變量、方法區(qū)中的靜態(tài)變量、本地方法棧中的 native 對象等。

3. 垃圾收集器有哪些？CMS 和 G1 的區(qū)別？生產環(huán)境如何選擇？【必考?調優(yōu)核心】

? 核心：垃圾收集器是 JVM 調優(yōu)的核心，面試必問 CMS 和 G1，這是目前生產環(huán)境的主流收集器，JDK9 后 G1 成為默認收集器。

? 一、主流垃圾收集器（按優(yōu)先級排序）

1. SerialGC：串行收集器，單線程回收，新生代用復制算法，老年代用標記 - 整理算法，適合單線程、小內存、客戶端程序，生產環(huán)境幾乎不用；
2. ParallelGC（并行收集器）：JDK8 默認收集器，新生代并行回收，老年代串行回收，追求吞吐量，適合后臺計算、批處理任務，無停頓要求的場景；
3. CMS（Concurrent Mark Sweep）：老年代收集器，并發(fā)收集、低停頓，基于「標記 - 清除」算法，核心是追求最短的 GC 停頓時間，適合高并發(fā)、響應時間敏感的業(yè)務（如電商、金融）；
4. G1（Garbage First）：JDK9 默認收集器，新生代 + 老年代通用收集器，基于「標記 - 整理」算法，核心是兼顧吞吐量和低停頓，適合大內存、高并發(fā)的生產環(huán)境，是目前的最優(yōu)解 ?。

? 二、CMS vs G1 核心區(qū)別（面試必答，滿分答案）

1. 回收范圍：CMS 只回收老年代，新生代需要配合 ParallelGC；G1 回收整個堆（新生代 + 老年代），無需搭配其他收集器；
2. 內存劃分：CMS 的堆是連續(xù)的，新生代是 Eden+S0+S1，老年代是連續(xù)區(qū)域；G1 將堆劃分為多個大小相等的 Region，新生代和老年代交錯分布，靈活度更高；
3. 回收算法：CMS 是「標記 - 清除」，會產生內存碎片，導致頻繁 Full GC；G1 是「標記 - 整理」，無內存碎片，內存利用率高；
4. 停頓控制：CMS 只能控制老年代的停頓，無法精準控制整體停頓；G1 支持可預測的停頓時間，可以設置 -XX:MaxGCPauseMillis，保證 GC 停頓不超過指定時間；
5. 適用場景：CMS 適合小內存（<=8G）、低停頓的場景；G1 適合大內存（>=8G）、兼顧吞吐量和低停頓的場景，生產環(huán)境優(yōu)先選擇 G1 ?。

4. 什么是內存泄漏和內存溢出？常見的內存泄漏場景？如何排查？【必考?實戰(zhàn)核心】

? 一、內存泄漏 vs 內存溢出（核心區(qū)別，面試必問）

1. 內存泄漏（Memory Leak）：對象不再被使用，但依然被其他對象持有引用，無法被 GC 回收，導致堆內存逐漸耗盡，是內存溢出的根源；
   • 特點：內存泄漏是漸進式的，內存占用會慢慢升高，最終導致 OOM；
2. 內存溢出（OOM）：JVM 的堆內存 / 元空間不足，無法為新對象分配內存，拋出 OutOfMemoryError 異常，程序崩潰；
   • 核心關系：內存泄漏 → 內存溢出，內存泄漏是因，內存溢出是果。

? 二、Java 中常見的內存泄漏場景（必背，生產高頻）

1. 靜態(tài)集合類：static List/Map 持有對象的強引用，對象使用后不刪除，導致永遠無法被 GC 回收；
2. 單例模式：單例持有外部對象的強引用，外部對象生命周期結束后，依然被單例持有，無法回收；
3. 未關閉的資源：數(shù)據庫連接、Redis 連接、文件流、Socket 連接等，使用后未調用close()關閉，資源句柄被持有，導致內存泄漏；
4. ThreadLocal 內存泄漏：使用后未調用remove()，導致 value 無法被 GC 回收（前文已講）；
5. 匿名內部類 / 內部類：內部類持有外部類的強引用，外部類生命周期結束后，被內部類持有無法回收。

? 三、內存泄漏 / 溢出的排查方案（生產實戰(zhàn)，面試加分，必背）

1. 開啟 JVM 參數(shù)，打印 GC 日志和堆轉儲文件：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dump.hprof；
2. 當發(fā)生 OOM 時，會自動生成 dump 文件，使用工具分析：MAT(Memory Analyzer Tool) 或 JProfiler，分析大對象、內存泄漏的引用鏈；
3. 用 JDK 自帶命令排查：jps（查看進程 ID）→ jstat（查看 GC 情況）→ jmap（導出堆快照）→ jhat（分析堆快照）。

5. JVM 性能調優(yōu)的核心思路？常用的調優(yōu)參數(shù)？【必考?高薪考點】

? 一、JVM 調優(yōu)的核心思路（必背，分步驟，體現(xiàn)實戰(zhàn)能力）

? 核心原則：先業(yè)務優(yōu)化，后 JVM 調優(yōu)，調優(yōu)不是目的，目的是解決性能問題（如頻繁 GC、OOM、響應慢），調優(yōu)的核心是「減少 Full GC 的次數(shù)，降低 GC 的停頓時間」

1. 第一步：定位問題：通過 GC 日志、監(jiān)控工具（Prometheus+Grafana、SkyWalking），確定問題類型（內存泄漏、頻繁 GC、Full GC 過多、停頓時間過長）；
2. 第二步：基礎調優(yōu)：合理配置堆內存（-Xms=-Xmx）、新生代比例（-XX:NewRatio）、元空間大小，避免內存不足導致的 OOM；
3. 第三步：收集器調優(yōu)：根據業(yè)務場景選擇收集器（響應優(yōu)先選 G1，吞吐量優(yōu)先選 ParallelGC），配置收集器的參數(shù)；
4. 第四步：代碼優(yōu)化：解決內存泄漏問題，減少大對象創(chuàng)建，避免頻繁創(chuàng)建臨時對象，使用池化技術（線程池、連接池）；
5. 第五步：驗證效果：觀察 GC 日志，看 Full GC 次數(shù)是否減少、停頓時間是否降低、程序響應是否提升。

? 二、常用的 JVM 調優(yōu)參數(shù)（必背，生產高頻）

1. 堆內存配置：-Xms2g -Xmx2g（初始堆 2G，最大堆 2G，推薦相等）；
2. 新生代配置：-XX:NewRatio=2（新生代：老年代 = 1:2）、-XX:SurvivorRatio=8（Eden:S0:S1=8:1:1）；
3. 收集器配置：-XX:+UseG1GC（使用 G1 收集器）、-XX:MaxGCPauseMillis=200（G1 最大停頓時間 200ms）；
4. GC 日志配置：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./gc.log（打印 GC 日志）；
5. 元空間配置：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m。

四、Java 分布式 & 框架深度（結合之前 Spring/MySQL/Redis，15%）

1. Spring 解決循環(huán)依賴的核心原理？【必考，和之前 Spring 面試題銜接】

答案要點（精簡版，面試夠用）

1. 循環(huán)依賴：A 依賴 B，B 依賴 A，Spring 容器啟動時會出現(xiàn)死循環(huán)；
2. Spring只解決單例 Bean 的屬性注入循環(huán)依賴，原型 Bean / 構造器注入的循環(huán)依賴無法解決；
3. 核心方案：三級緩存機制
   • 一級緩存：singletonObjects → 存放完全初始化的 Bean；
   • 二級緩存：earlySingletonObjects → 存放實例化完成、未初始化的早期 Bean；
   • 三級緩存：singletonFactories → 存放 Bean 的工廠對象，解決 AOP 代理的循環(huán)依賴；
4. 核心邏輯：通過三級緩存，提前暴露 Bean 的早期對象，讓依賴的 Bean 能拿到引用，避免死循環(huán)。

2. Spring 事務失效的常見場景？【必考】

答案要點（高頻 8 種，前文已詳細講，精簡版）

1. 注解加在非 public 方法上；
2. 同類中無事務方法調用有事務方法（內部調用，不走代理）；
3. 事務方法手動捕獲異常不拋出；
4. 拋出非 RuntimeException 異常（默認只回滾運行時異常）；
5. 傳播機制配置錯誤（如 NOT_SUPPORTED）；
6. 目標對象不是 Spring 容器的 Bean；
7. 數(shù)據庫不支持事務（如 MyISAM）；
8. 配置了readOnly=true的只讀事務。

3. 分布式事務的解決方案？優(yōu)缺點及適用場景？【必考?架構級】

答案要點（按生產使用頻率排序，必背）

1. 可靠消息最終一致性（RocketMQ/Kafka 事務消息）：核心是「本地事務 + 消息隊列」，最終一致性，無侵入，性能高，生產首選 ?，適合電商、支付等大部分業(yè)務；
2. TCC 模式（補償事務）：Try-Confirm-Cancel，手動編寫正向和反向補償邏輯，強一致性，侵入性高，適合金融等高一致性場景；
3. Seata AT 模式：無侵入，基于數(shù)據庫本地事務 + undo log，性能高，適合微服務架構，生產常用 ?；
4. SAGA 模式：長事務拆分，按順序執(zhí)行，失敗后反向補償，適合超長事務（如訂單履約）；
5. 2PC 模式：強一致性，性能差，適合低并發(fā)、高一致性場景（如金融對賬）。

4. 緩存穿透、緩存擊穿、緩存雪崩的區(qū)別及解決方案？【必考，銜接 Redis 面試題】

答案要點（精簡版，必背）

1. 緩存穿透：請求不存在的 key，緩存和 DB 都查不到 → 解決方案：緩存空值、布隆過濾器；
2. 緩存擊穿：熱點 key 過期，大量請求打穿到 DB → 解決方案：熱點 key 永不過期、分布式鎖、緩存預熱；
3. 緩存雪崩：大量 key 同時過期 / Redis 宕機 → 解決方案：隨機過期時間、Redis 集群、熔斷降級、本地緩存兜底。

五、項目實戰(zhàn) & 架構設計（壓軸，體現(xiàn)綜合能力，10%）

1. 高并發(fā)系統(tǒng)的優(yōu)化方案？【必考?架構師必問】

答案要點（分維度，必背，萬能答案）

1. 應用層：接口限流（Redis+Lua）、異步處理（@Async/CompletableFuture）、池化技術（線程池 / 連接池）、熔斷降級（Sentinel/Hystrix）；
2. 緩存層：多級緩存（本地 Caffeine+Redis）、緩存預熱、緩存更新策略（先更 DB 再刪緩存）、防止緩存問題；
3. 數(shù)據庫層：讀寫分離、分庫分表、索引優(yōu)化、SQL 優(yōu)化、批量操作、避免大事務；
4. 架構層：微服務拆分、集群部署、負載均衡（Nginx/Ribbon）、高可用（主從 / 哨兵 / 集群）。

2. 如何保證接口的冪等性？【必考?實戰(zhàn)核心】

答案要點（按優(yōu)先級排序，必背）

1. 數(shù)據庫唯一索引：最基礎的方案，插入數(shù)據時用唯一索引，重復插入報錯，適合新增場景；
2. Redis 分布式鎖：請求前加鎖，處理完成釋放鎖，適合更新 / 刪除場景；
3. 冪等令牌：請求前獲取令牌，請求時攜帶令牌，處理完成后銷毀令牌，適合接口調用場景；
4. 樂觀鎖（版本號）：更新時判斷版本號，適合更新場景；
5. 業(yè)務狀態(tài)機：通過業(yè)務狀態(tài)判斷是否已處理，適合訂單 / 支付等有狀態(tài)的業(yè)務。

面試加分小技巧（高級開發(fā)必看）

1. 回答邏輯：所有問題都分點作答，先講定義，再講原理，最后講解決方案 / 適用場景，面試官喜歡思路清晰的候選人；
2. 核心重點：Java 高級開發(fā)的面試核心是 「并發(fā)編程 + JVM + 分布式」，這三個模塊吃透，薪資至少拔高一個檔次；
3. 原理結合實戰(zhàn)：回答問題時，盡量結合項目經驗，比如「我在項目中用線程池解決了 XX 問題」「我通過 JVM 調優(yōu)把 Full GC 次數(shù)從 10 次 / 天降到 0 次」，體現(xiàn)你的實戰(zhàn)能力；
4. 避坑原則：不會的問題不要瞎答，坦誠說「這個點我還在學習中」，比答錯強得多。

到此這篇關于Java高級開發(fā)高頻面試題完整版的文章就介紹到這了,更多相關Java高級開發(fā)高頻面試題內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論