大家好，我是小林。

今天分享一位讀者的騰訊春招實習面經，崗位Java后端，主要問了MySQL、Java、網絡這三大塊。

他覺得這場面試非常有收獲，雖然都是基礎問題，但是往下深挖根莖葉脈全部相連。反問環節面試官給了我很多建議，包括面試、策略、基礎、算法等等，是一次寶貴的學習經歷。

MySQL

介紹一下MySQL的索引機制

索引可以幫助我們快速搜索數據，innodb 存儲引擎用的是 b+樹索引，葉子節點存放的是索引+數據，非葉子節點只存放索引。

可以按照四個角度來分類索引。

• 按「數據結構」分類：B+tree索引、Hash索引、Full-text索引。
• 按「物理存儲」分類：聚簇索引（主鍵索引）、二級索引（輔助索引）。
• 按「字段特性」分類：主鍵索引、唯一索引、普通索引、前綴索引。
• 按「字段個數」分類：單列索引、聯合索引。

聯合索引是什么？

通過將多個字段組合成一個索引，該索引就被稱為聯合索引。

比如，將商品表中的 product_no 和 name 字段組合成聯合索引(product_no, name)，創建聯合索引的方式如下：

CREATE INDEX index_product_no_name ON product(product_no, name);

聯合索引(product_no, name) 的 B+Tree 示意圖如下（圖中葉子節點之間我畫了單向鏈表，但是實際上是雙向鏈表，原圖我找不到了，修改不了，偷個懶我不重畫了，大家腦補成雙向鏈表就行）。

聯合索引

可以看到，聯合索引的非葉子節點用兩個字段的值作為 B+Tree 的 key 值。當在聯合索引查詢數據時，先按 product_no 字段比較，在 product_no 相同的情況下再按 name 字段比較。

也就是說，聯合索引查詢的 B+Tree 是先按 product_no 進行排序，然后再 product_no 相同的情況再按 name 字段排序。

因此，使用聯合索引時，存在最左匹配原則，也就是按照最左優先的方式進行索引的匹配。在使用聯合索引進行查詢的時候，如果不遵循「最左匹配原則」，聯合索引會失效，這樣就無法利用到索引快速查詢的特性了。

什么是聚簇索引？

聚簇索引的 B+Tree 的葉子節點存放的是實際數據，所有完整的用戶記錄都存放在主鍵索引的 B+Tree 的葉子節點里。

什么是覆蓋索引？

在查詢時使用了二級索引，如果查詢的數據能在二級索引里查詢的到，那么就不需要回表，這個過程就是覆蓋索引。如果查詢的數據不在二級索引里，就會先檢索二級索引，找到對應的葉子節點，獲取到主鍵值后，然后再檢索主鍵索引，就能查詢到數據了，這個過程就是回表。

整個索引查詢的過程是怎樣的？

InnoDB 里的 B+ 樹中的每個節點都是一個數據頁，結構示意圖如下：

B+ 樹如何實現快速查找主鍵為 6 的記錄，以上圖為例子：

• 從根節點開始，通過二分法快速定位到符合頁內范圍包含查詢值的頁，因為查詢的主鍵值為 6，在[1, 7)范圍之間，所以到頁 30 中查找更詳細的目錄項；
• 在非葉子節點（頁30）中，繼續通過二分法快速定位到符合頁內范圍包含查詢值的頁，主鍵值大于 5，所以就到葉子節點（頁16）查找記錄；
• 接著，在葉子節點（頁16）中，通過槽查找記錄時，使用二分法快速定位要查詢的記錄在哪個槽（哪個記錄分組），定位到槽后，再遍歷槽內的所有記錄，找到主鍵為 6 的記錄。

可以看到，在定位記錄所在哪一個頁時，也是通過二分法快速定位到包含該記錄的頁。定位到該頁后，又會在該頁內進行二分法快速定位記錄所在的分組（槽號），最后在分組內進行遍歷查找。

事務的隔離級別有哪些？

• 讀未提交，指一個事務還沒提交時，它做的變更就能被其他事務看到；
• 讀提交，指一個事務提交之后，它做的變更才能被其他事務看到；
• 可重復讀，指一個事務執行過程中看到的數據，一直跟這個事務啟動時看到的數據是一致的，MySQL InnoDB 引擎的默認隔離級別；
• 串行化；會對記錄加上讀寫鎖，在多個事務對這條記錄進行讀寫操作時，如果發生了讀寫沖突的時候，后訪問的事務必須等前一個事務執行完成，才能繼續執行；

