BAT大廠面試的100道考題【算法、源碼、架構、中間件、設計模式、網絡、項目】，過60分的不到10%

作者：小傅哥
博客：https://bugstack.cn

沉澱、分享、成長，讓自己和他人都能有所收穫！😄

---

獨生子女生娃，沒救了！

• 考題：https://docs.qq.com/form/page/DT3JKRWN5bkh4U2J2

小傅哥，你的100道Java考題，我只考了16分，是不是沒救了！給我個答案吧！那麼鑑於不少小夥伴已經考完了，那麼小傅哥就做一個考題解析，方便讀者可以針對自己的問題進行補充學習。

其實這些考題只是相當於在你的技術棧地圖中，拎出100個檢查站點，進行片段化的提問，來檢查你對知識網的覆蓋程度。而學習的最終目標遠不是來背這些題，那樣是沒有多大的意義的，否則你在面對面試官時換個方向再問，可能你還是沒法回答。所以更有意義的事是慢下來，不貪多，一步一個腳印的用自己的思考和實踐驗證學會這些內容。

好啦，小傅哥就做個這些問題的分析，如果你還沒有參與考試也可以先嚐試考一下，再看解答會更有感覺。

解析：考題知識點

1. 算法（1~10）

01：常見的數據結構有哪些

• 選項：

  • A.隊列
  • B.棧
  • C.哈希表
  • D.堆
  • E.字典樹
  • F.樹（二叉查找樹、AVL樹、紅黑樹、線段樹）
  • G.橋
  • H.圖
  • I.並查集
  • J布隆過濾器

• 答案：A、B、C、D、E、F、H、I、J

• 解析：基本的數據結構都是基於數組和鏈表滿足不同場景訴求所擴展出來的

• 詳細：https://zh.wikipedia.org/wiki/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E6%9C%AF%E8%AF%AD%E5%88%97%E8%A1%A8 —— 數據結構屬於列表

02：優先隊列是基於什麼數據結構實現？

• 選項：
  • A.鏈表
  • B.哈希表
  • C.棧
  • D.二叉堆
• 答案：D
• 解析：Java 中的優先隊列 PriorityQueue 是基於數組結構的二叉堆實現的
• 詳細：https://bugstack.cn/md/algorithm/data-structures/2022-08-06-queue.html

03：HashMap 解決哈希碰撞的數據結構？

• 選項：
  • A.杜鵑散列
  • B.開放尋址
  • C.拉鍊尋址
  • D.合併散列
• 答案：C
• 解析：HashMap 爲了解決元素的碰撞，採用哈希桶 + 鏈表/紅黑樹的數據結構，也稱爲拉鍊尋址。開放尋址是 ThreadLocal 的數據結構
• 詳細：https://bugstack.cn/md/algorithm/data-structures/2022-08-27-hash-table.html#_2-%E6%8B%89%E9%93%BE%E5%AF%BB%E5%9D%80

04：ArrayDeque 實現堆擴容時需要進行幾次元素拷貝？

• 選項：
  • A.1
  • B.2
  • C.3
  • D.4
• 答案：B
• 解析：ArrayDeque 是基於數組實現的堆棧結構，在元素的存放上因爲有擴容數組操作，爲了保持堆棧的先進後出的特性，所以需要分段拷貝元素。
• 詳細：https://bugstack.cn/md/algorithm/data-structures/2022-08-17-stack.html

05：基於數組實現的二叉堆，元素k如何計算父節點

• 選項：
  • A.k >> 1
  • B.(k + 1) << 1
  • C.(k - 1) <<< 1
  • D.(k - 1) >>> 1
• 答案：D
• 解析：基於數組實現的二叉堆所有子節點與父節點的位置關係，是子節點除以2取整，就是父節點的位置。之所以是這樣的一個計算關係，因爲它整個二叉堆上每一層元素在數組位置的存放上，就是一個1、2、4、8碼的結構，也就是二進制結構。所以可以除以2取整計算父節點位置。那麼使用二進制計算就是 (k - 1) >>> 1
• 詳細：https://bugstack.cn/md/algorithm/data-structures/2022-09-03-heap.html

06：鏈表刪除任意元素的時間複雜度

• 選項：
  • A.O(1)
  • B.O(n)
  • C.O(logn)
  • D.O(n^2)
• 答案：B
• 解析：鏈表的操作只有插入的時間複雜度是O(1)，其他操作時間複雜度都O(n)。也因爲有這樣的情況，所以開始設計出二叉搜索樹、AVL平衡樹、紅黑樹等數據結構。讓時間複雜度儘可能平衡到O(logn)。
• 詳細：https://bugstack.cn/md/algorithm/data-structures/2022-07-22-linked-list.html

07：HashMap 負載因子的使用

• 選項：
  • A.負載因子越大，有限空間內存放元素越少
  • B.負載因子越小，有限空間內存放元素越多
  • C.負載因子越大，有限空間內存放元素越多
  • D.負載因子越小，有限空間內存放元素越少
• 答案：C、D
• 解析：對於 HashMap 來說，複雜因子的作用就是爲了調衡元素的的碰撞情況。負載因子太大，是可以節省空間但碰撞的概率就會增大。反之就是用空間換時間，需要拉倒空間解決碰撞。所以 HashMap 選擇 0.75 也就是 3/4 作爲默認負載因子。
• 詳細：https://bugstack.cn/md/java/interview/2020-08-07-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC3%E7%AF%87%E3%80%8AHashMap%E6%A0%B8%E5%BF%83%E7%9F%A5%E8%AF%86%EF%BC%8C%E6%89%B0%E5%8A%A8%E5%87%BD%E6%95%B0%E3%80%81%E8%B4%9F%E8%BD%BD%E5%9B%A0%E5%AD%90%E3%80%81%E6%89%A9%E5%AE%B9%E9%93%BE%E8%A1%A8%E6%8B%86%E5%88%86%EF%BC%8C%E6%B7%B1%E5%BA%A6%E5%AD%A6%E4%B9%A0%E3%80%8B.html#_3-%E5%88%9D%E5%A7%8B%E5%8C%96%E5%AE%B9%E9%87%8F%E5%92%8C%E8%B4%9F%E8%BD%BD%E5%9B%A0%E5%AD%90

08：ThreadLocal 解決哈希碰撞的散列算法？

• 選項：
  • A.擾動函數
  • B.斐波那契
  • C.平方散列
  • D.合併散列
• 答案：B
• 解析：ThreadLocal 是基於數組的開放尋址數據結構，採用的斐波那契散列，因爲它在有限空間內，對線程內的元素計算索引位置更加分散。HashMap 爲了降低元素的碰撞採用的是擾動函數
• 詳細：https://bugstack.cn/md/java/interview/2020-09-23-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC12%E7%AF%87%E3%80%8A%E9%9D%A2%E8%AF%95%E5%AE%98%EF%BC%8CThreadLocal%20%E4%BD%A0%E8%A6%81%E8%BF%99%E4%B9%88%E9%97%AE%EF%BC%8C%E6%88%91%E5%B0%B1%E6%8C%82%E4%BA%86%EF%BC%81%E3%80%8B.html

09：HashMap 鏈表轉紅黑樹條件

• 選項：
  • A.空間長度8，元素個數大於8
  • B.空間長度64，元素個數大於7
  • C.空間長度8，元素個數大於7
  • D.空間長度64，元素個數大於8
• 答案：D
• 解析：HashMap 不是一上來就在最低的初始化長度內，超過最長鏈表長度就直接轉換紅黑樹，而是達到64位長度後，元素大於8，還有碰撞的情況下將鏈表轉換爲紅黑樹。HashMap 裏的數學知識點含量巨大
• 詳細：https://bugstack.cn/md/java/interview/2020-08-13-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC4%E7%AF%87%E3%80%8AHashMap%E6%95%B0%E6%8D%AE%E6%8F%92%E5%85%A5%E3%80%81%E6%9F%A5%E6%89%BE%E3%80%81%E5%88%A0%E9%99%A4%E3%80%81%E9%81%8D%E5%8E%86%EF%BC%8C%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E3%80%8B.html

10：關於 ArrayList 和 LinkedList 插入1000萬個元素性能對比

• 選項：
  • A.頭插時，ArrayList 性能高於 LinkedList
  • B.頭插時，LinkedList 性能高於 ArrayList
  • C.中間插，ArrayList 性能高於 LinkedList
  • D.中間插，LinkedList 性能高於 ArrayList
  • E.尾插時，ArrayList 性能高於 LinkedList
  • F.尾插時，LinkedList 性能高於 ArrayList
• 答案：B、C、E
• 解析：ArrayList 耗時在元素拷貝、LinkedList 耗時在節點創建，大批量的新元素創建也是一種比較耗時的行爲。具體可以參考壓測數據
• 詳細：https://bugstack.cn/md/java/interview/2020-08-30-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC8%E7%AF%87%E3%80%8ALinkedList%E6%8F%92%E5%85%A5%E9%80%9F%E5%BA%A6%E6%AF%94ArrayList%E5%BF%AB%EF%BC%9F%E4%BD%A0%E7%A1%AE%E5%AE%9A%E5%90%97%EF%BC%9F%E3%80%8B.html

2. 源碼-Java（11~20）

01：JDK創建代理的方式

• 選項：
  • A.new JavassistProxy().defineClass(clazz.getName(), bytes, 0, bytes.length).newInstance()
  • B.dynamicType.load(Thread.currentThread().getContextClassLoader()).getLoaded().newInstance();
  • C.Proxy.newProxyInstance
  • D.Enhancer.create(object.getClass(), this);
• 答案：C
• 解析：JDK 默認提供創建代理的方式是 Proxy.newProxyInstance，而不是如 Javassist、Cglib 等方式創建。
• 詳細：https://bugstack.cn/md/java/interview/2020-10-14-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC13%E7%AF%87%E3%80%8A%E9%99%A4%E4%BA%86JDK%E3%80%81CGLIB%EF%BC%8C%E8%BF%98%E6%9C%893%E7%A7%8D%E7%B1%BB%E4%BB%A3%E7%90%86%E6%96%B9%E5%BC%8F%EF%BC%9F%E9%9D%A2%E8%AF%95%E5%8F%88%E5%8D%A1%E4%BD%8F%EF%BC%81%E3%80%8B.html

02：volatile 關鍵字的作用

• 選項：
  • A.可見性
  • B.有序性
  • C.原子性
  • D.防重排
