核心考點拆解)
西安華為研究所面試避坑 3 個手寫實現(xiàn)核心考點拆解
報錯堆滿屏幕，StackTrace 長得像天書，面試官盯著你問底層邏輯？別慌。在西安華為研究所的面試實戰(zhàn)中，光背八股文根本過不了關。很多候選人卡在手寫實現(xiàn)環(huán)節(jié)，明明代碼跑通了，卻因為性能或邊界條件被 Pass。這篇文章不玩虛的，直接拆解三個高頻考點：進程同步、內存池管理、以及分布式鎖。這些不是書本上的理論，而是我們在項目里天天用的“保命”代碼。
如果你正在準備去西安或者已經在西安求職，這篇干貨能讓你在二面甚至終面時，從“聽題”變成“解題”。
考點梳理：華為到底在考什么？
很多人以為西安所主要考 Java 基礎，那是誤會。西安華為研究所（主要承擔終端、軟件平臺等研發(fā)）對代碼質量的要求極高。這里的面試風格非常直接：給場景，寫代碼，找 Bug，談優(yōu)化。
根據(jù)往年通過者的反饋，高頻考點集中在以下三個維度：并發(fā)與同步：這是重災區(qū)。不僅僅是 synchronized 和 Lock 的區(qū)別，而是要求在具體場景下（如生產者-消費者、死鎖預防）進行手寫實現(xiàn)。
數(shù)據(jù)結構與算法落地：不是 LeetCode 那種純算法題，而是將算法應用到工程問題中。比如手寫一個 LRU Cache，或者實現(xiàn)一個簡單的內存池。
分布式系統(tǒng)基礎：隨著業(yè)務上云，對分布式鎖、一致性 Hash、Raft 協(xié)議的理解成為標配。尤其是分布式鎖，要求能手寫實現(xiàn)基于 Redis 或 Zookeeper 的簡易版本。核心痛點：大部分候選人能把概念說清楚，但一讓你寫代碼，就卡在細節(jié)上。比如 volatile 的內存屏障、ThreadLocal 的內存泄漏風險、Redis 鎖的 Lua 腳本原子性。這些細節(jié)，才是區(qū)分“會背”和“會用”的關鍵。
標準答法：如何結構化表達你的思路？
在面試中，不要上來就敲鍵盤。華為的面試官很看重思維過程。建議采用“分析-設計-編碼-反思”的四步法。
第一步：明確需求與邊界。
在動手前，先和面試官確認：線程安全嗎？性能要求高嗎？數(shù)據(jù)量多大？如果是實現(xiàn) LRU，問清楚是單線程還是多線程環(huán)境。這一步能體現(xiàn)你的工程素養(yǎng)，避免寫出一坨“能跑但沒法用”的代碼。
第二步：給出核心數(shù)據(jù)結構。
用自然語言或偽代碼描述你打算用什么數(shù)據(jù)結構。比如實現(xiàn) LRU，就說“我會用 HashMap 配合雙向鏈表，保證 O(1) 的讀寫時間復雜度”。
第三步：手寫核心代碼。
這是得分點。代碼風格要干凈，變量命名要有意義。不要為了炫技寫復雜的泛型，清晰最重要。
第四步：主動指出不足與優(yōu)化方向。
寫完代碼后，主動說：“這個實現(xiàn)是單線程安全的，如果需要多線程，我可以用 ConcurrentHashMap 加鎖，或者使用 synchronized 塊。另外，如果數(shù)據(jù)量特別大，可以考慮分段鎖?！?這種自我反思，在面試官眼里非常加分。
注意：在描述分布式鎖時，一定要提到原子性。比如用 Redis 實現(xiàn)鎖，不能只說 set 和 del，必須強調 SET key value NX EX timeout 的原子性，或者使用 Lua 腳本。這是很多候選人容易忽略的坑，也是西安所面試官最愛追問的點。
代碼實現(xiàn)：三個高頻場景的手寫詳解
下面給出三個核心場景的代碼實現(xiàn)。這些代碼并非完美生產級代碼，但涵蓋了面試中必須展示的核心邏輯和關鍵細節(jié)。
1. 手寫線程安全的 LRU Cache
LRU（Least Recently Used，最近最少使用）是緩存系統(tǒng)的基礎。華為喜歡考這個，因為它考察你對數(shù)據(jù)結構組合運用的能力。
import java.util.HashMap;
import java.util.Map;/*** 雙向鏈表節(jié)點*/
class DLinkedNode {int key;int value;DLinkedNode prev;DLinkedNode next;public DLinkedNode() {}public DLinkedNode(int key, int value) {this.key = key;this.value = value;}
}/*** 線程安全的 LRU Cache* 注意：實際生產中，建議將 get 和 put 方法加鎖，* 或者使用 ReentrantReadWriteLock 提高并發(fā)性能。*/
class LRUCache {private int capacity;private MapInteger, DLinkedNode cache = new HashMap();// 使用偽頭結點和偽尾節(jié)點，簡化邊界判斷private final DLinkedNode head = new DLinkedNode();private final DLinkedNode tail = new DLinkedNode();public LRUCache(int capacity) {this.capacity = capacity;head.next = tail;tail.prev = head;}public synchronized int get(int key) {DLinkedNode node = cache.get(key);if (node == null) {return -1;}// 將訪問過的節(jié)點移動到鏈表頭部moveToHead(node);return node.value;}public synchronized void put(int key, int value) {DLinkedNode node = cache.get(key);if (node == null) {// 如果不存在，創(chuàng)建新節(jié)點DLinkedNode newNode = new DLinkedNode(key, value);cache.put(key, newNode);addAtHead(newNode);// 如果容量超過限制，刪除尾部節(jié)點if (cache.size() capacity) {DLinkedNode tailNode = removeTail();cache.remove(tailNode.key);}} else {// 如果存在，更新值并移動到頭部node.value = value;moveToHead(node);}}// 輔助方法：將節(jié)點移動到頭部private void moveToHead(DLinkedNode node) {remove(node);addAtHead(node);}// 輔助方法：在頭部添加節(jié)點private void addAtHead(DLinkedNode node) {node.prev = head;node.next = head.next;head.next.prev = node;head.next = node;}// 輔助方法：刪除節(jié)點private void remove(DLinkedNode node) {node.prev.next = node.next;node.next.prev = node.prev;}// 輔助方法：刪除尾部節(jié)點private DLinkedNode removeTail() {DLinkedNode res = tail.prev;remove(res);return res;}
}逐行講解關鍵點：偽頭尾節(jié)點：這是鏈表操作的經典技巧，避免了處理 head 為空或 tail 為空的邊界情況，代碼更簡潔。
synchronized：為了演示線程安全，這里加了 synchronized。在面試中，你要主動指出：synchronized 粒度太粗，會影響性能。更好的方案是使用 ReentrantReadWriteLock，get 方法用讀鎖，put 方法用寫鎖。
Key 的存儲：在 DLinkedNode 中存儲 key 是為了在刪除尾部節(jié)點時，能夠同步從 HashMap 中移除對應的 key。這是很多新手容易漏掉的細節(jié)。2. 手寫基于 Redis 的分布式鎖（含 Lua 腳本）
分布式鎖是微服務架構中的核心組件。西安所的項目大量使用 Redis，因此對分布式鎖的要求非常嚴格，尤其是原子性和防誤刪。
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.params.SetParams;
import java.util.Collections;
import java.util.UUID;public class RedisDistributedLock {private final JedisPool jedisPool;private final String lockKey;private final String threadId = UUID.randomUUID().toString();private static final int EXPIRE_TIME = 30; // 30秒過期public RedisDistributedLock(JedisPool jedisPool, String lockKey) {this.jedisPool = jedisPool;this.lockKey = lockKey;}/*** 嘗試獲取鎖* @return true 表示獲取成功*/public boolean tryLock() {try (Jedis jedis = jedisPool.getResource()) {// 使用 SET key value NX EX timeout 命令// NX: 不存在才設置// EX: 設置過期時間，防止死鎖// 這是一條原子命令，確保了加鎖的原子性String result = jedis.set(lockKey, threadId, SetParams.setParams().nx().ex(EXPIRE_TIME));return OK.equals(result);}}/*** 釋放鎖* 注意：必須使用 Lua 腳本，確保判斷和刪除的原子性*/public void unlock() {String script = if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end;try (Jedis jedis = jedisPool.getResource()) {// 執(zhí)行 Lua 腳本Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(threadId));// 可以記錄日志，檢查是否成功刪除}}
}逐行講解關鍵點：SetParams：這是 Redis Java 客戶端（如 Jedis 或 Lettuce）提供的 API。使用 set 命令配合 NX 和 EX 參數(shù)，是實現(xiàn)分布式鎖的標準姿勢。千萬不要分開寫 set 和 expire，那樣在兩次操作之間進程掛掉，就會導致死鎖。
Lua 腳本：釋放鎖時，必須檢查 value 是否等于當前線程的 threadId。如果不檢查，可能會出現(xiàn) A 線程的鎖過期了，B 線程加上了鎖，然后 A 線程執(zhí)行完刪除操作，把 B 線程的鎖給刪了。Lua 腳本在 Redis 中是原子執(zhí)行的，完美解決了這個問題。
threadId：每個線程生成一個唯一的 ID，作為鎖的 value。這是防止誤刪的關鍵。3. 手寫一個簡單的內存池（避免頻繁 GC）
在高并發(fā)場景下，頻繁的 new 對象會導致 Young GC 頻繁發(fā)生，影響吞吐量。內存池（Object Pool）是解決這個問題的經典手段。
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;/*** 簡單的對象池* @param T 對象類型*/
public class ObjectPoolT {private final int capacity;private final BlockingQueueT pool;private final ObjectFactoryT factory;public interface ObjectFactoryT {T create();void destroy(T obj);}public ObjectPool(int capacity, ObjectFactoryT factory) {this.capacity = capacity;this.factory = factory;this.pool = new LinkedBlockingQueue(capacity);// 預熱：初始化時創(chuàng)建部分對象for (int i = 0; i capacity / 2; i++) {pool.offer(factory.create());}}/*** 從池中獲取對象* @param timeout 超時時間* @param unit 時間單位* @return 對象實例* @throws InterruptedException 如果等待被中斷*/public T borrow(long timeout, TimeUnit unit) throws InterruptedException {T obj = pool.poll(timeout, unit);if (obj == null) {// 如果池空且超時，可以新建一個，或者拋出異常// 這里為了演示簡單，直接新建obj = factory.create();}return obj;}/*** 歸還對象* @param obj 要歸還的對象*/public void offer(T obj) {if (obj == null) {throw new IllegalArgumentException(Object cannot be null);}// 重置對象狀態(tài)（可選，取決于業(yè)務）// factory.reset(obj); pool.offer(obj);}
}逐行講解關鍵點：BlockingQueue：使用 LinkedBlockingQueue 作為底層容器，它天生就是線程安全的，且支持阻塞操作。當池空時，borrow 方法會阻塞直到有對象歸還或超時，這天然實現(xiàn)了背壓（Backpressure）。
ObjectFactory：使用工廠模式解耦對象創(chuàng)建邏輯。不同的對象類型（如 ByteBuffer、Socket）有不同的創(chuàng)建和銷毀邏輯，通過接口注入，提高了代碼的復用性。
預熱：在構造函數(shù)中預創(chuàng)建一半的對象，可以避免冷啟動時的性能抖動。追問與延伸：面試官最愛挖的坑
當你寫完上述代碼后，面試官不會就此罷休。以下是西安所面試中常見的追問，提前準備能讓你從容應對。
Q1: 如果 LRU Cache 的容量非常大（比如百萬級），HashMap 會出現(xiàn)什么問題？如何優(yōu)化？
A: HashMap 在并發(fā)環(huán)境下可能出現(xiàn)擴容鎖競爭，或者如果 Key 分布不均，可能導致鏈表過長，查詢退化為 O(N)。優(yōu)化方案：使用 ConcurrentHashMap 替代 HashMap，利用其分段鎖（JDK8 是 CAS + synchronized）提高并發(fā)性能。
如果 Key 分布不均，可以考慮使用一致性 Hash 或者布隆過濾器預過濾。
對于極端場景，可以分片，每個分片維護一個 LRU，最后合并。Q2: 分布式鎖中，如果 Redis 主從切換，導致鎖丟失怎么辦？
A: 這是經典的 CAP 問題。主從復制是異步的，如果主節(jié)點寫入鎖后立刻宕機，從節(jié)點升主時可能沒有這條鎖數(shù)據(jù)，導致兩個客戶端同時持有鎖。
解決方案：RedLock 算法：在多個獨立的 Redis 節(jié)點上加鎖，只要超過半數(shù)節(jié)點加鎖成功，就認為加鎖成功。這提高了可用性，但不能完全解決一致性問題。
Zookeeper：使用 Zookeeper 的臨時順序節(jié)點實現(xiàn)分布式鎖。ZK 基于 ZAB 協(xié)議，保證了強一致性。雖然性能比 Redis 低，但更安全。
業(yè)務兜底：在業(yè)務層做冪等性設計。即使鎖失效，業(yè)務邏輯也能保證數(shù)據(jù)最終一致。Q3: 內存池中的對象，如何確保歸還時的狀態(tài)是干凈的？
A: 這是一個非常實際的問題。如果對象在借用期間被修改了狀態(tài)，直接歸還會導致下一個使用者拿到臟數(shù)據(jù)。
解決方案：Reset 方法：在 ObjectFactory 接口中增加 reset 方法，歸還時調用，重置對象狀態(tài)。
封裝：不要直接暴露對象，而是包裝一層，使用者通過包裝類的方法操作，歸還時自動重置。
不可變對象：如果可能，盡量使用不可變對象，或者每次借用后創(chuàng)建新的包裝實例。記憶口訣：把考點刻在腦子里
為了在緊張面試中快速回憶，我總結了以下口訣：
LRU 考點：哈希鏈表雙向走，偽頭偽尾少煩憂。
訪問移到最前方，滿額刪尾再移除。
并發(fā)讀寫鎖要加，Key 存節(jié)點別漏抓。分布式鎖考點：設置原子 NX EX，過期時間防死結。
刪除必須 Lua 驗，ID 比對防誤刪。
主從切換有隱患，ZK 強一致更穩(wěn)。內存池考點：阻塞隊列做容器，工廠模式造對象。
預熱啟動避抖動，歸還重置保干凈。
超時新建或拋錯，背壓機制控流量。西安所面試特別提示：
西安華為研究所的面試官非常務實。他們不關心你用了多炫酷的技術，只關心你的代碼是否安全、是否高效、是否可維護。在手寫實現(xiàn)環(huán)節(jié)，務必注重邊界條件處理、異常處理和日志記錄。哪怕代碼簡單，只要邏輯嚴密、注釋清晰、能主動指出優(yōu)化方向，就能拿高分。
此外，西安所的項目涉及大量硬件交互和高并發(fā)場景，對底層原理的考察會比互聯(lián)網(wǎng)大廠更深。比如 JVM 內存模型、網(wǎng)絡 IO 模型（BIO/NIO/AIO）、操作系統(tǒng)進程調度等。這些基礎不牢，手寫實現(xiàn)的代碼再漂亮，也難以通過終面。
你在項目里踩過這個坑嗎？比如 LRU 在高并發(fā)下的鎖競爭，或者分布式鎖的誤刪問題？評論區(qū)聊聊，咱們一起復盤，避坑指南越寫越全。 西安華為研究所面試避坑 3 個手寫實現(xiàn)核心考點拆解
西安華為研究所面試避坑 3 個手寫實現(xiàn)核心考點拆解
報錯堆滿屏幕，StackTrace 長得像天書，面試官盯著你問底層邏輯？別慌。在西安華為研究所的面試實戰(zhàn)中，光背八股文根本過不了關。很多候選人卡在手寫實現(xiàn)環(huán)節(jié)，明明代碼跑通了，卻因為性能或邊界條件被 Pass。這篇文章不玩虛的，直接拆解三個高頻考點：進程同步、內存池管理、以及分布式鎖。這些不是書本上的理論，而是我們在項目里天天用的“保命”代碼。
如果你正在準備去西安或者已經在西安求職，這篇干貨能讓你在二面甚至終面時，從“聽題”變成“解題”。
考點梳理：華為到底在考什么？
很多人以為西安所主要考 Java 基礎，那是誤會。西安華為研究所（主要承擔終端、軟件平臺等研發(fā)）對代碼質量的要求極高。這里的面試風格非常直接：給場景，寫代碼，找 Bug，談優(yōu)化。
根據(jù)往年通過者的反饋，高頻考點集中在以下三個維度：并發(fā)與同步：這是重災區(qū)。不僅僅是 synchronized 和 Lock 的區(qū)別，而是要求在具體場景下（如生產者-消費者、死鎖預防）進行手寫實現(xiàn)。
數(shù)據(jù)結構與算法落地：不是 LeetCode 那種純算法題，而是將算法應用到工程問題中。比如手寫一個 LRU Cache，或者實現(xiàn)一個簡單的內存池。
分布式系統(tǒng)基礎：隨著業(yè)務上云，對分布式鎖、一致性 Hash、Raft 協(xié)議的理解成為標配。尤其是分布式鎖，要求能手寫實現(xiàn)基于 Redis 或 Zookeeper 的簡易版本。核心痛點：大部分候選人能把概念說清楚，但一讓你寫代碼，就卡在細節(jié)上。比如 volatile 的內存屏障、ThreadLocal 的內存泄漏風險、Redis 鎖的 Lua 腳本原子性。這些細節(jié)，才是區(qū)分“會背”和“會用”的關鍵。
標準答法：如何結構化表達你的思路？
在面試中，不要上來就敲鍵盤。華為的面試官很看重思維過程。建議采用“分析-設計-編碼-反思”的四步法。
第一步：明確需求與邊界。
在動手前，先和面試官確認：線程安全嗎？性能要求高嗎？數(shù)據(jù)量多大？如果是實現(xiàn) LRU，問清楚是單線程還是多線程環(huán)境。這一步能體現(xiàn)你的工程素養(yǎng)，避免寫出一坨“能跑但沒法用”的代碼。
第二步：給出核心數(shù)據(jù)結構。
用自然語言或偽代碼描述你打算用什么數(shù)據(jù)結構。比如實現(xiàn) LRU，就說“我會用 HashMap 配合雙向鏈表，保證 O(1) 的讀寫時間復雜度”。
第三步：手寫核心代碼。
這是得分點。代碼風格要干凈，變量命名要有意義。不要為了炫技寫復雜的泛型，清晰最重要。
第四步：主動指出不足與優(yōu)化方向。
寫完代碼后，主動說：“這個實現(xiàn)是單線程安全的，如果需要多線程，我可以用 ConcurrentHashMap 加鎖，或者使用 synchronized 塊。另外，如果數(shù)據(jù)量特別大，可以考慮分段鎖?！?這種自我反思，在面試官眼里非常加分。
注意：在描述分布式鎖時，一定要提到原子性。比如用 Redis 實現(xiàn)鎖，不能只說 set 和 del，必須強調 SET key value NX EX timeout 的原子性，或者使用 Lua 腳本。這是很多候選人容易忽略的坑，也是西安所面試官最愛追問的點。
代碼實現(xiàn)：三個高頻場景的手寫詳解
下面給出三個核心場景的代碼實現(xiàn)。這些代碼并非完美生產級代碼，但涵蓋了面試中必須展示的核心邏輯和關鍵細節(jié)。
1. 手寫線程安全的 LRU Cache
LRU（Least Recently Used，最近最少使用）是緩存系統(tǒng)的基礎。華為喜歡考這個，因為它考察你對數(shù)據(jù)結構組合運用的能力。
import java.util.HashMap;
import java.util.Map;/*** 雙向鏈表節(jié)點*/
class DLinkedNode {int key;int value;DLinkedNode prev;DLinkedNode next;public DLinkedNode() {}public DLinkedNode(int key, int value) {this.key = key;this.value = value;}
}/*** 線程安全的 LRU Cache* 注意：實際生產中，建議將 get 和 put 方法加鎖，* 或者使用 ReentrantReadWriteLock 提高并發(fā)性能。*/
class LRUCache {private int capacity;private MapInteger, DLinkedNode cache = new HashMap();// 使用偽頭結點和偽尾節(jié)點，簡化邊界判斷private final DLinkedNode head = new DLinkedNode();private final DLinkedNode tail = new DLinkedNode();public LRUCache(int capacity) {this.capacity = capacity;head.next = tail;tail.prev = head;}public synchronized int get(int key) {DLinkedNode node = cache.get(key);if (node == null) {return -1;}// 將訪問過的節(jié)點移動到鏈表頭部moveToHead(node);return node.value;}public synchronized void put(int key, int value) {DLinkedNode node = cache.get(key);if (node == null) {// 如果不存在，創(chuàng)建新節(jié)點DLinkedNode newNode = new DLinkedNode(key, value);cache.put(key, newNode);addAtHead(newNode);// 如果容量超過限制，刪除尾部節(jié)點if (cache.size() capacity) {DLinkedNode tailNode = removeTail();cache.remove(tailNode.key);}} else {// 如果存在，更新值并移動到頭部node.value = value;moveToHead(node);}}// 輔助方法：將節(jié)點移動到頭部private void moveToHead(DLinkedNode node) {remove(node);addAtHead(node);}// 輔助方法：在頭部添加節(jié)點private void addAtHead(DLinkedNode node) {node.prev = head;node.next = head.next;head.next.prev = node;head.next = node;}// 輔助方法：刪除節(jié)點private void remove(DLinkedNode node) {node.prev.next = node.next;node.next.prev = node.prev;}// 輔助方法：刪除尾部節(jié)點private DLinkedNode removeTail() {DLinkedNode res = tail.prev;remove(res);return res;}
}逐行講解關鍵點：偽頭尾節(jié)點：這是鏈表操作的經典技巧，避免了處理 head 為空或 tail 為空的邊界情況，代碼更簡潔。
synchronized：為了演示線程安全，這里加了 synchronized。在面試中，你要主動指出：synchronized 粒度太粗，會影響性能。更好的方案是使用 ReentrantReadWriteLock，get 方法用讀鎖，put 方法用寫鎖。
Key 的存儲：在 DLinkedNode 中存儲 key 是為了在刪除尾部節(jié)點時，能夠同步從 HashMap 中移除對應的 key。這是很多新手容易漏掉的細節(jié)。2. 手寫基于 Redis 的分布式鎖（含 Lua 腳本）
分布式鎖是微服務架構中的核心組件。西安所的項目大量使用 Redis，因此對分布式鎖的要求非常嚴格，尤其是原子性和防誤刪。
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.params.SetParams;
import java.util.Collections;
import java.util.UUID;public class RedisDistributedLock {private final JedisPool jedisPool;private final String lockKey;private final String threadId = UUID.randomUUID().toString();private static final int EXPIRE_TIME = 30; // 30秒過期public RedisDistributedLock(JedisPool jedisPool, String lockKey) {this.jedisPool = jedisPool;this.lockKey = lockKey;}/*** 嘗試獲取鎖* @return true 表示獲取成功*/public boolean tryLock() {try (Jedis jedis = jedisPool.getResource()) {// 使用 SET key value NX EX timeout 命令// NX: 不存在才設置// EX: 設置過期時間，防止死鎖// 這是一條原子命令，確保了加鎖的原子性String result = jedis.set(lockKey, threadId, SetParams.setParams().nx().ex(EXPIRE_TIME));return OK.equals(result);}}/*** 釋放鎖* 注意：必須使用 Lua 腳本，確保判斷和刪除的原子性*/public void unlock() {String script = if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end;try (Jedis jedis = jedisPool.getResource()) {// 執(zhí)行 Lua 腳本Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(threadId));// 可以記錄日志，檢查是否成功刪除}}
}逐行講解關鍵點：SetParams：這是 Redis Java 客戶端（如 Jedis 或 Lettuce）提供的 API。使用 set 命令配合 NX 和 EX 參數(shù)，是實現(xiàn)分布式鎖的標準姿勢。千萬不要分開寫 set 和 expire，那樣在兩次操作之間進程掛掉，就會導致死鎖。
Lua 腳本：釋放鎖時，必須檢查 value 是否等于當前線程的 threadId。如果不檢查，可能會出現(xiàn) A 線程的鎖過期了，B 線程加上了鎖，然后 A 線程執(zhí)行完刪除操作，把 B 線程的鎖給刪了。Lua 腳本在 Redis 中是原子執(zhí)行的，完美解決了這個問題。
threadId：每個線程生成一個唯一的 ID，作為鎖的 value。這是防止誤刪的關鍵。3. 手寫一個簡單的內存池（避免頻繁 GC）
在高并發(fā)場景下，頻繁的 new 對象會導致 Young GC 頻繁發(fā)生，影響吞吐量。內存池（Object Pool）是解決這個問題的經典手段。
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;/*** 簡單的對象池* @param T 對象類型*/
public class ObjectPoolT {private final int capacity;private final BlockingQueueT pool;private final ObjectFactoryT factory;public interface ObjectFactoryT {T create();void destroy(T obj);}public ObjectPool(int capacity, ObjectFactoryT factory) {this.capacity = capacity;this.factory = factory;this.pool = new LinkedBlockingQueue(capacity);// 預熱：初始化時創(chuàng)建部分對象for (int i = 0; i capacity / 2; i++) {pool.offer(factory.create());}}/*** 從池中獲取對象* @param timeout 超時時間* @param unit 時間單位* @return 對象實例* @throws InterruptedException 如果等待被中斷*/public T borrow(long timeout, TimeUnit unit) throws InterruptedException {T obj = pool.poll(timeout, unit);if (obj == null) {// 如果池空且超時，可以新建一個，或者拋出異常// 這里為了演示簡單，直接新建obj = factory.create();}return obj;}/*** 歸還對象* @param obj 要歸還的對象*/public void offer(T obj) {if (obj == null) {throw new IllegalArgumentException(Object cannot be null);}// 重置對象狀態(tài)（可選，取決于業(yè)務）// factory.reset(obj); pool.offer(obj);}
}逐行講解關鍵點：BlockingQueue：使用 LinkedBlockingQueue 作為底層容器，它天生就是線程安全的，且支持阻塞操作。當池空時，borrow 方法會阻塞直到有對象歸還或超時，這天然實現(xiàn)了背壓（Backpressure）。
ObjectFactory：使用工廠模式解耦對象創(chuàng)建邏輯。不同的對象類型（如 ByteBuffer、Socket）有不同的創(chuàng)建和銷毀邏輯，通過接口注入，提高了代碼的復用性。
預熱：在構造函數(shù)中預創(chuàng)建一半的對象，可以避免冷啟動時的性能抖動。追問與延伸：面試官最愛挖的坑
當你寫完上述代碼后，面試官不會就此罷休。以下是西安所面試中常見的追問，提前準備能讓你從容應對。
Q1: 如果 LRU Cache 的容量非常大（比如百萬級），HashMap 會出現(xiàn)什么問題？如何優(yōu)化？
A: HashMap 在并發(fā)環(huán)境下可能出現(xiàn)擴容鎖競爭，或者如果 Key 分布不均，可能導致鏈表過長，查詢退化為 O(N)。優(yōu)化方案：使用 ConcurrentHashMap 替代 HashMap，利用其分段鎖（JDK8 是 CAS + synchronized）提高并發(fā)性能。
如果 Key 分布不均，可以考慮使用一致性 Hash 或者布隆過濾器預過濾。
對于極端場景，可以分片，每個分片維護一個 LRU，最后合并。Q2: 分布式鎖中，如果 Redis 主從切換，導致鎖丟失怎么辦？
A: 這是經典的 CAP 問題。主從復制是異步的，如果主節(jié)點寫入鎖后立刻宕機，從節(jié)點升主時可能沒有這條鎖數(shù)據(jù)，導致兩個客戶端同時持有鎖。
解決方案：RedLock 算法：在多個獨立的 Redis 節(jié)點上加鎖，只要超過半數(shù)節(jié)點加鎖成功，就認為加鎖成功。這提高了可用性，但不能完全解決一致性問題。
Zookeeper：使用 Zookeeper 的臨時順序節(jié)點實現(xiàn)分布式鎖。ZK 基于 ZAB 協(xié)議，保證了強一致性。雖然性能比 Redis 低，但更安全。
業(yè)務兜底：在業(yè)務層做冪等性設計。即使鎖失效，業(yè)務邏輯也能保證數(shù)據(jù)最終一致。Q3: 內存池中的對象，如何確保歸還時的狀態(tài)是干凈的？
A: 這是一個非常實際的問題。如果對象在借用期間被修改了狀態(tài)，直接歸還會導致下一個使用者拿到臟數(shù)據(jù)。
解決方案：Reset 方法：在 ObjectFactory 接口中增加 reset 方法，歸還時調用，重置對象狀態(tài)。
封裝：不要直接暴露對象，而是包裝一層，使用者通過包裝類的方法操作，歸還時自動重置。
不可變對象：如果可能，盡量使用不可變對象，或者每次借用后創(chuàng)建新的包裝實例。記憶口訣：把考點刻在腦子里
為了在緊張面試中快速回憶，我總結了以下口訣：
LRU 考點：哈希鏈表雙向走，偽頭偽尾少煩憂。
訪問移到最前方，滿額刪尾再移除。
并發(fā)讀寫鎖要加，Key 存節(jié)點別漏抓。分布式鎖考點：設置原子 NX EX，過期時間防死結。
刪除必須 Lua 驗，ID 比對防誤刪。
主從切換有隱患，ZK 強一致更穩(wěn)。內存池考點：阻塞隊列做容器，工廠模式造對象。
預熱啟動避抖動，歸還重置保干凈。
超時新建或拋錯，背壓機制控流量。西安所面試特別提示：
西安華為研究所的面試官非常務實。他們不關心你用了多炫酷的技術，只關心你的代碼是否安全、是否高效、是否可維護。在手寫實現(xiàn)環(huán)節(jié)，務必注重邊界條件處理、異常處理和日志記錄。哪怕代碼簡單，只要邏輯嚴密、注釋清晰、能主動指出優(yōu)化方向，就能拿高分。
此外，西安所的項目涉及大量硬件交互和高并發(fā)場景，對底層原理的考察會比互聯(lián)網(wǎng)大廠更深。比如 JVM 內存模型、網(wǎng)絡 IO 模型（BIO/NIO/AIO）、操作系統(tǒng)進程調度等。這些基礎不牢，手寫實現(xiàn)的代碼再漂亮，也難以通過終面。
你在項目里踩過這個坑嗎？比如 LRU 在高并發(fā)下的鎖競爭，或者分布式鎖的誤刪問題？評論區(qū)聊聊，咱們一起復盤，避坑指南越寫越全。