后端有點(diǎn)卷？沖客戶端去了！

大家好，我是小林。

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

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

由其第三面，直接給兩個(gè)場(chǎng)景代碼題手寫出來，還是有點(diǎn)難度。。

快手一面

擁塞控制介紹一下

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

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

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

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

擁塞控制主要是四個(gè)算法：

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

慢啟動(dòng)

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

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

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

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

慢啟動(dòng)算法的變化過程如下圖：

慢啟動(dòng)算法

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

那慢啟動(dòng)漲到什么時(shí)候是個(gè)頭呢？

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

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

擁塞避免

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

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

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

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

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

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

擁塞避免

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

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

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

擁塞發(fā)生

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

• 超時(shí)重傳
• 快速重傳

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

這個(gè)時(shí)候，ssthresh 和 cwnd 的值會(huì)發(fā)生變化：

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

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

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

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

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

TCP 認(rèn)為這種情況不嚴(yán)重，因?yàn)榇蟛糠譀]丟，只丟了一小部分，則 ssthresh 和 cwnd 變化如下：

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

快速恢復(fù)

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

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

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

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

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

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

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

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

http/ https 的區(qū)別？

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

Https四次加密過程？

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

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

1. ClientHello

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

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

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

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

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

2. SeverHello

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

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

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

（3）確認(rèn)的密碼套件列表，如 RSA 加密算法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

get和post的區(qū)別？

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

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

• 資源占用：每個(gè)進(jìn)程都有獨(dú)立的地址空間、文件描述符和其他系統(tǒng)資源，進(jìn)程之間的資源是相互獨(dú)立的，而線程共享所屬進(jìn)程的地址空間和資源，包括文件描述符、信號(hào)處理等。

• 調(diào)度和切換：進(jìn)程是系統(tǒng)進(jìn)行調(diào)度和分配資源的基本單位，進(jìn)程之間的切換開銷相對(duì)較大。而線程是在進(jìn)程內(nèi)部執(zhí)行的，線程的切換開銷相對(duì)較小。

• 通信和同步：進(jìn)程之間通信的方式包括管道、消息隊(duì)列、共享內(nèi)存等，進(jìn)程間通信相對(duì)復(fù)雜。線程之間共享進(jìn)程的內(nèi)存空間，直接讀寫共享數(shù)據(jù)即可實(shí)現(xiàn)通信和同步。

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

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

• 線程控制塊（Thread Control Block，TCB）：用于保存線程的狀態(tài)信息，如程序計(jì)數(shù)器（Program Counter，PC）、寄存器值、線程 ID、線程優(yōu)先級(jí)等。

• 棧（Stack）：每個(gè)線程都有自己的?？臻g，用于保存函數(shù)調(diào)用的局部變量、函數(shù)的返回地址以及其他臨時(shí)數(shù)據(jù)。棧是線程私有的，不同線程之間的棧是相互獨(dú)立的。

• 寄存器（Registers）：線程在執(zhí)行過程中會(huì)使用到寄存器，包括通用寄存器（如EAX、EBX等）、程序計(jì)數(shù)器（PC）等。寄存器保存了線程當(dāng)前的執(zhí)行狀態(tài)。

• 共享資源：線程可以共享所屬進(jìn)程的資源，如打開的文件、信號(hào)處理器等。這些資源可以在線程之間共享和訪問。

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

• 函數(shù)調(diào)用的局部變量：當(dāng)一個(gè)函數(shù)被調(diào)用時(shí)，其局部變量會(huì)被保存在棧中。這些局部變量在函數(shù)執(zhí)行結(jié)束后會(huì)被銷毀。

• 函數(shù)的返回地址：當(dāng)一個(gè)函數(shù)執(zhí)行完畢后，需要返回到調(diào)用該函數(shù)的地址。返回地址會(huì)被保存在棧中，以便函數(shù)執(zhí)行完畢后能夠正確返回。

• 函數(shù)調(diào)用過程中的臨時(shí)數(shù)據(jù)：在函數(shù)執(zhí)行過程中，可能會(huì)需要保存一些臨時(shí)數(shù)據(jù)，如函數(shù)的參數(shù)、中間計(jì)算結(jié)果等，這些數(shù)據(jù)會(huì)保存在棧中。

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

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

• 保存返回地址：在函數(shù)調(diào)用前，調(diào)用指令會(huì)將下一條指令的地址（即函數(shù)調(diào)用后需要繼續(xù)執(zhí)行的地址）壓入棧中，以便函數(shù)執(zhí)行完畢后能夠正確返回到調(diào)用點(diǎn)。