• 答案：A、D
• 解析：在 volatile 的特性描述中主要爲可見性和防重排，儘可能保證有序性。所以這裏的選擇 A、D 或者 A、B、D 都可以。但 volatile 是不具有原子性的，synchronized 既可以保證原子性 ，也可以保證可見性。
• 詳細：https://bugstack.cn/md/java/interview/2020-10-21-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC14%E7%AF%87%E3%80%8Avolatile%20%E6%80%8E%E4%B9%88%E5%AE%9E%E7%8E%B0%E7%9A%84%E5%86%85%E5%AD%98%E5%8F%AF%E8%A7%81%EF%BC%9F%E6%B2%A1%E6%9C%89%20volatile%20%E4%B8%80%E5%AE%9A%E4%B8%8D%E5%8F%AF%E8%A7%81%E5%90%97%EF%BC%9F%E3%80%8B.html

03：Integer.toHexString("".hashCode()) 輸出結果？

• 選項：
  • A.拋異常
  • B.1
  • C.0
  • D.7fffffff
• 答案：C
• 解析：哈希的計算公式；s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] 當字符串爲空時則不會通過公式計算哈希值，也就是0，那麼0的 toHexString 16進制轉換仍然是0。
• 詳細：https://bugstack.cn/md/java/interview/2020-08-04-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC2%E7%AF%87%E3%80%8A%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%EF%BC%8CHashCode%E4%B8%BA%E4%BB%80%E4%B9%88%E4%BD%BF%E7%94%A831%E4%BD%9C%E4%B8%BA%E4%B9%98%E6%95%B0%EF%BC%9F%E3%80%8B.html

04：哪些是公平鎖實現方式？

• 選項：
  • A.CLH
  • B.MCSLock
  • C.TicketLock
  • D.SpinLock
• 答案：A、B、C、D
• 解析：CLH、MCS、Spin、Ticket 四種自旋鎖的實現方式都是公平鎖。
• 詳細：https://bugstack.cn/md/java/interview/2020-11-04-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC16%E7%AF%87%E3%80%8A%E7%A0%81%E5%86%9C%E4%BC%9A%E9%94%81%EF%BC%8CReentrantLock%E4%B9%8B%E5%85%AC%E5%B9%B3%E9%94%81%E8%AE%B2%E8%A7%A3%E5%92%8C%E5%AE%9E%E7%8E%B0%E3%80%8B.html

05：Synchronized 和 ReentrantLock 的描述

• 選項：
  • A.兩者都是獨佔鎖，只允許線程互斥的訪問臨界資源
  • B.兩者都是基於AQS提供的共享資源同步框架實現的（獨佔、可重入、允許中斷）
  • C.ReentrantLock是JVM層面的實現，synchronized是Java層面的實現
  • D.ReentrantLock是Java層面的實現，synchronized是JVM層面的實現
• 答案：A、D
• 解析：兩者都是獨佔鎖，但 Synchronized 是基於 JVM 層面的，ReentrantLock 是基於 Java 層面的，也就是基於 Java API 實現的。
• 詳細：https://bugstack.cn/md/java/interview/2020-11-11-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC17%E7%AF%87%E3%80%8A%E7%A0%81%E5%86%9C%E4%BC%9A%E9%94%81%EF%BC%8CReentrantLock%E4%B9%8BAQS%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90%E5%92%8C%E5%AE%9E%E8%B7%B5%E4%BD%BF%E7%94%A8%E3%80%8B.html

06：Thread.start()的啓動過程包括？

• 選項：
  • A.Java 創建線程和啓動
  • B.調用本地方法 start0()
  • C.JVM 中 JVM_StartThread 的創建和啓動
  • D.設置線程狀態等待被喚醒
  • E.根據不同的OS啓動線程並喚醒
  • F.回調 run() 方法啓動 Java 線程
• 答案：A、B、C、D、E、F
• 解析：線程的創建包括了很多底層 C 語言的邏輯，體現在；Thread.c、jvm.cpp、thread.cpp、os.cpp、os_linux.cpp、os_windows.cpp、vmSymbols.cpp
• 詳細：https://bugstack.cn/md/java/interview/2020-11-25-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC19%E7%AF%87%E3%80%8AThread.start()%20%EF%BC%8C%E5%AE%83%E6%98%AF%E6%80%8E%E4%B9%88%E8%AE%A9%E7%BA%BF%E7%A8%8B%E5%90%AF%E5%8A%A8%E7%9A%84%E5%91%A2%EF%BC%9F%E3%80%8B.html

07：Thread 線程狀態包括？

• 選項：
  • A.NEW
  • B.RUNNABLE
  • C.BLOCKED
  • D.WAITING
  • E.TIMED_WAITING
  • F.TERMINATED
• 答案：A、B、C、D、E、F
• 解析：java.lang.Thread.State 的枚舉狀態包括； NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED;
• 詳細：https://bugstack.cn/md/java/interview/2020-12-02-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC20%E7%AF%87%E3%80%8AThread%20%E7%BA%BF%E7%A8%8B%EF%BC%8C%E7%8A%B6%E6%80%81%E8%BD%AC%E6%8D%A2%E3%80%81%E6%96%B9%E6%B3%95%E4%BD%BF%E7%94%A8%E3%80%81%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90%E3%80%8B.html

08：線程池拒絕策略包括？

• 選項：
  • A.AbortPolicy(拋異常方式拒絕)
  • B.DiscardPolicy(直接丟棄)
  • C.DiscardOldestPolicy(丟棄存活時間最長的任務)
  • D.CallerRunsPolicy(誰提交誰執行)
• 答案：A、B、C、D
• 解析：線程池的拒絕策略包括；拋異常拒絕、直接丟棄、丟棄存活時間最長的和誰提交誰執行。
• 詳細：https://bugstack.cn/md/java/interview/2020-12-09-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC21%E7%AF%87%E3%80%8A%E6%89%8B%E5%86%99%E7%BA%BF%E7%A8%8B%E6%B1%A0%EF%BC%8C%E5%AF%B9%E7%85%A7%E5%AD%A6%E4%B9%A0ThreadPoolExecutor%E7%BA%BF%E7%A8%8B%E6%B1%A0%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86%EF%BC%81%E3%80%8B.html

09：JDK 常用命令敘述錯誤的是？

• 選項：
  • A.javac– 編譯器，將後綴名爲.java的源代碼編譯成後綴名爲.class的字節碼
  • B.jstack – 獲取java進程內存映射信息
  • C.jhat – java堆分析工具
  • D.jstat – JVM檢測統計工具
• 答案：B
• 解析：jstack（Stack Trace for Java），用於生成虛擬機當前時刻的線程快照（threaddump、javacore）。所以它是 Java堆棧跟蹤工具。
• 詳細：https://bugstack.cn/md/java/interview/2021-01-13-%E9%9D%A2%E7%BB%8F%E6%89%8B%E5%86%8C%20%C2%B7%20%E7%AC%AC26%E7%AF%87%E3%80%8AJVM%E6%95%85%E9%9A%9C%E5%A4%84%E7%90%86%E5%B7%A5%E5%85%B7%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%80%BB%E7%BB%93%E3%80%8B.html

10：JVM 虛擬機運行時數據區包括？

• 選項：
  • A.Frame，棧幀
  • B.JvmStack，虛擬機棧
  • C.LocalVars，局部變量
  • D.OperandStack，操作數棧
  • E.Slot，數據槽
  • F.heap，堆，裏面包括常量池和方法區
• 答案：A、B、C、D、E、F
• 解析：運行時數據區包括；棧幀、虛擬機棧、局部變量、操作數棧、數據槽、堆，在手寫JVM中有這部分的體現。
• 詳細：https://bugstack.cn/md/java/develop-jvm/2019-05-05-%E7%94%A8Java%E5%AE%9E%E7%8E%B0JVM%E7%AC%AC%E5%9B%9B%E7%AB%A0%E3%80%8A%E8%BF%90%E8%A1%8C%E6%97%B6%E6%95%B0%E6%8D%AE%E5%8C%BA%E3%80%8B.html

3. 源碼-Spring（21~30）

01：Bean 對象容器使用的是？

• 選項：
  • A.ArrayList
  • B.LinkedList
  • C.HashSet
  • D.HashMap
• 答案：D
• 解析：Spring 中的 Bean 對象是存放到 HashMap 的數組結構中的，因爲這個數組結構有 Key -> Value 結構，更加符合 Bean 對象的存放和獲取。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-05-20-%E7%AC%AC2%E7%AB%A0%EF%BC%9A%E5%B0%8F%E8%AF%95%E7%89%9B%E5%88%80%EF%BC%8C%E5%AE%9E%E7%8E%B0%E4%B8%80%E4%B8%AA%E7%AE%80%E5%8D%95%E7%9A%84Bean%E5%AE%B9%E5%99%A8.html

02：InstantiationStrategy Bean 對象的實例化策略有哪些？

• 選項：
  • A.CglibSubclassingInstantiationStrategy
  • B.SimpleInstantiationStrategy
  • C.JDKInstantiationStrategy
  • D.ASMInstantiationStrategy
• 答案：A、B
• 解析：Spring 默認提供了 JDK（SimpleInstantiationStrategy） 和 Cglib（CglibSubclassingInstantiationStrategy） 兩種實例化策略。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-05-30-%E7%AC%AC4%E7%AB%A0%EF%BC%9A%E5%B4%AD%E9%9C%B2%E5%A4%B4%E8%A7%92%EF%BC%8C%E5%9F%BA%E4%BA%8ECglib%E5%AE%9E%E7%8E%B0%E5%90%AB%E6%9E%84%E9%80%A0%E5%87%BD%E6%95%B0%E7%9A%84%E7%B1%BB%E5%AE%9E%E4%BE%8B%E5%8C%96%E7%AD%96%E7%95%A5.html

03：資源解析的類型包括

• 選項：
  • A.classpath
  • B.resources
  • C.https
  • D.rpc
• 答案：A、B、C
• 解析：Spring 的解析方式包括；類資源、本地resources配置、遠程https拉取。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-06-09-%E7%AC%AC6%E7%AB%A0%EF%BC%9A%E6%B0%94%E5%90%9E%E5%B1%B1%E6%B2%B3%EF%BC%8C%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%AE%9E%E7%8E%B0%E8%B5%84%E6%BA%90%E5%8A%A0%E8%BD%BD%E5%99%A8%EF%BC%8C%E4%BB%8ESpring.xml%E8%A7%A3%E6%9E%90%E5%92%8C%E6%B3%A8%E5%86%8CBean%E5%AF%B9%E8%B1%A1.html

04：BeanPostProcessor 與 BeanFactoryPostProcessor 的作用範圍

• 選項：
  • A.BeanPostProcessor 用於 Bean 對象執行初始化方法前後擴展
  • B.BeanFactoryPostProcessor 用於 Bean 對象執行初始化方法前後擴展
  • C.BeanPostProcessor 用於 BeanDefinition 加載完成後提供擴展機制
  • D.BeanFactoryPostProcessor 用於 BeanDefinition 加載完成後提供擴展機制
