我扛住字節(jié)面試了，太干了！

作者：小林coding 2023-04-18 15:22:04

Python是一種解釋型語言，需要在運(yùn)行時(shí)通過解釋器將代碼轉(zhuǎn)換為機(jī)器碼來執(zhí)行，因此相對(duì)于C++而言，執(zhí)行效率較低。但是Python具有很多優(yōu)秀的庫(kù)和框架，這些庫(kù)和框架可以幫助開發(fā)人員快速開發(fā)出高效的應(yīng)用程序，從而提高開發(fā)效率。

大家好，我是小林。

春招進(jìn)展快 2 個(gè)月，大家都找到暑期實(shí)習(xí)了嗎？今年相比往年我感覺比較卷，很少見到offer收割機(jī)的選手。

不管環(huán)境如何，持續(xù)學(xué)習(xí)這個(gè)是不能放棄的，心態(tài)也要穩(wěn)一穩(wěn)，坦然面對(duì)失敗，失敗才是常態(tài)，成功可能才是偶然的。

好了，雞湯喝完了，那我來一點(diǎn)干貨吧，又干又澀，毫無感情，但是又很有用。

今天分享一位讀者字節(jié)后端面經(jīng)，讀者技術(shù)棧是C++和GO。

語言

C ++， Python 哪一個(gè)更快？

讀者答：這個(gè)我不知道從哪方面說，就是 C + + 的話，它其實(shí)能夠提供開發(fā)者非常多的權(quán)限，就是說它能涉及到一些操作系統(tǒng)級(jí)別的一些操作，速度應(yīng)該挺快。然后 Python 實(shí)現(xiàn)功能還是蠻快的。

小林補(bǔ)充：

一般而言，C++更快一些，因?yàn)樗且环N編譯型語言，可以直接編譯成機(jī)器碼，在執(zhí)行時(shí)不需要解釋器的介入，因此執(zhí)行效率較高。

編譯型語言和解釋型語言有沒有了解過

讀者答：可能 C + + 它提供的更偏機(jī)器語言一樣，就是只需要進(jìn)行相關(guān)的編譯查找就可以。但是 Python 的話它可能是更像腳本語言，所以說在進(jìn)行執(zhí)行的時(shí)候還需要再進(jìn)行嗯，一方面的句子語法處理，所以執(zhí)行速度上會(huì)慢一些。

堆內(nèi)存和棧內(nèi)存有什么區(qū)別

讀者答：go里面的堆分配的主要是一些比較大的對(duì)象，棧里面的話可能就是分配一些臨時(shí)的對(duì)象，或者是比較小的數(shù)據(jù)變量。然后如果分配的就是比如說如果申請(qǐng)了一個(gè)channel，或者是一個(gè)非常大的對(duì)象的話，那么它就會(huì)從默認(rèn)的從棧上的空間分配到堆上，因?yàn)槎焉系倪@空堆上的空間進(jìn)行分配之后，它能保留的時(shí)間會(huì)更長(zhǎng)一些，這大概就是棧和堆之間的一個(gè)區(qū)別。

小林補(bǔ)充：

管理方式不同：棧內(nèi)存由系統(tǒng)自動(dòng)分配和釋放，而堆內(nèi)存則需要程序員手動(dòng)分配和釋放。
分配方式不同：棧內(nèi)存是一種連續(xù)的內(nèi)存空間，系統(tǒng)會(huì)自動(dòng)為每個(gè)線程分配一定大小的棧空間，函數(shù)的參數(shù)和局部變量都會(huì)在棧上分配內(nèi)存。而堆內(nèi)存是不連續(xù)的內(nèi)存空間，程序員需要通過動(dòng)態(tài)分配內(nèi)存來獲得堆內(nèi)存空間。
大小限制不同：棧內(nèi)存的大小是固定的，并且比堆內(nèi)存小得多。程序運(yùn)行時(shí)，每個(gè)線程的棧空間通常只有幾MB到幾十MB，而堆內(nèi)存的大小則取決于系統(tǒng)的剩余內(nèi)存大小和程序員的動(dòng)態(tài)分配。
訪問速度不同：棧內(nèi)存的訪問速度比堆內(nèi)存快得多，因?yàn)闂?nèi)存是連續(xù)的，訪問局部變量和函數(shù)參數(shù)時(shí)可以直接讀取棧指針的偏移量。而堆內(nèi)存是不連續(xù)的，訪問速度較慢。

局部變量是放在堆還是放在棧里面？

讀者答：局部變量的話，因?yàn)樗辉谝粋€(gè)函數(shù)里面進(jìn)行相關(guān)的生命周期的存在，所以應(yīng)該是在棧上面的。

