大家好，我是小林。

分享一篇騰訊春招二面面經(jīng)，崗位是C++后端，考察的內(nèi)容是C++、Redis、網(wǎng)絡(luò)。

(資料圖)

c++shared_ptr的原理

答：內(nèi)部的共享數(shù)據(jù)和引用計(jì)數(shù)實(shí)現(xiàn)

補(bǔ)充：

shared_ptr多個(gè)指針指向相同的對(duì)象。shared_ptr使用引用計(jì)數(shù)，每一個(gè)shared_ptr的拷貝都指向相同的內(nèi)存。每使用他一次，內(nèi)部的引用計(jì)數(shù)加1，每析構(gòu)一次，內(nèi)部的引用計(jì)數(shù)減1，減為0時(shí)，自動(dòng)刪除所指向的堆內(nèi)存。shared_ptr內(nèi)部的引用計(jì)數(shù)是線程安全的，但是對(duì)象的讀取需要加鎖。

shared_ptr的一個(gè)最大的陷阱是循環(huán)引用，循環(huán)引用會(huì)導(dǎo)致堆內(nèi)存無(wú)法正確釋放，導(dǎo)致內(nèi)存泄漏，可以通過(guò) weak_ptr 來(lái)解決這個(gè)問(wèn)題。

多線程怎么保證引用計(jì)數(shù)的安全的

答：引用計(jì)數(shù)這個(gè)變量是std::atomic，操作時(shí)自帶鎖

常見(jiàn)的鎖有哪些

答：讀寫(xiě)鎖、互斥鎖這些，再就是一些鎖思想，比如樂(lè)觀鎖、悲觀鎖、自旋鎖

valotile關(guān)鍵字的用處

答：避免編譯器額外優(yōu)化

Redis微博上的熱度排行榜用什么數(shù)據(jù)結(jié)構(gòu)

答：Zset，講了講zrangebyscore

補(bǔ)充：

Zset 類型（Sorted Set，有序集合） 可以根據(jù)元素的權(quán)重來(lái)排序，我們可以自己來(lái)決定每個(gè)元素的權(quán)重值。比如說(shuō)，我們可以根據(jù)元素插入 Sorted Set 的時(shí)間確定權(quán)重值，先插入的元素權(quán)重小，后插入的元素權(quán)重大。

在面對(duì)需要展示最新列表、排行榜等場(chǎng)景時(shí)，如果數(shù)據(jù)更新頻繁或者需要分頁(yè)顯示，可以優(yōu)先考慮使用 Sorted Set。

有序集合比較典型的使用場(chǎng)景就是排行榜。例如學(xué)生成績(jī)的排名榜、游戲積分排行榜、視頻播放排名、電商系統(tǒng)中商品的銷量排名等。

我們以博文點(diǎn)贊排名為例，小林發(fā)表了五篇博文，分別獲得贊為 200、40、100、50、150。

# arcticle:1 文章獲得了200個(gè)贊> ZADD user:xiaolin:ranking 200 arcticle:1(integer) 1# arcticle:2 文章獲得了40個(gè)贊> ZADD user:xiaolin:ranking 40 arcticle:2(integer) 1# arcticle:3 文章獲得了100個(gè)贊> ZADD user:xiaolin:ranking 100 arcticle:3(integer) 1# arcticle:4 文章獲得了50個(gè)贊> ZADD user:xiaolin:ranking 50 arcticle:4(integer) 1# arcticle:5 文章獲得了150個(gè)贊> ZADD user:xiaolin:ranking 150 arcticle:5(integer) 1

文章 arcticle:4 新增一個(gè)贊，可以使用 ZINCRBY 命令（為有序集合key中元素member的分值加上increment）：

> ZINCRBY user:xiaolin:ranking 1 arcticle:4"51"

查看某篇文章的贊數(shù)，可以使用 ZSCORE 命令（返回有序集合key中元素個(gè)數(shù)）：

> ZSCORE user:xiaolin:ranking arcticle:4"50"