• 答案：A、D
• 解析：BeanFactoryPostProcessor 作用域 Bean 容器上下文中 refresh 對象時，提供了擴展修改 BeanDefinition 的機制。BeanPostProcessor 是在 Bean 實例化階段的前後提供的擴展點。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-06-17-%E7%AC%AC7%E7%AB%A0%EF%BC%9A%E6%89%80%E5%90%91%E6%8A%AB%E9%9D%A1%EF%BC%8C%E5%AE%9E%E7%8E%B0%E5%BA%94%E7%94%A8%E4%B8%8A%E4%B8%8B%E6%96%87%EF%BC%8C%E8%87%AA%E5%8A%A8%E8%AF%86%E5%88%AB%E3%80%81%E8%B5%84%E6%BA%90%E5%8A%A0%E8%BD%BD%E3%80%81%E6%89%A9%E5%B1%95%E6%9C%BA%E5%88%B6.html

05：向虛擬機註冊鉤子的作用？

• 選項：
  • A.init-method 初始化方法
  • B.destroy-method 銷燬方法
  • C.init-bean 實例化對象方法
  • D.destroy-bean 銷燬對象方法
• 答案：B
• 解析：虛擬機鉤子 Runtime.getRuntime().addShutdownHook(new Thread(() -> System.out.println("close！"))); 就是作用於 XML 中配置的 destroy-method 銷燬方法上。用於對 Bean 對象的銷燬處理。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-06-23-%E7%AC%AC8%E7%AB%A0%EF%BC%9A%E9%BE%99%E8%A1%8C%E6%9C%89%E9%A3%8E%EF%BC%8C%E5%90%91%E8%99%9A%E6%8B%9F%E6%9C%BA%E6%B3%A8%E5%86%8C%E9%92%A9%E5%AD%90%EF%BC%8C%E5%AE%9E%E7%8E%B0Bean%E5%AF%B9%E8%B1%A1%E7%9A%84%E5%88%9D%E5%A7%8B%E5%8C%96%E5%92%8C%E9%94%80%E6%AF%81%E6%96%B9%E6%B3%95.html

06：Aware 感知接口的實現類包括？

• 選項：
  • A.BeanClassLoaderAware
  • B.BeanFactoryAware
  • C.BeanNameAware
  • D.ApplicationContextAware
• 答案：A、B、C、D
• 解析：Aware 是 Bean 容器的感知接口，提供了用於獲取 ClassLoader、BeanFactory、BeanName、ApplicationContext 的對象。在 Bean 對象實例化的不同階段提供調用機制，讓外部獲取到這些信息。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-06-28-%E7%AC%AC9%E7%AB%A0%EF%BC%9A%E8%99%8E%E8%A1%8C%E6%9C%89%E9%9B%A8%EF%BC%8C%E5%AE%9A%E4%B9%89%E6%A0%87%E8%AE%B0%E7%B1%BB%E5%9E%8BAware%E6%8E%A5%E5%8F%A3%EF%BC%8C%E5%AE%9E%E7%8E%B0%E6%84%9F%E7%9F%A5%E5%AE%B9%E5%99%A8%E5%AF%B9%E8%B1%A1.html

07：FactoryBean 和 BeanFacory 的用途

• 選項：
  • A.FactoryBean 獲取 Bean 對象
  • B.BeanFacory 獲取 Bean 對象
  • C.FactoryBean 創建對象
  • D.BeanFacory 創建對象
• 答案：B、C
• 解析：FactoryBean 工廠對象，是提供了一個使用工廠創建的對象，也就是創建那些複雜的對象。這個複雜指的是創建的對象不是直接new出來，還需一些包裝和代理的操作，就像把每一個 DAO 接口封裝成一個 Mapper 映射對象交給 Spring 容器管理一樣。而 BeanFactory 是對象的工廠，專門提供各類對象的，也是 Spring 自身提供的獲取 Bean 對象的接口。你所有獲取的 Bean 對象都使用這個接口獲取的。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-06-30-%E7%AC%AC10%E7%AB%A0%EF%BC%9A%E6%A8%AA%E5%88%80%E8%B7%83%E9%A9%AC%EF%BC%8C%E5%85%B3%E4%BA%8EBean%E5%AF%B9%E8%B1%A1%E4%BD%9C%E7%94%A8%E5%9F%9F%E4%BB%A5%E5%8F%8AFactoryBean%E7%9A%84%E5%AE%9E%E7%8E%B0%E5%92%8C%E4%BD%BF%E7%94%A8.html

08：如何實現一個容器事件

• 選項：
  • A.實現 ApplicationContextAware
  • B.實現 BeanPostProcessor
  • C.實現 BeanFactoryPostProcessor
  • D.繼承 ApplicationContextEvent
• 答案：D
• 解析：其實像 Spring 中所有對外提供的 Aware、BeanPostProcessor、Event 都是一種 SPI 機制，滿足外部對各類操作的擴展。而 Event 事件也是一種擴展機制，就像 ApplicationContextEvent 是用於監聽應用容器的事件。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-07-07-%E7%AC%AC11%E7%AB%A0%EF%BC%9A%E6%9B%B4%E4%B8%8A%E5%B1%82%E6%A5%BC%EF%BC%8C%E5%9F%BA%E4%BA%8E%E8%A7%82%E5%AF%9F%E8%80%85%E5%AE%9E%E7%8E%B0%EF%BC%8C%E5%AE%B9%E5%99%A8%E4%BA%8B%E4%BB%B6%E5%92%8C%E4%BA%8B%E4%BB%B6%E7%9B%91%E5%90%AC%E5%99%A8.html

09：AOP 切面如何攔截方法

• 選項：
  • A.正則表達式
  • B.切點表達式
  • C.類方法匹配
  • D.Ognl表達式
• 答案：B
• 解析：Spring 中 AOP 切面攔截方法使用的是 execution(* cn.bugstack.springframework.test.bean.IUserService.*(..)) 表達式匹配，它是一種 AspectJExpressionPointcut 提供的切點表達式。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-07-13-%E7%AC%AC12%E7%AB%A0%EF%BC%9A%E7%82%89%E7%81%AB%E7%BA%AF%E9%9D%92%EF%BC%8C%E5%9F%BA%E4%BA%8EJDK%E5%92%8CCglib%E5%8A%A8%E6%80%81%E4%BB%A3%E7%90%86%EF%BC%8C%E5%AE%9E%E7%8E%B0AOP%E6%A0%B8%E5%BF%83%E5%8A%9F%E8%83%BD.html

10：哪一級存緩存放代理對象

• 選項：
  • A.singletonObjects
  • B.earlySingletonObjects
  • C.singletonFactories
  • D.earlySingletonFactories
• 答案：C
• 解析：Spring 框架在 DefaultSingletonBeanRegistry 類中一共提供了三級緩存來存放不同階段的對象，包括；普通對象、提前暴漏的對象和代理對象。而代理對象就是存放在 singletonFactories 中。你看到了吧，它是個Factories，和 FactoryBean 其實意思一樣，它們都是工廠對象，不是實際的對象，所以也稱爲代理對象。
• 詳細：https://bugstack.cn/md/spring/develop-spring/2021-08-07-%E7%AC%AC17%E7%AB%A0%EF%BC%9A%E6%94%BB%E6%97%A0%E4%B8%8D%E5%85%8B%EF%BC%8C%E9%80%9A%E8%BF%87%E4%B8%89%E7%BA%A7%E7%BC%93%E5%AD%98%E8%A7%A3%E5%86%B3%E5%BE%AA%E7%8E%AF%E4%BE%9D%E8%B5%96.html

4. 源碼-MyBatis（31~40）

01：MapperProxy 的作用是什麼？

• 選項：
  • A.DAO接口創建映射器代理
  • B.SQL 執行器代理
  • C.會話執行器
  • D.攔截器
• 答案：A
• 解析：MapperProxy 是每一個映射器代理類，也就是給每一個 DAO 接口創建出一個代理的映射器，這個映射就是把 DAO 接口和SQL語句、執行操作、結果封裝給包裝起來，讓用戶調用 DAO 接口時就能完成對數據庫的增刪改查操作。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-03-27-%E7%AC%AC2%E7%AB%A0%EF%BC%9A%E5%88%9B%E5%BB%BA%E7%AE%80%E5%8D%95%E7%9A%84%E6%98%A0%E5%B0%84%E5%99%A8%E4%BB%A3%E7%90%86%E5%B7%A5%E5%8E%82.html

02：解析的SQL語句存放到哪裏？

• 選項：
  • A.存放到 SqlSession 會話中
  • B.存放到 Executor 執行器實現類中
  • C.存放到 Configuration 配置類中
  • D.存放到 MapperProxy 映射器代理類中
• 答案：C
• 解析：MyBatis 框架不像是 Spring 有維護 Bean 對象的容器，在 MyBatis 中用於貫穿整個會話週期的是 Configuration 配置項，那麼類似這樣的 SQL 語句、執行器的創建、映射的參數都是保存在 Configuration 配置項中的。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-04-09-%E7%AC%AC4%E7%AB%A0%EF%BC%9AXML%E7%9A%84%E8%A7%A3%E6%9E%90%E5%92%8C%E6%B3%A8%E5%86%8C%E4%BD%BF%E7%94%A8.html

03：池化數據源的目的是什麼？

• 選項：
  • A.提高連接的可複用性
  • B.有效管理空閒連接
  • C.統一控制資源使用
  • D.包裝 JDBC 事務
• 答案：A、B、C
• 解析：池化的目的不只是數據源、線程、服務，其核心目的都是提高連接資源的複用性、空閒連接的管理和統一控制資源的使用。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-04-17-%E7%AC%AC5%E7%AB%A0%EF%BC%9A%E6%95%B0%E6%8D%AE%E6%BA%90%E7%9A%84%E8%A7%A3%E6%9E%90%E3%80%81%E5%88%9B%E5%BB%BA%E5%92%8C%E4%BD%BF%E7%94%A8.html

04：Executor 執行器提供哪些方法

• 選項：
  • A.query
  • B.commit
  • C.rollback
  • D.close
• 答案：A、B、C、D
• 解析：Executor 是 MyBatis SqlSession 會話中的 SQL 執行器，這個類負責包裝 SQL 所提供的必備方法。同時這個類只有 update 沒有 insert、delete 方法。所以其實更多的技術要從根本上學習，否則換個角度問其實還是沒法回答
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-04-28-%E7%AC%AC7%E7%AB%A0%EF%BC%9ASQL%E6%89%A7%E8%A1%8C%E5%99%A8%E7%9A%84%E5%AE%9A%E4%B9%89%E5%92%8C%E5%AE%9E%E7%8E%B0.html

