大家好，我是小林。

(資料圖片僅供參考)

今天又來分享面經(jīng)了，這次騰訊春招實習(xí)的面經(jīng)，崗位是 java 后端開發(fā)。

讀者的背景是985碩，根據(jù)讀者的面試感受說是，騰訊面試比之前的要難，但是增加自信了，遇到不會的問題，開始會胡說八道了。

說一下BIO、NIO和AIO讀者答：BIO是阻塞IO。在上一個線程的任務(wù)執(zhí)行完之前，該線程必須阻塞等待上一個線程執(zhí)行完畢。NIO是非阻塞IO。一旦是響應(yīng)事件發(fā)生了，該線程就會將對應(yīng)的響應(yīng)事件交給對應(yīng)的事件處理器進行處理。AIO是異步IO。主線程接收到請求后，可以分發(fā)給其他線程進行異步處理，主線程繼續(xù)接收其他請求。小林補充：

BIO（Blocking IO）、NIO（Non-Blocking IO）和AIO（Asynchronous IO）是Java中常用的IO模式。它們之間的主要區(qū)別在于IO的處理方式和效率。

BIO是同步阻塞IO，在進行IO操作時，必須等待IO操作完成后才能進行下一步操作，這時線程會被阻塞。BIO適用于連接數(shù)比較小且固定的架構(gòu)，由于線程阻塞等待IO操作，所以并發(fā)處理能力不強。

NIO是同步非阻塞IO，可以支持多個連接同時進行讀寫操作，因此可以用較少的線程來處理大量的連接。NIO通過Selector來監(jiān)聽多個Channel的狀態(tài)，當(dāng)Channel中有數(shù)據(jù)可讀或可寫時，Selector會通知程序進行讀寫操作。NIO適用于連接數(shù)多且連接時間較短的場景。

AIO是異步非阻塞IO，與NIO不同的是，AIO不需要用戶線程等待IO操作完成，而是由操作系統(tǒng)來完成IO操作，操作系統(tǒng)完成IO操作后會通知用戶線程處理。AIO適用于連接數(shù)較多且連接時間較長的場景，如高性能網(wǎng)絡(luò)服務(wù)器等。

你說一下NIO是如何實現(xiàn)同步非阻塞的？主線程是只有一個嘛？讀者答：

NIO底層是用Selector、Channel和ByteBuffer來實現(xiàn)的。主線程在循環(huán)使用select方法進行阻塞等待，當(dāng)有acceptable、readable或者writable事件發(fā)生的時候，循環(huán)就會往下走，將對應(yīng)的事件交給對應(yīng)的事件處理器進行處理。

他可以多線程的，可以有多個accept()線程和多個worker線程。

小林補充：

在NIO中，使用了多路復(fù)用器Selector來實現(xiàn)同步非阻塞的IO操作。Selector是一個可以監(jiān)控多個通道（Channel）是否有數(shù)據(jù)可讀或可寫的對象，當(dāng)一個或多個Channel準(zhǔn)備好讀或?qū)憰r，Selector會通知程序進行讀寫操作，而不是像BIO一樣阻塞等待IO操作完成。

在NIO中，主線程通常只有一個，但是可以使用Selector來管理多個Channel，實現(xiàn)多個連接的非阻塞讀寫操作。當(dāng)有多個Channel需要進行IO操作時，Selector會輪詢這些Channel，檢查它們的狀態(tài)是否可讀或可寫，如果有可讀或可寫的Channel，就將其加入到一個已選擇鍵集合中，等待程序處理。這樣，一個線程就可以同時處理多個Channel，提高了系統(tǒng)的并發(fā)處理能力。

你用過哪些設(shè)計模式

單例模式，觀察者模式，責(zé)任鏈模式

講一下觀察者模式讀者答：

觀察者模式就是他有多個觀察者，有一個觀察管理者，觀察者一開始會都注冊到觀察管理者的列表當(dāng)中，當(dāng)對應(yīng)的位置發(fā)生了相應(yīng)的事件呢，就會由觀察管理者調(diào)用相應(yīng)的觀察者的方法執(zhí)行相應(yīng)的動作。

