大家好，我是小林。

互聯(lián)網(wǎng)崗位里，可以說后端開發(fā)是最卷，投的人最多的，但是隔壁的客戶端開發(fā)投的就很少，有后端同學(xué)會被客戶端部門撈起來去面試，所以如果卷不過后端，又想進大廠的同學(xué)，可以嘗試投客戶端開發(fā)，面試相對沒那么卷，薪資待遇跟后端也是一樣的。

今天分享一位快手客戶端一二三面的面經(jīng)，同學(xué)的技術(shù)棧是C++后端，但是面試不會問后端內(nèi)容了，主要就圍繞Cpp+操作系統(tǒng)+網(wǎng)絡(luò)協(xié)議+算法來問，相比后端所需要準備的內(nèi)容就少了 mysql 、redis、消息隊列等后端組件，但是計算基礎(chǔ)的深度會問的比較深一點。

由其第三面，直接給兩個場景代碼題手寫出來，還是有點難度。。

快手一面

擁塞控制介紹一下

在網(wǎng)絡(luò)出現(xiàn)擁堵時，如果繼續(xù)發(fā)送大量數(shù)據(jù)包，可能會導(dǎo)致數(shù)據(jù)包時延、丟失等，這時 TCP 就會重傳數(shù)據(jù)，但是一重傳就會導(dǎo)致網(wǎng)絡(luò)的負擔(dān)更重，于是會導(dǎo)致更大的延遲以及更多的丟包，這個情況就會進入惡性循環(huán)被不斷地放大....

所以，TCP 不能忽略網(wǎng)絡(luò)上發(fā)生的事，它被設(shè)計成一個無私的協(xié)議，當(dāng)網(wǎng)絡(luò)發(fā)送擁塞時，TCP 會自我犧牲，降低發(fā)送的數(shù)據(jù)量。

于是，就有了擁塞控制，控制的目的就是避免「發(fā)送方」的數(shù)據(jù)填滿整個網(wǎng)絡(luò)。

為了在「發(fā)送方」調(diào)節(jié)所要發(fā)送數(shù)據(jù)的量，定義了一個叫做「擁塞窗口」的概念。

擁塞控制主要是四個算法：

• 慢啟動
• 擁塞避免
• 擁塞發(fā)生
• 快速恢復(fù)

慢啟動

TCP 在剛建立連接完成后，首先是有個慢啟動的過程，這個慢啟動的意思就是一點一點的提高發(fā)送數(shù)據(jù)包的數(shù)量，如果一上來就發(fā)大量的數(shù)據(jù)，這不是給網(wǎng)絡(luò)添堵嗎？

慢啟動的算法記住一個規(guī)則就行：當(dāng)發(fā)送方每收到一個 ACK，擁塞窗口 cwnd 的大小就會加 1。

這里假定擁塞窗口 cwnd 和發(fā)送窗口 swnd 相等，下面舉個栗子：

• 連接建立完成后，一開始初始化 cwnd = 1，表示可以傳一個 MSS 大小的數(shù)據(jù)。
• 當(dāng)收到一個 ACK 確認應(yīng)答后，cwnd 增加 1，于是一次能夠發(fā)送 2 個
• 當(dāng)收到 2 個的 ACK 確認應(yīng)答后， cwnd 增加 2，于是就可以比之前多發(fā)2 個，所以這一次能夠發(fā)送 4 個
• 當(dāng)這 4 個的 ACK 確認到來的時候，每個確認 cwnd 增加 1， 4 個確認 cwnd 增加 4，于是就可以比之前多發(fā) 4 個，所以這一次能夠發(fā)送 8 個。

慢啟動算法的變化過程如下圖：

慢啟動算法

可以看出慢啟動算法，發(fā)包的個數(shù)是指數(shù)性的增長。

那慢啟動漲到什么時候是個頭呢？

有一個叫慢啟動門限 ssthresh （slow start threshold）狀態(tài)變量。

• 當(dāng) cwnd < ssthresh 時，使用慢啟動算法。
• 當(dāng) cwnd >= ssthresh 時，就會使用「擁塞避免算法」。

擁塞避免

