一、Java 核心基礎與進階

1、我們知道 Java 中存在 “值傳遞” 和 “引用傳遞” 的說法，你能結合具體例子，說明 Java 到底是值傳遞還是引用傳遞嗎？這背后涉及到 JVM 中哪些內存區域的交互？

Java中只有值傳遞，不存在引用傳遞。判斷傳遞方式的核心在于：傳遞的是變量的副本，而非變量本身。區別在于副本的內容是基本類型的值還是對象引用的地址。

案例1：傳遞基本類型（int）

public static void main(String[] args) {int a = 10;change(a);System.out.println(a); // 輸出 10，未被修改
}
private static void change(int num) {num = 20; // 操作的是副本 num，與原變量 a 無關
}

在上述案例中，變量a是基本類型，在虛擬機棧的局部變量表中，傳遞時將a的值復制一份給參數num，二者在棧中是獨立的內存空間，修改num不影響a。

案例2：傳遞引用類型

class User {String name;public User(String name) { this.name = name; }
}
public static void main(String[] args) {User user = new User("張三");changeUser(user);System.out.println(user.name); // 輸出 "李四"，被修改replaceUser(user);System.out.println(user.name); // 仍輸出 "李四"，未被替換
}
private static void changeUser(User u) {u.name = "李四"; // 操作副本 u 指向的堆中對象（與原 user 指向同一對象）
}
private static void replaceUser(User u) {u = new User("王五"); // 副本 u 指向新對象，與原 user 無關
}

在上述案例中，先是new了一個user對象，存儲在虛擬機棧的局部變量表，指向堆內存中新建的user對象，調用changeUser方法時，傳遞的是user的副本，即堆中對象的地址，形參u與user指向同一堆對象，因此改變u.name會影響源對象，而調用replaceUser時，形參u被賦值為新對象的地址，但原user的地址未變，因此源對象不受影響。

2、HashMap 是日常開發中最常用的集合之一，你能詳細說說 JDK 1.7 和 JDK 1.8 中 HashMap 的實現差異嗎？比如哈希沖突解決方式、擴容機制、線程安全性問題，以及為什么 JDK 1.8 要將鏈表轉紅黑樹的閾值設為 8？

hashmap的核心是“數組+鏈表/紅黑樹”的哈希表結構，jdk1.8針對性能問題做了大幅優化，具體差異是：

1）底層結構：jdk1.7使用的是數組+鏈表的頭插法，jdk1.8使用的是數組+鏈表+紅黑樹的尾插法

2）哈希沖突解決：jdk1.7僅鏈表，使用的是拉鏈法，jdk1.8是當鏈表長度<=7時用鏈表，>8轉紅黑樹。

3）擴容機制：jdk1.7擴容時重新計算所有元素哈希值，jdk1.8對于每個節點，根據哈希值與原容量的與運算結果，若結果為0，則節點位置不變，若結果不為0，則節點在新數組中的索引=原索引+原容量。

4）線程安全性：jdk1.7并發擴容時會出現“鏈表環”，可能導致死循環，而jdk1.8使用尾插法避免鏈表環，但仍非線程安全。

5）初始容量計算：jdk1.7構造時直接初始化數組，jdk1.8則延遲初始化，首次put時才創建數組。

那為什么鏈表轉紅黑樹的閾值設為8呢？

1）從概率角度上講，hashmap中鏈表長度遵循泊松分布，鏈表長度達到8的概念極低，說明此時哈希沖突已非常嚴重，鏈表查詢效率會急劇下降。

2）從性能權衡的角度上講，紅黑樹的插入和刪除復雜度是O（logN）,但維護紅黑樹的開銷比鏈表大，若閾值設的太小，會頻繁觸發樹化，增加開銷，設的太大則鏈表查詢耗時過長。

3）反向閾值：當鏈表長度因刪除元素縮短至6時，紅黑樹會轉回鏈表，避免因頻繁波動導致反復樹化或鏈化。

3、線程池是并發編程的核心組件，你在項目中是如何配置線程池參數的？請結合具體場景說明你的設計思路，以及如何避免線程池的常見問題？

線程池的核心參數主要包括：核心線程數（corePoolSize），最大線程數（maximumPoolSize）,任務隊列（workQueue），拒絕策略（rejectedExecutionHandle）等。

如何配置參數主要看業務場景，下面舉兩個例子：