獲取小林文章贊數(shù)最多的 3 篇文章，可以使用 ZREVRANGE 命令（倒序獲取有序集合 key 從start下標(biāo)到stop下標(biāo)的元素）：

# WITHSCORES 表示把 score 也顯示出來(lái)> ZREVRANGE user:xiaolin:ranking 0 2 WITHSCORES1) "arcticle:1"2) "200"3) "arcticle:5"4) "150"5) "arcticle:3"6) "100"

獲取小林 100 贊到 200 贊的文章，可以使用 ZRANGEBYSCORE 命令（返回有序集合中指定分?jǐn)?shù)區(qū)間內(nèi)的成員，分?jǐn)?shù)由低到高排序）：

> ZRANGEBYSCORE user:xiaolin:ranking 100 200 WITHSCORES1) "arcticle:3"2) "100"3) "arcticle:5"4) "150"5) "arcticle:1"6) "200"

rehash的過(guò)程講一下

答：新舊表雙寫(xiě)，逐漸遷移

補(bǔ)充：

為了避免 rehash 在數(shù)據(jù)遷移過(guò)程中，因拷貝數(shù)據(jù)的耗時(shí)，影響 Redis 性能的情況，所以 Redis 采用了漸進(jìn)式 rehash，也就是將數(shù)據(jù)的遷移的工作不再是一次性遷移完成，而是分多次遷移。

漸進(jìn)式 rehash 步驟如下：

給「哈希表 2」 分配空間，一般會(huì)比「哈希表 1」 大 2 倍；在 rehash 進(jìn)行期間，每次哈希表元素進(jìn)行新增、刪除、查找或者更新操作時(shí)，Redis 除了會(huì)執(zhí)行對(duì)應(yīng)的操作之外，還會(huì)順序?qū)ⅰ腹１?1 」中索引位置上的所有 key-value 遷移到「哈希表 2」 上；隨著處理客戶端發(fā)起的哈希表操作請(qǐng)求數(shù)量越多，最終在某個(gè)時(shí)間點(diǎn)會(huì)把「哈希表 1 」的所有 key-value 遷移到「哈希表 2」，從而完成 rehash 操作。

這樣就巧妙地把一次性大量數(shù)據(jù)遷移工作的開(kāi)銷，分?jǐn)偟搅硕啻翁幚碚?qǐng)求的過(guò)程中，避免了一次性 rehash 的耗時(shí)操作。

在進(jìn)行漸進(jìn)式 rehash 的過(guò)程中，會(huì)有兩個(gè)哈希表，所以在漸進(jìn)式 rehash 進(jìn)行期間，哈希表元素的刪除、查找、更新等操作都會(huì)在這兩個(gè)哈希表進(jìn)行。

比如，查找一個(gè) key 的值的話，先會(huì)在「哈希表 1」 里面進(jìn)行查找，如果沒(méi)找到，就會(huì)繼續(xù)到哈希表 2 里面進(jìn)行找到。

另外，在漸進(jìn)式 rehash 進(jìn)行期間，新增一個(gè) key-value 時(shí)，會(huì)被保存到「哈希表 2 」里面，而「哈希表 1」 則不再進(jìn)行任何添加操作，這樣保證了「哈希表 1 」的 key-value 數(shù)量只會(huì)減少，隨著 rehash 操作的完成，最終「哈希表 1 」就會(huì)變成空表。

遷移過(guò)程中老表是什么時(shí)候釋放，怎么知道老表可以釋放了

答：通過(guò)數(shù)據(jù)長(zhǎng)度

補(bǔ)充：

每個(gè) hash table 都有存著一個(gè) used 字段，每次單步 rehash 完成的時(shí)候，最后都會(huì)檢查老表即 ht[0].used 是否變成了 0，變成 0 后，就說(shuō)明老的哈希表里已經(jīng)沒(méi)有數(shù)據(jù)了，此時(shí)就會(huì)去 free 掉老表，交換老表新表的指針，rehashidx 置為 -1，然后就完成了整個(gè) rehash。

網(wǎng)絡(luò)不同地區(qū)的用戶的請(qǐng)求怎么打到附近的地區(qū)呢？