臟讀、幻讀、不可重讀分別是什么意思？

• 臟讀：如果一個事務「讀到」了另一個「未提交事務修改過的數據」，就意味著發生了「臟讀」現象。
• 幻讀：在一個事務內多次查詢某個符合查詢條件的「記錄數量」，如果出現前后兩次查詢到的記錄數量不一樣的情況，就意味著發生了「幻讀」現象。
• 不可重復讀：在一個事務內多次讀取同一個數據，如果出現前后兩次讀到的數據不一樣的情況，就意味著發生了「不可重復讀」現象。

InnoDB 多版本并發控制的具體原理，底層細節？

對于「讀提交」和「可重復讀」隔離級別的事務來說，它們是通過 Read View 來實現的，它們的區別在于創建 Read View 的時機不同，大家可以把 Read View 理解成一個數據快照，就像相機拍照那樣，定格某一時刻的風景。

• 「讀提交」隔離級別是在「每個select語句執行前」都會重新生成一個 Read View；
• 「可重復讀」隔離級別是執行第一條select時，生成一個 Read View，然后整個事務期間都在用這個 Read View。

Read View 有四個重要的字段：

• m_ids ：指的是在創建 Read View 時，當前數據庫中「活躍事務」的事務 id 列表，注意是一個列表，“活躍事務”指的就是，啟動了但還沒提交的事務。
• min_trx_id ：指的是在創建 Read View 時，當前數據庫中「活躍事務」中事務 id 最小的事務，也就是 m_ids 的最小值。
• max_trx_id ：這個并不是 m_ids 的最大值，而是創建 Read View 時當前數據庫中應該給下一個事務的 id 值，也就是全局事務中最大的事務 id 值 + 1；
• creator_trx_id ：指的是創建該 Read View 的事務的事務 id。

對于使用 InnoDB 存儲引擎的數據庫表，它的聚簇索引記錄中都包含下面兩個隱藏列：

• trx_id，當一個事務對某條聚簇索引記錄進行改動時，就會把該事務的事務 id 記錄在 trx_id 隱藏列里；
• roll_pointer，每次對某條聚簇索引記錄進行改動時，都會把舊版本的記錄寫入到 undo 日志中，然后這個隱藏列是個指針，指向每一個舊版本記錄，于是就可以通過它找到修改前的記錄。

在創建 Read View 后，我們可以將記錄中的 trx_id 劃分這三種情況：

一個事務去訪問記錄的時候，除了自己的更新記錄總是可見之外，還有這幾種情況：

• 如果記錄的 trx_id 值小于 Read View 中的 min_trx_id 值，表示這個版本的記錄是在創建 Read View 前已經提交的事務生成的，所以該版本的記錄對當前事務可見。
• 如果記錄的 trx_id 值大于等于 Read View 中的 max_trx_id 值，表示這個版本的記錄是在創建 Read View 后才啟動的事務生成的，所以該版本的記錄對當前事務不可見。
• 如果記錄的 trx_id 值在 Read View 的 min_trx_id 和 max_trx_id 之間，需要判斷 trx_id 是否在 m_ids 列表中：

• 如果記錄的 trx_id 在 m_ids 列表中，表示生成該版本記錄的活躍事務依然活躍著（還沒提交事務），所以該版本的記錄對當前事務不可見。
• 如果記錄的 trx_id 不在 m_ids列表中，表示生成該版本記錄的活躍事務已經被提交，所以該版本的記錄對當前事務可見。

這種通過「版本鏈」來控制并發事務訪問同一個記錄時的行為就叫 MVCC（多版本并發控制）。

next Key是什么，怎么實現？

Next-Key Lock 稱為臨鍵鎖，是 Record Lock + Gap Lock 的組合，鎖定一個范圍，并且鎖定記錄本身。

假設，表中有一個范圍 id 為（3，5] 的 next-key lock，那么其他事務即不能插入 id = 4 記錄，也不能修改 id = 5 這條記錄。

所以，next-key lock 即能保護該記錄，又能阻止其他事務將新紀錄插入到被保護記錄前面的間隙中。

索引失效的場景有哪些，你知道什么改進方法嗎？