小林補充：

觀察者模式（Observer Pattern）是一種設(shè)計模式，它定義了一種一對多的依賴關(guān)系，讓多個觀察者對象同時監(jiān)聽某一個主題對象，當(dāng)主題對象狀態(tài)發(fā)生變化時，它的所有觀察者都會收到通知并自動更新。

在觀察者模式中，有兩個核心角色：Subject（主題）和Observer（觀察者）。主題是被觀察的對象，它維護了一個觀察者列表，可以動態(tài)添加或刪除觀察者。當(dāng)主題狀態(tài)發(fā)生變化時，它會通知所有觀察者，并調(diào)用它們的更新方法。觀察者是接收主題通知的對象，它定義了一個更新方法，使主題在狀態(tài)發(fā)生變化時能夠及時通知到它。

觀察者模式可以實現(xiàn)松耦合的設(shè)計，主題對象和觀察者對象之間沒有直接的耦合關(guān)系，它們之間通過抽象的接口進行通信，可以方便地增加或刪除觀察者，而不需要修改主題對象的代碼。觀察者模式在很多場景中都有應(yīng)用，比如GUI事件處理、消息隊列、發(fā)布訂閱系統(tǒng)等。

java 代碼示例：

當(dāng)然，以下是一個簡單的Java代碼實例，演示了觀察者模式的基本實現(xiàn)：

import java.util.ArrayList;import java.util.List;// 主題（Subject）接口interface Subject {    void registerObserver(Observer observer);    void removeObserver(Observer observer);    void notifyObservers();}// 觀察者（Observer）接口interface Observer {    void update(String message);}// 具體主題（ConcreteSubject）實現(xiàn)class ConcreteSubject implements Subject {    private List observers = new ArrayList<>();    private String message;    @Override    public void registerObserver(Observer observer) {        observers.add(observer);    }    @Override    public void removeObserver(Observer observer) {        observers.remove(observer);    }    @Override    public void notifyObservers() {        for (Observer observer : observers) {            observer.update(message);        }    }    public void setMessage(String message) {        this.message = message;        notifyObservers();    }}// 具體觀察者（ConcreteObserver）實現(xiàn)class ConcreteObserver implements Observer {    private String name;    public ConcreteObserver(String name) {        this.name = name;    }    @Override    public void update(String message) {        System.out.println(name + " received message: " + message);    }}// 測試類public class ObserverPatternDemo {    public static void main(String[] args) {        ConcreteSubject subject = new ConcreteSubject();        Observer observer1 = new ConcreteObserver("Observer1");        Observer observer2 = new ConcreteObserver("Observer2");        Observer observer3 = new ConcreteObserver("Observer3");        subject.registerObserver(observer1);        subject.registerObserver(observer2);        subject.registerObserver(observer3);        subject.setMessage("Hello, everyone!");        subject.removeObserver(observer2);        subject.setMessage("How are you doing?");    }}

運行上述代碼，輸出如下：

Observer1 received message: Hello, everyone!Observer2 received message: Hello, everyone!Observer3 received message: Hello, everyone!Observer1 received message: How are you doing?Observer3 received message: How are you doing?

可以看到，當(dāng)主題對象狀態(tài)發(fā)生變化時，它會通知所有觀察者，并調(diào)用它們的更新方法。觀察者可以根據(jù)接收到的消息進行相應(yīng)的處理。

java內(nèi)存結(jié)構(gòu)讀者答：

JVM內(nèi)存結(jié)構(gòu)分為5大區(qū)域，程序計數(shù)器、虛擬機棧、本地方法棧、堆內(nèi)存、方法區(qū)。

方法區(qū)：

用來存儲加載的類信息、常量、靜態(tài)變量、編譯后的代碼等數(shù)據(jù)。

堆內(nèi)存：

堆內(nèi)存可以細(xì)分為：老年代、新生代(Eden、From Survivor、To Survivor)。JVM啟動時創(chuàng)建，用來存放對象的實例。堆內(nèi)存是垃圾收集器管理的主要區(qū)域。

虛擬機棧：

