面經(jīng) | 好消息：字節(jié)發(fā)新年紅包了，壞消息：明年沒有了

，然后從證書拿到公鑰，并生成一個隨機數(shù)，用公鑰加密隨機數(shù)發(fā)送給中間人，中間人使用私鑰解密，得到隨機數(shù)，此時雙方都有隨機數(shù)，然后通過算法生成對稱加密密鑰（A），后續(xù)客戶端與中間人通信就用這個對稱加密密鑰來加密數(shù)據(jù)了。在中間人與服務(wù)端進行 TLS 握手過程中，服務(wù)端會發(fā)送從 CA 機構(gòu)簽發(fā)的公鑰證書給中間人，從證書拿到公鑰，并生成一個隨機數(shù)，用公鑰加密隨機數(shù)發(fā)送給服務(wù)端，服務(wù)端使用私鑰解密，得到隨機數(shù)，此時雙方都有隨機數(shù)，然后通過算法生成對稱加密密鑰（B），后續(xù)中間人與服務(wù)端通信就用這個對稱加密密鑰來加密數(shù)據(jù)了。

后續(xù)的通信過程中，中間人用對稱加密密鑰（A）解密客戶端的 HTTPS 請求的數(shù)據(jù)，然后用對稱加密密鑰（B）加密 HTTPS 請求后，轉(zhuǎn)發(fā)給服務(wù)端，接著服務(wù)端發(fā)送 HTTPS 響應(yīng)數(shù)據(jù)給中間人，中間人用對稱加密密鑰（B）解密 HTTPS 響應(yīng)數(shù)據(jù)，然后再用對稱加密密鑰（A）加密后，轉(zhuǎn)發(fā)給客戶端。

從客戶端的角度看，其實并不知道網(wǎng)絡(luò)中存在中間人服務(wù)器這個角色。那么中間人就可以解開瀏覽器發(fā)起的 HTTPS 請求里的數(shù)據(jù)，也可以解開服務(wù)端響應(yīng)給瀏覽器的 HTTPS 響應(yīng)數(shù)據(jù)。相當(dāng)于，中間人能夠 “偷看” 瀏覽器與服務(wù)端之間的 HTTPS 請求和響應(yīng)的數(shù)據(jù)。

但是要發(fā)生這種場景是有前提的，前提是用戶點擊接受了中間人服務(wù)器的證書。

中間人服務(wù)器與客戶端在 TLS 握手過程中，實際上發(fā)送了自己偽造的證書給瀏覽器，而這個偽造的證書是能被瀏覽器（客戶端）識別出是非法的，于是就會提醒用戶該證書存在問題。

如果用戶執(zhí)意點擊「繼續(xù)瀏覽此網(wǎng)站」，相當(dāng)于用戶接受了中間人偽造的證書，那么后續(xù)整個 HTTPS 通信都能被中間人監(jiān)聽了。

MySql索引是什么？

MySQL索引是數(shù)據(jù)庫表中的一種數(shù)據(jù)結(jié)構(gòu)，可以提高數(shù)據(jù)檢索的速度。

索引存儲了指向表中數(shù)據(jù)的指針，這樣數(shù)據(jù)庫在查找數(shù)據(jù)時可以使用索引來快速定位到表中的特定行，而不必掃描整個表。使用索引可以顯著提高查詢的效率，特別是在處理大量數(shù)據(jù)時。

介紹一下索引有哪些類型？

可以按照四個角度來分類索引。

按「數(shù)據(jù)結(jié)構(gòu)」分類：B+tree索引、Hash索引、Full-text索引。

按「物理存儲」分類：聚簇索引（主鍵索引）、二級索引（輔助索引）。

按「字段特性」分類：主鍵索引、唯一索引、普通索引、前綴索引。

按「字段個數(shù)」分類：單列索引、聯(lián)合索引。

MySql索引底層是用的什么數(shù)據(jù)結(jié)構(gòu)？

從數(shù)據(jù)結(jié)構(gòu)的角度來看，MySQL 常見索引有 B+Tree 索引、HASH 索引、Full-Text 索引。

每一種存儲引擎支持的索引類型不一定相同，我在表中總結(jié)了 MySQL 常見的存儲引擎 InnoDB、MyISAM 和 Memory 分別支持的索引類型。