當(dāng)擁塞窗口 cwnd 「超過」慢啟動門限 ssthresh 就會進入擁塞避免算法。

一般來說 ssthresh 的大小是 65535 字節(jié)。

那么進入擁塞避免算法后，它的規(guī)則是：每當(dāng)收到一個 ACK 時，cwnd 增加 1/cwnd。

接上前面的慢啟動的栗子，現(xiàn)假定 ssthresh 為 8：

• 當(dāng) 8 個 ACK 應(yīng)答確認到來時，每個確認增加 1/8，8 個 ACK 確認 cwnd 一共增加 1，于是這一次能夠發(fā)送 9 個 MSS 大小的數(shù)據(jù)，變成了線性增長。

擁塞避免算法的變化過程如下圖：

擁塞避免

所以，我們可以發(fā)現(xiàn)，擁塞避免算法就是將原本慢啟動算法的指數(shù)增長變成了線性增長，還是增長階段，但是增長速度緩慢了一些。

就這么一直增長著后，網(wǎng)絡(luò)就會慢慢進入了擁塞的狀況了，于是就會出現(xiàn)丟包現(xiàn)象，這時就需要對丟失的數(shù)據(jù)包進行重傳。

當(dāng)觸發(fā)了重傳機制，也就進入了「擁塞發(fā)生算法」。

擁塞發(fā)生

當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞，也就是會發(fā)生數(shù)據(jù)包重傳，重傳機制主要有兩種：

• 超時重傳
• 快速重傳

當(dāng)發(fā)生了「超時重傳」，則就會使用擁塞發(fā)生算法。

這個時候，ssthresh 和 cwnd 的值會發(fā)生變化：

• ssthresh 設(shè)為 cwnd/2，
• cwnd 重置為 1 （是恢復(fù)為 cwnd 初始化值，我這里假定 cwnd 初始化值 1）

擁塞發(fā)生算法的變化如下圖：

擁塞發(fā)送 —— 超時重傳

接著，就重新開始慢啟動，慢啟動是會突然減少數(shù)據(jù)流的。這真是一旦「超時重傳」，馬上回到解放前。但是這種方式太激進了，反應(yīng)也很強烈，會造成網(wǎng)絡(luò)卡頓。

還有更好的方式，前面我們講過「快速重傳算法」。當(dāng)接收方發(fā)現(xiàn)丟了一個中間包的時候，發(fā)送三次前一個包的 ACK，于是發(fā)送端就會快速地重傳，不必等待超時再重傳。

TCP 認為這種情況不嚴重，因為大部分沒丟，只丟了一小部分，則 ssthresh 和 cwnd 變化如下：

• cwnd = cwnd/2 ，也就是設(shè)置為原來的一半;
• ssthresh = cwnd;
• 進入快速恢復(fù)算法

快速恢復(fù)

快速重傳和快速恢復(fù)算法一般同時使用，快速恢復(fù)算法是認為，你還能收到 3 個重復(fù) ACK 說明網(wǎng)絡(luò)也不那么糟糕，所以沒有必要像 RTO 超時那么強烈。

正如前面所說，進入快速恢復(fù)之前，cwnd 和 ssthresh 已被更新了：

• cwnd = cwnd/2 ，也就是設(shè)置為原來的一半;
• ssthresh = cwnd;

然后，進入快速恢復(fù)算法如下：

• 擁塞窗口 cwnd = ssthresh + 3 （ 3 的意思是確認有 3 個數(shù)據(jù)包被收到了）；
• 重傳丟失的數(shù)據(jù)包；
• 如果再收到重復(fù)的 ACK，那么 cwnd 增加 1；
• 如果收到新數(shù)據(jù)的 ACK 后，把 cwnd 設(shè)置為第一步中的 ssthresh 的值，原因是該 ACK 確認了新的數(shù)據(jù)，說明從 duplicated ACK 時的數(shù)據(jù)都已收到，該恢復(fù)過程已經(jīng)結(jié)束，可以回到恢復(fù)之前的狀態(tài)了，也即再次進入擁塞避免狀態(tài)；

快速恢復(fù)算法的變化過程如下圖：

快速重傳和快速恢復(fù)