答：講了CDN

補(bǔ)充：

CDN 將內(nèi)容資源分發(fā)到位于多個(gè)地理位置機(jī)房中的服務(wù)器上，這樣我們?cè)谠L問(wèn)內(nèi)容資源的時(shí)候，不用訪問(wèn)源服務(wù)器。而是直接訪問(wèn)離我們最近的 CDN 節(jié)點(diǎn) ，這樣一來(lái)就省去了長(zhǎng)途跋涉的時(shí)間成本，從而實(shí)現(xiàn)了網(wǎng)絡(luò)加速。

找到離用戶最近的 CDN 節(jié)點(diǎn)是由 CDN 的全局負(fù)載均衡器（*Global Sever Load Balance，GSLB*）負(fù)責(zé)的。

那 GSLB 是在什么時(shí)候起作用的呢？在回答這個(gè)問(wèn)題前，我們先來(lái)看看在沒(méi)有 CDN 的情況下，訪問(wèn)域名時(shí)發(fā)生的事情。

在沒(méi)有 CDN 的情況下，當(dāng)我們?cè)L問(wèn)域名時(shí)，DNS 服務(wù)器最終會(huì)返回源服務(wù)器的地址。

比如，當(dāng)我們?cè)跒g覽器輸入 www.xiaolin.com 域名后，在本地 host 文件找不到域名時(shí)，客戶端就會(huì)訪問(wèn)本地 DNS 服務(wù)器。

這時(shí)候:

如果本地 DNS 服務(wù)器有緩存該網(wǎng)站的地址，則直接返回網(wǎng)站的地址；如果沒(méi)有就通過(guò)遞歸查詢的方式，先請(qǐng)求根 DNS，根 DNS 返回頂級(jí) DNS（.com）的地址；再請(qǐng)求 .com 頂級(jí) DNS 得到 xiaolin.com 的域名服務(wù)器地址，再?gòu)?xiaolin.com 的域名服務(wù)器中查詢到 www.xiaolin.com 對(duì)應(yīng)的 IP 地址，然后返回這個(gè) IP 地址，同時(shí)本地 DNS 緩存該 IP 地址，這樣下一次的解析同一個(gè)域名就不需要做 DNS 的迭代查詢了。

但加入 CDN 后就不一樣了。

會(huì)在 xiaolin.com 這個(gè) DNS 服務(wù)器上，設(shè)置一個(gè) CNAME 別名，指向另外一個(gè)域名 www.xiaolin.cdn.com，返回給本地 DNS 服務(wù)器。

接著繼續(xù)解析該域名，這個(gè)時(shí)候訪問(wèn)的就是 xiaolin.cdn.com 這臺(tái) CDN 專用的 DNS 服務(wù)器，在這個(gè)服務(wù)器上，又會(huì)設(shè)置一個(gè) CNAME，指向另外一個(gè)域名，這次指向的就是 CDN 的 GSLB。

接著，本地 DNS 服務(wù)器去請(qǐng)求 CDN 的 GSLB 的域名，GSLB 就會(huì)為用戶選擇一臺(tái)合適的 CDN 節(jié)點(diǎn)提供服務(wù)，選擇的依據(jù)主要有以下幾點(diǎn)：

看用戶的 IP 地址，查表得知地理位置，找相對(duì)最近的 CDN 節(jié)點(diǎn)；看用戶所在的運(yùn)營(yíng)商網(wǎng)絡(luò)，找相同網(wǎng)絡(luò)的 CDN 節(jié)點(diǎn)；看用戶請(qǐng)求 URL，判斷哪一臺(tái)服務(wù)器上有用戶所請(qǐng)求的資源；查詢 CDN 節(jié)點(diǎn)的負(fù)載情況，找負(fù)載較輕的節(jié)點(diǎn)；