• 當我們使用左或者左右模糊匹配的時候，也就是 like %xx 或者 like %xx%這兩種方式都會造成索引失效；
• 當我們在查詢條件中對索引列使用函數，就會導致索引失效。
• 當我們在查詢條件中對索引列進行表達式計算，也是無法走索引的。
• MySQL 在遇到字符串和數字比較的時候，會自動把字符串轉為數字，然后再進行比較。如果字符串是索引列，而條件語句中的輸入參數是數字的話，那么索引列會發生隱式類型轉換，由于隱式類型轉換是通過 CAST 函數實現的，等同于對索引列使用了函數，所以就會導致索引失效。
• 聯合索引要能正確使用需要遵循最左匹配原則，也就是按照最左優先的方式進行索引的匹配，否則就會導致索引失效。
• 在 WHERE 子句中，如果在 OR 前的條件列是索引列，而在 OR 后的條件列不是索引列，那么索引會失效。

提交事務的一整個過程，每個日志都是怎么工作的？

具體更新一條記錄 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:

1. 執行器負責具體執行，會調用存儲引擎的接口，通過主鍵索引樹搜索獲取 id = 1 這一行記錄：

如果 id=1 這一行所在的數據頁本來就在 buffer pool 中，就直接返回給執行器更新；

如果記錄不在 buffer pool，將數據頁從磁盤讀入到 buffer pool，返回記錄給執行器。

2. 執行器得到聚簇索引記錄后，會看一下更新前的記錄和更新后的記錄是否一樣：

如果一樣的話就不進行后續更新流程；

如果不一樣的話就把更新前的記錄和更新后的記錄都當作參數傳給 InnoDB 層，讓 InnoDB 真正的執行更新記錄的操作；

3. 開啟事務， InnoDB 層更新記錄前，首先要記錄相應的 undo log，因為這是更新操作，需要把被更新的列的舊值記下來，也就是要生成一條 undo log，undo log 會寫入 Buffer Pool 中的 Undo 頁面，不過在內存修改該 Undo 頁面后，需要記錄對應的 redo log。
4. InnoDB 層開始更新記錄，會先更新內存（同時標記為臟頁），然后將記錄寫到 redo log 里面，這個時候更新就算完成了。為了減少磁盤I/O，不會立即將臟頁寫入磁盤，后續由后臺線程選擇一個合適的時機將臟頁寫入到磁盤。這就是 WAL 技術，MySQL 的寫操作并不是立刻寫到磁盤上，而是先寫 redo 日志，然后在合適的時間再將修改的行數據寫到磁盤上。
5. 至此，一條記錄更新完了。
6. 在一條更新語句執行完成后，然后開始記錄該語句對應的 binlog，此時記錄的 binlog 會被保存到 binlog cache，并沒有刷新到硬盤上的 binlog 文件，在事務提交時才會統一將該事務運行過程中的所有 binlog 刷新到硬盤。
7. 事務提交（為了方便說明，這里不說組提交的過程，只說兩階段提交）：

prepare 階段：將 redo log 對應的事務狀態設置為 prepare，然后將 redo log 刷新到硬盤；

commit 階段：將 binlog 刷新到磁盤，接著調用引擎的提交事務接口，將 redo log 狀態設置為 commit（將事務設置為 commit 狀態后，刷入到磁盤 redo log 文件）；

8. 至此，一條更新語句執行完成。

Java

JVM內存區域 每一個區域的內容？

JVM的內存結構主要分為以下幾個部分：

• 程序計數器（Program Counter Register）：每個線程都有一個程序計數器。當線程執行 Java 方法時，程序計數器保存當前執行指令的地址，以便在 JVM 調用其他方法或恢復線程執行時重新回到正確的位置。
• Java 虛擬機棧（Java Virtual Machine Stacks）：每個線程都有一個虛擬機棧。虛擬機棧保存著方法執行期間的局部變量、操作數棧、方法出口等信息。線程每調用一個 Java 方法時，會創建一個棧幀（Stack Frame），棧幀包含著該方法的局部變量、操作數棧、方法返回地址等信息。棧幀在方法執行結束后會被彈出。
• 本地方法棧（Native Method Stack）：與 Java 虛擬機棧類似，但是為本地方法服務。
• Java 堆（Java Heap）：Java 堆是 Java 虛擬機中最大的一塊內存區域，用于存儲各種類型的對象實例，也是垃圾收集器的主要工作區域。Java 堆是所有線程共享的部分。
• 方法區（Method Area）：方法區也是所有線程共享的部分，它用于存儲類的加載信息、靜態變量、常量池、方法字節碼等數據。在 Java 8 及以前的版本中，方法區被實現為永久代（Permanent Generation），在 Java 8 中被改為元空間（Metaspace）。

