大家好，我是小林。

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

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

說一下BIO、NIO和AIO

讀者答：

• BIO是阻塞IO。在上一個(gè)線程的任務(wù)執(zhí)行完之前，該線程必須阻塞等待上一個(gè)線程執(zhí)行完畢。
• NIO是非阻塞IO。一旦是響應(yīng)事件發(fā)生了，該線程就會(huì)將對(duì)應(yīng)的響應(yīng)事件交給對(duì)應(yīng)的事件處理器進(jìn)行處理。
• AIO是異步IO。主線程接收到請(qǐng)求后，可以分發(fā)給其他線程進(jìn)行異步處理，主線程繼續(xù)接收其他請(qǐng)求。

小林補(bǔ)充：

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

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

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

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

你說一下NIO是如何實(shí)現(xiàn)同步非阻塞的？主線程是只有一個(gè)嘛？

讀者答：

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

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

小林補(bǔ)充：

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

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

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

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

講一下觀察者模式

讀者答：

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

小林補(bǔ)充：

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

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

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

java 代碼示例：

當(dāng)然，以下是一個(gè)簡(jiǎn)單的Java代碼實(shí)例，演示了觀察者模式的基本實(shí)現(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）實(shí)現(xiàn)
class ConcreteSubject implements Subject {
    private List<Observer> 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）實(shí)現(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);
    }
}

// 測(cè)試類
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?");
    }
}

運(yùn)行上述代碼，輸出如下：

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)主題對(duì)象狀態(tài)發(fā)生變化時(shí)，它會(huì)通知所有觀察者，并調(diào)用它們的更新方法。觀察者可以根據(jù)接收到的消息進(jìn)行相應(yīng)的處理。

java內(nèi)存結(jié)構(gòu)

讀者答：

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

方法區(qū)：

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

堆內(nèi)存：

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

虛擬機(jī)棧：

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

本地方法棧：

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

程序計(jì)數(shù)器(Program Counter Register)：

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

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

說一下數(shù)據(jù)庫(kù)事務(wù)的四大特性

讀者答：

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

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

char和varchar的區(qū)別

讀者答：

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

小林補(bǔ)充：

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

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

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

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

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

說一下外鍵約束

讀者答：

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

小林補(bǔ)充：

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

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

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

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

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

說一下binlog

讀者答：

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

小林補(bǔ)充：

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

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

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

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

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

說一下分庫(kù)分表

讀者答：

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

小林補(bǔ)充：

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

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

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

遇到過數(shù)據(jù)庫(kù)死鎖嗎

讀者答：

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

小林補(bǔ)充：

假設(shè)有兩事務(wù)，一個(gè)事務(wù)要插入訂單 1007 ，另外一個(gè)事務(wù)要插入訂單 1008，因?yàn)樾枰獙?duì)訂單做冪等性校驗(yàn)，所以兩個(gè)事務(wù)先要查詢?cè)撚唵问欠翊嬖冢淮嬖诓挪迦胗涗洠^程如下：

可以看到，兩個(gè)事務(wù)都陷入了等待狀態(tài)（前提沒有打開死鎖檢測(cè)），也就是發(fā)生了死鎖，因?yàn)槎荚谙嗷サ却龑?duì)方釋放鎖。

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

TCP和UDP的區(qū)別

讀者答：

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

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

3.TCP連接的可靠性強(qiáng)，UDP的可靠性不強(qiáng)。

4.TCP只能一對(duì)一，UDP支持一對(duì)多和多對(duì)多。

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

TCP是如何保證可靠的？

讀者答：

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

流量控制是使用什么數(shù)據(jù)結(jié)構(gòu)來實(shí)現(xiàn)的？

讀者答：

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

小林補(bǔ)充：

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

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

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

分塊傳輸

讀者答：

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

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

小林補(bǔ)充：

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

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

讀者答：

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

小林補(bǔ)充：

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

項(xiàng)目問題

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

• 性能調(diào)優(yōu)是怎么做的？
• 你覺得你的這個(gè)項(xiàng)目性能瓶頸在哪里？
• 項(xiàng)目你自己做的嗎？開源了嗎？

無算法題

面試總結(jié)

感覺：

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

不足之處：

• 再積累積累吧