吐槽一下：企業(yè)微信是真忙啊，面試過程中，面試官還會被拉去開會，開局寫完三道算法之后，硬是讓我等了將近一個小時，體驗非常不好....

---

#### **一、算法題**
1. **二維數組處理**  
   - 題目描述：對二維數組按第一列升序、第二列降序排序后，求第二列的最長遞增子序列  
   - 思路：排序后轉化為最長遞增子序列（LIS）問題，用動態(tài)規(guī)劃或貪心+二分解決  

2. **滑動窗口問題**  
   - 題目描述：維護一個窗口，保證窗口內字符不重復，求最大窗口長度  
   - 思路：滑動窗口+哈希表記錄字符位置  

3. **二叉樹第K大元素**  
   - 題目描述：按左-根-右順序收集元素后取第K大值  
   - 思路：中序遍歷得到有序列表后直接取第K大（暴力解法）  

---

#### **二、項目相關**
1. **登錄鑒權機制**  
   - 流程：手機號+驗證碼登錄，未注冊用戶自動注冊  
   - Token刷新：通過攔截器對非登錄請求刷新Token有效期  
   - **追問**：  
     - Token生成算法？使用JWT（Header+Payload+Signature）  
     - Token唯一性保障？通過JWT簽名和用戶唯一標識  

2. **數據庫優(yōu)化**  
   - 慢查詢解決：檢查索引失效、分庫分表、SQL優(yōu)化  
   - **索引原則**：  
     - 高區(qū)分度字段優(yōu)先  
     - 聯合索引遵循最左匹配原則  
     - 避免對長文本字段建索引  

---

#### **三、緩存問題**
1. **緩存穿透**  
   - 場景：請求不存在的數據（如非法ID）  
   - 解決：緩存空值+布隆過濾器  

2. **緩存擊穿**  
   - 場景：熱點Key失效后高并發(fā)請求壓垮數據庫  
   - 解決：互斥鎖（如Redis的SETNX）  

3. **緩存雪崩**  
   - 場景：大量Key同時過期  
   - 解決：隨機過期時間+集群部署  

---

#### **四、多線程與鎖**
1. **線程安全集合**  
   - `ConcurrentHashMap` vs `Hashtable`：分段鎖 vs 全表鎖  

2. **鎖機制**  
   - 悲觀鎖：`synchronized`、`ReentrantLock`  
   - 樂觀鎖：CAS（如Atomic類）、版本號  
   - **區(qū)別**：悲觀鎖強一致但性能低，樂觀鎖高并發(fā)但需處理沖突  

---

#### **五、消息隊列**
1. **選擇RabbitMQ的原因**  
   - 輕量級、適合單體項目，對比Kafka/RocketMQ更簡單  

2. **長連接實現**  
   - 基于AMQP協議，通過心跳機制維持TCP長連接  

---

#### **六、設計模式與AOP**
1. **AOP應用場景**  
   - 公共字段自動填充（如創(chuàng)建時間、更新人）  
   - 實現：通過切面攔截DAO層操作  

---

#### **七、反問環(huán)節(jié)**
1. 實習生工作內容：測試平臺開發(fā)，參與1-2個項目  
2. 面試輪次：4輪技術面（按正式員工標準）  
3. 改進建議：技術深度需加強（如Redis底層原理、鎖實現細節(jié)）  

---

**參考答案亮點**  
- **JWT結構**：Header（算法）、Payload（用戶信息）、Signature（簽名）  
- **索引失效場景**：對字段使用函數、類型隱式轉換、模糊查詢左匹配  
- **CAS問題**：ABA問題（通過版本號解決）、自旋開銷  
- **RabbitMQ協議**：基于AMQP，支持多種消息模式（Work Queue、Pub/Sub）