JVM異常問題？

• StackOverflowError（線程請求棧深度超過虛擬機所允許的最大深度）
• OutOfMemoryError（堆內存不夠用）
• PermGen space（方法區內存不夠用）。

String保存在哪里呢

String 保存在字符串常量池中，不同于其他對象，它的值是不可變的，且可以被多個引用共享。

java版本改動問題 1.7 1.8有哪些主要區別？

• Java 7 新特性：鉆石操作符、try-with-resource語句、支持動態類型語言、Fork/Join框架等。
• Java 8 新特性：Lambda 表達式、Stream API、新的 Date/Time API、Nashorn JavaScript 引擎等。

怎么找到需要回收的垃圾？

Java中的垃圾回收機制通過判斷對象是否可達來確定哪些對象可以被回收。當一個對象沒有任何引用指向它時，它就可以被回收，這個過程由JVM的垃圾回收器自動完成。

JVM使用可達性分析算法來判斷對象是否可達。從GC Roots對象開始，通過一系列的引用鏈來遍歷所有的對象，如果一個對象不可達，則說明它已經死亡，可以被回收了。

在Java中，有4種引用類型：強引用、軟引用、弱引用和虛引用。其中，強引用是最常見的引用類型，只要強引用存在，垃圾回收器就不會回收該對象。軟引用、弱引用和虛引用則分別表示對對象的軟引用、弱引用和虛引用，當垃圾回收器進行垃圾回收時，會根據不同的引用類型來決定是否回收對象。

有哪些常見的垃圾回收器，舉幾個說說？

1. Serial收集器：單線程的垃圾回收器，使用標記-復制算法，適合小型應用程序或客戶端應用程序。
2. Parallel收集器：多線程的垃圾回收器，使用標記-復制算法，適合在后臺運行的中型應用程序。
3. CMS收集器：并發垃圾回收器，使用標記-清除算法，適合對響應時間有要求的中型應用程序。
4. G1收集器：并發垃圾回收器，使用標記-整理算法，適合對響應時間有要求且堆內存較大的應用程序。

其中，Serial收集器和Parallel收集器是新生代收集器，CMS和G1是老年代收集器。

HashMap底層怎么實現的 ？線程安全嗎？

HashMap底層是基于數組和鏈表實現的。簡單來說，HashMap將key通過hash算法映射到數組中，然后在對應的鏈表中查找value。當多個key的hash值相同時，會在同一個數組位置上使用鏈表來存儲這些key-value。但是，當鏈表長度太長時，會影響HashMap的性能，因此在JDK1.8中，當鏈表長度超過閾值時，會將鏈表轉換為紅黑樹，以提高查找效率。

HashMap不是線程安全的，因為多個線程同時訪問HashMap時可能會導致數據不一致的問題。可以使用ConcurrentHashMap來實現線程安全的Map。

紅黑樹是什么？

紅黑樹是一種自平衡的二叉查找樹，可以保證在最壞情況下基本動態操作的時間復雜度為O(log n)。紅黑樹中的每個節點都有一個顏色屬性，可以是紅色或黑色。紅黑樹滿足以下5個性質：

1. 每個節點要么是紅色，要么是黑色。
2. 根節點是黑色的。
3. 每個葉子節點（NIL節點，空節點）是黑色的。
4. 如果一個節點是紅色的，則它的兩個子節點都是黑色的。
5. 對于每個節點，從該節點到其所有后代葉子節點的簡單路徑上，均包含相同數目的黑色節點。

通過這些性質，紅黑樹可以保證在插入和刪除節點時，自動調整樹的結構，以保持樹的平衡和性質的滿足。相比于普通的二叉查找樹，紅黑樹的平衡性更好，查找、插入和刪除都具有更穩定的時間復雜度，因此在很多場景下被廣泛應用。

什么是公平鎖和非公平鎖？

公平鎖和非公平鎖是針對鎖的獲取方式而言的。

公平鎖是指多個線程按照申請鎖的順序來獲取鎖，即先到先得的原則。當線程A釋放鎖后，線程B、C、D依次獲取鎖，如果此時線程E申請鎖，則它需要等待B、C、D依次獲取到鎖并釋放鎖后才能獲取鎖。