InnoDB 是在 MySQL 5.5 之后成為默認(rèn)的 MySQL 存儲引擎，B+Tree 索引類型也是 MySQL 存儲引擎采用最多的索引類型。

MySql查詢數(shù)據(jù)怎么優(yōu)化？

通過 explain 執(zhí)行結(jié)果，查看 sql 是否走索引，如果不走索引，考慮增加索引。可以通過建立聯(lián)合索引，實現(xiàn)覆蓋索引優(yōu)化，減少回表聯(lián)合索引符合最左匹配原則，不然會索引失效避免索引失效，比如不要用左模糊匹配、函數(shù)計算、表達式計算等等。聯(lián)表查詢最好要以小表驅(qū)動大表，并且被驅(qū)動表的字段要有索引，當(dāng)然最好通過冗余字段的設(shè)計，避免聯(lián)表查詢。針對 limit n,y 深分頁的查詢優(yōu)化，可以把Limit查詢轉(zhuǎn)換成某個位置的查詢：select * from tb_sku where id>20000 limit 10;，該方案適用于主鍵自增的表，將字段多的表分解成多個表，有些字段使用頻率高，有些低，數(shù)據(jù)量大時，會由于使用頻率低的存在而變慢，可以考慮分開

spring循環(huán)依賴是怎么解決？

循環(huán)依賴指的是兩個類中的屬性相互依賴對方：例如 A 類中有 B 屬性，B 類中有 A屬性，從而形成了一個依賴閉環(huán)，如下圖。

循環(huán)依賴問題在Spring中主要有三種情況：

第一種：通過構(gòu)造方法進行依賴注入時產(chǎn)生的循環(huán)依賴問題。第二種：通過setter方法進行依賴注入且是在多例（原型）模式下產(chǎn)生的循環(huán)依賴問題。第三種：通過setter方法進行依賴注入且是在單例模式下產(chǎn)生的循環(huán)依賴問題。

只有【第三種方式】的循環(huán)依賴問題被 Spring 解決了，其他兩種方式在遇到循環(huán)依賴問題時，Spring都會產(chǎn)生異常。

Spring 解決單例模式下的setter循環(huán)依賴問題的主要方式是通過三級緩存解決循環(huán)依賴。三級緩存指的是 Spring 在創(chuàng)建 Bean 的過程中，通過三級緩存來緩存正在創(chuàng)建的 Bean，以及已經(jīng)創(chuàng)建完成的 Bean 實例。具體步驟如下：

實例化 Bean：Spring 在實例化 Bean 時，會先創(chuàng)建一個空的 Bean 對象，并將其放入一級緩存中。

屬性賦值：Spring 開始對 Bean 進行屬性賦值，如果發(fā)現(xiàn)循環(huán)依賴，會將當(dāng)前 Bean 對象提前暴露給后續(xù)需要依賴的 Bean（通過提前暴露的方式解決循環(huán)依賴）。

初始化 Bean：完成屬性賦值后，Spring 將 Bean 進行初始化，并將其放入二級緩存中。

注入依賴：Spring 繼續(xù)對 Bean 進行依賴注入，如果發(fā)現(xiàn)循環(huán)依賴，會從二級緩存中獲取已經(jīng)完成初始化的 Bean 實例。

通過三級緩存的機制，Spring 能夠在處理循環(huán)依賴時，確保及時暴露正在創(chuàng)建的 Bean 對象，并能夠正確地注入已經(jīng)初始化的 Bean 實例，從而解決循環(huán)依賴問題，保證應(yīng)用程序的正常運行。

spring三級緩存的數(shù)據(jù)結(jié)構(gòu)是什么？

都是 Map類型的緩存，比如Map {k:name; v:bean}。

一級緩存（Singleton Objects）：這是一個Map類型的緩存，存儲的是已經(jīng)完全初始化好的bean，即完全準(zhǔn)備好可以使用的bean實例。鍵是bean的名稱，值是bean的實例。這個緩存在DefaultSingletonBeanRegistry類中的singletonObjects屬性中。

二級緩存（Early Singleton Objects）：這同樣是一個Map類型的緩存，存儲的是早期的bean引用，即已經(jīng)實例化但還未完全初始化的bean。這些bean已經(jīng)被實例化，但是可能還沒有進行屬性注入等操作。這個緩存在DefaultSingletonBeanRegistry類中的earlySingletonObjects屬性中。