GSLB 會(huì)基于以上的條件進(jìn)行綜合分析后，找出一臺(tái)最合適的 CDN 節(jié)點(diǎn)，并返回該 CDN 節(jié)點(diǎn)的 IP 地址給本地 DNS 服務(wù)器，然后本地 DNS 服務(wù)器緩存該 IP 地址，并將 IP 返回給客戶端，客戶端去訪問(wèn)這個(gè) CDN 節(jié)點(diǎn)，下載資源。

TCP的close_wait在哪端，如果我們場(chǎng)景中出現(xiàn)了大量的close_wait，你覺(jué)得要怎么排查

答：被動(dòng)方，代碼邏輯有問(wèn)題，沒(méi)close

補(bǔ)充：

CLOSE_WAIT 狀態(tài)是「被動(dòng)關(guān)閉方」才會(huì)有的狀態(tài)，而且如果「被動(dòng)關(guān)閉方」沒(méi)有調(diào)用 close 函數(shù)關(guān)閉連接，那么就無(wú)法發(fā)出 FIN 報(bào)文，從而無(wú)法使得 CLOSE_WAIT 狀態(tài)的連接轉(zhuǎn)變?yōu)?LAST_ACK 狀態(tài)。

所以，當(dāng)服務(wù)端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接的時(shí)候，說(shuō)明服務(wù)端的程序沒(méi)有調(diào)用 close 函數(shù)關(guān)閉連接。

那什么情況會(huì)導(dǎo)致服務(wù)端的程序沒(méi)有調(diào)用 close 函數(shù)關(guān)閉連接？這時(shí)候通常需要排查代碼。

我們先來(lái)分析一個(gè)普通的 TCP 服務(wù)端的流程：

創(chuàng)建服務(wù)端 socket，bind 綁定端口、listen 監(jiān)聽(tīng)端口將服務(wù)端 socket 注冊(cè)到 epollepoll_wait 等待連接到來(lái)，連接到來(lái)時(shí)，調(diào)用 accpet 獲取已連接的 socket將已連接的 socket 注冊(cè)到 epollepoll_wait 等待事件發(fā)生對(duì)方連接關(guān)閉時(shí)，我方調(diào)用 close

可能導(dǎo)致服務(wù)端沒(méi)有調(diào)用 close 函數(shù)的原因，如下。

第一個(gè)原因：第 2 步?jīng)]有做，沒(méi)有將服務(wù)端 socket 注冊(cè)到 epoll，這樣有新連接到來(lái)時(shí)，服務(wù)端沒(méi)辦法感知這個(gè)事件，也就無(wú)法獲取到已連接的 socket，那服務(wù)端自然就沒(méi)機(jī)會(huì)對(duì) socket 調(diào)用 close 函數(shù)了。

不過(guò)這種原因發(fā)生的概率比較小，這種屬于明顯的代碼邏輯 bug，在前期 read view 階段就能發(fā)現(xiàn)的了。

第二個(gè)原因：第 3 步?jīng)]有做，有新連接到來(lái)時(shí)沒(méi)有調(diào)用 accpet 獲取該連接的 socket，導(dǎo)致當(dāng)有大量的客戶端主動(dòng)斷開(kāi)了連接，而服務(wù)端沒(méi)機(jī)會(huì)對(duì)這些 socket 調(diào)用 close 函數(shù)，從而導(dǎo)致服務(wù)端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接。

發(fā)生這種情況可能是因?yàn)榉?wù)端在執(zhí)行 accpet 函數(shù)之前，代碼卡在某一個(gè)邏輯或者提前拋出了異常。

第三個(gè)原因：第 4 步?jīng)]有做，通過(guò) accpet 獲取已連接的 socket 后，沒(méi)有將其注冊(cè)到 epoll，導(dǎo)致后續(xù)收到 FIN 報(bào)文的時(shí)候，服務(wù)端沒(méi)辦法感知這個(gè)事件，那服務(wù)端就沒(méi)機(jī)會(huì)調(diào)用 close 函數(shù)了。

發(fā)生這種情況可能是因?yàn)榉?wù)端在將已連接的 socket 注冊(cè)到 epoll 之前，代碼卡在某一個(gè)邏輯或者提前拋出了異常。之前看到過(guò)別人解決 close_wait 問(wèn)題的實(shí)踐文章，感興趣的可以看看：一次 Netty 代碼不健壯導(dǎo)致的大量 CLOSE_WAIT 連接原因分析