非公平鎖是指多個線程獲取鎖的順序是隨機的，不保證公平性。當線程A釋放鎖后，線程B、C、D等線程都可以通過競爭獲取到鎖，而此時線程E也可以通過競爭獲取到鎖。

在實際應用中，公平鎖可以避免饑餓現象，但是由于需要維護線程隊列，因此效率相對較低。而非公平鎖由于不需要維護線程隊列，因此效率相對較高，但是可能會導致某些線程長時間無法獲取鎖。

ThreadLocal 是什么？

ThreadLocal是Java中的一個線程封閉技術，它可以讓每個線程都擁有自己單獨的變量副本，從而保證線程安全。ThreadLocal提供了一種線程本地存儲的機制，為每個線程提供一個獨立的變量副本，使得每個線程中的變量互不干擾。

計算機網絡

TCP 三次握手、四次揮手的過程？

三次握手的過程：

TCP 三次握手

• 一開始，客戶端和服務端都處于 CLOSE 狀態。先是服務端主動監聽某個端口，處于 LISTEN 狀態
• 客戶端會隨機初始化序號（client_isn），將此序號置于 TCP 首部的「序號」字段中，同時把 SYN 標志位置為 1，表示 SYN 報文。接著把第一個 SYN 報文發送給服務端，表示向服務端發起連接，該報文不包含應用層數據，之后客戶端處于 SYN-SENT 狀態。
• 服務端收到客戶端的 SYN 報文后，首先服務端也隨機初始化自己的序號（server_isn），將此序號填入 TCP 首部的「序號」字段中，其次把 TCP 首部的「確認應答號」字段填入 client_isn + 1, 接著把 SYN 和 ACK 標志位置為 1。最后把該報文發給客戶端，該報文也不包含應用層數據，之后服務端處于 SYN-RCVD 狀態。
• 客戶端收到服務端報文后，還要向服務端回應最后一個應答報文，首先該應答報文 TCP 首部 ACK 標志位置為 1 ，其次「確認應答號」字段填入 server_isn + 1 ，最后把報文發送給服務端，這次報文可以攜帶客戶到服務端的數據，之后客戶端處于 ESTABLISHED 狀態。
• 服務端收到客戶端的應答報文后，也進入 ESTABLISHED 狀態。

四次揮手的過程：

• 客戶端打算關閉連接，此時會發送一個 TCP 首部 FIN 標志位被置為 1 的報文，也即 FIN 報文，之后客戶端進入 FIN_WAIT_1 狀態。
• 服務端收到該報文后，就向客戶端發送 ACK 應答報文，接著服務端進入 CLOSE_WAIT 狀態。
• 客戶端收到服務端的 ACK 應答報文后，之后進入 FIN_WAIT_2 狀態。
• 等待服務端處理完數據后，也向客戶端發送 FIN 報文，之后服務端進入 LAST_ACK 狀態。
• 客戶端收到服務端的 FIN 報文后，回一個 ACK 應答報文，之后進入 TIME_WAIT 狀態
• 服務端收到了 ACK 應答報文后，就進入了 CLOSE 狀態，至此服務端已經完成連接的關閉。
• 客戶端在經過 2MSL 一段時間后，自動進入 CLOSE 狀態，至此客戶端也完成連接的關閉。

為什么要三次握手、四次揮手？

三次握手的原因：

• 三次握手可以阻止重復歷史連接的初始化
• 三次握手可以同步雙方的初始序列號
• 三次握手可以避免資源浪費

四次次揮手的原因：

• 服務端通常需要等待完成數據的發送和處理，所以服務端的 ACK 和 FIN 一般都會分開發送，因此是需要四次揮手。

LINUX有哪些IO機制？

• 阻塞IO（Blocking IO）：應用程序在進行IO操作時，會一直阻塞等待IO完成，期間無法進行其他操作。
• 非阻塞IO（Non-blocking IO）：應用程序在進行IO操作時，會立即返回，無論IO操作是否完成，應用程序都可以進行其他操作。需要通過輪詢的方式來判斷IO是否完成，因此效率較低。
• IO多路復用（IO Multiplexing）：通過select、poll、epoll等系統調用，在一個進程中可以同時監控多個文件描述符，當有任何一個文件描述符就緒時，就可以進行IO操作。
• 信號驅動IO（Signal Driven IO）：應用程序在進行IO操作時，向內核注冊一個信號處理函數，內核在IO完成時會向應用程序發送一個信號，應用程序收到信號后再進行數據處理。
• 異步IO（Asynchronous IO）：應用程序進行IO操作時，可以立即返回，內核負責將數據讀取到指定的緩沖區中，并在完成后通知應用程序，應用程序可以繼續進行其他操作。異步IO需要操作系統和硬件的支持，目前主要應用于高性能IO場景。