也就是沒有像「超時重傳」一夜回到解放前，而是還在比較高的值，后續(xù)呈線性增長。

http/https 的區(qū)別？

• HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，存在安全風(fēng)險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網(wǎng)絡(luò)層之間加入了 SSL/TLS 安全協(xié)議，使得報文能夠加密傳輸。
• HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。
• 兩者的默認端口不一樣，HTTP 默認端口號是 80，HTTPS 默認端口號是 443。
• HTTPS 協(xié)議需要向 CA（證書權(quán)威機構(gòu)）申請數(shù)字證書，來保證服務(wù)器的身份是可信的。

Https四次加密過程？

基于 RSA 算法的 TLS 握手過程比較容易理解，所以這里先用這個給大家展示 TLS 握手過程，如下圖：

HTTPS 連接建立過程

TLS 協(xié)議建立的詳細流程：

1. ClientHello

首先，由客戶端向服務(wù)器發(fā)起加密通信請求，也就是 ClientHello 請求。

在這一步，客戶端主要向服務(wù)器發(fā)送以下信息：

（1）客戶端支持的 TLS 協(xié)議版本，如 TLS 1.2 版本。

（2）客戶端生產(chǎn)的隨機數(shù)（Client Random），后面用于生成「會話秘鑰」條件之一。

（3）客戶端支持的密碼套件列表，如 RSA 加密算法。

2. SeverHello

服務(wù)器收到客戶端請求后，向客戶端發(fā)出響應(yīng)，也就是 SeverHello。服務(wù)器回應(yīng)的內(nèi)容有如下內(nèi)容：

（1）確認 TLS 協(xié)議版本，如果瀏覽器不支持，則關(guān)閉加密通信。

（2）服務(wù)器生產(chǎn)的隨機數(shù)（Server Random），也是后面用于生產(chǎn)「會話秘鑰」條件之一。

（3）確認的密碼套件列表，如 RSA 加密算法。

（4）服務(wù)器的數(shù)字證書。

3.客戶端回應(yīng)

客戶端收到服務(wù)器的回應(yīng)之后，首先通過瀏覽器或者操作系統(tǒng)中的 CA 公鑰，確認服務(wù)器的數(shù)字證書的真實性。

如果證書沒有問題，客戶端會從數(shù)字證書中取出服務(wù)器的公鑰，然后使用它加密報文，向服務(wù)器發(fā)送如下信息：

（1）一個隨機數(shù)（pre-master key）。該隨機數(shù)會被服務(wù)器公鑰加密。

（2）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。

（3）客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項同時把之前所有內(nèi)容的發(fā)生的數(shù)據(jù)做個摘要，用來供服務(wù)端校驗。

上面第一項的隨機數(shù)是整個握手階段的第三個隨機數(shù)，會發(fā)給服務(wù)端，所以這個隨機數(shù)客戶端和服務(wù)端都是一樣的。

服務(wù)器和客戶端有了這三個隨機數(shù)（Client Random、Server Random、pre-master key），接著就用雙方協(xié)商的加密算法，各自生成本次通信的「會話秘鑰」。

4. 服務(wù)器的最后回應(yīng)

服務(wù)器收到客戶端的第三個隨機數(shù)（pre-master key）之后，通過協(xié)商的加密算法，計算出本次通信的「會話秘鑰」。

然后，向客戶端發(fā)送最后的信息：

（1）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。

（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項同時把之前所有內(nèi)容的發(fā)生的數(shù)據(jù)做個摘要，用來供客戶端校驗。

至此，整個 TLS 的握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進入加密通信，就完全是使用普通的 HTTP 協(xié)議，只不過用「會話秘鑰」加密內(nèi)容。

get和post的區(qū)別？