鏈表跟數(shù)組有哪一些區(qū)別？

讀者答：鏈表的長(zhǎng)度是不固定的，對(duì)它進(jìn)行相關(guān)的插入或者是刪除操作是非常快的。查找需要從頭到尾遍歷值，效率低。

數(shù)組來說的話，數(shù)組的話是預(yù)先分配了一段固定長(zhǎng)度的連續(xù)的內(nèi)存空間，通過數(shù)組的下標(biāo)索引來查找和賦值。但是如果要進(jìn)行插入刪除操作的話，那可能會(huì)需要就是將數(shù)據(jù)中你要插入那個(gè)位置之后的所有的數(shù)組來進(jìn)行挪位，才能進(jìn)行相關(guān)的插入操作，所以說它這個(gè)插入和刪除的操作就會(huì)相比鏈表會(huì)麻煩。

小林補(bǔ)充：

可以提一下數(shù)組因?yàn)閮?nèi)存地址是連續(xù)，可以增加cpu緩存命中率，而鏈表的內(nèi)存地址并不是連續(xù)的，cpu緩存命中率會(huì)很低。

數(shù)組怎么動(dòng)態(tài)擴(kuò)容？

讀者答：go 的話它其實(shí)提供了一個(gè) slice 這樣子的結(jié)構(gòu)，也就是說它底層維護(hù)了一個(gè)指向數(shù)組的指針，然后還維護(hù)了一個(gè)數(shù)組的長(zhǎng)度和一個(gè)它的空間預(yù)存的一個(gè) CAP 的容量值。然后如果將這個(gè)當(dāng)前的數(shù)組 space 的大小它是小于 1024 的話，那基本上都是 2 倍的擴(kuò)容，然后如果超過 1. 2 次的大小的話，基本上是 1. 25 倍的擴(kuò)容。

協(xié)程與我們普通的線程有什么區(qū)別？

讀者答：協(xié)程可以理解為用戶級(jí)別的線程，所以說在大小方面和調(diào)度方面都是比進(jìn)程要更加的方便和簡(jiǎn)便的。

小林補(bǔ)充：

調(diào)度方式不同：線程是由操作系統(tǒng)調(diào)度的，而協(xié)程則是由程序員控制的。當(dāng)一個(gè)線程被調(diào)度時(shí)，它會(huì)被操作系統(tǒng)掛起，等待下一次調(diào)度。而協(xié)程則是由程序員在代碼中主動(dòng)調(diào)用的，可以在不同的任務(wù)之間切換，而不需要等待操作系統(tǒng)的調(diào)度。
系統(tǒng)資源占用不同：線程是操作系統(tǒng)管理的實(shí)體，它占用系統(tǒng)資源比較大，包括內(nèi)存、線程棧、CPU 時(shí)間片等。而協(xié)程則是在用戶空間中實(shí)現(xiàn)的，不需要操作系統(tǒng)的支持，因此占用的資源比較少。
切換成本不同：線程的切換需要保存和恢復(fù)線程上下文，需要耗費(fèi)一定的時(shí)間和資源。而協(xié)程的切換只需要保存和恢復(fù)棧幀等少量數(shù)據(jù)，因此切換成本比線程低。
編程模型不同：線程是面向操作系統(tǒng)的，而協(xié)程是面向任務(wù)的。線程需要使用操作系統(tǒng)提供的 API 進(jìn)行線程間通信和同步，而協(xié)程則可以使用語言級(jí)別的協(xié)程庫(kù)實(shí)現(xiàn)協(xié)作式多任務(wù)。

協(xié)程的的通訊有哪些方式？

讀者答：不清楚，go 使用時(shí)，可能會(huì)配合 channel 來進(jìn)行使用，起一個(gè)死循環(huán)，監(jiān)聽不同的信號(hào)量進(jìn)行處理。還是說是指那個(gè) GMP 的模型？

小林補(bǔ)充：

共享內(nèi)存：協(xié)程通過共享內(nèi)存來交換數(shù)據(jù)，這種方式簡(jiǎn)單直接，但需要考慮同步和互斥問題，否則會(huì)出現(xiàn)數(shù)據(jù)競(jìng)爭(zhēng)等問題。
消息傳遞：協(xié)程通過消息隊(duì)列等方式來傳遞數(shù)據(jù)，這種方式可以避免數(shù)據(jù)競(jìng)爭(zhēng)等問題，但需要考慮消息的發(fā)送和接收順序等問題。
信號(hào)量：協(xié)程通過信號(hào)量等方式來實(shí)現(xiàn)同步和互斥，這種方式需要考慮好信號(hào)量的數(shù)量和使用順序，否則會(huì)出現(xiàn)死鎖等問題。