1）復雜計算，排序類場景：此場景特點是任務主要消耗CPU資源，線程空閑時間極少，一般配置規則是 核心線程數=CPU核心數+1（這里+1是為了避免CPU空閑，若某個線程因頁缺失等短暫阻塞，可立即有線程補位），最大線程數和核心線程數保持一致，避免創建臨時線程，減少上下文切換導致的開銷。

2）數據庫查詢，RPC調用，文件讀寫等場景：此場景特點是任務大部分時間都在等待IO完成，線程空閑時間長，一般配置規則是 核心線程數=2*CPU核心數，最大線程數可設為核心線程數的2~4倍。

任務隊列的選擇優先使用有界隊列（ArrayBlockingQueue）,避免用無界隊列導致任務無限堆積，最終觸發OOM。

有界隊列（ArrayBlockingQueue）：基于數組實現的有界阻塞隊列，特點是容量固定，創建時必須指定大小，支持公平和非公平的訪問策略，適用于任務數量已知，需要控制隊列大小的場景。

無界隊列（LinkedBlockingQueue）：基于鏈表實現的阻塞隊列，特點是可指定容量，默認容量為Integer的最大值，近似無界，吞吐量通常高于有界隊列，適用于任務數量不確定，需要較大緩存空間的場景。

拒絕策略可從CallerRunsPolicy，DiscardOldestPolicy兩者中選，核心業務，例如訂單支付等可以使用CallerRunsPolicy，避免任務丟失，非核心業務，如日志收集，可使用DiscardOldestPolicy，丟棄最舊的的任務或者自定義策略，禁止使用AbortPolicy（默認，直接拋異常），會導致業務中斷。

AbortPolicy（默認策略）：當任務隊列已滿且線程池中的線程數達到最大線程數時，直接拋出RejectedExecutionException?異常

CallerRunsPolicy（調用者運行策略）：讓提交任務的線程自己執行該任務

DiscardPolicy（丟棄策略）：直接丟棄新提交的任務，不做任何處理也不拋出異常

DiscardOldestPolicy（丟棄最舊任務策略）：丟棄隊列中最舊的任務，再次嘗試提交新任務

如何避免線程泄露？

當任務執行時無限阻塞，導致線程長期被占用，無法回收的情況出現時，可以給任務設置超時時間，并使用有界隊列+監控的方式，當隊列超過閾值則告警，定期檢測空閑線程，設置allowCoreThreadTimeOut為true讓核心線程超時回收。

如何避免隊列積壓？

監控隊列使用率，當超過80%時，自動擴容線程池（動態調整最大線程數）或降級非核心業務。

4、談談你對 Java 內存模型（JMM）的理解？它解決了什么問題？volatile 關鍵字的作用是什么？它能保證原子性嗎？為什么？

JMM是一種抽象的模型，用來屏蔽各種硬件和操作系統的內存訪問差異，java內存模型定義了線程和主內存之間的抽象關系，線程之間的共享變量存在主內存中，每一個線程都有一個私有的本地內存，本地內存存儲了該線程以讀寫共享變量的副本。

JMM主要解決了多線程場景下因CPU緩存，指令重排導致的可見性，原子性，有序性等問題。

可見性：一個線程修改的變量，其他線程能立即看到

有序性：一個操作不可中斷，要么全部執行，要么全部不執行

有序性：程序執行順序與代碼順序一致

JMM通過內存屏障實現上述特性，禁止指令重排序，強制緩存刷新，確保線程間變量交互符合預期。

volatile的作用和局限性

volatile是輕量級同步機制，僅保證可見性和有序性，不保證原子性。

可見性是指當一個共享變量被線程更改，其他線程會立即感知到，這里的原理是因為當一個變量被volatile修飾后，線程獲取時不會從自己的本地內存中取，而是直接去主內存中取，每次修改完后也會及時同步到主內存中。有序性是指，操作被volatile修飾后的變量，不會被重排序。

不保證原子性：

private volatile int i = 0;
// 多線程執行 increment()，最終結果可能小于 10000
public void increment() {i++; // 非原子操作，分“讀 i -> i+1 -> 寫回 i”三步
}

即使i時volatile，多線程同時讀i時，可能都拿到相同的值，各自加1后寫回主內存，最終結果為101，而非102。解決原子性需要用到synchronized?或?AtomicInteger（CAS 機制）。

5、垃圾回收（GC）是 JVM 性能優化的重點，你了解哪些常見的垃圾收集器？在項目中如何判斷當前 GC 策略是否合理？如果出現 Full GC 頻繁，你的排查步驟是什么？

常見的垃圾收集器：