第四個(gè)原因：第 6 步?jīng)]有做，當(dāng)發(fā)現(xiàn)客戶端關(guān)閉連接后，服務(wù)端沒(méi)有執(zhí)行 close 函數(shù)，可能是因?yàn)榇a漏處理，或者是在執(zhí)行 close 函數(shù)之前，代碼卡在某一個(gè)邏輯，比如發(fā)生死鎖等等。

可以發(fā)現(xiàn)，當(dāng)服務(wù)端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接的時(shí)候，通常都是代碼的問(wèn)題，這時(shí)候我們需要針對(duì)具體的代碼一步一步的進(jìn)行排查和定位，主要分析的方向就是服務(wù)端為什么沒(méi)有調(diào)用 close。

TCP粘包問(wèn)題怎么解決答：特殊標(biāo)記追問(wèn)：打斷，如果使用特殊標(biāo)記解決會(huì)遇到什么問(wèn)題答：正文轉(zhuǎn)義字符

補(bǔ)充：

1、固定長(zhǎng)度的消息

這種是最簡(jiǎn)單方法，即每個(gè)用戶消息都是固定長(zhǎng)度的，比如規(guī)定一個(gè)消息的長(zhǎng)度是 64 個(gè)字節(jié)，當(dāng)接收方接滿 64 個(gè)字節(jié)，就認(rèn)為這個(gè)內(nèi)容是一個(gè)完整且有效的消息。

但是這種方式靈活性不高，實(shí)際中很少用。

2、特殊字符作為邊界

我們可以在兩個(gè)用戶消息之間插入一個(gè)特殊的字符串，這樣接收方在接收數(shù)據(jù)時(shí)，讀到了這個(gè)特殊字符，就把認(rèn)為已經(jīng)讀完一個(gè)完整的消息。

HTTP 是一個(gè)非常好的例子。

HTTP 通過(guò)設(shè)置回車符、換行符作為 HTTP 報(bào)文協(xié)議的邊界。

有一點(diǎn)要注意，這個(gè)作為邊界點(diǎn)的特殊字符，如果剛好消息內(nèi)容里有這個(gè)特殊字符，我們要對(duì)這個(gè)字符轉(zhuǎn)義，避免被接收方當(dāng)作消息的邊界點(diǎn)而解析到無(wú)效的數(shù)據(jù)。

3、自定義消息結(jié)構(gòu)

我們可以自定義一個(gè)消息結(jié)構(gòu)，由包頭和數(shù)據(jù)組成，其中包頭包是固定大小的，而且包頭里有一個(gè)字段來(lái)說(shuō)明緊隨其后的數(shù)據(jù)有多大。

比如這個(gè)消息結(jié)構(gòu)體，首先 4 個(gè)字節(jié)大小的變量來(lái)表示數(shù)據(jù)長(zhǎng)度，真正的數(shù)據(jù)則在后面。

struct {     u_int32_t message_length;     char message_data[]; } message;

當(dāng)接收方接收到包頭的大?。ū热?4 個(gè)字節(jié)）后，就解析包頭的內(nèi)容，于是就可以知道數(shù)據(jù)的長(zhǎng)度，然后接下來(lái)就繼續(xù)讀取數(shù)據(jù)，直到讀滿數(shù)據(jù)的長(zhǎng)度，就可以組裝成一個(gè)完整到用戶消息來(lái)處理了。

protobuf了解嗎

答：不了解

補(bǔ)充：

Protobuf 是用于數(shù)據(jù)序列化和反序列化的格式，類似于 json。但它們有以下幾點(diǎn)區(qū)別：