05：MyBatis 框架中值的設置

• 選項：
  • A.通過 hutool
  • B.通過 lombok
  • C.實現 MetaObject 框架
  • D.硬編碼
• 答案：C
• 解析：只要是一些中間件的框架開發就會有關於對象中值的設置，但這些值的屬性有些時候都是動態提供的，所以不能直接硬編碼。那麼就需要開發一些反射工具，類似 hutool 也是這樣的工具，但在 MyBatis 中是它自己實現的 MetaObject 反射工具包來處理值的設置和獲取。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-05-03-%E7%AC%AC8%E7%AB%A0%EF%BC%9A%E6%8A%8A%E5%8F%8D%E5%B0%84%E7%94%A8%E5%88%B0%E5%87%BA%E7%A5%9E%E5%85%A5%E5%8C%96.html

06：參數的處理和結果集的封裝，用到了什麼設計模式

• 選項：
  • A.代理模式
  • B.適配器模式
  • C.策略模式
  • D.責任鏈模式
• 答案：C
• 解析：在 MyBatis 框架中對於 JDBC 的封裝處理是不能只是 if···else 判斷，這樣就過於臃腫了，那麼對這些 Long、Integer、String 等，各類屬性的獲取和設置，就可以使用策略模式來處理。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-05-26-%E7%AC%AC10%E7%AB%A0%EF%BC%9A%E4%BD%BF%E7%94%A8%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F%EF%BC%8C%E8%B0%83%E7%94%A8%E5%8F%82%E6%95%B0%E5%A4%84%E7%90%86%E5%99%A8.html

07：#{}與${}的區別是什麼？

• 選項：
  • A.#{} 是預編譯處理，${}是字符串替換。
  • B.#{} 是字符串替換，${}是預編譯處理。
  • C.#{} 能防止SQL注入，${}不能防止SQL注入
  • D.#{} 不能防止SQL注入，${}能防止SQL注入
• 答案：A、C
• 解析：#{} 是預編譯處理，能防止 SQL 注入，${} 是字符串替換，不安全不能防止 SQL 注入
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-06-02-%E7%AC%AC11%E7%AB%A0%EF%BC%9A%E6%B5%81%E7%A8%8B%E8%A7%A3%E8%80%A6%EF%BC%8C%E5%B0%81%E8%A3%85%E7%BB%93%E6%9E%9C%E9%9B%86%E5%A4%84%E7%90%86%E5%99%A8.html

08：Insert 返回自增索引

• 選項：
  • A.配置 SELECT LAST_INSERT_ID()
  • B.一個DB連接的事務下，執行兩條 SQL 語句
  • C.自增結果通過return返回
  • D.Jdbc3KeyGenerator 適用於MySql、PostgreSQL
• 答案：A、B、D
• 解析：讓 Insert 操作能返回自增索引，其實相當於要在一個事務下執行2條 SQL 否則是沒法返回的。另外 Jdbc3KeyGenerator：主要用於數據庫的自增主鍵，比如 MySQL、PostgreSQL。SelectKeyGenerator：主要用於數據庫不支持自增主鍵的情況，比如 Oracle、DB2。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-06-25-%E7%AC%AC15%E7%AB%A0%EF%BC%9A%E8%BF%94%E5%9B%9EInsert%E6%93%8D%E4%BD%9C%E8%87%AA%E5%A2%9E%E7%B4%A2%E5%BC%95%E5%80%BC.html

09：Plugin 插件功能作用範圍

• 選項：
  • A.ParameterHandler
  • B.ResultSetHandler
  • C.StatementHandler
  • D.Executor
• 答案：A、B、C、D
• 解析：MyBatis 框架在 Plugin 插件功能上提供了；ParameterHandler、ResultSetHandler、StatementHandler、Executor 四種範圍擴展機制，你可以在插件機制上擴展自身的需求。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-07-01-%E7%AC%AC17%E7%AB%A0%EF%BC%9APlugin%E6%8F%92%E4%BB%B6%E5%8A%9F%E8%83%BD%E5%AE%9E%E7%8E%B0.html

10：緩存的作用範圍

• 選項：
  • A.一級緩存作用於 SqlSession
  • B.一級緩存作用於 namespace
  • C.二級緩存作用於 namespace
  • D.二級緩存作用於 All 全局查詢
• 答案：A、C
• 解析：一級緩存是作用在 SqlSession 會話層面的，一次會話結束(commit、rollback、close)後緩存就結束了。而二級緩存則是作用到 namespace 範圍，通過裝飾一級緩存，把數據保存到隊列中進行使用。那麼你知道這是一種什麼隊列嗎？爲什麼二級緩存並不常用？
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-07-05-%E7%AC%AC19%E7%AB%A0%EF%BC%9A%E4%BA%8C%E7%BA%A7%E7%BC%93%E5%AD%98.html

5. 設計模式（41~50）

01：設計模式分類

• 選項：
  • A.創建型模式；工廠、建造、適配
  • B.結構型模式；迭代、享元、代理
  • C.行爲型模式；觀察、模板、命令
• 答案：C
• 解析：23種設計模式被分爲；創建型模式、結構型模式、行爲型模式。適配是結構型模式、迭代是行爲型模式。更多參考詳細鏈接。
• 詳細：https://bugstack.cn/md/develop/design-pattern/2022-03-12-%E9%87%8D%E5%AD%A6Java%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8FB%E7%AB%99%E8%A7%86%E9%A2%91.html

02：設計模式原則包括

• 選項：
  • A.開放封閉原則
  • B.里氏代換原則
  • C.依賴倒轉原則
  • D.接口隔離原則
  • E.迪米特法則
  • F.單一職責原則
• 答案：A、B、C、D、E、F
• 解析：設計原則包括；開放封閉、里氏替換、依賴倒置、接口隔離、迪米特、單一職責。
• 詳細：https://bugstack.cn/md/develop/design-pattern/2022-03-12-%E9%87%8D%E5%AD%A6Java%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8FB%E7%AB%99%E8%A7%86%E9%A2%91.html

03：多支付渠道與多支付方式，建議使用哪種設計模式

• 選項：
  • A.組合模式
  • B.裝飾器模式
  • C.代理模式
  • D.橋接模式
• 答案：D
• 解析：此題更多的是表達兩種NxN的鏈接使用，一般是橋接更爲合適。
• 詳細：https://bugstack.cn/md/develop/design-pattern/2020-06-04-%E9%87%8D%E5%AD%A6%20Java%20%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E3%80%8A%E5%AE%9E%E6%88%98%E6%A1%A5%E6%8E%A5%E6%A8%A1%E5%BC%8F%E3%80%8B.html

04：MyBatis 二級緩存對一級緩存的上層實現，使用的什麼設計模式

• 選項：
  • A.門面模式
  • B.代理模式
  • C.裝飾器模式
  • D.策略模式
• 答案：C
• 解析：二級緩存是建立在一級緩存複用基礎功能做的實現，把一級緩存中的數據在執行完會話操作後，遷移到二級緩存隊列中。所以它使用了一種裝飾器模式實現。new CachingExecutor(new SimpleExecutor(this, transaction));
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-07-05-%E7%AC%AC19%E7%AB%A0%EF%BC%9A%E4%BA%8C%E7%BA%A7%E7%BC%93%E5%AD%98.html

05：規則樹人羣過濾，建議使用什麼設計模式實現

• 選項：
  • A.命令模式
  • B.備忘錄模式
  • C.策略模式
  • D.組合模式
• 答案：D
• 解析：規則樹的特點是可組合，節點可複用，形成一套二叉搜索樹的結構。所以它更適合使用組合模式來實現。
• 詳細：https://bugstack.cn/md/develop/design-pattern/2020-06-08-%E9%87%8D%E5%AD%A6%20Java%20%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E3%80%8A%E5%AE%9E%E6%88%98%E7%BB%84%E5%90%88%E6%A8%A1%E5%BC%8F%E3%80%8B.html

06：不太常用的設計模式組合

• 選項：
  • A.模板 + 策略 + 工廠
  • B.組合 + 策略 + 建造
  • C.中介 + 備忘 + 訪問
  • D.工廠 + 裝飾 + 模板
• 答案：C
• 解析：一般情況下常用的模式組合，主要爲三類中的交叉組合，比如；創建型、結構型、行爲型。但因爲中介、備忘、訪問，都是行爲模式，所以通常比較少的被組合使用起來。
• 詳細：https://bugstack.cn/md/develop/design-pattern/2020-06-27-%E9%87%8D%E5%AD%A6%20Java%20%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E3%80%8A%E5%AE%9E%E6%88%98%E4%B8%AD%E4%BB%8B%E8%80%85%E6%A8%A1%E5%BC%8F%E3%80%8B.html

07：模板模式的重點

• 選項：
  • A.包裝服務，對外提供接口
  • B.替代if···else判斷流程
  • C.規定一套統一的標準流程
  • D.存放以及可恢復配置信息
• 答案：C
• 解析：模板模式的核心實在在於提供一個抽象類定義出標準的流程，和要調用方法的順序，以及提供出抽象方法給子類實現。這在各類框架中也是非常常用的模式，例如 Spring、MyBatis 以及業務需求類似抽獎活動，定義抽獎流程；風控、規則、庫存、抽獎、消息、發貨等。
• 詳細：https://bugstack.cn/md/project/lottery/Part-2/%E7%AC%AC06%E8%8A%82%EF%BC%9A%E6%A8%A1%E6%9D%BF%E6%A8%A1%E5%BC%8F%E5%A4%84%E7%90%86%E6%8A%BD%E5%A5%96%E6%B5%81%E7%A8%8B.html

08：建立起 MyBatis 和 Spring 的連接

• 選項：
  • A.實現 BeanFactory
  • B.實現 FactoryBean
  • C.實現 BeanPostProcessor
  • D.實現 BeanFactoryPostProcessor
• 答案：B
• 解析：建立起連接的最大關鍵，在於讓 Spring 管理 MyBatis 的映射器代理對象。也就是通過 FactoryBean 包裝一下 DAO 接口代理類的獲取。
• 詳細：https://bugstack.cn/md/spring/develop-mybatis/2022-07-06-%E7%AC%AC20%E7%AB%A0%EF%BC%9A%E6%95%B4%E5%90%88Spring.html

09：各類優惠券；直減、滿減、免息等包裝使用，需要什麼設計模式

• 選項：
  • A.觀察者模式
  • B.策略模式
  • C.組合模式
  • D.備忘錄模式
• 答案：B
• 解析：對於擁有同類共性的物料，但有差異化的使用時，通常都是使用策略模式進行封裝。這在提到 MyBatis 中封裝參數使用策略模式是一樣的。
• 詳細：https://bugstack.cn/md/develop/design-pattern/2020-07-05-%E9%87%8D%E5%AD%A6%20Java%20%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E3%80%8A%E5%AE%9E%E6%88%98%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F%E3%80%8B.html