常規(guī)的多線程開發(fā)需要注意哪一些問題？

讀者答：場(chǎng)景考慮，你這個(gè)線程是不可以就是無限制的創(chuàng)建的嗎？而且創(chuàng)建線程是需要開銷的，所以一般是會(huì)使用線程池這樣的方式，先預(yù)先創(chuàng)建好一些已經(jīng)分配好的線程資源，然后有需要用的話就先進(jìn)行相關(guān)的使用，然后這個(gè)線程池也負(fù)責(zé)了一些GC 的處理。

線程池里面大概要開多少的線程數(shù)量，這個(gè)線程數(shù)量的話就會(huì)跟你的任務(wù)相關(guān)。CPU 密集型根據(jù)CPU 的核數(shù)或者和任務(wù)執(zhí)行的有關(guān)的時(shí)間來進(jìn)行這個(gè)線程數(shù)量的考慮。

讀寫共享變量會(huì)遇到什么問題？

讀者答：并發(fā)訪問

什么是死鎖？

讀者答：兩個(gè)或多個(gè)進(jìn)程之間他們都在等待一些資源，然后沒有辦法完全釋放現(xiàn)在已經(jīng)占有的資源，但是他們需要的資源的話又被其他的進(jìn)程所占有著，同時(shí)這一整個(gè)過程中你又沒有辦法去搶占，造成了一個(gè)循環(huán)等待的情況（請(qǐng)求保持，互斥，不可剝奪，循環(huán)等待）

如何避免出現(xiàn)死鎖，怎么排查？

讀者答：加鎖或者channel，打斷點(diǎn)，加日志信息。

小林補(bǔ)充：

避免死鎖：

按照固定的順序獲取鎖：按照固定的順序獲取鎖可以避免死鎖的發(fā)生。例如，如果A線程先獲取了鎖1，再獲取鎖2，那么B線程就應(yīng)該先獲取鎖2，再獲取鎖1。
設(shè)置超時(shí)時(shí)間：在獲取鎖的過程中，可以設(shè)置超時(shí)時(shí)間，如果超過一定時(shí)間還沒有獲取到鎖，就放棄獲取鎖，避免因等待鎖而導(dǎo)致的死鎖。

排查方式：

使用工具：可以使用一些工具來幫助檢測(cè)和定位死鎖問題，例如jstack和jconsole等。
分析日志：可以分析系統(tǒng)日志和線程日志，查看是否有線程在等待某個(gè)鎖，從而找出可能導(dǎo)致死鎖的原因。
代碼檢查：可以檢查代碼中是否存在多個(gè)線程競(jìng)爭(zhēng)同一個(gè)鎖的情況，是否存在鎖的嵌套等問題，從而找出可能導(dǎo)致死鎖的原因。

密碼學(xué)和計(jì)網(wǎng)

用到過哪些加密算法？

讀者答：

Sha256 或者是 MD5 這樣子的加密算法。不能還原成原來的數(shù)據(jù)，用來比較數(shù)據(jù)是否一致。
對(duì)稱和非對(duì)稱的加密算法RSA

小林補(bǔ)充：

對(duì)稱加密算法：如DES、3DES、AES等，使用相同的秘鑰加密和解密數(shù)據(jù)，加解密速度快，但秘鑰管理困難。
非對(duì)稱加密算法：如RSA、ECC等，使用公鑰加密數(shù)據(jù)，私鑰解密數(shù)據(jù)，安全性高，但加解密速度較慢。
哈希算法：如MD5、SHA-1、SHA-256等，將任意長(zhǎng)度的數(shù)據(jù)映射成固定長(zhǎng)度的哈希值，不可逆、不可篡改，主要用于數(shù)據(jù)完整性校驗(yàn)。
消息認(rèn)證碼（MAC）：如HMAC、CMAC等，將消息和秘鑰混合處理生成固定長(zhǎng)度的認(rèn)證碼，用于防止數(shù)據(jù)被篡改。
數(shù)字簽名算法：如RSA、DSA等，將消息和私鑰混合處理生成數(shù)字簽名，用于驗(yàn)證消息的來源和完整性。

對(duì)稱和非對(duì)稱的加密算法的區(qū)別，具體講講非對(duì)稱

讀者答：對(duì)稱的話它是有一個(gè)公鑰和一個(gè)私鑰的，然后私鑰的話是只有自己持有的，這樣子的話那他別人其實(shí)不會(huì)獲取到你的CL，然后你通過一個(gè)嗯可信的第三方來進(jìn)行相關(guān)的妙加密。這樣子的話別人只需要通過你的公鑰來進(jìn)行一下獲取你的公鑰來進(jìn)行你傳輸內(nèi)容的加解密就可以，然后來保證這樣子的一個(gè)數(shù)據(jù)的安全性。