三級緩存（Singleton Factories）：這也是一個Map類型的緩存，存儲的是ObjectFactory對象，這些對象可以生成早期的bean引用。當(dāng)一個bean正在創(chuàng)建過程中，如果它被其他bean依賴，那么這個正在創(chuàng)建的bean就會通過這個ObjectFactory來創(chuàng)建一個早期引用，從而解決循環(huán)依賴的問題。這個緩存在DefaultSingletonBeanRegistry類中的singletonFactories屬性中。

linux中軟鏈接和硬鏈接的區(qū)別？

有時候我們希望給某個文件取個別名，那么在 Linux 中可以通過硬鏈接（_Hard Link_）?和軟鏈接（_Symbolic Link_）?的方式來實現(xiàn)，它們都是比較特殊的文件，但是實現(xiàn)方式也是不相同的。

硬鏈接是多個目錄項中的「索引節(jié)點」指向一個文件，也就是指向同一個 inode，但是 inode 是不可能跨越文件系統(tǒng)的，每個文件系統(tǒng)都有各自的 inode 數(shù)據(jù)結(jié)構(gòu)和列表，所以硬鏈接是不可用于跨文件系統(tǒng)的。由于多個目錄項都是指向一個 inode，那么只有刪除文件的所有硬鏈接以及源文件時，系統(tǒng)才會徹底刪除該文件。

軟鏈接相當(dāng)于重新創(chuàng)建一個文件，這個文件有獨立的 inode，但是這個文件的內(nèi)容是另外一個文件的路徑，所以訪問軟鏈接的時候，實際上相當(dāng)于訪問到了另外一個文件，所以軟鏈接是可以跨文件系統(tǒng)的，甚至目標(biāo)文件被刪除了，鏈接文件還是在的，只不過指向的文件找不到了而已。

手撕代碼

鏈表向右循環(huán)K個數(shù)

一面感受

體驗很好，面試官很會引導(dǎo)。面試官說我準(zhǔn)備的很充分，快要結(jié)束時直接讓我準(zhǔn)備二面，說一面直接給我過了。

二面八股

進程和線程的區(qū)別？

本質(zhì)區(qū)別：進程是操作系統(tǒng)資源分配的基本單位，而線程是任務(wù)調(diào)度和執(zhí)行的基本單位

在開銷方面：每個進程都有獨立的代碼和數(shù)據(jù)空間（程序上下文），程序之間的切換會有較大的開銷；線程可以看做輕量級的進程，同一類線程共享代碼和數(shù)據(jù)空間，每個線程都有自己獨立的運行棧和程序計數(shù)器（PC），線程之間切換的開銷小

穩(wěn)定性方面：進程中某個線程如果崩潰了，可能會導(dǎo)致整個進程都崩潰。而進程中的子進程崩潰，并不會影響其他進程。

內(nèi)存分配方面：系統(tǒng)在運行的時候會為每個進程分配不同的內(nèi)存空間；而對線程而言，除了CPU外，系統(tǒng)不會為線程分配內(nèi)存（線程所使用的資源來自其所屬進程的資源），線程組之間只能共享資源

包含關(guān)系：沒有線程的進程可以看做是單線程的，如果一個進程內(nèi)有多個線程，則執(zhí)行過程不是一條線的，而是多條線（線程）共同完成的；線程是進程的一部分，所以線程也被稱為輕權(quán)進程或者輕量級進程

你說到進程是分配資源的基本單位，那么這個資源指的是什么？

虛擬內(nèi)存、文件句柄、信號量等資源。

說一說fork()原理？

主進程在執(zhí)行 fork 的時候，操作系統(tǒng)會把主進程的「頁表」復(fù)制一份給子進程，這個頁表記錄著虛擬地址和物理地址映射關(guān)系，而不會復(fù)制物理內(nèi)存，也就是說，兩者的虛擬空間不同，但其對應(yīng)的物理空間是同一個。

這樣一來，子進程就共享了父進程的物理內(nèi)存數(shù)據(jù)了，這樣能夠節(jié)約物理內(nèi)存資源，頁表對應(yīng)的頁表項的屬性會標(biāo)記該物理內(nèi)存的權(quán)限為只讀。

