【面經(jīng)分享，附答案】字節(jié)系統(tǒng)架構(gòu)，一面，后端開發(fā)

以后發(fā)面經(jīng)我都會盡量帶上我的答案（藍色引用框中的就是），不過不會寫得那么詳細，大概就是寫一下如果我答的話具體邏輯是怎么樣的，關(guān)鍵詞啥的。有些我覺得不是很常見或者暫時不知道咋回答的題目，會加粗顯示出來，也歡迎小伙伴們和我交流

今日面經(jīng)來源：https://www.nowcoder.com/discuss/985106

一面

總結(jié)：完全沒有問項目問題，計算機網(wǎng)絡部分問的特別細！死問我數(shù)據(jù)鏈路層的傳輸原理，答得磕磕絆絆，有好些題都沒有答得很好，算法題倒是挺簡單的，最后反問，面試官說我答得挺好的，但有些地方細節(jié)上還需要再學習優(yōu)化下。

1）HTTP 三次握手，狀態(tài)碼，交互細節(jié)

HTTP 三次握手就是 TCP 三次握手，HTTP 是應用層協(xié)議，它的任務是與服務器交換信息。至于怎么連到服務器，怎么保證數(shù)據(jù)正確，HTTP 不管。事實上它總是假設數(shù)據(jù)是正確地傳輸?shù)摹?/p>

而 TCP 的任務是保證連接的可靠，包括防丟、防錯。為了做到這些，在初次連接時要進行3次握手，以保證確實連接到了目標機器。而連接上后具體傳送什么數(shù)據(jù)，TCP 是不管的

狀態(tài)碼：1xx 信息類提示，2xx 請求成功，3xx 請求重定向，4xx 服務器異常，5xx 客戶端異常

交互細節(jié)應該就是 TCP 三次握手

2）為什么要三次握手

3）四次揮手，狀態(tài)碼，傳輸細節(jié)，為什么握手要三次，揮手要四次

4）數(shù)據(jù)鏈路層怎么傳輸數(shù)據(jù)的，展開說說

5）ARP 協(xié)議中網(wǎng)關(guān)怎么去轉(zhuǎn)換 IP 地址到對應 MAC 地址的

關(guān)鍵點：ARP 高速緩存、廣播 ARP 請求報文、ARP 響應報文

6）如果數(shù)據(jù)包不在當前子網(wǎng)內(nèi)，怎么傳輸?shù)侥繕俗泳W(wǎng)網(wǎng)關(guān)的

首先，如何判斷這個數(shù)據(jù)包的目標 IP 地址和當前主機的 IP 地址是否在同一子網(wǎng)（網(wǎng)段）內(nèi)？利用子網(wǎng)掩碼可以判斷兩臺主機是否中同一子網(wǎng)中。若兩臺主機的 IP 地址分別與它們的子網(wǎng)掩碼相 “與” 后的結(jié)果相同，則說明這兩臺主機在同一子網(wǎng)中。

其次，網(wǎng)關(guān)到底是什么呢？網(wǎng)關(guān)實質(zhì)上是一個網(wǎng)絡通向其他網(wǎng)絡的 IP 地址（一般都是路由器的 IP 地址）。而默認網(wǎng)關(guān)（Default Gateway）就是一臺主機如果找不到可用的網(wǎng)關(guān)，就把數(shù)據(jù)包發(fā)給默認指定的網(wǎng)關(guān)，由這個網(wǎng)關(guān)來處理數(shù)據(jù)包

當一臺計算機發(fā)送數(shù)據(jù)時，根據(jù)數(shù)據(jù)包中的目標 IP 地址，通過子網(wǎng)掩碼來判定目標主機是否在本地子網(wǎng)中，如果目標主機在本地子網(wǎng)中，則（通過二層設備 - 交換機）直接發(fā)送即可。如果目標不在本地子網(wǎng)中則將該信息送到缺省網(wǎng)關(guān)/路由器，由路由器將其轉(zhuǎn)發(fā)到其他網(wǎng)絡中，進一步尋找目標主機。

7）MySQL 的行鎖怎么實現(xiàn)的

InnoDB 行鎖是通過給索引上的索引項加鎖來實現(xiàn)的

8）MySQL 的事務，展開說說

先解釋下 ACID 特性，然后說下 MySQL 如何保證 ACID 的：鎖來保證隔離性（可擴展四種并發(fā)問題、四種隔離級別、行鎖的三種算法、著重提一下 Next-Key Lock 解決幻讀問題 ），redo log 保證持久性和原子性（持久性對應 WAL 和 CheckPoint，原子性對應 redo log 兩階段提交），undo log（MVCC）保證一致性

9）MySQL 索引了解嗎，索引是怎么實現(xiàn)的

10）索引有哪些，介紹下

聚簇索引、非聚簇索引、唯一索引、聯(lián)合索引、覆蓋索引、前綴索引

11）聯(lián)合索引中間可以有 null 值嗎，為什么，測試過嗎？

12）B+ 樹的特點，原理

13）B+ 樹索引和 Hash 索引的區(qū)別，優(yōu)劣

14）了解死鎖（DeadLock）嗎