10：單例模式實現方式包括

• 選項：
  • A.懶漢模式
  • B.餓漢模式
  • C.類的內部類
  • D.雙重校驗鎖
  • E.枚舉
  • F.compareAndSet
• 答案：A、B、C、D、E、F
• 解析：這六種方式都是創建單例的方式，也是基礎面試中常考的題。
• 詳細：https://bugstack.cn/md/develop/design-pattern/2020-05-31-%E9%87%8D%E5%AD%A6%20Java%20%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E3%80%8A%E5%AE%9E%E6%88%98%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F%E3%80%8B.html

6. 系統架構（51~60）

01：創建工程框架包括

• 選項：
  • A.MVC
  • B.DDD
  • C.六邊形
  • D.整潔架構
  • E.SOA架構
• 答案：A、B、C、D、E
• 解析：MVC、DDD、六邊形、整潔架構、SOA架構，都是創建工程搭建的方式
• 詳細：https://bugstack.cn/md/develop/framework/frame/2019-12-22-%E6%9E%B6%E6%9E%84%E6%A1%86%E6%9E%B6%E6%90%AD%E5%BB%BA%E4%B8%80%E3%80%8A%E5%8D%95%E4%BD%93%E5%BA%94%E7%94%A8%E6%9C%8D%E5%8A%A1%E4%B9%8BSSM%E6%95%B4%E5%90%88%EF%BC%9ASpring4%20+%20SpringMvc%20+%20Mybatis%E3%80%8B.html

02：引入Dubbo到框架中，爲什麼需要單獨分出RPC的模塊層

• 選項：
  • A.拆分出來方便維護
  • B.並沒有太大意義，也可以不拆分
  • C.對外提供的RPC調用，需要接口描述
  • D.單獨拆分避免循環依賴
• 答案：C
• 解析：RPC 服務的調用方式有2種，一種是需要接口信息的編碼方式，另外一種是泛化調用。而工程中使用 Dubbo 框架，對外提供服務的話，通常是需要對應提供一個對應的接口描述信息的，這樣外部才能引用這個 Jar 包並做代理操作進行接口調用。所以需要單獨拆分出 RPC 模塊層用於打包。
• 詳細：https://bugstack.cn/md/project/lottery/Part-2/%E7%AC%AC03%E8%8A%82%EF%BC%9A%E8%B7%91%E9%80%9A%E5%B9%BF%E6%92%AD%E6%A8%A1%E5%BC%8FRPC%E8%BF%87%E7%A8%8B%E8%B0%83%E7%94%A8.html

03：分佈式框架技術棧包括

• 選項：
  • A.Spring
  • B.RPC
  • C.MQ
  • D.分庫分表
  • E.分佈式任務
• 答案：B、C、D、E
• 解析：分佈式框架需要解決應用的分佈式部署下，數據的通信和使用。所以要有 RPC、MQ、分庫分表、分佈式任務來處理。
• 詳細：https://bugstack.cn/md/project/lottery/Part-1/%E7%AC%AC03%E8%8A%82%EF%BC%9A%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1.html

04：DDD領域服務包括什麼

• 選項：
  • A.service 服務實現
  • B.repository 倉儲接口
  • C.aggregates 聚合對象
  • D.dao 數據服務
• 答案：A、B、C
• 解析：在 DDD 領域服務的實現中，DAO 是被分配到倉儲服務中，而 DDD 領域服務是定義一個倉儲接口。其實這裏還涉及到了工程的搭建和循環依賴。
• 詳細：https://bugstack.cn/md/project/lottery/Part-2/%E7%AC%AC02%E8%8A%82%EF%BC%9A%E6%90%AD%E5%BB%BADDD%E5%9B%9B%E5%B1%82%E6%9E%B6%E6%9E%84.html

05：低代碼能解決什麼場景問題

• 選項：
  • A.所有CRUD的代碼都可以解決
  • B.各類領域服務的實現
  • C.部分通用共性的接口串聯編排類場景
  • D.產品和運營可以直接替代研發直接上線需求
• 答案：C
• 解析：其實低代碼並不能解決所有問題，甚至哪怕是 CRUD 更多的也需要研發來編寫。而低代碼的核心處理場景是解決部分通用性的接口串聯編排。
• 詳細：https://bugstack.cn/md/develop/framework/scheme/2021-02-21-%E5%85%B3%E4%BA%8E%E4%BD%8E%E4%BB%A3%E7%A0%81%E7%BC%96%E7%A8%8B%E7%9A%84%E5%8F%AF%E6%8C%81%E7%BB%AD%E6%80%A7%E4%BA%A4%E4%BB%98%E8%AE%BE%E8%AE%A1%E5%92%8C%E5%88%86%E6%9E%90.html

06：Zachman框架的六個觀點

• 選項：
  • A.數據
  • B.功能
  • C.網絡
  • D.系統
  • E.時間
  • F.原因
  • G.人
• 答案：A、B、C、E、F、G
• 解析：Zachman框架，由約翰 扎科曼（John Zachman ）在1987年創立的全球第一個企業架構理論，其論文《信息系統架構框架》至今仍被業界認爲是企業架構設計方面最權威的理論。讀者可以閱讀詳細內容擴展學習。
• 詳細：https://bugstack.cn/md/develop/framework/scheme/2021-02-28-%E5%B7%A5%E4%BD%9C%E4%B8%A4%E4%B8%89%E5%B9%B4%EF%BC%8C%E6%95%B4%E4%B8%8D%E6%98%8E%E7%99%BD%E6%9E%B6%E6%9E%84%E5%9B%BE%E9%83%BD%E7%94%BB%E5%95%A5%EF%BC%9F.html

07：中臺設計通常分爲

• 選項：
  • A.業務中臺
  • B.技術中臺
  • C.數據中臺
  • D.運維中臺
• 答案：A、B、C
• 解析：中臺主要包括；業務中臺、技術中臺、數據中臺，但運維不算一箇中臺，它是公司底層支撐的大基建，無論公司哪個部門的中臺，都不能把運維拿出來造一份輪子。PS：雖然中臺的概念已經不那麼火，甚至很多都已經拆中臺了，但不是中臺的概率不好，只是不同場景的公司需要適合自己的架構方案。閱讀詳細你會知道中臺最早是從一個遊戲公司來的。
• 詳細：https://bugstack.cn/md/develop/framework/scheme/2021-03-24-%E5%88%9A%E7%81%AB%E4%BA%86%E7%9A%84%E4%B8%AD%E5%8F%B0%E8%BD%AC%E5%A4%B4%E5%B0%B1%E6%8B%86%EF%BC%8C%E4%B8%80%E5%A4%A7%E6%B3%A2%E5%85%AC%E5%8F%B8%E6%94%BE%E4%B8%8D%E4%B8%8B%E5%8F%88%E6%8B%BF%E4%B8%8D%E8%B5%B7%E6%9D%A5%EF%BC%81.html

08：中臺的實現難度主要包括

• 選項：
  • A.新需求響應難度增加
  • B.服務集成複雜度增加
  • C.可複用實現難度增加
  • D.工程師語言難度增加
• 答案：A、B、C
• 解析：中臺在實踐中主要的問題體現在；響應需求的難度、服務的集成複雜度和複用性變得困難。這是因爲一個需求的實現要誇多個部門的多個系統實現，所有溝通成本也會增加。
• 詳細：https://bugstack.cn/md/develop/framework/scheme/2021-03-24-%E5%88%9A%E7%81%AB%E4%BA%86%E7%9A%84%E4%B8%AD%E5%8F%B0%E8%BD%AC%E5%A4%B4%E5%B0%B1%E6%8B%86%EF%BC%8C%E4%B8%80%E5%A4%A7%E6%B3%A2%E5%85%AC%E5%8F%B8%E6%94%BE%E4%B8%8D%E4%B8%8B%E5%8F%88%E6%8B%BF%E4%B8%8D%E8%B5%B7%E6%9D%A5%EF%BC%81.html#%E5%9B%9B%E3%80%81%E5%88%9A%E5%BB%BA%E5%A5%BD%E5%8F%88%E8%A6%81%E6%8B%86

09：非入侵的系統監控設計需要哪些技術棧

• 選項：
  • A.Javaagent
  • B.字節碼框架
  • C.TTL
  • D.JDK
• 答案：A、B、C
• 解析：非入侵的全鏈路監控系統，最早是由谷歌的 Dapper 論文而來，在設計實現上主要包括的技術棧爲；Javaagent、字節碼框架(ASM\Javassist\TTL-鏈路打標)。
• 詳細：https://bugstack.cn/md/develop/framework/scheme/2021-07-19-%E8%B0%83%E7%A0%94%E5%AD%97%E8%8A%82%E7%A0%81%E6%8F%92%E6%A1%A9%E6%8A%80%E6%9C%AF%EF%BC%8C%E7%94%A8%E4%BA%8E%E7%B3%BB%E7%BB%9F%E7%9B%91%E6%8E%A7%E8%AE%BE%E8%AE%A1%E5%92%8C%E5%AE%9E%E7%8E%B0.html

10：軟件設計原則康威定律包括

• 選項：
  • A.組織溝通方式會通過系統設計表達出來
  • B.時間再多一件事情也不可能做的完美，但總有時間做完一件事情
  • C.線型系統和線型組織架構間有潛在的異質同態特性
  • D.大的系統組織總是比小系統更傾向於分解