Serial GC（串行收集器）：單線程執行垃圾收集，收集時會暫停所有用戶線程（STW，stop-the-world）,優勢是實現簡單，內存占用小，適合單線程環境或客戶端應用，這個收集器清理效率很高，但是在多核場景下無法有效利用cpu資源。

Parallel GC（并行收集器）：多線程執行垃圾收集，仍會產生STW，但效率比Serial GC高。適合CPU核心數較多的場景，吞吐量優先。

CMS（并發標記清除收集器）：號稱停頓時間最短的收集器，以低延遲為目標，大部分工作與用戶線程并發執行，減少STW時間，核心流程是：初始標記（STW）-> 并發標記 -> 重新標記（STW）-> 并發清除。它的優勢在于STW時間短，適合響應時間敏感的應用。

G1（垃圾優先收集器）：這個收集器是基于標記復制算法的，以一條線程去標記GCRoots可達的對象，此過程很快，需要停頓，然后再啟動一個線程去做可達性分析，這個速度很慢，然后使用多條線程去回收廢棄對象，也需要停頓。適用于大內存應用，對延遲和吞吐量都有要求的服務（如大型分布式系統）。

ZGC：jdk11引入的低延遲收集器，支持TB級別的大堆，STW時間極短，幾乎不影響吞吐量，STW時間和堆大小無關，并支持并發壓縮，無內存碎片，適合超大堆場景。適用于大型分布式系統，需要處理海量數據且堆延遲敏感的應用。

Shenandoah GC：jdk12引入，目標是低延遲，大堆支持，適用場景與ZGC類似。

如何判斷當前 GC 策略是否合理？

1）full GC頻率：生產環境應控制在1次/天，若頻繁觸發，說明內存配置或者對象生命周期有問題

2）GC停頓時間：YGC（年輕代GC）：停頓時間應<100ms，頻率可接受（如1次/分鐘）,full gc停頓時間應<1s ，否則會影響用戶體驗（如接口超時）

3）內存使用率：老年代內存使用率長期 > 80%，容易觸發full gc，年輕代內存不足會導致YGC頻繁

Full GC排查步驟

1）查看GC日志：分析full gc觸發原因

2）分析內存泄漏：是否有大對象長期存活未被回收

3）檢查jvm參數：老年代大小是否合理，元空間是否不足

4）優化對象生命周期：避免創建大量臨時大對象，盡量復用對象，并及時釋放

二、主流框架與中間件

1、Spring 是 Java 生態的基石，你能說說 Spring IoC 容器的初始化流程嗎？Bean 的生命周期中，“初始化前”“初始化后” 有哪些擴展點？你在項目中用過哪些擴展點解決實際問題？

IOC容器的初始化流程：

主要分為bean加載和bean實例化兩個階段，核心步驟：

1）資源定位：通過ResourceLoader加載配置文件，將其轉化為Resource對象

2）bean定義加載和解析：用beanDefinitionReader解析Resource中的bean標簽或注解，將配置信息封裝為BeanDefinition（包含類名，屬性，依賴等）。

3）Bean定義注冊：將BeanDefinition注冊到BeanDefinitionRegistry中

4）Bean實例化：從BeanDefinitionRegistry中獲取BeanDefinition，通過反射創建bean實例

5）bean初始化：依賴注入，通過AutowiredAnnotationBeanPostProcessor完成屬性注入，并執行InitializingBean?接口的afterPropertiesSet()?或自定義?init-method。

6）bean緩存：將初始化完成的bean放入單例池，后續直接從緩存獲取。

bean生命周期的擴展點

1）BeanPostProcessor：bean實例化后，初始化前后調用，可用于aop代理或者字段加解密

2）InitializingBean：bean依賴注入完成后調用，可用于初始化資源，例如創建數據庫連接池或者啟動定時任務等

3）DisposableBean：容器關閉時調用，可用于釋放資源，例如關閉連接池，停止線程池等

4）BeanFactoryPostProcessor：bean定義注冊后，實例化前調用，可用于動態修改bean配置，如根據環境變量調整數據源URL

用?BeanPostProcessor?實現接口日志打印：

@Component
public class LogBeanPostProcessor implements BeanPostProcessor {// Bean 初始化前調用@Overridepublic Object postProcessBeforeInitialization(Object bean, String beanName) {if (bean instanceof OrderService) {System.out.println("OrderService 實例化完成，準備初始化");}return bean;}// Bean 初始化后調用（若有 AOP 代理，此時 bean 已是代理對象）@Overridepublic Object postProcessAfterInitialization(Object bean, String beanName) {if (bean instanceof OrderService) {System.out.println("OrderService 初始化完成，可使用");}return bean;}
}