數(shù)據(jù)大?。篜rotobuf是一種二進(jìn)制格式，相對(duì)于JSON來(lái)說(shuō)，數(shù)據(jù)大小更小，序列化和反序列化的效率更高，因此在網(wǎng)絡(luò)傳輸和存儲(chǔ)方面具有一定的優(yōu)勢(shì)。性能：由于Protobuf是二進(jìn)制格式，相對(duì)于JSON來(lái)說(shuō)，解析速度更快，占用的CPU和內(nèi)存資源更少，因此在高并發(fā)場(chǎng)景下，性能更優(yōu)。可讀性：JSON是一種文本格式，可讀性更好，易于調(diào)試和排查問(wèn)題。而Protobuf是一種二進(jìn)制格式，可讀性較差。

Protobuf適用于高性能、大數(shù)據(jù)量、高并發(fā)等場(chǎng)景，而JSON適用于數(shù)據(jù)交換、易讀性要求高的場(chǎng)景。

說(shuō)一下代碼里使用異步的思路

答：舉了個(gè)客戶端異步connect，使用select檢測(cè)結(jié)果的例子

順勢(shì)問(wèn)select/epoll的區(qū)別

答：常規(guī)八股回答

補(bǔ)充：

select 和 poll 的缺陷在于，當(dāng)客戶端越多，也就是 Socket 集合越大，Socket 集合的遍歷和拷貝會(huì)帶來(lái)很大的開(kāi)銷，因此也很難應(yīng)對(duì) C10K。

epoll 是解決 C10K 問(wèn)題的利器，通過(guò)兩個(gè)方面解決了 select/poll 的問(wèn)題。

epoll 在內(nèi)核里使用「紅黑樹(shù)」來(lái)關(guān)注進(jìn)程所有待檢測(cè)的 Socket，紅黑樹(shù)是個(gè)高效的數(shù)據(jù)結(jié)構(gòu)，增刪改一般時(shí)間復(fù)雜度是 O(logn)，通過(guò)對(duì)這棵黑紅樹(shù)的管理，不需要像 select/poll 在每次操作時(shí)都傳入整個(gè) Socket 集合，減少了內(nèi)核和用戶空間大量的數(shù)據(jù)拷貝和內(nèi)存分配。epoll 使用事件驅(qū)動(dòng)的機(jī)制，內(nèi)核里維護(hù)了一個(gè)「鏈表」來(lái)記錄就緒事件，只將有事件發(fā)生的 Socket 集合傳遞給應(yīng)用程序，不需要像 select/poll 那樣輪詢掃描整個(gè)集合（包含有和無(wú)事件的 Socket ），大大提高了檢測(cè)的效率。IO特別密集時(shí)epoll效率還高嗎

答：可以考慮select/poll，這種情況輪詢也很高效，且結(jié)構(gòu)簡(jiǎn)單。

補(bǔ)充：

可以先解釋io特別密集時(shí)為什么 epoll 效率不高。原因是：

連接密集（短連接特別多），使用epoll的話，每一次連接需要發(fā)生epoll_wait->accpet->epoll_ctl調(diào)用，而使用select只需要select->accpet，減少了一次系統(tǒng)調(diào)用。讀寫(xiě)密集的話，如果收到數(shù)據(jù)，我們需要響應(yīng)數(shù)據(jù)的話，使用epoll的情況下， read 完后也需要epoll_ctl 加入寫(xiě)事件，相比select多了一次系統(tǒng)調(diào)用講一講ET模式

答：常規(guī)八股回答

補(bǔ)充：

epoll 支持兩種事件觸發(fā)模式，分別是邊緣觸發(fā)（edge-triggered，ET）和水平觸發(fā)（level-triggered，LT）。

這兩個(gè)術(shù)語(yǔ)還挺抽象的，其實(shí)它們的區(qū)別還是很好理解的。