• 根據(jù) RFC 規(guī)范，GET 的語義是從服務(wù)器獲取指定的資源，這個資源可以是靜態(tài)的文本、頁面、圖片視頻等。GET 請求的參數(shù)位置一般是寫在 URL 中，URL 規(guī)定只能支持 ASCII，所以 GET 請求的參數(shù)只允許 ASCII 字符 ，而且瀏覽器會對 URL 的長度有限制（HTTP協(xié)議本身對 URL長度并沒有做任何規(guī)定）。
• 根據(jù) RFC 規(guī)范，POST 的語義是根據(jù)請求負荷（報文body）對指定的資源做出處理，具體的處理方式視資源類型而不同。POST 請求攜帶數(shù)據(jù)的位置一般是寫在報文 body 中，body 中的數(shù)據(jù)可以是任意格式的數(shù)據(jù)，只要客戶端與服務(wù)端協(xié)商好即可，而且瀏覽器不會對 body 大小做限制。

進程線程有什么區(qū)別？

• 資源占用：每個進程都有獨立的地址空間、文件描述符和其他系統(tǒng)資源，進程之間的資源是相互獨立的，而線程共享所屬進程的地址空間和資源，包括文件描述符、信號處理等。
• 調(diào)度和切換：進程是系統(tǒng)進行調(diào)度和分配資源的基本單位，進程之間的切換開銷相對較大。而線程是在進程內(nèi)部執(zhí)行的，線程的切換開銷相對較小。
• 通信和同步：進程之間通信的方式包括管道、消息隊列、共享內(nèi)存等，進程間通信相對復(fù)雜。線程之間共享進程的內(nèi)存空間，直接讀寫共享數(shù)據(jù)即可實現(xiàn)通信和同步。

線程有哪些資源，棧中保存什么？

線程在操作系統(tǒng)中有一些特定的資源，包括：

• 線程控制塊（Thread Control Block，TCB）：用于保存線程的狀態(tài)信息，如程序計數(shù)器（Program Counter，PC）、寄存器值、線程 ID、線程優(yōu)先級等。
• 棧（Stack）：每個線程都有自己的?？臻g，用于保存函數(shù)調(diào)用的局部變量、函數(shù)的返回地址以及其他臨時數(shù)據(jù)。棧是線程私有的，不同線程之間的棧是相互獨立的。
• 寄存器（Registers）：線程在執(zhí)行過程中會使用到寄存器，包括通用寄存器（如EAX、EBX等）、程序計數(shù)器（PC）等。寄存器保存了線程當(dāng)前的執(zhí)行狀態(tài)。
• 共享資源：線程可以共享所屬進程的資源，如打開的文件、信號處理器等。這些資源可以在線程之間共享和訪問。

棧中，主要保存了以下內(nèi)容：

• 函數(shù)調(diào)用的局部變量：當(dāng)一個函數(shù)被調(diào)用時，其局部變量會被保存在棧中。這些局部變量在函數(shù)執(zhí)行結(jié)束后會被銷毀。
• 函數(shù)的返回地址：當(dāng)一個函數(shù)執(zhí)行完畢后，需要返回到調(diào)用該函數(shù)的地址。返回地址會被保存在棧中，以便函數(shù)執(zhí)行完畢后能夠正確返回。
• 函數(shù)調(diào)用過程中的臨時數(shù)據(jù)：在函數(shù)執(zhí)行過程中，可能會需要保存一些臨時數(shù)據(jù)，如函數(shù)的參數(shù)、中間計算結(jié)果等，這些數(shù)據(jù)會保存在棧中。

函數(shù)調(diào)用的時候，壓棧怎么樣的

函數(shù)調(diào)用時，會進行以下壓棧操作：

• 保存返回地址：在函數(shù)調(diào)用前，調(diào)用指令會將下一條指令的地址（即函數(shù)調(diào)用后需要繼續(xù)執(zhí)行的地址）壓入棧中，以便函數(shù)執(zhí)行完畢后能夠正確返回到調(diào)用點。
• 保存調(diào)用者的棧幀指針：在函數(shù)調(diào)用前，調(diào)用指令會將當(dāng)前棧幀指針（即調(diào)用者的棧指針）壓入棧中，以便函數(shù)執(zhí)行完畢后能夠恢復(fù)到調(diào)用者的執(zhí)行狀態(tài)。
• 傳遞參數(shù)：函數(shù)調(diào)用時，會將參數(shù)值依次壓入棧中，這些參數(shù)值在函數(shù)內(nèi)部可以通過棧來訪問。
• 分配局部變量空間：函數(shù)調(diào)用時，會為局部變量分配空間，這些局部變量會被保存在棧中。棧指針會相應(yīng)地移動以適應(yīng)新的局部變量空間。