2、Spring 事務的傳播機制和隔離級別分別有哪些？請舉例說明 “事務傳播機制 PROPAGATION_REQUIRES_NEW” 和 “PROPAGATION_NESTED” 的區別，以及實際項目中如何避免事務失效的問題？

傳播機制：

REQUIRED（默認值）：如果當前存在事務，則加入該事務；如果當前沒有事務，則創建一個新事務

SUPPORTS：如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式執行

MANDATORY：必須在一個已存在的事務中執行，如果當前沒有事務，則拋出異常

REQUIRES_NEW：無論當前是否存在事務，都創建一個新事務，如果當前存在事務，則將當前事務掛起

NOT_SUPPORTED：以非事務的方式執行，如果當前存在事務，則將事務暫停

NEVER：以非事務方式執行；如果當前存在事務，則拋出異常

NESTED：如果當前存在事務，則在嵌套事務中執行，如果當前沒有事務，則創建新事務

REQUIRES_NEW的特點是子事務和父事務完全獨立，子事務回滾和提交不會影響父事務，例如訂單創建作為父事務，調用日志記錄作為子事務，即使日志記錄失敗回滾，訂單創建仍可正常提交。

NESTED的特點是子事務依賴父事務，子事務回滾僅回滾自身，父事務回滾會連帶子事務回滾，例如訂單創建為父事務，包含庫存扣減的子事務，庫存扣減失敗，訂單創建可選擇記錄執行或者回滾，若訂單創建回滾，庫存扣減也會回滾。

隔離級別：

DEFAULT（默認值）：默認值為READ_COMMITTED。

READ_UNCOMMITTED（讀未提交）：允許事務讀取其他事務未提交的數據，可能出現臟讀

READ_COMMITTED（讀已提交）：事務只能讀取其他事務已經提交的數據，可以避免臟讀，但是可能出現不可重復讀

REPEATABLE_READ（可重復讀）：保證同一事務內多次讀取同一數據的結果一致，可以避免臟讀和不可重復讀，但是會出現幻讀

SERIALIZABLE（序列化讀）：最高隔離級別，強制事務串行執行，避免所有并發問題。

如何解決事務失效？

1）非public方法：@Transactional此注解僅對public方法生效，因為spring動態代理默認不攔截非public方法，解決辦法就是將方法改為public，或者自定義AOP攔截非public方法

2）方法自調用：同一個類中，無事務方法調用有事務方法，因未經spring代理，事務不生效

示例：

