大家好，我是小林。

今天又來分享面經(jīng)了，這次騰訊春招實(shí)習(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)的事件處理器進(jìn)行處理。

• AIO是異步IO。主線程接收到請求后，可以分發(fā)給其他線程進(jìn)行異步處理，主線程繼續(xù)接收其他請求。

小林補(bǔ)充：

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

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

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

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

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

讀者答：

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

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

小林補(bǔ)充：

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

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

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

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

講一下觀察者模式

讀者答：

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

小林補(bǔ)充：

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

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

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

java 代碼示例：

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

importjava.util.ArrayList;
importjava.util.List;

//主題（Subject）接口
interfaceSubject{
voidregisterObserver(Observerobserver);
voidremoveObserver(Observerobserver);
voidnotifyObservers();
}

//觀察者（Observer）接口
interfaceObserver{
voidupdate(Stringmessage);
}

//具體主題（ConcreteSubject）實(shí)現(xiàn)
classConcreteSubjectimplementsSubject{
privateListobservers=newArrayList<>();
privateStringmessage;

@Override
publicvoidregisterObserver(Observerobserver){
observers.add(observer);
}

@Override
publicvoidremoveObserver(Observerobserver){
observers.remove(observer);
}

@Override
publicvoidnotifyObservers(){
for(Observerobserver:observers){
observer.update(message);
}
}

publicvoidsetMessage(Stringmessage){
this.message=message;
notifyObservers();
}
}

//具體觀察者（ConcreteObserver）實(shí)現(xiàn)
classConcreteObserverimplementsObserver{
privateStringname;

publicConcreteObserver(Stringname){
this.name=name;
}

@Override
publicvoidupdate(Stringmessage){
System.out.println(name+"receivedmessage:"+message);
}
}

//測試類
publicclassObserverPatternDemo{
publicstaticvoidmain(String[]args){
ConcreteSubjectsubject=newConcreteSubject();

Observerobserver1=newConcreteObserver("Observer1");
Observerobserver2=newConcreteObserver("Observer2");
Observerobserver3=newConcreteObserver("Observer3");

subject.registerObserver(observer1);
subject.registerObserver(observer2);
subject.registerObserver(observer3);

subject.setMessage("Hello,everyone!");

subject.removeObserver(observer2);

subject.setMessage("Howareyoudoing?");
}
}

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

Observer1receivedmessage:Hello,everyone!
Observer2receivedmessage:Hello,everyone!
Observer3receivedmessage:Hello,everyone!
Observer1receivedmessage:Howareyoudoing?
Observer3receivedmessage:Howareyoudoing?

可以看到，當(dāng)主題對象狀態(tài)發(fā)生變化時，它會通知所有觀察者，并調(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ū)：

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

堆內(nèi)存：

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

虛擬機(jī)棧：

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

本地方法棧：

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

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

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

1. 作為當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器，通過它實(shí)現(xiàn)代碼的流程控制，如：順序執(zhí)行、分支、循環(huán)、異常處理。
2. 在多線程的情況下，程序計(jì)數(shù)器用于記錄當(dāng)前線程執(zhí)行的位置，當(dāng)線程被切換回來的時候可以通過程序計(jì)數(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)存空間。

小林補(bǔ)充：

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

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

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

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

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

說一下外鍵約束

讀者答：

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

小林補(bǔ)充：

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

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

CREATETABLEstudents(
idINTPRIMARYKEY,
nameVARCHAR(50),
course_idINT,
FOREIGNKEY(course_id)REFERENCEScourses(id)
);

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

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

說一下binlog

讀者答：

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

小林補(bǔ)充：

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

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

• 數(shù)據(jù)恢復(fù)：binlog日志可以用于回滾到之前的某個時間點(diǎn)，從而恢復(fù)數(shù)據(jù)。
• 數(shù)據(jù)復(fù)制：binlog日志可以用于在主從數(shù)據(jù)庫之間復(fù)制數(shù)據(jù)，從而實(shí)現(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 的缺點(diǎn)是每行數(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ù)。

小林補(bǔ)充：

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

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

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

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

讀者答：

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

小林補(bǔ)充：

假設(shè)有兩事務(wù)，一個事務(wù)要插入訂單 1007 ，另外一個事務(wù)要插入訂單 1008，因?yàn)樾枰獙τ唵巫鰞绲刃孕ｒ?yàn)，所以兩個事務(wù)先要查詢該訂單是否存在，不存在才插入記錄，過程如下：

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

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

TCP和UDP的區(qū)別

讀者答：

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

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

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

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

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

TCP是如何保證可靠的？

讀者答：

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

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

讀者答：

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

小林補(bǔ)充：

TCP傳輸協(xié)議中，流量控制是使用滑動窗口（Sliding Window）來實(shí)現(xià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)整，從而實(shí)現(xiàn)流量控制的功能。如果接收方的接收窗口變小，發(fā)送方會相應(yīng)地減小自己的發(fā)送窗口，以避免過多的數(shù)據(jù)堆積在網(wǎng)絡(luò)中導(dǎo)致?lián)砣Ｈ绻邮辗降慕邮沾翱谧兇螅l(fā)送方會相應(yīng)地增加自己的發(fā)送窗口，以提高數(shù)據(jù)傳輸速率。

分塊傳輸

讀者答：

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

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

小林補(bǔ)充：

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

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

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

讀者答：

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

小林補(bǔ)充：

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

項(xiàng)目問題

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

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

無算法題

面試總結(jié)

感覺：

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

不足之處：

• 再積累積累吧