HTTP和HTTPS有什么區(qū)別？

讀者答：因?yàn)镠TTP是明文傳輸?shù)模缓?HTTPS 的話就是在這樣的基礎(chǔ)上增加SSL的一些加密的保護(hù)，來保證它傳輸消息的安全性。

小林補(bǔ)充：

HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，存在安全風(fēng)險(xiǎn)的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網(wǎng)絡(luò)層之間加入了 SSL/TLS 安全協(xié)議，使得報(bào)文能夠加密傳輸。
HTTP 連接建立相對(duì)簡(jiǎn)單， 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ù)器的身份是可信的。

怎么去使用這些加密算法？

讀者答：混合使用對(duì)稱和非對(duì)稱加密算法，會(huì)話密鑰是對(duì)稱的，獲取的過程是非對(duì)稱的。

小林補(bǔ)充：

通過混合加密的方式可以保證信息的機(jī)密性，解決了竊聽的風(fēng)險(xiǎn)。

混合加密

HTTPS 采用的是對(duì)稱加密和非對(duì)稱加密結(jié)合的「混合加密」方式：

在通信建立前采用非對(duì)稱加密的方式交換「會(huì)話秘鑰」，后續(xù)就不再使用非對(duì)稱加密。
在通信過程中全部使用對(duì)稱加密的「會(huì)話秘鑰」的方式加密明文數(shù)據(jù)。

采用「混合加密」的方式的原因：

對(duì)稱加密只使用一個(gè)密鑰，運(yùn)算速度快，密鑰必須保密，無法做到安全的密鑰交換。
非對(duì)稱加密使用兩個(gè)密鑰：公鑰和私鑰，公鑰可以任意分發(fā)而私鑰保密，解決了密鑰交換問題但速度慢。

TCP 跟 UDP有什么區(qū)別？

讀者答：TCP 的話它提供了一系列的可靠傳輸機(jī)制來保證它這個(gè)傳輸是可靠的，相較而言的話，那它的傳輸速度就是慢的，而UDP 的話，它沒有做這個(gè)可靠的控制，它只是盡力而為，所以說它的傳輸速度是快的，而且占用的資源也會(huì)更小一些。具體使用的話要看不同的那個(gè)業(yè)務(wù)場(chǎng)景來進(jìn)行相關(guān)的使用。

UDP 怎么改造變?yōu)榭煽總鬏敚?/h3>
讀者答：應(yīng)用層加序列號(hào)和ACK。然后本地會(huì)緩存一些自己已經(jīng)發(fā)過的消息，然后同時(shí)也要求對(duì)方在收到消息之后返回 ACK 來確認(rèn)這個(gè)消息已經(jīng)收到，如果沒有收到 ACK 的話，可能會(huì)設(shè)置一些定時(shí)重傳的這樣的一些方式，來確保這個(gè)消息能夠成功的發(fā)送到對(duì)方。
小林補(bǔ)充：
還要在應(yīng)用層實(shí)現(xiàn)滑動(dòng)窗口，實(shí)現(xiàn)流量控制，根據(jù)接收方的接收能力才發(fā)送數(shù)據(jù)，還有擁塞控制，當(dāng)網(wǎng)絡(luò)中有大量數(shù)據(jù)包同時(shí)傳輸時(shí)，會(huì)導(dǎo)致網(wǎng)絡(luò)擁塞，從而影響數(shù)據(jù)傳輸?shù)馁|(zhì)量和效率。TCP擁塞控制通過動(dòng)態(tài)調(diào)整數(shù)據(jù)傳輸速率，避免了網(wǎng)絡(luò)擁塞的發(fā)生，從而保證了數(shù)據(jù)傳輸?shù)目煽啃院透咝浴?/p>

數(shù)據(jù)庫(kù)

MySQL常見的性能優(yōu)化方式

讀者答：索引和分庫(kù)分表

加了索引之后，插入速度跟那個(gè)讀的速度有什么區(qū)別？

讀者答：b +樹索引結(jié)構(gòu)它其實(shí)跟實(shí)際的磁盤結(jié)構(gòu)是比較一致的，使得隨機(jī)寫變成相關(guān)的順序?qū)懀迦胨俣茸兛斓摹⑺械臄?shù)據(jù)結(jié)數(shù)據(jù)信息的話都存在葉子節(jié)點(diǎn)，能夠提高范圍查找的速度。