線程私有的。虛擬機棧由多個棧幀組成。一個線程會執(zhí)行一個或多個方法，一個方法對應(yīng)一個棧幀。每一次方法調(diào)用都會有一個對應(yīng)的棧幀被壓入棧中，每一個方法調(diào)用結(jié)束后，都會有一個棧幀被彈出。棧幀內(nèi)容包含：局部變量表、操作數(shù)棧、動態(tài)鏈接、方法返回地址等信息。

本地方法棧：

和虛擬機棧功能類似，虛擬機棧是為虛擬機執(zhí)行JAVA方法而準(zhǔn)備的，本地方法棧是為虛擬機使用Native本地方法而準(zhǔn)備的。

程序計數(shù)器(Program CounterRegister)：

線程私有的，程序計數(shù)器主要有兩個作用：

作為當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器，通過它實現(xiàn)代碼的流程控制，如：順序執(zhí)行、分支、循環(huán)、異常處理。在多線程的情況下，程序計數(shù)器用于記錄當(dāng)前線程執(zhí)行的位置，當(dāng)線程被切換回來的時候可以通過程序計數(shù)器中的信息獲取上次執(zhí)行的位置，然后繼續(xù)執(zhí)行。說一下數(shù)據(jù)庫事務(wù)的四大特性讀者答：

事務(wù)有ACID四大特性。就是原子性、一致性、隔離性和持久性。原子性就是指事務(wù)中的操作要么全做要么全不做，不存在中間態(tài)。一致性是指事務(wù)執(zhí)行前后數(shù)據(jù)庫的完整性不被破壞，保持一致。隔離性是指多個事務(wù)并發(fā)執(zhí)行時事務(wù)之間互不影響。持久性是指事務(wù)執(zhí)行成功后，事務(wù)對于數(shù)據(jù)庫的操作會永久的保存在磁盤上，永不丟失。

從一定程度上來講，AID是手段，C是目的，就是通過原子性、隔離性和持久性來保證一致性。

char和varchar的區(qū)別讀者答：

char是固定長度的字符串類型，varchar是可變長度的字符串類型。拿char(128)和varchar(128)舉例來說。char(128)是無論字符串大小，都會在磁盤上分配128個字符的內(nèi)存空間。而varchar(128)會根據(jù)字符本身的長短來分配內(nèi)存空間。

小林補充：

在MySQL中，CHAR和VARCHAR都是用于存儲字符類型數(shù)據(jù)的數(shù)據(jù)類型，它們的區(qū)別在于存儲方式和使用場景。

CHAR?類型用于存儲固定長度的字符串，其長度在定義表時就已經(jīng)固定，且最大長度為255個字符。當(dāng)存儲的字符串長度小于定義的長度時，MySQL會在其后面補充空格使其長度達(dá)到定義的長度。由于存儲的長度是固定的，因此CHAR?類型的讀取速度比VARCHAR類型更快。

VARCHAR?類型則用于存儲可變長度的字符串，其長度可以在存儲數(shù)據(jù)時動態(tài)地改變，但最大長度也為255個字符。當(dāng)存儲的字符串長度小于定義的長度時，MySQL不會在其后面補充空格。由于存儲的長度是可變的，因此VARCHAR?類型的存儲空間相對更小，但讀取速度比CHAR類型稍微慢一些。

那與varchar相比，char字段是不是一無是處呢？

大部分情況，是的，最好使用varchar。不過考慮一個極端的場景：某個字段的最大長度是100字節(jié)，但是會頻繁修改。如果使用char(100)?，則插入記錄后就分配了100個字節(jié)，后續(xù)修改不會造成頁分裂、頁空隙等問題，而varchar(100)由于沒有提前分配存儲空間，后續(xù)修改時可能出現(xiàn)頁分裂，進而導(dǎo)致性能下降。

說一下外鍵約束讀者答：

舉例來說，某一個字段是表b的主鍵，但是它也是表a中的字段，表a中該字段的使用范圍取決于表b。外鍵約束主要是用來維護兩個表的一致性。

小林補充：

外鍵約束的作用是維護表與表之間的關(guān)系，確保數(shù)據(jù)的完整性和一致性。讓我們舉一個簡單的例子：