靜態(tài)鏈接庫和動態(tài)鏈接庫有什么區(qū)別？

• 鏈接方式：靜態(tài)鏈接庫在編譯鏈接時會被完整地復(fù)制到可執(zhí)行文件中，成為可執(zhí)行文件的一部分；而動態(tài)鏈接庫在編譯鏈接時只會在可執(zhí)行文件中包含對庫的引用，實際的庫文件在運行時由操作系統(tǒng)動態(tài)加載。
• 文件大?。红o態(tài)鏈接庫會使得可執(zhí)行文件的大小增加，因為庫的代碼被完整地復(fù)制到可執(zhí)行文件中；而動態(tài)鏈接庫不會增加可執(zhí)行文件的大小，因為庫的代碼在運行時才會被加載。
• 內(nèi)存占用：靜態(tài)鏈接庫在運行時會被完整地加載到內(nèi)存中，占用固定的內(nèi)存空間；而動態(tài)鏈接庫在運行時才會被加載，可以在多個進程之間共享，減少內(nèi)存占用。
• 可擴展性：動態(tài)鏈接庫的可擴展性更好，可以在不修改可執(zhí)行文件的情況下替換或添加新的庫文件，而靜態(tài)鏈接庫需要重新編譯鏈接。

動態(tài)鏈接庫怎么裝載到內(nèi)存的？

通過用mmap把該庫直接映射到各個進程的地址空間中，盡管每個進程都認為自己地址空間中加載了該庫，但實際上該庫在內(nèi)存中只有一份，mmap就這樣很神奇和動態(tài)鏈接庫聯(lián)動起來了。

圖片

虛擬內(nèi)存介紹一下

• 第一，虛擬內(nèi)存可以使得進程對運行內(nèi)存超過物理內(nèi)存大小，因為程序運行符合局部性原理，CPU 訪問內(nèi)存會有很明顯的重復(fù)訪問的傾向性，對于那些沒有被經(jīng)常使用到的內(nèi)存，我們可以把它換出到物理內(nèi)存之外，比如硬盤上的 swap 區(qū)域。
• 第二，由于每個進程都有自己的頁表，所以每個進程的虛擬內(nèi)存空間就是相互獨立的。進程也沒有辦法訪問其他進程的頁表，所以這些頁表是私有的，這就解決了多進程之間地址沖突的問題。
• 第三，頁表里的頁表項中除了物理地址之外，還有一些標(biāo)記屬性的比特，比如控制一個頁的讀寫權(quán)限，標(biāo)記該頁是否存在等。在內(nèi)存訪問方面，操作系統(tǒng)提供了更好的安全性。

中斷是什么

在操作系統(tǒng)中，中斷是指由硬件或軟件觸發(fā)的一種事件，它會暫時中止當(dāng)前正在執(zhí)行的程序，并轉(zhuǎn)而執(zhí)行與中斷相關(guān)的處理程序。中斷可以是內(nèi)部的，如除法錯誤或越界訪問，也可以是外部的，如硬件設(shè)備的輸入/輸出請求或時鐘中斷。

中斷的作用是提供一種機制來處理和響應(yīng)各種事件，例如處理硬件設(shè)備的輸入/輸出請求、處理異常情況、進行時鐘調(diào)度等。當(dāng)發(fā)生中斷時，操作系統(tǒng)會根據(jù)中斷類型確定要執(zhí)行的中斷處理程序，并在處理完中斷后恢復(fù)原來的程序執(zhí)行。

中斷處理程序可以執(zhí)行一系列操作，如保存當(dāng)前進程的上下文、處理中斷事件、與設(shè)備進行通信、調(diào)度其他進程等。通過使用中斷，操作系統(tǒng)可以實現(xiàn)多任務(wù)處理、實時響應(yīng)外部事件、提高系統(tǒng)的可靠性和穩(wěn)定性。

操作系統(tǒng)的鎖，自己實現(xiàn)一個讀寫鎖