不過，當(dāng)父進程或者子進程在向這個內(nèi)存發(fā)起寫操作時，CPU 就會觸發(fā)寫保護中斷，這個寫保護中斷是由于違反權(quán)限導(dǎo)致的，然后操作系統(tǒng)會在「寫保護中斷處理函數(shù)」里進行物理內(nèi)存的復(fù)制，并重新設(shè)置其內(nèi)存映射關(guān)系，將父子進程的內(nèi)存讀寫權(quán)限設(shè)置為可讀寫，最后才會對內(nèi)存進行寫操作，這個過程被稱為「寫時復(fù)制(Copy On Write)」。

寫時復(fù)制顧名思義，在發(fā)生寫操作的時候，操作系統(tǒng)才會去復(fù)制物理內(nèi)存，這樣是為了防止 fork 創(chuàng)建子進程時，由于物理內(nèi)存數(shù)據(jù)的復(fù)制時間過長而導(dǎo)致父進程長時間阻塞的問題。

fork()會復(fù)制哪些東西？

fork 階段會復(fù)制父進程的頁表（虛擬內(nèi)存）fork 之后，如果發(fā)生了寫時復(fù)制，就會復(fù)制物理內(nèi)存

堆和棧的區(qū)別？

分配方式：堆是動態(tài)分配內(nèi)存，由程序員手動申請和釋放內(nèi)存，通常用于存儲動態(tài)數(shù)據(jù)結(jié)構(gòu)和對象。棧是靜態(tài)分配內(nèi)存，由編譯器自動分配和釋放內(nèi)存，用于存儲函數(shù)的局部變量和函數(shù)調(diào)用信息。

內(nèi)存管理：堆需要程序員手動管理內(nèi)存的分配和釋放，如果管理不當(dāng)可能會導(dǎo)致內(nèi)存泄漏或內(nèi)存溢出。棧由編譯器自動管理內(nèi)存，遵循后進先出的原則，變量的生命周期由其作用域決定，函數(shù)調(diào)用時分配內(nèi)存，函數(shù)返回時釋放內(nèi)存。

大小和速度：堆通常比棧大，內(nèi)存空間較大，動態(tài)分配和釋放內(nèi)存需要時間開銷。棧大小有限，通常比較小，內(nèi)存分配和釋放速度較快，因為是編譯器自動管理。

說說io多路復(fù)用？

I/O 多路復(fù)用可以只使用一個進程來維護多個 Socket?。

一個進程雖然任一時刻只能處理一個請求，但是處理每個請求的事件時，耗時控制在 1 毫秒以內(nèi)，這樣 1 秒內(nèi)就可以處理上千個請求，把時間拉長來看，多個請求復(fù)用了一個進程，這就是多路復(fù)用，這種思想很類似一個 CPU 并發(fā)多個進程，所以也叫做時分多路復(fù)用。

select/poll/epoll 內(nèi)核提供給用戶態(tài)的多路復(fù)用系統(tǒng)調(diào)用，進程可以通過一個系統(tǒng)調(diào)用函數(shù)從內(nèi)核中獲取多個事件。在獲取事件時，先把所有連接（文件描述符）傳給內(nèi)核，再由內(nèi)核返回產(chǎn)生了事件的連接，然后在用戶態(tài)中再處理這些連接對應(yīng)的請求即可。

tcp與udp的區(qū)別