假設(shè)你有兩個表，一個是學(xué)生表，另一個是課程表，這兩個表之間有一個關(guān)系，即一個學(xué)生可以選修多門課程，而一門課程也可以被多個學(xué)生選修。在這種情況下，我們可以在學(xué)生表中定義一個指向課程表的外鍵，如下所示：

CREATE TABLE students (  id INT PRIMARY KEY,  name VARCHAR(50),  course_id INT,  FOREIGN KEY (course_id) REFERENCES courses(id));

這里，students?表中的course_id?字段是一個外鍵，它指向courses?表中的id?字段。這個外鍵約束確保了每個學(xué)生所選的課程在courses表中都存在，從而維護了數(shù)據(jù)的完整性和一致性。

如果沒有定義外鍵約束，那么就有可能出現(xiàn)學(xué)生選了不存在的課程或者刪除了一個課程而忘記從學(xué)生表中刪除選修該課程的學(xué)生的情況，這會破壞數(shù)據(jù)的完整性和一致性。因此，使用外鍵約束可以幫助我們避免這些問題。

說一下binlog讀者答：

binlog是二進制日志文件。他主要用來做主從同步。他有statement格式和row格式。statement記錄了執(zhí)行的SQL語句，Row 格式保存哪條記錄被修改。binlog事務(wù)提交的時候才寫入的。也可以用來做歸檔。

小林補充：

binlog日志是MySQL數(shù)據(jù)庫的一種日志記錄機制，用于記錄數(shù)據(jù)庫的修改操作（如插入、更新、刪除等），以便在需要時進行數(shù)據(jù)恢復(fù)、數(shù)據(jù)復(fù)制和數(shù)據(jù)同步等操作。

binlog日志的實現(xiàn)以下功能：

數(shù)據(jù)恢復(fù)：binlog日志可以用于回滾到之前的某個時間點，從而恢復(fù)數(shù)據(jù)。數(shù)據(jù)復(fù)制：binlog日志可以用于在主從數(shù)據(jù)庫之間復(fù)制數(shù)據(jù)，從而實現(xiàn)數(shù)據(jù)的高可用和負(fù)載均衡等功能。

MySQL的binlog日志有三種格式，分別是Statement格式、Row格式和Mixed格式。它們之間的區(qū)別如下：

STATEMENT：每一條修改數(shù)據(jù)的 SQL 都會被記錄到 binlog 中（相當(dāng)于記錄了邏輯操作，所以針對這種格式， binlog 可以稱為邏輯日志），主從復(fù)制中 slave 端再根據(jù) SQL 語句重現(xiàn)。但 STATEMENT 有動態(tài)函數(shù)的問題，比如你用了 uuid 或者 now 這些函數(shù)，你在主庫上執(zhí)行的結(jié)果并不是你在從庫執(zhí)行的結(jié)果，這種隨時在變的函數(shù)會導(dǎo)致復(fù)制的數(shù)據(jù)不一致；ROW：記錄行數(shù)據(jù)最終被修改成什么樣了（這種格式的日志，就不能稱為邏輯日志了），不會出現(xiàn) STATEMENT 下動態(tài)函數(shù)的問題。但 ROW 的缺點是每行數(shù)據(jù)的變化結(jié)果都會被記錄，比如執(zhí)行批量 update 語句，更新多少行數(shù)據(jù)就會產(chǎn)生多少條記錄，使 binlog 文件過大，而在 STATEMENT 格式下只會記錄一個 update 語句而已；MIXED：包含了 STATEMENT 和 ROW 模式，它會根據(jù)不同的情況自動使用 ROW 模式和 STATEMENT 模式；說一下分庫分表讀者答：

我可能知道的就是想我簡歷上調(diào)研過的這個mycat組件，他是根據(jù)業(yè)務(wù)字段的hash值來確定分片的，比如user_id不同的用戶信息就會存儲到不同分片當(dāng)中，他是多個分片同時提供服務(wù)。

小林補充：