讀者只會讀取數(shù)據(jù)，不會修改數(shù)據(jù)，而寫者即可以讀也可以修改數(shù)據(jù)。

讀者-寫者的問題描述：

• 「讀-讀」允許：同一時刻，允許多個讀者同時讀
• 「讀-寫」互斥：沒有寫者時讀者才能讀，沒有讀者時寫者才能寫
• 「寫-寫」互斥：沒有其他寫者時，寫者才能寫

接下來，提出幾個解決方案來分析分析。

方案一

使用信號量的方式來嘗試解決：

• 信號量 wMutex：控制寫操作的互斥信號量，初始值為 1 ；
• 讀者計數(shù) rCount：正在進行讀操作的讀者個數(shù)，初始化為 0；
• 信號量 rCountMutex：控制對 rCount 讀者計數(shù)器的互斥修改，初始值為 1；

接下來看看代碼的實現(xiàn)：

圖片

上面的這種實現(xiàn)，是讀者優(yōu)先的策略，因為只要有讀者正在讀的狀態(tài)，后來的讀者都可以直接進入，如果讀者持續(xù)不斷進入，則寫者會處于饑餓狀態(tài)。

方案二

那既然有讀者優(yōu)先策略，自然也有寫者優(yōu)先策略：

• 只要有寫者準備要寫入，寫者應(yīng)盡快執(zhí)行寫操作，后來的讀者就必須阻塞；
• 如果有寫者持續(xù)不斷寫入，則讀者就處于饑餓；

在方案一的基礎(chǔ)上新增如下變量：

• 信號量 rMutex：控制讀者進入的互斥信號量，初始值為 1；
• 信號量 wDataMutex：控制寫者寫操作的互斥信號量，初始值為 1；
• 寫者計數(shù) wCount：記錄寫者數(shù)量，初始值為 0；
• 信號量 wCountMutex：控制 wCount 互斥修改，初始值為 1；

具體實現(xiàn)如下代碼：

注意，這里 rMutex 的作用，開始有多個讀者讀數(shù)據(jù)，它們?nèi)窟M入讀者隊列，此時來了一個寫者，執(zhí)行了 P(rMutex) 之后，后續(xù)的讀者由于阻塞在 rMutex 上，都不能再進入讀者隊列，而寫者到來，則可以全部進入寫者隊列，因此保證了寫者優(yōu)先。

同時，第一個寫者執(zhí)行了 P(rMutex) 之后，也不能馬上開始寫，必須等到所有進入讀者隊列的讀者都執(zhí)行完讀操作，通過 V(wDataMutex) 喚醒寫者的寫操作。

方案三

既然讀者優(yōu)先策略和寫者優(yōu)先策略都會造成饑餓的現(xiàn)象，那么我們就來實現(xiàn)一下公平策略。

公平策略：

• 優(yōu)先級相同；
• 寫者、讀者互斥訪問；
• 只能一個寫者訪問臨界區(qū)；
• 可以有多個讀者同時訪問臨界資源；

具體代碼實現(xiàn)：

圖片

看完代碼不知你是否有這樣的疑問，為什么加了一個信號量 flag，就實現(xiàn)了公平競爭？

對比方案一的讀者優(yōu)先策略，可以發(fā)現(xiàn)，讀者優(yōu)先中只要后續(xù)有讀者到達，讀者就可以進入讀者隊列， 而寫者必須等待，直到?jīng)]有讀者到達。

沒有讀者到達會導(dǎo)致讀者隊列為空，即 rCount==0，此時寫者才可以進入臨界區(qū)執(zhí)行寫操作。

而這里 flag 的作用就是阻止讀者的這種特殊權(quán)限（特殊權(quán)限是只要讀者到達，就可以進入讀者隊列）。

比如：開始來了一些讀者讀數(shù)據(jù)，它們?nèi)窟M入讀者隊列，此時來了一個寫者，執(zhí)行 P(falg) 操作，使得后續(xù)到來的讀者都阻塞在 flag 上，不能進入讀者隊列，這會使得讀者隊列逐漸為空，即 rCount 減為 0。

