阿里內部面試高頻題深度解析：並發、鎖、集合、JVM、Spring、MySQL 全景覆蓋

阿里內部面試實戰題庫深度解析

本文整理自阿里內部面試真題，涵蓋 Java 並發編程、鎖機制、集合框架、JVM 底層、Spring AOP、數據庫優化、事務隔離、Spring 組件掃描等 12 大高頻考點。每題附帶核心知識點、源碼級分析與實戰最佳實踐，助你在大廠面試中脫穎而出。

一、StringBuffer vs StringBuilder：多線程環境下的選擇邏輯

面試題

方法內部頻繁 append，方法返回 toString()，多線程並發訪問，選 StringBuffer 還是 StringBuilder？

標準答案

選 StringBuffer。原因：StringBuffer 所有公共方法均以 synchronized 修飾，線程安全；StringBuilder 無鎖，效率高但非線程安全。多線程共享同一實例時，必須保證原子性，否則會出現內容錯亂、索引越界等問題。

源碼證據

// StringBuffer
public synchronized StringBuffer append(String str) { ... }

// StringBuilder
public StringBuilder append(String str) { ... } // 無 synchronized

進階補充

• 若變數為方法局部變數（線程封閉），優先用 StringBuilder，無鎖開銷，效能最優。
• JDK 9+ 引入 StringConcatFactory，+ 拼接底層已優化為 invokedynamic，單線程場景下 StringBuilder 甚至非必需。

二、synchronized 全方位使用姿勢

核心作用

Java 關鍵字，隱式監視器鎖，可重入。修飾方法/代碼塊時，保證同一時刻僅有一線程執行該臨界區。

四種鎖定目標與代碼模板

實戰輸出分析

文章附帶三組完整運行結果，驗證了：synchronized(this) 僅阻塞同一實例的並發；不同實例互不干擾；靜態方法鎖住 Class，跨實例也互斥。

三、ReentrantLock 核心 API 與特性對比

常用方法

• lock()：阻塞獲取鎖，可被中斷 (lockInterruptibly())
• tryLock() / tryLock(timeout, unit)：非阻塞/限時嘗試獲取，避免死等
• unlock()：釋放鎖，必須在 finally 中調用
• newCondition()：支持多條件變量，精準喚醒

vs synchronized

ReentrantLock 提供「可中斷、超時獲取、公平鎖選項、多 Condition」等高級特性，適用於複雜併發控制場景；synchronized 語法簡潔、JVM 原生優化 (偏向鎖/輕量級鎖/重量級鎖升級)、無需手動 unlock，適用於簡單同步。

四、分佈式集群同步方案選型

主流方案對比

Redis 鎖關鍵偽代碼 (Redisson 風格)

// 加鎖
String lockKey = "lock:order:" + orderId;
boolean success = redisTemplate.opsForValue()
    .setIfAbsent(lockKey, threadId, 30, TimeUnit.SECONDS);
if (!success) return false;

// 續期看門狗 (另一線程)
while (holdLock) {
    redisTemplate.expire(lockKey, 30, TimeUnit.SECONDS);
    Thread.sleep(10_000);
}

// 釋放鎖 (Lua 保證原子性)
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
redisTemplate.execute(new DefaultRedisScript<>(script, Long.class), Collections.singletonList(lockKey), threadId);

五、樂觀鎖設計要點與實踐

核心思想

「先嘗試更新，失敗再重試」，不加鎖，通過版本號或 CAS 比對實現無鎖併發控制。

兩種實現方式

1. 版本號機制：表加 version INT DEFAULT 0，更新時 UPDATE t SET val=?, version=version+1 WHERE id=? AND version=?，影響行數=0 表示衝突。
2. CAS (Compare-And-Swap)：AtomicInteger、LongAdder、數據庫 WHERE col = expected。

適用場景與避坑

• 讀多寫少、衝突概率低、業務允許重試 (庫存扣減、餘額變更)。
• ABA 問題：引入 AtomicStampedReference 或版本號雙重校驗。
• 長事務中慎用，避免大量重試導致餓死。

六、冪等性控制：設計與落地

定義

同一請求重複執行多次，對系統狀態的影響與執行一次相同。

常見業務場景

• 支付回調重複通知、用戶重複點擊下單、MQ 消息重複消費、網關重試。

四層冪等方案

IDCM 專案實戰經驗

採用「前置 Token + 數據庫唯一索引 + 狀態機」三層防線：下單前調用 /token/apply 獲取 UUID 存 Redis (5min TTL)；下單攜帶 Token，Service 層 DELETE FROM token WHERE token=? AND user_id=? 成功才執行業務；訂單表 UNIQUE KEY uk_biz_no (biz_no) 兜底。

七、Spring AOP 關鍵技術棧

• 動態代理：JDK 動態代理 (基於接口) / CGLIB (繼承目標類)，運行時生成代理類字節碼。
• 切點表達式：AspectJ Pointcut Expression (execution(), @annotation() 等) 精準匹配連接點。
• 通知類型：Before/After/AfterReturning/AfterThrowing/Around，環繞通知最強大可控制目標方法執行。
• 織入時機：運行時織入 (Spring 默認)、加載時織入 (LTW)、編譯時織入 (AspectJ 編譯器)。
• 核心類：ProxyFactory, AdvisedSupport, MethodInterceptor, InvocationHandler (JDK)。

八、HashMap vs ConcurrentHashMap 深度對比

九、java.util.concurrent 常用組件清單

十、大表查詢優化方案與索引設計原則

優化方案層級

1. 架構層：分庫分表、讀寫分離、冷熱數據分離、緩存 (Redis) 前置。
2. SQL 層：避免 SELECT *、優化 JOIN 順序、使用 EXPLAIN 分析執行計劃、覆蓋索引、延遲關聯。
3. 索引層：最左前綴原則、區分度高的列優先、避免在索引列上做函數運算、聯合索引代替單列索引、覆蓋索引減少回表。
4. 配置層：innodb_buffer_pool_size 設為物理內存 60-70%、調整 innodb_flush_log_at_trx_commit 平衡性能與持久化。

索引設計黃金法則

• WHERE/JOIN/ORDER BY/GROUP BY 涉及的列建立索引。
• 聯合索引遵循「等值在前、範圍在後、排序最後」。
• 單表索引數 ≤ 5，單索引列數 ≤ 5。
• 定期 ANALYZE TABLE 更新統計信息，OPTIMIZE TABLE 整理碎片。

十一、數據庫事務隔離級別與實戰選型

IDCM 專案實踐：核心交易採用 REPEATABLE READ + 顯式鎖 (SELECT ... FOR UPDATE) 保證一致性；報表查詢開啟 READ COMMITTED 避免間隙鎖影響並發；長事務拆分為短事務 + 補償機制 (TCC/Saga)。

十二、Spring 組件掃描注解區別與配置

component-scan 進階配置

<context:component-scan base-package="com.idcm">
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Service"/>
    <context:exclude-filter type="regex" expression="com\.idcm\.test\..*"/>
</context:component-scan>

IDCM 專案採用「基包掃描 + 註解過濾 + 排除測試包」策略，啟動速度提升 30%。

總結

這 12 道題貫穿了 Java 後端開發的核心技術棧。面試時，「原理清晰、源碼可追、場景落地、優缺點對比」是拿到高評價的關鍵。建議針對薄弱環節專項突擊，結合項目實戰經驗構建自己的答案庫。