大家好，我是小林。

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

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

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

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

語言

C ++， Python 哪一個更快？

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

小林補充：

一般而言，C++更快一些，因為它是一種編譯型語言，可以直接編譯成機器碼，在執(zhí)行時不需要解釋器的介入，因此執(zhí)行效率較高。

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

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

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

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

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

小林補充：

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

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

讀者答：局部變量的話，因為它只在一個函數(shù)里面進(jìn)行相關(guān)的生命周期的存在，所以應(yīng)該是在棧上面的。

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

讀者答：鏈表的長度是不固定的，對它進(jìn)行相關(guān)的插入或者是刪除操作是非?？斓摹２檎倚枰獜念^到尾遍歷值，效率低。

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

小林補充：

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

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

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

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

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

小林補充：

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

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

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

小林補充：

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

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

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

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

讀寫共享變量會遇到什么問題？

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

什么是死鎖？

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

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

讀者答：加鎖或者channel，打斷點，加日志信息。

小林補充：

避免死鎖：

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

排查方式：

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

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

用到過哪些加密算法？

讀者答：

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

小林補充：

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

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

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

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

讀者答：因為HTTP是明文傳輸?shù)?，然?HTTPS 的話就是在這樣的基礎(chǔ)上增加SSL的一些加密的保護，來保證它傳輸消息的安全性。

小林補充：

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

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

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

小林補充：

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

混合加密

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

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

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

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

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

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

UDP 怎么改造變?yōu)榭煽總鬏敚?/h3>

讀者答：應(yīng)用層加序列號和ACK。然后本地會緩存一些自己已經(jīng)發(fā)過的消息，然后同時也要求對方在收到消息之后返回 ACK 來確認(rèn)這個消息已經(jīng)收到，如果沒有收到 ACK 的話，可能會設(shè)置一些定時重傳的這樣的一些方式，來確保這個消息能夠成功的發(fā)送到對方。

小林補充：

還要在應(yīng)用層實現(xiàn)滑動窗口，實現(xiàn)流量控制，根據(jù)接收方的接收能力才發(fā)送數(shù)據(jù)，還有擁塞控制，當(dāng)網(wǎng)絡(luò)中有大量數(shù)據(jù)包同時傳輸時，會導(dǎo)致網(wǎng)絡(luò)擁塞，從而影響數(shù)據(jù)傳輸?shù)馁|(zhì)量和效率。TCP擁塞控制通過動態(tài)調(diào)整數(shù)據(jù)傳輸速率，避免了網(wǎng)絡(luò)擁塞的發(fā)生，從而保證了數(shù)據(jù)傳輸?shù)目煽啃院透咝浴?/p>

數(shù)據(jù)庫

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

讀者答：索引和分庫分表

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

讀者答：b +樹索引結(jié)構(gòu)它其實跟實際的磁盤結(jié)構(gòu)是比較一致的，使得隨機寫變成相關(guān)的順序?qū)?，插入速度變快的。將所有的?shù)據(jù)結(jié)數(shù)據(jù)信息的話都存在葉子節(jié)點，能夠提高范圍查找的速度。

Redis在架構(gòu)中會起到什么作用？

讀者答：當(dāng)緩存使用的

可以直接存到進(jìn)程內(nèi)存，現(xiàn)在為什么要專門做Redis？

讀者答：因為Redis快（面試官說不是，因為還存在進(jìn)程通訊，不如直接內(nèi)存快；自己去實現(xiàn)一份緩存不一定有Redis好，在分布式架構(gòu)中Redis能做同步）

算法題

• 打印圣誕樹
• 每隔1s調(diào)用一個會panic然后之后會recover的函數(shù)

項目問題：

忽略....