這個寫者也不能立馬開始寫（因為此時讀者隊列不為空），會阻塞在信號量 wDataMutex 上，讀者隊列中的讀者全部讀取結(jié)束后，最后一個讀者進程執(zhí)行 V(wDataMutex)，喚醒剛才的寫者，寫者則繼續(xù)開始進行寫操作。

算法題

• 二叉樹層序遍歷 構(gòu)建一個二叉樹測試

快手二面

指針和引用值傳遞的概念

• 值傳遞是指將參數(shù)的值復(fù)制一份，傳遞給函數(shù)或方法進行操作。在值傳遞中，函數(shù)或方法對參數(shù)進行修改不會影響到原始的變量值。
• 指針引用是指將參數(shù)的內(nèi)存地址傳遞給函數(shù)或方法，使得函數(shù)或方法可以直接訪問和修改原始變量的值。在指針引用中，函數(shù)或方法對參數(shù)的修改會直接反映在原始變量上。

int double string強制轉(zhuǎn)化為什么會精度丟失?

• 整數(shù)到浮點數(shù)：整數(shù)類型是精確表示的，而浮點數(shù)類型則是近似表示的，具有固定的有效位數(shù)。當(dāng)將整數(shù)轉(zhuǎn)換為浮點數(shù)時，可能會導(dǎo)致精度丟失，因為浮點數(shù)無法精確地表示整數(shù)的所有位數(shù)。
• 浮點數(shù)到整數(shù)：浮點數(shù)類型具有小數(shù)部分和指數(shù)部分，而整數(shù)類型只能表示整數(shù)值。當(dāng)將浮點數(shù)轉(zhuǎn)換為整數(shù)時，小數(shù)部分將被丟棄，可能導(dǎo)致精度丟失。
• 字符串到數(shù)值類型：字符串表示的是文本形式的數(shù)據(jù)，而數(shù)值類型表示的是數(shù)值形式的數(shù)據(jù)。當(dāng)將字符串轉(zhuǎn)換為數(shù)值類型時，如果字符串無法解析為有效的數(shù)值，或者字符串表示的數(shù)值超出了目標(biāo)類型的范圍，就會導(dǎo)致精度丟失或產(chǎn)生錯誤的結(jié)果。

void*是什么?

void*是一種通用的指針類型，被稱為"無類型指針"。它可以用來表示指向任何類型的指針，因為void*指針沒有指定特定的數(shù)據(jù)類型。

由于void*是無類型的，它不能直接進行解引用操作，也不能進行指針運算。在使用void*指針時，需要將其轉(zhuǎn)換為具體的指針類型才能進行操作。

void*指針常用于需要在不同類型之間進行通用操作的情況，例如在函數(shù)中傳遞任意類型的指針參數(shù)或在動態(tài)內(nèi)存分配中使用。

malloc的參數(shù)列表 void*怎么轉(zhuǎn)化為int*的？

可以使用類型轉(zhuǎn)換將void*指針轉(zhuǎn)化為int*指針。以下是將void*指針轉(zhuǎn)化為int*指針的示例代碼：

void* voidPtr = malloc(sizeof(int));  // 分配內(nèi)存并返回void*指針
int* intPtr = (int*)voidPtr;           // 將void*指針轉(zhuǎn)化為int*指針

// 現(xiàn)在可以通過intPtr指針訪問int類型的數(shù)據(jù)
*intPtr = 42;

在上述示例中，使用malloc函數(shù)分配了存儲一個int類型數(shù)據(jù)所需的內(nèi)存，并返回了一個void*指針。然后，通過將void*指針轉(zhuǎn)換為int*指針，將其賦值給intPtr變量。現(xiàn)在，可以通過intPtr指針訪問和操作int類型的數(shù)據(jù)。

算法題

• 從一個數(shù)組中找出滿足比左側(cè)都要大比右側(cè)都要小的數(shù)

快手三面

• n個線程按照順序打印編號
• 設(shè)計一個貪吃蛇小游戲，蛇的數(shù)據(jù)結(jié)構(gòu)和蛇體更新和碰撞檢測

三面一個八股沒問，直接來兩個場景代碼題，比較注重實操，太難啦。