當(dāng)數(shù)據(jù)量過大造成事務(wù)執(zhí)行緩慢時，就要考慮分表，因為減少每次查詢數(shù)據(jù)總量是解決數(shù)據(jù)查詢緩慢的主要原因。你可能會問：“查詢可以通過主從分離或緩存來解決，為什么還要分表？”但這里的查詢是指事務(wù)中的查詢和更新操作。

為了應(yīng)對高并發(fā)，一個數(shù)據(jù)庫實例撐不住，即單庫的性能無法滿足高并發(fā)的要求，就把并發(fā)請求分散到多個實例中去，這種就是分庫。

總的來說，分庫分表使用的場景不一樣：分表是因為數(shù)據(jù)量比較大，導(dǎo)致事務(wù)執(zhí)行緩慢；分庫是因為單庫的性能無法滿足要求。

遇到過數(shù)據(jù)庫死鎖嗎讀者答：

事務(wù)A通過數(shù)據(jù)修改操作占用著資源A,事務(wù)B通過數(shù)據(jù)修改操作占用著資源B,而他們又同時請求對方的資源，互不退讓就造成了死鎖。如果沒有終止一個事務(wù)或者回滾過一段時間或超時。

小林補充：

假設(shè)有兩事務(wù)，一個事務(wù)要插入訂單 1007 ，另外一個事務(wù)要插入訂單 1008，因為需要對訂單做冪等性校驗，所以兩個事務(wù)先要查詢該訂單是否存在，不存在才插入記錄，過程如下：

可以看到，兩個事務(wù)都陷入了等待狀態(tài)（前提沒有打開死鎖檢測），也就是發(fā)生了死鎖，因為都在相互等待對方釋放鎖。

死鎖的四個必要條件：互斥、占有且等待、不可強占用、循環(huán)等待。只要系統(tǒng)發(fā)生死鎖，這些條件必然成立，但是只要破壞任意一個條件就死鎖就不會成立。

TCP和UDP的區(qū)別讀者答：

1.TCP是面向連接的協(xié)議，建立和釋放連接需要進行三次握手和四次揮手。UDP是面向無連接的協(xié)議，無需進行三次握手和四次揮手。說明udp比TCP實時性更強。

2.TCP 是流式傳輸，沒有邊界，但保證順序和可靠。UDP 是一個包一個包的發(fā)送，是有邊界的，但可能會丟包和亂序。

3.TCP連接的可靠性強，UDP的可靠性不強。

4.TCP只能一對一，UDP支持一對多和多對多。

5.TCP的頭部開銷比UDP大。TCP 首部長度較長，會有一定的開銷，首部在沒有使用「選項」字段時是 20 個字節(jié)，如果使用了「選項」字段則會變長的。UDP 首部只有 8 個字節(jié)，并且是固定不變的，開銷較小。

TCP是如何保證可靠的？讀者答：tcp的序列號可以避免亂序的問題，保證收到的tcp報文都是有序的。在 TCP 中，當(dāng)發(fā)送端的數(shù)據(jù)到達(dá)接收主機時，接收端主機會返回一個確認(rèn)應(yīng)答消息，表示已收到消息。TCP 針對數(shù)據(jù)包丟失的情況，會用重傳機制解決。用快重傳解決個別報文段的丟失問題。使用滑動窗口實現(xiàn)流量控制。使用接收方確認(rèn)報文中的窗口字段來控制發(fā)送方發(fā)送窗口大小，進而控制發(fā)送方的發(fā)送速率，使得接收方來得及接收。使用基于窗口的擁塞控制，來盡量避免避免網(wǎng)絡(luò)擁塞。流量控制是使用什么數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)的？讀者答：

流量控制是使用滑動窗口來實現(xiàn)的。接收方確認(rèn)報文中的窗口字段可以用來控制發(fā)送方窗口的大小。如果窗戶的值為0，則發(fā)送方停止發(fā)送數(shù)據(jù)，但是發(fā)送方會定期的向接收方發(fā)送窗口探測報文以得到窗口的大小。

小林補充：