• 答案：A、B、C、D
• 解析：康威定律 (康威法則 , Conway's Law) 是馬爾文·康威1967年提出的："設計系統的架構受制於產生這些設計的組織的溝通結構。"
• 詳細：https://zh.m.wikipedia.org/zh-hans/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B

7. 中間件（61~70）

01：中間件分爲哪些類

• 選項：
  • A.終端仿真/屏幕轉換中間件
  • B.數據訪問中間件
  • C.遠程過程調用中間件
  • D.消息中間件
  • E.交易中間件
  • F.對象中間件
• 答案：A、B、C、D、E、F
• 解析：中間件的分類有很多中，這可能也是讓大家在平常的開發中迷惑，到底哪些是中間件。一些基本的中間件定義很好定位，比如MQ、RPC、Dapper等等，但有些軟件服務雖然不是作爲中間件開發出來的，但它們如果符合中間件的定義，也可以歸納到中間的範疇裏。
• 詳細：https://bugstack.cn/md/assembly/middleware/%E7%AC%AC%201%20%E7%AB%A0%20%E4%BB%80%E4%B9%88%E6%98%AF%E4%B8%AD%E9%97%B4%E4%BB%B6.html

02：非業務邏輯的共性服務功能

• 選項：
  • A.白名單&黑名單
  • B.熔斷
  • C.降級
  • D.限流
  • E.切量
  • F.A/BTest
• 答案：A、B、C、D、E、F
• 解析：通常在軟件開發中，會把一些通用的共性功能提煉出來，作爲共用的組件使用。這些組件可以嵌入到網關中。
• 詳細：https://bugstack.cn/md/assembly/middleware/%E7%AC%AC%203%20%E7%AB%A0%20%E6%9C%8D%E5%8A%A1%E6%B2%BB%E7%90%86%EF%BC%8C%E7%BB%9F%E4%B8%80%E7%99%BD%E5%90%8D%E5%8D%95%E6%8E%A7%E5%88%B6.html

03：SpringBoot Starter 如何加載自定義配置（resources/META-INF/spring.factories）

• 選項：
  • A.AutoConfigurations
  • B.EnableAutoConfiguration
  • C.ImportAutoConfiguration
  • D.AutoConfigurationPackage
• 答案：B
• 解析：SpringBoot Starter 的開發是基於 SPI 機制進行擴展，使用 EnableAutoConfiguration 加載配置。如：org.springframework.boot.autoconfigure.EnableAutoConfiguration=cn.bugstack.middleware.whitelist.config.WhiteListAutoConfigure
• 詳細：https://bugstack.cn/md/assembly/middleware/%E7%AC%AC%203%20%E7%AB%A0%20%E6%9C%8D%E5%8A%A1%E6%B2%BB%E7%90%86%EF%BC%8C%E7%BB%9F%E4%B8%80%E7%99%BD%E5%90%8D%E5%8D%95%E6%8E%A7%E5%88%B6.html

04：ES 查詢方式

• 選項：
  • A.x-pack-sql-jdbc
  • B.spring-data-elasticsearch
  • C.elasticsearch-rest-high-level-client
  • D.以上全部
• 答案：D
• 解析：除了大家很常用的 spring-data-elasticsearch、elasticsearch-rest-high-level-client，以外 x-pack-sql-jdbc 也是一種查詢 ES 的操作方式，它可以讓你像使用數據庫一樣使用 ES。x-pack-sql-jdbc，在 7.x 版本中已經集成在 Elasticsearch 的代碼中。
• 詳細：https://bugstack.cn/md/assembly/middleware/%E7%AC%AC%2010%20%E7%AB%A0%20ES-JDBC%20%E6%9F%A5%E8%AF%A2%E5%BC%95%E6%93%8E.html

05：Dubbo 通信方式

• 選項：
  • A.HTTP
  • B.Webservice
  • C.WebFlux
  • D.Netty
• 答案：D
• 解析：Dubbo 實現的 RPC 框架，使用的是 Netty 作爲 Socket 通信框架。
• 詳細：https://bugstack.cn/md/assembly/middleware/%E7%AC%AC%2012%20%E7%AB%A0%20RPC%20%E6%A1%86%E6%9E%B6%E5%AE%9E%E7%8E%B0.html

06：數據庫路由分庫分表散列算法

• 選項：
  • A.哈希散列
  • B.斐波那契散列
  • C.平方散列
  • D.跳房子散列
• 答案：A
• 解析：數據庫和表的數據結構近似於HashMap的拉鍊結構，所以在設計實現上也基本是選擇了哈希散列的方式處理元素的索引。
• 詳細：https://bugstack.cn/md/assembly/middleware/2021-08-19-%E5%9F%BA%E4%BA%8EHash%E6%95%A3%E5%88%97%EF%BC%8C%E6%95%B0%E6%8D%AE%E5%BA%93%E8%B7%AF%E7%94%B1%E7%BB%84%E4%BB%B6%E8%AE%BE%E8%AE%A1.html

07：分佈式任務調度實現技術

• 選項：
  • A.擴展Quartz的任務執行能力，開發 SDK 組件
  • B.將任務服務引入 SDK 並 push 到註冊中心
  • C.通過控制檯統一管理註冊中心任務進行下發執行
  • D.以上全部
• 答案：D
• 解析：這些選項的合併其實就是一個把 Quartz 擴展爲分佈式任務的核心流程，具體設計可以參考詳細文檔；
• 詳細：https://bugstack.cn/md/assembly/middleware/2019-12-08-%E5%BC%80%E5%8F%91%E5%9F%BA%E4%BA%8ESpringBoot%E7%9A%84%E5%88%86%E5%B8%83%E5%BC%8F%E4%BB%BB%E5%8A%A1%E4%B8%AD%E9%97%B4%E4%BB%B6DcsSchedule.html

08：字節碼增強的框架

• 選項：
  • A.ASM
  • B.Byte-Buddy
  • C.Javassist
  • D.Cglib
• 答案：A、B、C
• 解析：字節碼增強框架主要流行的有三個；ASM、Byte-Buddy、Javassist，但大哥是 ASM 基本所有其他的字節碼操作也都是基於 ASM 實現。例如 Cglib 但它是工具，到不能算是字節碼增強框架。
• 詳細：https://bugstack.cn/md/bytecode/asm/2020-03-25-%5BASM%E5%AD%97%E8%8A%82%E7%A0%81%E7%BC%96%E7%A8%8B%5D%E5%A6%82%E6%9E%9C%E4%BD%A0%E5%8F%AA%E5%86%99CRUD%EF%BC%8C%E9%82%A3%E8%BF%99%E7%A7%8D%E6%8A%80%E6%9C%AF%E4%BD%A0%E6%B0%B8%E8%BF%9C%E7%A2%B0%E4%B8%8D%E5%88%B0.html

09：RPC-Dubbo 泛化調用的使用場景

• 選項：
  • A.API網關服務
  • B.集成測試平臺
  • C.低代碼平臺
  • D.以上都是
• 答案：D
• 解析：在一些框架和組件的設計實現中，如果有需要對 RPC 進行配置和調用，那麼是沒法硬編碼的，因爲這些接口都是通過配置動態讀取的，那麼這個時候你就需要使用泛化調用了。所以像；API網關、集成測試平臺、低代碼平臺等，都是需要泛化調用的。
• 詳細：https://bugstack.cn/md/assembly/api-gateway/2022-08-20-%E7%AC%AC2%E7%AB%A0%EF%BC%9A%E4%BB%A3%E7%90%86RPC%E6%B3%9B%E5%8C%96%E8%B0%83%E7%94%A8.html

10：IEDA Plugin 開發完成後如何提交到市場

• 選項：
  • A.發送郵件給 IDEA 官網運營
  • B.在 Github 構建 Release
  • C.通過網站 plugins.jetbrains.com
  • D.本地 IDEA 開發工具構建
• 答案：C
• 解析：這個題有點偏門，基本是需要了解這方面內容才能回答。也算是對架構師的技術棧知曉範圍的考覈，看是否可以在某些問題場景給出不同的解決訪問。那麼像 IDEA 插件的發佈則需要在 plugins.jetbrains.com 官網進行發佈。
• 詳細：https://bugstack.cn/md/assembly/idea-plugin/2021-08-29-%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%EF%BC%8CIDEA%20%E6%8F%92%E4%BB%B6%E6%80%8E%E4%B9%88%E5%8F%91%E5%B8%83%EF%BC%9F.html

8. 網絡通信（71~80）

01：NIO 通信模式

• 選項：
  • A.同步阻塞I/O模式
  • B.同步非阻塞模式
  • C.異步非阻塞I/O模型
  • D.以上都不是
• 答案：B
• 解析：Java BIO[Blocking I/O] 同步阻塞I/O模式、Java NIO[New I/O] 同步非阻塞模式、Java AIO[Asynchronous I/O] 異步非阻塞I/O模型
• 詳細：https://bugstack.cn/md/netty/base/2019-07-30-netty%E6%A1%88%E4%BE%8B%EF%BC%8Cnetty4.1%E5%9F%BA%E7%A1%80%E5%85%A5%E9%97%A8%E7%AF%87%E9%9B%B6%E3%80%8A%E5%88%9D%E5%85%A5JavaIO%E4%B9%8B%E9%97%A8BIO%E3%80%81NIO%E3%80%81AIO%E5%AE%9E%E6%88%98%E7%BB%83%E4%B9%A0%E3%80%8B.html

02：Netty 的優勢有哪些？

• 選項：
  • A.使用簡單：封裝了 NIO 的很多細節，使用更簡單。
  • B.功能強大：預置了多種編解碼功能，支持多種主流協議。
  • C.性能高：通過與其他業界主流的 NIO 框架對比，Netty 的綜合性能最優。
  • D.穩定性好：Netty 修復了已經發現的所有 NIO 的 bug，讓開發人員可以專注於業務本身。
• 答案：A、B、C、D
• 解析：Netty 官網描述其特點；使用方便、效率高、安全的介紹。這也是大家都喜歡使用 Netty 的原因。
• 詳細：https://netty.io/

03：Netty 的應用場景有哪些？

• 選項：
  • A.Dubbo
  • B.MQ
  • C.API網關
  • D.以上都是
• 答案：D
• 解析：在各類框架中涉及到通信的時候，都會考慮使用 Netty 作爲通信框架使用，包括；Dubbo、MQ、Api網關等。
• 詳細：https://bugstack.cn/md/assembly/api-gateway/2022-08-12-%E5%BC%80%E7%AF%87%EF%BC%9A%E5%A6%82%E6%9E%9C%E8%AE%A9%E6%88%91%E8%AE%BE%E8%AE%A1%E4%B8%80%E5%A5%97%EF%BC%8CTPS%E7%99%BE%E4%B8%87%E7%BA%A7API%E7%BD%91%E5%85%B3.html

04：Netty 高性能表現在哪些方面？

• 選項：
  • A.多線程Reactor反應器模式
  • B.內存零拷貝
  • C.內存池設計
  • D.對象池設計
• 答案：A、B、C、D
• 解析：Netty 的設計表現爲；更高的吞吐量，更低的延遲、更少的資源消耗、最小化不必要的內存拷貝。
• 詳細：https://netty.io/

05：Netty 和 Tomcat 的區別？

• 選項：
  • A.Tomcat 是 Web 容器，Netty 是套接字服務
  • B.Tomcat 是 HTTP服務，Netty 可以實現多種服務(HTTP、FTP、UDP、RPC)
  • C.Tomcat 性能低於 Netty
  • D.Netty 更適合結合其他框架使用
• 答案：A、B、D
• 解析：Netty 和 Tomcat 的主要區別主要體現在協議和作用的不同，但不能拋開場景說某個性能就高。
• 詳細：https://stackoverflow.com/questions/56794263/spring-webflux-differrences-when-netty-vs-tomcat-is-used-under-the-hood

06：半包粘包協議的使用

• 選項：
  • A.LineBasedFrameDecoder 基於換行符
  • B.ObjDecoder 對象傳輸處理
  • C.ByteToMessageDecoder 擴展自定義傳輸協議
  • D.以上都是
• 答案：D
• 解析：Netty 本身就提供了很多關於傳輸協議來處理半包粘包，同時也提供了自定義擴展類，你可以基於這些類擴展自己的業務場景中的協議信息。
• 詳細：https://bugstack.cn/md/netty/base/2019-08-11-netty%E6%A1%88%E4%BE%8B%EF%BC%8Cnetty4.1%E5%9F%BA%E7%A1%80%E5%85%A5%E9%97%A8%E7%AF%87%E5%85%AB%E3%80%8ANettyClient%E5%8D%8A%E5%8C%85%E7%B2%98%E5%8C%85%E5%A4%84%E7%90%86%E3%80%81%E7%BC%96%E7%A0%81%E8%A7%A3%E7%A0%81%E5%A4%84%E7%90%86%E3%80%81%E6%94%B6%E5%8F%91%E6%95%B0%E6%8D%AE%E6%96%B9%E5%BC%8F%E3%80%8B.html

07：Netty 流量整形處理類

• 選項：
  • A.ChannelTrafficShapingHandler
  • B.SimpleChannelInboundHandler
  • C.ChannelInboundHandlerAdapter
  • D.以上都不是
• 答案：A
• 解析：流量整形（Traffic Shaping）是一種主動調整流量輸出速率的措施。一個典型應用是基於下游網絡結點的TP指標來控制本地流量的輸出。Netty 提供了 GlobalTrafficShapingHandler、ChannelTrafficShapingHandler、 GlobalChannelTrafficShapingHandler 類來處理流量傳輸速率。
• 詳細：https://bugstack.cn/md/netty/expand/2019-08-27-netty%E6%A1%88%E4%BE%8B%EF%BC%8Cnetty4.1%E4%B8%AD%E7%BA%A7%E6%8B%93%E5%B1%95%E7%AF%87%E5%8D%81%E4%BA%8C%E3%80%8ANetty%E6%B5%81%E9%87%8F%E6%95%B4%E5%BD%A2%E6%95%B0%E6%8D%AE%E6%B5%81%E9%80%9F%E7%8E%87%E6%8E%A7%E5%88%B6%E5%88%86%E6%9E%90%E4%B8%8E%E5%AE%9E%E6%88%98%E3%80%8B.html

08：Netty 使用 SSL 通信的作用

• 選項：
  • A.竊聽風險eavesdropping：第三方可以獲知通信內容。
  • B.篡改風險tampering：第三方可以修改通信內容。
  • C.冒充風險pretending：第三方可以冒充他人身份參與通信。
  • D.以上都是
• 答案：D
• 解析：SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是爲網絡通信提供安全及數據完整性的一種安全協議。TLS與SSL在傳輸層對網絡連接進行加密。通過它來防止；竊聽、篡改和冒充。
• 詳細：https://bugstack.cn/md/netty/expand/2019-08-28-netty%E6%A1%88%E4%BE%8B%EF%BC%8Cnetty4.1%E4%B8%AD%E7%BA%A7%E6%8B%93%E5%B1%95%E7%AF%87%E5%8D%81%E4%B8%89%E3%80%8ANetty%E5%9F%BA%E4%BA%8ESSL%E5%AE%9E%E7%8E%B0%E4%BF%A1%E6%81%AF%E4%BC%A0%E8%BE%93%E8%BF%87%E7%A8%8B%E4%B8%AD%E5%8F%8C%E5%90%91%E5%8A%A0%E5%AF%86%E9%AA%8C%E8%AF%81%E3%80%8B.html

09：IM 通信；登錄、驗證、文件、表情、消息多協議處理

• 選項：
  • A.定義通信一些包，含有針頭和標記位
  • B.自定義繼承實現 ByteToMessageDecoder 攔截標記指令
  • C.通過指令獲取對應解析序列化操作
  • D.每個對應的消息處理器實現類 SimpleChannelInboundHandler 接收指定協議消息
• 答案：A、B、C、D
• 解析：一般對於 IM 通信的實現中，是需要自定義一組通信協議的，協議中要包括幀頭、幀尾、標識符、長度等信息，來方便你完成半包粘包以及不同協議的處理。
• 詳細：https://bugstack.cn/md/project/im/2.2%EF%BC%9A%E9%80%9A%E4%BF%A1%E5%8D%8F%E8%AE%AE%E5%8C%85%E5%AE%9A%E4%B9%89.html

10：Netty ChunkedStream 數據流切塊傳輸的目的

• 選項：
  • A.解決網絡帶寬下，大數據塊傳輸的性能問題
  • B.基於 ChunkedStream 對數據分塊
  • C.通過管道消息傳輸控制 ChannelProgressivePromise
  • D.以上都包括
• 答案：D
• 解析：在Netty這種異步NIO框架的結構下，服務端與客戶端通信過程中，高效、頻繁、大量的寫入大塊數據時，因網絡傳輸飽和的可能性就會造成數據處理擁堵、GC頻繁、用戶掉線的可能性。那麼由於寫操作是非阻塞的，所以即使沒有寫出所有的數據，寫操作也會在完成時返回並通知ChannelFuture。當這種情況發生時，如果仍然不停地寫入，就有內存耗盡的風險。所以在寫大塊數據時，需要對大塊數據進行切割發送處理。
• 詳細：https://bugstack.cn/md/netty/expand/2019-08-26-netty%E6%A1%88%E4%BE%8B%EF%BC%8Cnetty4.1%E4%B8%AD%E7%BA%A7%E6%8B%93%E5%B1%95%E7%AF%87%E5%8D%81%E4%B8%80%E3%80%8ANetty%E5%9F%BA%E4%BA%8EChunkedStream%E6%95%B0%E6%8D%AE%E6%B5%81%E5%88%87%E5%9D%97%E4%BC%A0%E8%BE%93%E3%80%8B.html

9. 實戰項目（81~90）

01：分佈式下保證冪等性實現

• 選項：
  • A.Redis setNx 實現
  • B.JDK Lock 鎖
  • C.數據庫唯一索引
  • D.以上都是
• 答案：C
• 解析：在編程中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。而分佈式環境下JDK Lock 鎖只能保證當前實例加鎖，但服務下的其他實例是沒法保證的。而像一些交易、金融、賬務等場景也都不敢使用 Redis setNx 實現，基本還是需要數據庫唯一索引來限定。
• 詳細：https://bugstack.cn/md/project/lottery/Part-2/%E7%AC%AC11%E8%8A%82%EF%BC%9A%E5%A3%B0%E6%98%8E%E4%BA%8B%E5%8A%A1%E9%A2%86%E5%8F%96%E6%B4%BB%E5%8A%A8%E9%A2%86%E5%9F%9F%E5%BC%80%E5%8F%91.html

02：什麼情況下分庫分表

• 選項：
  • A.TPS、QPS、GMV、PV、UV等數據指標，增速較快
  • B.數據增量很大，數據庫連接數擴容不能滿足
  • C.存量數據較大，熱數據不多
  • D.單體應用承載了過多的業務訴求，業務又增量加快
• 答案：A、B、D
• 解析：對於存量數據較大，但熱數據訪問不多的情況下，大部分是通過遷移來解決，而不是引入分庫分表提高系統的開發成本來處理。
• 詳細：https://bugstack.cn/md/zsxq/material/interview.html

03：商品秒殺獨佔競態鎖

• 選項：
  • A.可能發生死鎖的風險
  • B.比較適合優化爲分段靜態的滑塊鎖
  • C.導致商品庫存超賣
  • D.客戶發現有庫存但不能參與
• 答案：A、B、D
• 解析：獨佔競態鎖比較容易發生死鎖的風險，所以會導致用戶發現有庫存但不能參與，可以使用分段滑塊鎖進行優化。但這不是導致超賣，只會少賣。
• 詳細：https://bugstack.cn/md/develop/standard/2021-01-10-%E6%8F%A1%E8%8D%89%EF%BC%8C%E8%BF%99%E4%BA%9B%E7%A0%94%E5%8F%91%E4%BA%8B%E6%95%8530%E6%88%91%E9%83%BD%E5%B9%B2%E8%BF%87%EF%BC%81.html#_2-%E6%8A%80%E6%9C%AF%E6%96%B9%E6%A1%88%E5%AE%9E%E7%8E%B0%E7%B1%BB

04：抽獎概率 0.0000001 很小如何設計

• 選項：
  • A.採用 Redis 存放一個對應概率碼
  • B.建立一個超大的 HashMap 存放
  • C.通過雙色球設計，每個爲數是一組數字的組合
  • D.與運營溝通，調整方案
• 答案：A、C、D
• 解析：對於抽獎系統有時候運營會需要一些極小的概率的獎品，保持有但基本中不了。對於這樣的情況實現方式還是蠻多的，比如開獎多少次後才投放，或者就是提供概率。而概率又太大，所以要進行一些設計比如 Redis 提供一個對應的概率碼，或者雙色球每一個位置又是N種組合。但不太合適建一個重大的 HashMap 來存放。
• 詳細：https://bugstack.cn/md/zsxq/material/interview.html

05：多種類型抽獎策略如何註冊

• 選項：
  • A.構造注入
  • B.方法注入 @Bean
  • C.List注入
  • D.Map注入
• 答案：A、B、C
• 解析：對於使用策略模式實現的多種獎品組合，如果希望結合工廠模式提供服務，那麼怎麼維護對象的注入呢？這裏可以使用構造注入、方法注入和 List注入，但不太適合 Map 注入，因爲在不擴展 Spring 的情況下，Map 沒法匹配到你對應每一個方法的 Key 值。
• 詳細：https://bugstack.cn/md/project/lottery/Part-2/%E7%AC%AC07%E8%8A%82%EF%BC%9A%E7%AE%80%E5%8D%95%E5%B7%A5%E5%8E%82%E6%90%AD%E5%BB%BA%E5%8F%91%E5%A5%96%E9%A2%86%E5%9F%9F.html

06：A/BTest 用途

• 選項：
  • A.形成數據對照
  • B.量化數據分析
  • C.運營策略對比
  • D.以上都是
• 答案：D
• 解析：A/B testing（以下簡稱 AB test）可以說是統計學和計算機科學相融合的產物，在互聯網圈子中有着舉足輕重的地位，各大科技巨頭要做產品研發、數據分析都離不開使用 A/B Test 做對照組。
• 詳細：https://bugstack.cn/md/project/lottery/introduce/Lottery%E6%8A%BD%E5%A5%96%E7%B3%BB%E7%BB%9F.html

07：MySQL 應用連接數配置

• 選項：
  • A.總應用數 * 活躍連接數 < MySQL 可分配連接數
  • B.總應用數 * 最大連接數 < MySQL 可分配連接數
  • C.總應用數 * 空閒連接數 < MySQL 可分配連接數
  • D.以上都可以
• 答案：B
• 解析：分佈式服務所有配置的連接池最大連接數綜合要小於MySQL 分配的連接數，否則在流量上來以後會拖垮數據庫。
• 詳細：https://bugstack.cn/md/develop/standard/2021-01-10-%E6%8F%A1%E8%8D%89%EF%BC%8C%E8%BF%99%E4%BA%9B%E7%A0%94%E5%8F%91%E4%BA%8B%E6%95%8530%E6%88%91%E9%83%BD%E5%B9%B2%E8%BF%87%EF%BC%81.html#_3-%E6%8A%80%E6%9C%AF%E6%9C%8D%E5%8A%A1%E4%BD%BF%E7%94%A8%E7%B1%BB

08：高併發下提供給前端H5分頁

• 選項：
  • A.limit x,y
  • B.where id > ? limit x
  • C.以上都可以
• 答案：B
• 解析：對於給前端 H5 提供的接口帶有分頁，要考慮性能，不能直接就 limit x,y 這樣在大批量查詢數據的時候會拖垮數據庫，起不到索引的作用。所以要使用 where id > ? limit x 這樣方式進行分頁。
• 詳細：https://bugstack.cn/md/project/lottery/Part-4/%E7%AC%AC01%E8%8A%82%EF%BC%9A%E6%90%AD%E5%BB%BA%E5%BE%AE%E4%BF%A1%E5%85%AC%E4%BC%97%E5%8F%B7%E7%BD%91%E5%85%B3%E6%9C%8D%E5%8A%A1.html

09：項目運行較慢，重啓後就好了

• 選項：
  • A.應用服務不足
  • B.定時任務跑批
  • C.IO密集型運算
  • D.以上都是
• 答案：D
• 解析：服務運行慢重啓就好，一般是服務數量不足，IO運算大，或者有定時任務，因爲你重啓這些業務短暫時間是與你斷開連接了，所以速度好像快了。但實際治標不治本，需要優化服務。
• 詳細：https://bugstack.cn/md/develop/standard/2021-09-15-%E8%BF%98%E9%87%8D%E6%9E%84%EF%BC%9F%E5%B0%B1%E4%BD%A0%E9%82%A3%E4%BB%A3%E7%A0%81%E5%8F%AA%E8%83%BD%E9%93%B2%E4%BA%86%E9%87%8D%E5%86%99%EF%BC%81.html

10：分庫分表數據如何彙總查詢(給C端用戶使用)

• 選項：
  • A.通過編寫聯合查詢多庫的SQL
  • B.從每個庫表查詢到內存中彙總
  • C.通過binlog同步到ES，從ES查詢
  • D.以上都可以
• 答案：C
• 解析：通常在分佈式服務中會使用分庫分表承擔較大的數據體量，但給C端的查詢，基本不會使用複雜的 SQL 查詢，更不會關聯多個庫表，這樣會拖垮數據庫。基本合理的方式是C端查詢在有路由字段的時候都是查指定庫表，直接提供返回即可。而如果是彙總類查詢則需要基於 binlog 把分庫分表數據同步到 ES 查詢使用。
• 詳細：https://bugstack.cn/md/project/lottery/Part-5/%E7%AC%AC07%E8%8A%82%EF%BC%9A%E9%83%A8%E7%BD%B2%E7%8E%AF%E5%A2%83%20Elasticsearch%E3%80%81Kibana.html

10. 擴展問題（91~100）

01：常用的繪圖工具

• 選項：
  • A.xmind
  • B.visio
  • C.draw.io
  • D.Workbench
• 答案：A、B、C、D
• 解析：xmind、visio、draw.io、workbench
• 詳細：https://bugstack.cn/md/other/guide-to-reading.html

02：常用的開發工具

• 選項：
  • A.IntelliJ IDEA
  • B.Navicat
  • C.Docker
  • D.JD-GUI
  • E.RDM
  • F.Postman
• 答案：A、B、C、D、E、F
• 解析：常用工具系列；IntelliJ IDEAJ、Navicat、Docker、JD-GUI、RDM、Postman
• 詳細：https://bugstack.cn/md/other/guide-to-reading.html

03：UML 類圖，實現的畫法

• 選項：
  • A.虛線空心箭頭
  • B.虛線實心箭頭
  • C.實線空心箭頭
  • D.實線實心箭頭
• 答案：A
• 解析：實現接口的畫法是虛線空心箭頭，其他的可以參考詳細文檔
• 詳細：https://bugstack.cn/md/about/study/2020-10-18-UML%E7%B1%BB%E5%9B%BE%E8%BF%98%E4%B8%8D%E6%87%82%EF%BC%9F%E6%9D%A5%E7%9C%8B%E7%9C%8B%E8%BF%99%E7%89%88%E4%B9%A1%E6%9D%91%E7%88%B1%E6%83%85%E7%B1%BB%E5%9B%BE%EF%BC%8C%E4%B8%80%E6%8A%8A%E5%AD%A6%E4%BC%9A%EF%BC%81.html

04：樹上10只鳥開一槍還剩下幾隻，你會想到什麼？

• 選項：
  • A.手搶是無聲的嗎？
  • B.有沒有被關在籠子裏或者綁在樹上的鳥？
  • C.有殘疾或者飛不動的鳥嗎？
  • D.會不會一槍打死兩隻或者更多？
  • E.所有的鳥都可以自由活動飛離樹以外嗎？
  • F.打死以後掛在樹上還是掉下來了？
  • G.確定那隻鳥被打死了？
  • H.這個城市打鳥犯不犯法？
• 答案：A、B、C、D、E、F、G、H
• 解析：這是一到考察思路的題，基本就看你能對一個項目的開發前，能考慮到哪些點。
• 詳細：https://bugstack.cn/md/about/job/2020-11-15-BATJTMD%EF%BC%8C%E5%A4%A7%E5%8E%82%E6%8B%9B%E8%81%98%EF%BC%8C%E9%83%BD%E6%8B%9B%E4%BB%80%E4%B9%88%E6%A0%B7Java%E7%A8%8B%E5%BA%8F%E5%91%98%EF%BC%9F.html

05：想把代碼寫好，都要包括哪些東西

• 選項：
  • A.數據結構
  • B.算法邏輯
  • C.設計模式
  • D.系統架構
• 答案：A、B、C、D
• 解析：對於能寫好代碼從設計上來說，會包括對庫表的設計（數據結構），功能的實現（算法邏輯），設計模式和架構。所有的代碼邏輯也都是對數學邏輯的具體實現。
• 詳細：https://bugstack.cn/md/about/study/2021-01-17-%E6%95%B0%E5%AD%A6%EF%BC%8C%E7%A6%BB%E4%B8%80%E4%B8%AA%E7%A8%8B%E5%BA%8F%E5%91%98%E6%9C%89%E5%A4%9A%E8%BF%91%EF%BC%9F.html

06：如何保證需求如期交付？

• 選項：
  • A.從產品的BRD到PRD階段開始確定預期上線時間
  • B.產品、UI設計、測試、研發、交付、預發、上線等時間線規劃
  • C.每天一個固定時間開項目進度敏捷站會，對其進度，評估風險
  • D.如果是突然加需求，調整PRD等，那麼需要重新進行資源協調。
• 答案：A、B、C、D
• 解析：爲了保證項目的如期交付和交付質量，互聯網中會從產品的BRD、PRD、研發設計、開發、測試等各個環節進行把控。
• 詳細：https://bugstack.cn/md/zsxq/material/architecture_design.html

07：什麼是併發，什麼是並行？

• 選項：
  • A.併發：是指如何正確、高校地控制共享資源；
  • B.並行：是指如何利用更多的資源來產生高快速的響應；
  • C.並行：是指如何正確、高校地控制共享資源；
  • D.併發：是指如何利用更多的資源來產生高快速的響應；
• 答案：A、B
• 解析：其實有一大部分研發人員，搞不懂什麼是併發編程，甚至常把併發編程和分佈式聯繫起來。但很多的分佈式架構設計，並不是在壓榨一臺機器的性能做IO密集型運算，所以如；併發、並行、多任務、多進程、多線程、分佈式系統等，很多術語在大量的編程資料中被濫用了。
• 詳細：https://bugstack.cn/md/about/study/2022-06-19-OnJava.html#%E5%9B%9B%E3%80%81%E6%B7%B1%E5%BA%A6-%E9%80%8F%E6%9E%90%E5%8E%9F%E7%90%86

08：你覺得怎樣編碼更合理

• 選項：
  • A.先運行起來再優化性能
  • B.小心冗長的參數列表
  • C.不要通過子類來擴展基礎功能
  • D.使用設計模式消除”裸功能“
• 答案：A、B、C、D
• 解析：在 On Java 一書中介紹了編碼指南和實現意見，這些也都是程序員在編碼多年的經驗和習慣。
• 詳細：https://bugstack.cn/md/about/study/2022-06-19-OnJava.html#%E4%BA%94%E3%80%81%E6%8C%87%E5%8D%97-%E5%B7%A8%E4%BD%AC%E7%BB%8F%E9%AA%8C

09：你覺得我們的面試爲什麼像造火箭？

• 選項：
  • A.因爲面試官對我不瞭解，所以需要提出一些質疑的問題，通過我的回答瞭解我。
  • B.過橋的時候都不需要手扶着橋墩，但沒有橋墩的橋，誰也不敢上橋。而多問的那些問題，是在考察我的邊界在那裏，能給企業帶來多少種可能。
  • C.應對緊急複雜場景時可以快速反應，哪怕它可能只是萬分之一的出現概率。但那也是我驗證能力的機會。
  • D.爲團隊增加各類有高度的技術專才，形成團隊技術力，獲取更多的話語權和接項目的能力。
• 答案：A、B、C、D
• 解析：大部分研發都覺得面試像造火箭，但站在面試公司的角度，畢竟是對求職責不瞭解，所以要通過一些質疑和問題來了解求職者的技術廣度和工程開發經驗。
• 詳細：https://bugstack.cn/md/about/job/2021-02-24-%E5%8D%8A%E5%B9%B4%E7%AD%9B%E9%80%89%E4%BA%86400+%E4%BB%BD%E7%AE%80%E5%8E%86%EF%BC%8C%E5%91%8A%E8%AF%89%E4%BD%A0%E6%80%8E%E4%B9%88%E5%86%99%E4%BC%9A%E8%A2%AB%E6%92%A9.html