select poll epoll，底層實現有什么區別？

select 和 poll 并沒有本質區別，它們內部都是使用「線性結構」來存儲進程關注的 Socket 集合。

在使用的時候，首先需要把關注的 Socket 集合通過 select/poll 系統調用從用戶態拷貝到內核態，然后由內核檢測事件，當有網絡事件產生時，內核需要遍歷進程關注 Socket 集合，找到對應的 Socket，并設置其狀態為可讀/可寫，然后把整個 Socket 集合從內核態拷貝到用戶態，用戶態還要繼續遍歷整個 Socket 集合找到可讀/可寫的 Socket，然后對其處理。

很明顯發現，select 和 poll 的缺陷在于，當客戶端越多，也就是 Socket 集合越大，Socket 集合的遍歷和拷貝會帶來很大的開銷，因此也很難應對 C10K。

epoll 是解決 C10K 問題的利器，通過兩個方面解決了 select/poll 的問題。

• epoll 在內核里使用「紅黑樹」來關注進程所有待檢測的 Socket，紅黑樹是個高效的數據結構，增刪改一般時間復雜度是 O(logn)，通過對這棵黑紅樹的管理，不需要像 select/poll 在每次操作時都傳入整個 Socket 集合，減少了內核和用戶空間大量的數據拷貝和內存分配。
• epoll 使用事件驅動的機制，內核里維護了一個「鏈表」來記錄就緒事件，只將有事件發生的 Socket 集合傳遞給應用程序，不需要像 select/poll 那樣輪詢掃描整個集合（包含有和無事件的 Socket ），大大提高了檢測的效率。

BIO 和 NIO 的區別？

Java中，BIO和NIO都是IO模型，它們的主要區別在于：

• 阻塞和非阻塞：BIO采用阻塞模式，即在進行IO操作時，線程會一直阻塞等待IO完成。而NIO采用非阻塞模式，即在進行IO操作時，線程會立即返回，無論IO操作是否完成，線程都可以進行其他操作。
• IO模型：BIO采用同步阻塞IO模型，即一個線程只能處理一個連接，當有大量連接時，需要大量的線程來處理，會導致系統資源浪費。NIO采用同步非阻塞IO模型，將客戶端發送的連接請求都會注冊到多路復用器上，這樣一個線程可以處理多個連接，當有大量連接時，只需要少量的線程來處理，可以有效地提高系統資源利用率。

算法

鏈表判斷相交

public ListNode getIntersectionNode(ListNode headA, ListNode headB) {
    if (headA == null || headB == null) return null;
    ListNode pA = headA, pB = headB;
    while (pA != pB) {
        pA = pA == null ? headB : pA.next;
        pB = pB == null ? headA : pB.next;
    }
    return pA;
}

面試總結

感覺

非常有收獲的一次面試，值得之后自己單獨寫一寫文章去記錄一下。基礎不牢地動山搖，雖然都是基礎問題，但是往下深挖根莖葉脈全部相連，這些問題面試題里面都有解，但是自己真的是只知道表面，淺淺看個大概就上戰場了，還有就是非常感謝面試官，反問環節給了我很多建議，包括面試、策略、基礎、算法等等，是一次寶貴的學習經歷，說不遺憾是假的，但我很開心，有所收獲就好。

不足之處

基礎不夠扎實，很多只知其表不知其里，而且面試官經驗豐富，非常敏銳，當時壓力也很大，被問倒了心態也不穩，有的可以答出來的也沒想起來怎么說。

沒有幾個答的特別好的，稍微說一點就會被問深直到不會，這里就不貼當時回答了，說的都很淺，下來每一個問題都要仔細研究，要將知識連接成網。

自己給自己構造一個場景，順著把用到的技術全部梳理一遍，能講出這個整體過程，有頭有尾，才能真的理解，比如hashmap插入數據的過程、threadlocal創建釋放的過程、String怎么實現的字符串拼接、SpringBoot框架搭建的每一步等等。