@Service
public class OrderService {public void createOrder() {// 自調用，無事務doCreate(); }@Transactionalpublic void doCreate() { ... }
}

解決辦法為通過AopContext.currentProxy()獲取代理對象調用方法，或者將上述的doCreate方法拆分到另一服務類

3）異常被捕獲：方法內捕獲異常未拋出，spring無法感知異常，不會觸發回滾。解決方法是捕獲異常后手動拋出RunTimeException，或者通過TransactionStatus.setRollbackOnly()強制回滾

4）錯誤的異常類型：@Transactional?默認僅回滾RunTimeException和Error，不回滾checked異常（如IOException），解決辦法是指定異常類型，例如：@Transactional(rollbackFor = Exception.class)

3、MyBatis 中，#{} 和 ${} 的區別是什么？為什么說 #{} 能防止 SQL 注入？MyBatis 的一級緩存和二級緩存分別是什么？在分布式項目中使用二級緩存需要注意什么問題？

#{}和${}的區別

1）#{}是參數占位符，${}時字符串替換

2）#{}是基于JDBCPreparedStatement的預編譯SQL，${}是基于JDBCStatement，直接替換字符串

3）#{}無風險，參數會被視為“值”，自動加引號，${}有風險，參數會被視為sql片段，由sql注入的風險

4）#{}適用于傳遞參數，${}適用于傳遞sql片段

為什么#{}能夠防止sql注入？

例如執行 select * from user where name = #{name}時，若參數name為“‘張三’ or ‘1’ = ‘1’?”，mybatis會將其預編譯為

select * from user where name = ?

執行時參數被當做字符串值傳入，最終sql為

select * from user where name = '\'張三\' or \'1\'=\'1\''

不會被解析為sql邏輯，因此避免注入。

mybatis緩存機制

一級緩存：作用范圍在用一個SqlSession內，執行相同的SQL，會從緩存中獲取結果，避免重復查詢數據庫，當SqlSession關閉，或者執行insert、update，delete會清空一級緩存

二級緩存：作用范圍是同一個SqlSessionFactory下的所有SqlSession，按照Mapper接口隔離，不同Mapper的緩存互不干擾；可通過全局配置?mybatis.configuration.cache-enabled=true（默認開啟），或者在Mapper接口添加@CacheNamespace注解，使用二級緩存需要注意的是在分布式場景下，二級緩存的對象需要實現Serializable?序列化接口，因為緩存會將對象序列化到磁盤或內存，其次是一致性問題，多個服務節點的二級緩存獨立，某個節點修改數據后，其他節點緩存未更新，導致數據不一致。所以分布式場景下不建議使用二級緩存，改用Redis分布式緩存，如果必須使用，需要通過mq發消息通知其他節點清空緩存

4、分布式系統中經常用到消息隊列，你在項目中為什么選擇某款消息隊列？如何保證消息的 可靠性 和 不重復消費？如果消息隊列出現消息堆積，你的處理方案是什么？

可靠性保證

從生產端，Broker端，消費者端分別分析：

生產端：開啟消息確認，消息到達Broker后返回一條確認消息；失敗重試，設置對應的重試次數，避免網絡抖動導致的臨時失敗；本地消息表，核心業務用本地事務表+消息表雙寫，確保業務與消息發送原子性

Broker端：同步刷盤，消息寫入后立即刷盤，避免Broker宕機導致內存中消息丟失；主從復制，開啟Broker主從架構，主節點宕機后從節點接管，避免單點故障

消費者端：手動確認，關閉自動確認，確保消息消費完成后再確認，避免消費失敗導致消息丟失

不重復消費保證

消息重復的原因可能有：生產者重試，Broker重試，消費者確認超時等，解決核心是“業務層面去重”

方案一：唯一消息ID+冪等表

生產者發送消息時，生成全局唯一ID放入消息頭，消費者消費前，先查詢數據庫冪等表，如果已存在則跳過消費。如果不存在，消費后插入冪等表。

方案二：業務唯一鍵

利用業務自身的唯一鍵去重，例如訂單ID，消費時先查詢訂單是否已存在，存在則不處理

消息堆積處理

消息堆積的核心原因可能是 消費速度 < 生產速度，解決思路分緊急處理和長期優化

緊急處理：擴容消費者，增加消費者實例數；或者創建臨時消費隊列，創建臨時主題，將堆積消息分流到臨時主題，用多個消費者組并行消費

長期優化：可簡化消費流程，異步處理非核心步驟；或者調整Broker配置，增大Broker消息存儲上限，避免因磁盤滿導致消息丟棄；優化Broker刷盤策略。

5、分布式緩存Redis是提升系統性能的關鍵，你在項目中用 Redis 做過哪些場景？如何解決 Redis 的 “緩存穿透、緩存擊穿、緩存雪崩” 問題？Redis 集群的架構原理是什么？

Redis核心應用場景

緩存：可以緩存熱點數據，降低數據庫壓力，提升接口QPS

分布式鎖：用SET key value NX EX 10命令實現分布式鎖，解決并發搶單，庫存超賣問題

計數器：用INCR命令實現點贊數，閱讀量統計

限流器：用Redis+Lua腳本實現接口限流，防止惡意請求擊垮服務

消息隊列：用List結構的Lpush實現簡單的消息隊列

緩存的三大問題

緩存穿透：查詢不存在的數據（如ID = -1），緩存和數據庫都不命中，請求直達數據，解決方案是布隆過濾器或者空值緩存

緩存擊穿：熱點key過期瞬間，大量請求直達數據庫，可使用互斥鎖，查詢數據庫時枷鎖，只讓一個線程更新緩存，其他線程等待；熱點key永不過期

緩存雪崩：大量key同時過期，或Redis集群宕機，請求全部到數據庫，可使用過期時間加隨機值，redis集群，或者服務降級等方案

Redis集群架構

主從架構：由1個主節點+N個從節點組成，主節點負責寫操作，從節點負責讀操作，從節點通過復制同步主節點數據，實現數據備份，缺點是主節點宕機后，需手動切換從節點為主節點，無法自動故障轉移

哨兵架構：由主從架構+哨兵節點（通常3個）組成，可以監控主從節點狀態，當主節點宕機時，自動選舉從節點升級為主節點，并通知客戶端新的主節點地址，缺點是無法解決數據分片問題，單主節點內存受限

Cluster集群架構：由多個主從節點組成，主節點之間通過Gossip協議通信，支持數據分片及故障轉移，適用于海量數據，高并發讀寫的分布式場景