什么是死鎖？兩個線程互相請求對方的資源，并且不釋放自己的資源，形成循環(huán)等待，導致死鎖。

死鎖的四個必要條件？互斥條件、請求和保持條件、不剝奪條件、循環(huán)等待條件

如何避免/預防死鎖？破壞四個必要條件其中之一即可：

• 破壞互斥條件：不可行
• 破壞請求和保持條件：線程啟動時一次性請求完所有需要的資源，運行途中不允許請求其他資源
• 破壞不剝奪條件：請求新的資源時得不到滿足，必須釋放已經(jīng)保持的所有資源，待以后需要時再重新申請
• 破壞循環(huán)等待條件：給資源編號，只允許順序申請資源

15）MySQL 怎么解決死鎖的

16）平時遇到過死鎖嗎，怎么解決的

17）JVM 的垃圾清除說一下

18）垃圾收集算法有哪些

三大垃圾收集算法：

• Mark-Sweep（非移動式算法，不需要 STW）
• Mark-Copy（新生代垃圾收集算法，移動式算法，需要 STW）
• Mark-Compact（移動式算法，需要 STW）

19）介紹下知道的垃圾收集器有些什么

新生代：

• Serial（Mark-Copy、單線程）
• ParNew（Mark-Copy、多線程）
• Parallel Scavendge（Mark-Copy、多線程；關(guān)注吞吐量；自適應調(diào)節(jié)策略）

老年代：

• Serial Old（Mark-Compact、單線程）
• Parallel Old（Mark-Compact、多線程）
• CMS
• Mark-Sweep、多線程；
• 追求低延遲；
• 四個階段（初始標記、并發(fā)標記、重新標記、并發(fā)清除），第一和第三階段需要 STW；
• 采用 “增量更新” 解決 “對象消失” 問題；
• 一般還會設置 Serial Old 做老年代收集預案，因為 CMS 會出現(xiàn)并發(fā)失敗問題 “Concurrent Mode Failure”（無法處理“浮動垃圾” 導致堆被完全占滿而報錯 or CMS 垃圾收集運行期間預留的內(nèi)存無法滿足程序分配新對象的需要），這時候就會觸發(fā) Serial Old 用 Mark-Compact 算法做老年代收集；
• CMS 基于 Mark-Sweep 算法會有大量空間碎片產(chǎn)生，往往會出現(xiàn)老年代還有很多剩余空間，但就是無法找到足夠大的連續(xù)空間來分配當前對象，而不得不提前觸發(fā)一次 Full GC

面向全堆：

• G1
• Mark-Copy、多線程；
• 四個階段（初始標記、并發(fā)標記、最終標記、篩選回收），第一和第三和第四階段都需要 STW；
• 采用 “原始快照” 解決 “對象消失” 問題；
• 面向局部收集、基于 Region 的內(nèi)存布局；
• 非純粹地追求低延遲，而是在延遲可控的情況下獲得盡可能高的吞吐量；
• G1 無論是為了垃圾收集產(chǎn)生的內(nèi)存占用還是程序運行時的額外執(zhí)行負載都要比 CMS 要高；
• 目前在小內(nèi)存應用上 CMS 的表現(xiàn)大概率仍然要會優(yōu)于 G1，而在大內(nèi)存應用上 G1 則大多能發(fā)揮其優(yōu)勢

20）垃圾的判斷方法，引用計數(shù)法為什么用的沒有 GCRoot 的多，缺點是什么，為什么

兩大方法：

• 引用計數(shù)法（無法解決循環(huán)引用問題）
• 可達性分析法
• 兩個階段：根節(jié)點枚舉、對象圖遍歷
• 可擴展根節(jié)點枚舉必須進行 STW（OopMap，安全點和安全區(qū)域）；三色標記法分析為什么對象圖遍歷理論上也必須進行 STW（浮動垃圾、對象消失），因為這個階段時間較長所以設計了兩種方案（增量更新、原始更新 SATB）使得對象圖遍歷不需要進行 STW

21）平時測試過 JVM 的垃圾清除嗎

22）Redis 的了解，介紹下

可以說下 Redis 是基于內(nèi)存的，單線程工作的緩存，先介紹下為什么說 Redis 是單線程的（關(guān)鍵點：IO 多路復用、文件事件處理器）；然后可以介紹下除了基于內(nèi)存和單線程，Redis 還有哪些特性使得它那么快（Redis 特殊設計的數(shù)據(jù)結(jié)構(gòu) ziplist、skiplist，SDS 等；Redis 的虛擬內(nèi)存機制）

23）Redis 的持久化

兩大持久化機制：

• RDB：存儲數(shù)據(jù)庫狀態(tài)，二進制文件 dump.rdb；SAVE、BGSAVE fork 子進程自動間隔性保存
• AOF：追加寫入，存儲命令（先寫入 AOF 緩沖區(qū)，根據(jù) appendfsync 參數(shù)決定何時寫入并同步磁盤）；AOF 重寫、fork 子進程 AOF 后臺重寫（AOF 重寫緩沖區(qū)）

24）算法題：刪除鏈表的倒數(shù)第 k 個節(jié)點