使用邊緣觸發(fā)模式時(shí)，當(dāng)被監(jiān)控的 Socket 描述符上有可讀事件發(fā)生時(shí)，服務(wù)器端只會(huì)從 epoll_wait 中蘇醒一次，即使進(jìn)程沒(méi)有調(diào)用 read 函數(shù)從內(nèi)核讀取數(shù)據(jù)，也依然只蘇醒一次，因此我們程序要保證一次性將內(nèi)核緩沖區(qū)的數(shù)據(jù)讀取完；使用水平觸發(fā)模式時(shí)，當(dāng)被監(jiān)控的 Socket 上有可讀事件發(fā)生時(shí)，服務(wù)器端不斷地從 epoll_wait 中蘇醒，直到內(nèi)核緩沖區(qū)數(shù)據(jù)被 read 函數(shù)讀完才結(jié)束，目的是告訴我們有數(shù)據(jù)需要讀??；

舉個(gè)例子，你的快遞被放到了一個(gè)快遞箱里，如果快遞箱只會(huì)通過(guò)短信通知你一次，即使你一直沒(méi)有去取，它也不會(huì)再發(fā)送第二條短信提醒你，這個(gè)方式就是邊緣觸發(fā)；如果快遞箱發(fā)現(xiàn)你的快遞沒(méi)有被取出，它就會(huì)不停地發(fā)短信通知你，直到你取出了快遞，它才消停，這個(gè)就是水平觸發(fā)的方式。

這就是兩者的區(qū)別，水平觸發(fā)的意思是只要滿足事件的條件，比如內(nèi)核中有數(shù)據(jù)需要讀，就一直不斷地把這個(gè)事件傳遞給用戶；而邊緣觸發(fā)的意思是只有第一次滿足條件的時(shí)候才觸發(fā)，之后就不會(huì)再傳遞同樣的事件了。

如果使用水平觸發(fā)模式，當(dāng)內(nèi)核通知文件描述符可讀寫(xiě)時(shí)，接下來(lái)還可以繼續(xù)去檢測(cè)它的狀態(tài)，看它是否依然可讀或可寫(xiě)。所以在收到通知后，沒(méi)必要一次執(zhí)行盡可能多的讀寫(xiě)操作。

如果使用邊緣觸發(fā)模式，I/O 事件發(fā)生時(shí)只會(huì)通知一次，而且我們不知道到底能讀寫(xiě)多少數(shù)據(jù)，所以在收到通知后應(yīng)盡可能地讀寫(xiě)數(shù)據(jù)，以免錯(cuò)失讀寫(xiě)的機(jī)會(huì)。因此，我們會(huì)循環(huán)從文件描述符讀寫(xiě)數(shù)據(jù)，那么如果文件描述符是阻塞的，沒(méi)有數(shù)據(jù)可讀寫(xiě)時(shí)，進(jìn)程會(huì)阻塞在讀寫(xiě)函數(shù)那里，程序就沒(méi)辦法繼續(xù)往下執(zhí)行。所以，邊緣觸發(fā)模式一般和非阻塞 I/O 搭配使用，程序會(huì)一直執(zhí)行 I/O 操作，直到系統(tǒng)調(diào)用（如read和write）返回錯(cuò)誤，錯(cuò)誤類型為EAGAIN或EWOULDBLOCK。

一般來(lái)說(shuō)，邊緣觸發(fā)的效率比水平觸發(fā)的效率要高，因?yàn)檫吘売|發(fā)可以減少 epoll_wait 的系統(tǒng)調(diào)用次數(shù)，系統(tǒng)調(diào)用也是有一定的開(kāi)銷的的，畢竟也存在上下文的切換。

對(duì)于一個(gè)后端服務(wù)怎么提升性能回答：講了存儲(chǔ)層面的使用中間緩存、網(wǎng)絡(luò)框架設(shè)計(jì)優(yōu)化追問(wèn)：提示長(zhǎng)連接短連接追問(wèn)：怎么避免拷貝呢，不同的層面說(shuō)說(shuō)回答：C++移動(dòng)語(yǔ)義、零拷貝追問(wèn)：零拷貝的使用場(chǎng)景追問(wèn)：kafka了解嗎回答：不了解追問(wèn)：建議關(guān)注一下kafka，很快很好用算法

手撕：合并兩個(gè)有序鏈表

感受

基礎(chǔ)問(wèn)題大部分還好，面試官最后評(píng)價(jià)還不錯(cuò)。

關(guān)鍵詞：