連接：TCP 是面向連接的傳輸層協(xié)議，傳輸數(shù)據(jù)前先要建立連接；UDP 是不需要連接，即刻傳輸數(shù)據(jù)。服務(wù)對象：TCP 是一對一的兩點服務(wù)，即一條連接只有兩個端點。UDP 支持一對一、一對多、多對多的交互通信可靠性：TCP 是可靠交付數(shù)據(jù)的，數(shù)據(jù)可以無差錯、不丟失、不重復(fù)、按序到達。UDP 是盡最大努力交付，不保證可靠交付數(shù)據(jù)。但是我們可以基于 UDP 傳輸協(xié)議實現(xiàn)一個可靠的傳輸協(xié)議，比如 QUIC 協(xié)議擁塞控制、流量控制：TCP 有擁塞控制和流量控制機制，保證數(shù)據(jù)傳輸的安全性。UDP 則沒有，即使網(wǎng)絡(luò)非常擁堵了，也不會影響 UDP 的發(fā)送速率。首部開銷：TCP 首部長度較長，會有一定的開銷，首部在沒有使用「選項」字段時是 20 個字節(jié)，如果使用了「選項」字段則會變長的。UDP 首部只有 8 個字節(jié)，并且是固定不變的，開銷較小。傳輸方式：TCP 是流式傳輸，沒有邊界，但保證順序和可靠。UDP 是一個包一個包的發(fā)送，是有邊界的，但可能會丟包和亂序。應(yīng)用場景：TCP 是面向連接，能保證數(shù)據(jù)的可靠性交付，因此經(jīng)常用于：FTP、HTTP/HTTPS協(xié)議。UDP 面向無連接，它可以隨時發(fā)送數(shù)據(jù)，再加上 UDP 本身的處理既簡單又高效，經(jīng)常用于視頻、音頻等多媒體通信等。

說說HTTP頭部字段

Host?字段

客戶端發(fā)送請求時，用來指定服務(wù)器的域名。

Host:?www.A.com

有了 Host 字段，就可以將請求發(fā)往「同一臺」服務(wù)器上的不同網(wǎng)站。

Content-Length 字段

服務(wù)器在返回數(shù)據(jù)時，會有 Content-Length 字段，表明本次回應(yīng)的數(shù)據(jù)長度。

Content-Length:?1000

如上面則是告訴瀏覽器，本次服務(wù)器回應(yīng)的數(shù)據(jù)長度是 1000 個字節(jié)，后面的字節(jié)就屬于下一個回應(yīng)了。大家應(yīng)該都知道 HTTP 是基于 TCP 傳輸協(xié)議進行通信的，而使用了 TCP 傳輸協(xié)議，就會存在一個“粘包”的問題，HTTP 協(xié)議通過設(shè)置回車符、換行符作為 HTTP header 的邊界，通過 Content-Length 字段作為 HTTP body 的邊界，這兩個方式都是為了解決“粘包”的問題。

Connection 字段

Connection 字段最常用于客戶端要求服務(wù)器使用「HTTP 長連接」機制，以便其他請求復(fù)用。

HTTP 長連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。

HTTP/1.1 版本的默認(rèn)連接都是長連接，但為了兼容老版本的 HTTP，需要指定 Connection 首部字段的值為 Keep-Alive。

Connection:?Keep-Alive

開啟了 HTTP Keep-Alive 機制后， 連接就不會中斷，而是保持連接。當(dāng)客戶端發(fā)送另一個請求時，它會使用同一個連接，一直持續(xù)到客戶端或服務(wù)器端提出斷開連接。

Content-Type 字段

Content-Type 字段用于服務(wù)器回應(yīng)時，告訴客戶端，本次數(shù)據(jù)是什么格式。

Content-Type:?text/html;?Charset=utf-8

上面的類型表明，發(fā)送的是網(wǎng)頁，而且編碼是UTF-8?？蛻舳苏埱蟮臅r候，可以使用 Accept 字段聲明自己可以接受哪些數(shù)據(jù)格式。

Accept:?*/*

上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)。

說說HTTP2

HTTP/2 相比 HTTP/1.1 性能上的改進：

頭部壓縮：HTTP/2 會壓縮頭（Header）如果你同時發(fā)出多個請求，他們的頭是一樣的或是相似的，那么，協(xié)議會幫你消除重復(fù)的部分。這就是所謂的 HPACK 算法：在客戶端和服務(wù)器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發(fā)送同樣字段了，只發(fā)送索引號，這樣就提高速度了。

二進制格式：HTTP/2 不再像 HTTP/1.1 里的純文本形式的報文，而是全面采用了二進制格式，頭信息和數(shù)據(jù)體都是二進制，并且統(tǒng)稱為幀（frame）：頭信息幀（Headers Frame）和數(shù)據(jù)幀（Data Frame）。這樣雖然對人不友好，但是對計算機非常友好，因為計算機只懂二進制，那么收到報文后，無需再將明文的報文轉(zhuǎn)成二進制，而是直接解析二進制報文，這增加了數(shù)據(jù)傳輸?shù)男?/strong>。