TCP傳輸協(xié)議中，流量控制是使用滑動窗口（Sliding Window）來實現(xiàn)的?；瑒哟翱谑且环N基于數(shù)據(jù)流的、動態(tài)調(diào)整的、可變大小的窗口，它通過協(xié)商雙方的接收窗口和發(fā)送窗口大小，控制數(shù)據(jù)的傳輸速率。

在TCP協(xié)議中，每個數(shù)據(jù)包都有一個序號，接收方通過序號來確認(rèn)是否收到了正確的數(shù)據(jù)包。發(fā)送方將數(shù)據(jù)分成若干個數(shù)據(jù)段，每個數(shù)據(jù)段的大小不超過發(fā)送窗口的大小，然后將這些數(shù)據(jù)段發(fā)送給接收方。接收方會確認(rèn)已經(jīng)收到的數(shù)據(jù)，同時告訴發(fā)送方自己的接收窗口大小。發(fā)送方根據(jù)接收方的窗口大小，動態(tài)調(diào)整自己的發(fā)送窗口大小，從而控制數(shù)據(jù)的傳輸速率。

滑動窗口的大小是可以動態(tài)調(diào)整的，它可以根據(jù)網(wǎng)絡(luò)狀況和雙方的能力來自適應(yīng)地調(diào)整，從而實現(xiàn)流量控制的功能。如果接收方的接收窗口變小，發(fā)送方會相應(yīng)地減小自己的發(fā)送窗口，以避免過多的數(shù)據(jù)堆積在網(wǎng)絡(luò)中導(dǎo)致?lián)砣Ｈ绻邮辗降慕邮沾翱谧兇?，發(fā)送方會相應(yīng)地增加自己的發(fā)送窗口，以提高數(shù)據(jù)傳輸速率。

分塊傳輸讀者答：

分塊傳輸這一塊有個nagle算法。他的目的是盡量發(fā)送大數(shù)據(jù)塊，以減少發(fā)送報文的數(shù)量，提高傳輸效率。nagle算法規(guī)定在上一個未被確認(rèn)的分組的確認(rèn)到達(dá)之前，不能發(fā)送下一個分組。

分塊傳輸其實更像是http協(xié)議里的chunk傳輸。如果是特指tcp 的話，如果應(yīng)用層的數(shù)據(jù)超過mss的大小，數(shù)據(jù)會在tcp層進行分塊。

小林補充：

分塊傳輸感覺是說http協(xié)議里的chunk傳輸。它允許將數(shù)據(jù)分成多個塊（Chunk）進行傳輸，每個塊都包含一段數(shù)據(jù)和該塊數(shù)據(jù)的長度。在傳輸數(shù)據(jù)時，先發(fā)送一個塊的長度，然后發(fā)送該塊的數(shù)據(jù)，接著發(fā)送下一個塊的長度和數(shù)據(jù)，以此類推，直到所有的數(shù)據(jù)都傳輸完畢。

如果是特指tcp 的話，如果應(yīng)用層的數(shù)據(jù)超過mss的大小，數(shù)據(jù)會在tcp層進行分塊。

剛才你說nagle算法是為了發(fā)送大數(shù)據(jù)塊，數(shù)據(jù)塊是越大越好嗎？（我沒太聽懂這個問題，他又換了個說法，其實我還是沒懂，但是他提到了MTU，我就借坡下驢了）讀者答：

您剛才提到了MTU，有可能因為數(shù)據(jù)塊比較大，可能會出現(xiàn)拆包的問題，將一個大數(shù)據(jù)塊分為幾個MTU單元進行傳輸，因為TCP是按照序列號順序讀取的，所以可能會出現(xiàn)阻塞問題。

小林補充：

看業(yè)務(wù)場景，negle算法不適合像ssh這種傳輸小報文的場景，會增加延遲。

項目問題

縮減很多，只放出了共性的問題。

性能調(diào)優(yōu)是怎么做的？你覺得你的這個項目性能瓶頸在哪里？項目你自己做的嗎？開源了嗎？無算法題面試總結(jié)

感覺：

騰訊面試比之前的要難，增加自信了，開始會胡說八道了。即使知道自己說的不是對的，例如分塊傳輸那個問題。

不足之處：

再積累積累吧

關(guān)鍵詞：