• 保存調(diào)用者的棧幀指針：在函數(shù)調(diào)用前，調(diào)用指令會(huì)將當(dāng)前棧幀指針（即調(diào)用者的棧指針）壓入棧中，以便函數(shù)執(zhí)行完畢后能夠恢復(fù)到調(diào)用者的執(zhí)行狀態(tài)。

• 傳遞參數(shù)：函數(shù)調(diào)用時(shí)，會(huì)將參數(shù)值依次壓入棧中，這些參數(shù)值在函數(shù)內(nèi)部可以通過棧來訪問。

• 分配局部變量空間：函數(shù)調(diào)用時(shí)，會(huì)為局部變量分配空間，這些局部變量會(huì)被保存在棧中。棧指針會(huì)相應(yīng)地移動(dòng)以適應(yīng)新的局部變量空間。

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

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

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

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

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

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

中斷是什么

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

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

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

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

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

讀者-寫者的問題描述：

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

接下來，提出幾個(gè)解決方案來分析分析。

方案一

使用信號(hào)量的方式來嘗試解決：

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

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

上面的這種實(shí)現(xiàn)，是讀者優(yōu)先的策略，因?yàn)橹灰凶x者正在讀的狀態(tài)，后來的讀者都可以直接進(jìn)入，如果讀者持續(xù)不斷進(jìn)入，則寫者會(huì)處于饑餓狀態(tài)。

方案二

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

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

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

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

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

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

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

方案三

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

公平策略：

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

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

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

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

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

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

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

這個(gè)寫者也不能立馬開始寫（因?yàn)榇藭r(shí)讀者隊(duì)列不為空），會(huì)阻塞在信號(hào)量 wDataMutex 上，讀者隊(duì)列中的讀者全部讀取結(jié)束后，最后一個(gè)讀者進(jìn)程執(zhí)行 V(wDataMutex)，喚醒剛才的寫者，寫者則繼續(xù)開始進(jìn)行寫操作。

算法題

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

快手二面

指針和引用值傳遞的概念

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

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

• 整數(shù)到浮點(diǎn)數(shù)：整數(shù)類型是精確表示的，而浮點(diǎn)數(shù)類型則是近似表示的，具有固定的有效位數(shù)。當(dāng)將整數(shù)轉(zhuǎn)換為浮點(diǎn)數(shù)時(shí)，可能會(huì)導(dǎo)致精度丟失，因?yàn)楦↑c(diǎn)數(shù)無法精確地表示整數(shù)的所有位數(shù)。

• 浮點(diǎn)數(shù)到整數(shù)：浮點(diǎn)數(shù)類型具有小數(shù)部分和指數(shù)部分，而整數(shù)類型只能表示整數(shù)值。當(dāng)將浮點(diǎn)數(shù)轉(zhuǎn)換為整數(shù)時(shí)，小數(shù)部分將被丟棄，可能導(dǎo)致精度丟失。

• 字符串到數(shù)值類型：字符串表示的是文本形式的數(shù)據(jù)，而數(shù)值類型表示的是數(shù)值形式的數(shù)據(jù)。當(dāng)將字符串轉(zhuǎn)換為數(shù)值類型時(shí)，如果字符串無法解析為有效的數(shù)值，或者字符串表示的數(shù)值超出了目標(biāo)類型的范圍，就會(huì)導(dǎo)致精度丟失或產(chǎn)生錯(cuò)誤的結(jié)果。

void*是什么?

void*是一種通用的指針類型，被稱為"無類型指針"。它可以用來表示指向任何類型的指針，因?yàn)?code style="font-size:14px;padding:2px 4px;margin-right:2px;margin-left:2px;background-color:rgba(27,31,35,.05);font-family:'Operator Mono', Consolas, Monaco, Menlo, monospace;color:rgb(100,149,237);">void*指針沒有指定特定的數(shù)據(jù)類型。

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

void*指針常用于需要在不同類型之間進(jìn)行通用操作的情況，例如在函數(shù)中傳遞任意類型的指針參數(shù)或在動(dòng)態(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ù)分配了存儲(chǔ)一個(gè)int類型數(shù)據(jù)所需的內(nèi)存，并返回了一個(gè)void*指針。然后，通過將void*指針轉(zhuǎn)換為int*指針，將其賦值給intPtr變量?，F(xiàn)在，可以通過intPtr指針訪問和操作int類型的數(shù)據(jù)。

算法題

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

快手三面

• n個(gè)線程按照順序打印編號(hào)

• 設(shè)計(jì)一個(gè)貪吃蛇小游戲，蛇的數(shù)據(jù)結(jié)構(gòu)和蛇體更新和碰撞檢測(cè)

三面一個(gè)八股沒問，直接來兩個(gè)場(chǎng)景代碼題，比較注重實(shí)操，太難啦。