一面一面面試官看著二十七八歲，文質彬彬，這哪里是寫代碼的，頭發都飄起來了好么。上來就干項目，由于大家的項目都不太一樣，所以對于項目部分我就說說我面試的時候經常遇到的問題描述下項目一口是吃不了胖子的，描述之前先憋著氣掂量掂量自己所說的東西能不能唬住自己，然后唬住面試官。項目中擔任的角色對于大多數的我們而言，就是開發的角色，同樣的道理，角色對應相應的職務，闡述自己做的內容能引面試官上鉤，拉鉤上吊一百年不許變。在項目遇到什么困難這三個問題，是不是可以拎著腳趾拇都可以想出來，除非不是你做的，哈哈哈哈哈。不慌，不是我們做的也不怕，我們必須知道有個網站叫做Github，大牛這么多，自己不是大牛，難道不會學學人家麥。Clone下來，搭建環境跑起來，開始調試修改，通過將模塊拆分，進一步修改，這不就是你的項目嗎，當然我不怎么建議大家這么操作啦。

項目被問的差不多了，開始懟基礎知識，基礎知識老四套，計算機網絡，數據庫，操作系統，數據結構我看你簡歷中寫著網絡流量的還原，你應該對計算機網絡比較熟悉？(注意哈，簡歷上寫上去的東西，自己心里一定要有點B數)，那我們說說計算機網絡說說計算機網絡中TCP的三次握手吧

首先 Client 給 Server 發送一個SYN包，Server 接收到 SYN 回復 SYN+ACK，然后客戶端回復ACK 表示收到。你這樣回答肯定是不會讓面試官滿意的，那就加點配料，不放佐料的菜怎么香？那就詳細的安排一下

首先客戶端的協議棧向服務端發送SYN包，同時告訴服務端當前發送的序列號是X，此時客戶端進入 SYNC_SENT狀態

服務端的協議棧收到這個包以后，使用 ACK 應答，此時應答的值為 X+1，表示對 SYN 包 J 的確認，同時服務端也發送一個SYN包，告訴客戶端當前我的發送序列號是Y，此時服務端進入SYNC_RCVD狀態

客戶端協議棧收到 ACK 以后，應用程序通過connect調用表示服務端的單向連接成功，此時狀態為ESTABLISHED，同時客戶端協議棧對服務器端的 SYN 進行應答，此時數據為Y+1

服務端收到客戶端的應答包，通過accept阻塞調用返回，此時服務端到客戶單的單向連接也建立成功，服務器將進入ESTABLISHED狀態這樣是不是稍微有B格一點呢，而且還比較形象，當然為了加深大家對這個過程的印象，我再舉個例子

第一次握手：小藍給某女娃告白，說我喜歡你，然后我傻乎乎的等著回應

第二次握手：女生看我這顏值，秒回，自然就答應我啊，并回復我也喜歡你拉

第三次握手：我收到女生的回應說：“那晚上去吃火鍋，看電影，理療”

就這樣在一起啦，那么后續是啥樣呢？是不是得往下看看什么是四次揮手了(渣男石錘)，非也，還在熱戀期呢，專一的好嗎。面試官會繼續問你三次握手面試官說：“那我問你，如果客戶端發送的SYN丟失了或者其他原因導致Server無法處理，是什么原因？

這個場景非常常見，沒有萬無一失。在TCP的可靠傳輸中，如果SYN包在傳輸的過程中丟失，此時Client段會觸發重傳機制，但是也不是無腦的一直重傳過去，重傳的次數是受限制的，可以通過 tcp_syn_retries 這個配置項來決定。如果此時 tcp_syn_retries 的配置為3，那么其過程如下

TCP重傳

當 Client 發送 SYN 后，如果過了1s還沒有收到 Server 的回應，那么進行第一次的重傳。如果經過了2s沒有收到Sever的響應進行第二次的重傳，一直重傳tcp_syn_retries次。這里的重傳三次，意味著當第一次發送SYN后，需要等待(1 +2 +4 +8)秒，如果還是沒有響應，connect就會通過ETIMEOUT的錯誤返回。說說四次揮手吧，哎，卑微的藍藍

第一次揮手：女生覺得和這個男生不太合適，但是是個好人，決定提出分手，等待男生回應

第二次揮手：這男生吧，也是會玩兒，直接說：”分就分“

第三次揮手：過了一段時間，男生覺得好沒得面子："我一個大老爺們，應該是我提出分手啊"，于是給女生說：我們分手吧

第四次揮手：女生看到這個消息，你是「憨批」還是「神經病」？TIMEWAIT了解哈，過多的TIMEWAIT怎么辦，什么原因造成的?

回答問題的方法無外乎即是什么，為什么會出現以及可以解決的方案

在TCP的四次揮手過程中，發起連接斷開的一方會進入TIME_WAIT的狀態。通常一個TCP連接通過對外開發端口的方式提供服務，在高并發的情況下，每個連接占用一個端口，但是端口是有限的以致于可能導致端口耗盡，所以就會出現'"服務時而好時而壞的情況"。

如下圖所示的TCP四次揮手，TCP連接準備終止的時候會發送FIN報文，主機2進入CLOSE_WAIT狀態并發送ACK應答。主機1會在TIMEWAIT停留2MSL的時間。為什么不直接進入CLOSE轉態，而是需要先等待2MSL，這段時間在干啥？

第一個原因是為了確保最后的ACK能夠正常接收，從而有效的正常關閉。怎么理解，科學家們在設計TCP的時候，假設TCP報文會出錯從而開始重傳，如果主機1的報文沒有傳輸成功，那么主機2就會重發FIN報文，此時主機1沒有維護TIME_WAIT狀態，就會失去上下文從而恢復RST，導致服被動關閉一方出現錯誤。

四次揮手

第二個原因是讓舊鏈接的重復分節在網絡中自然消失。

一次網絡通信可能經過無數個路由器，交換機，不知道到底會是哪個環節出問題。我們為了標識一個連接，通過四元組的方式[源IP，源端口，目的IP，目的端口]。假設此時兩個連接A，B。A連接在中途中斷了，此時重新創建B連接，這個B連接的四元組和A連接一樣，如果A連接經過一段時間到達了目的地，那么B連接很有可能被認為是A連接的一部分，這樣就會造成混亂。所以TCP設置了這樣一個機制，讓兩個方向的分組都被丟棄。那么TIME_WAIT有哪些危害？

過多的連接勢必造成內存資源的浪費

對端口的占用。可開啟的端口也就32768~61000有沒有對TCP進行優化過

開玩笑，這東西復習過，盡管問，錘子不怕。優化的點很多，隨便提一點，讓后比較深的描述下這個過程就行比如調整哪些參數在某些特定的條件下會最優

我們應該都知道半連接，即收到SYN以后沒有回復SYN+ACK的連接，那么Server每收到新的SYN包，都會創建一個半連接，然后將這個半連接加入到半連接的隊列(syn queue)中，syn queue的長度又是有限的，可以通過tcp_max_syn_backlog進行配置，當隊列中積壓的半連接數超過了配置的值，新的SYN包就會被拋棄。對于服務器而言，可能瞬間多了很多新的連接，所以通過調大該值，以防止SYN包被丟棄而導致Client收不到SYN+ACK。

就這樣是不是就可以讓面試官感覺，這小伙子有點東西。那怎么配置呢

配置syn queue你以為面試官是傻子？當然不是，萬一面試官問你：半連接積壓較多，還有其他的原因？

哈哈哈，這說明面試官上鉤了哇，來，我們看看還有啥原因

還有可能是因為惡意的Client在進行SYN Flood*。SYN Flood*是個啥過程？

首先Client以較高頻率發送SYN包，且這個SYN包的源IP不停的更換，對于Server來說，這是新的鏈接，就會給它分配一個半連接

Server的SYN+ACK會根據之前的SYN包找IP，發現不是原來的IP，所以無法收到Client的ACK包，從而導致無法正確的建立連接，自然就讓Server的半連接隊列耗盡，無法響應正常的SYN包那有沒有什么方案解決這個問題？

那必須，畢竟面試嘛，需要讓面試官問我們知道的內容。在Linux內核中引入了SYN Cookies機制，那看看這個機制是啥意思

首先Server收到SYN包，不分配資源保存Client的信息，而是根據SYN計算出Cookie值，然后將Cookie記錄到SYN ACK并發送出去

如果是正常的情況，這個Cookies值會伴隨著Client的ACK報文帶回來

Server會根據這個Cookies檢查ACK包的合法性，合法則創建連接那么開啟SYN Cookies的方法？

SYN Cookies

網絡問到這就差不多了，挺好的，完全按照我的套路出牌。開始懟我操作系統說下什么是大頁內存我擦，我差點沒反應過來，"大爺內存"，不過確實牛逼，大頁內存，記住了，是大頁內存。

我們知道操作系統堆內存的管理采用多級頁表和分頁進行管理，操作系統給每個頁的默認大小是4KB。假設當前進程使用的內存比較大為1GB，那么此時在頁表中會占用1GB/4KB=26211個頁表項，但是系統的TLB可容乃的頁表項遠遠小于這個數量。所以當多個內存密集型應用訪問內存的時候，就會導致過多的TLB沒有命中，因此在特定的情況下會需要減少未命中次數，一個可行的辦法即是增大每個頁的尺寸。

操作系統默認支持的大頁為2MB，當使用1GB內存的時候，頁表將占用512頁表項，大大的提高TLB命中率從而提高性能。另外需要注意的是，大頁內存分配的是物理內存，所以不會有換出磁盤的操作，所以沒有缺頁中斷，也就不會引入訪問磁盤的時延。行，差不多時間了，寫個簡單代碼吧，實現一個無重復字符的最長子串

思路：使用滑動窗口保證每個窗口的字母都是唯一的使用 vectorm 來記錄一個字母如果后面出現重復時，i 應該調整到的新位置

所以每次更新的時候都會保存 j + 1 ，即字母后面的位置

j 表示子串的最后一個字母，計算子串長度為 j - i + 1

無重復字符的最長子串

二面一面感覺還不錯，果不其然二面來了，HR小姐姐打電話通知周三二面，行，對于從來不遲到的暖藍，肯定守時。拿著茶，等到2:30，至于為什么拿著茶，這是我的習慣，面試前喝杯茶等待面試官的捧擊(面試官其實大部分很溫柔的啦)。

可耐，面試官到點了居然還沒來，等不及的我打電話給HR，HR說不好意思，得等幾分鐘，行，對這甜美的聲音我忍了，可是等了十分鐘都沒音信，我下午還有個筆試，無奈給HR說，我下午還有事兒，要不改天面？

不知道什么情況，直接說，我馬上給你換個面試官，我的天吶，還有這種事兒，我這鄉卡卡的娃兒有這種的待遇？是我一面表現的太太突出？不會吧，反正小紅書我愛了。

“staty with me”響起，這正是我的手機鈴聲。。

"您好”

“你好，請問是XX？”

"嗯嗯，你好面試官"

"我是你的二面面試官，先自我介紹吧"我叫XX，來自XX大學，本科XX，碩士XXX，期間做了XX，謝謝面試官。自我介紹不用那么花里胡哨，挑重點說，不會在意你本科談了幾次戀愛，也不會在意你XXXX，簡單明了完事，開始二面應該學過C的吧，用C實現多態怎么個思路

至于這個題，我還是比較驚訝的，怎么突然問到了C，想了想可能還是考慮對于面向對象中多態，繼承等的理解。

多態無外乎就是編譯時多態和運行時多態，編譯時多態理解為重載，運行時多態理解為重寫。那么要實現重載，需要用到c中的宏，V_ARGS。

c實現重載

理解上面的方法，實現多態就更輕松了

c實現多態感覺沒啥問的，先寫個代碼，二路歸并

這是我之前說過的常考算法之一，中心思想即分治，可通過遞歸一直拆分，遞歸的結束條件即不可再分，即分為1個的時候就停止。從第一個開始時將每一個模塊當作一個已經排序好的數組，有如雙指針，在兩個數組頭設立指針，進行值的比較，然后插入到新數組中，上代碼咯

歸并排序倒排索引了解不？

假設我這里有幾十本文檔，每個文檔題目不一樣，如果我給你文檔的題目，你可能很快就可以找到相應的文檔。但是如果我讓你找論文中包含"暖"和“藍”這兩個字，你可能直接給我"兩兒巴“。因為多半很難很快就找出來。從稍微專業的角度來分，前一種是正排索引，后一個是倒排索引。

我們先看簡單的正排索引。此時給每個文檔一個唯一ID，然后使用哈希表將文檔的ID作為鍵，將文檔內容作為鍵對應的值。這樣我們就可以在O(1)的時間代價完成key的檢索。這也正是正排索引

正排索引

這里遍歷哈希表的時間代價為O(n)。每遍歷一個文檔都需要遍歷每個字符判斷是否包含兩字。假設每個文檔的平均長度為k，那么遍歷一個文檔的時間代價為O(K)。有沒有什么優化的方法？

其實以上就是兩種方案，一種是根據題目找到內容，另一種是根據關鍵字查找題目。這完全相反的方案，那我們反著試試

我們將關鍵字當做key，將包含這個關鍵字的文檔的列表當做存儲的內容。同樣建立一個哈希表，在O(1)的時間我就可以找到包含該關鍵字的文檔列表。這種根據內容或者字段反過來的索引結構即倒排索引。如何創建倒排索引？首先給文檔編個號表示唯一表示，然后排序遍歷文檔

解析每個文檔的關鍵字并生成。這里的關鍵字位置主要是為了檢索的時候顯示關鍵字前后信息

將關鍵字key插入哈希表。如果哈希表已存在這個key，就在對應的posting list中追加節點，記錄文檔ID。如果哈希表沒有響應的key則插入該key并創建posting list和對應的節點

重復2 3步處理完所以文檔

創建倒排索引如果要查詢同時包含"暖"“藍”兩個key怎么辦？

順藤摸瓜啦，分別用兩個key去倒排索引中檢索，這樣使用的兩個不同list：A和B。A中的文檔都包含了"暖"字，B中的文檔都包含了"藍"字。如果文檔即出現"暖"也出現"藍"，是不是就正好包含了兩個字？所以只需要找到AB公共元素即可如何找到AB兩個鏈表的公共元素？希望小伙伴們思考下，經常在手撕算法中被問到首先使用兩個指針P1 P2分別指向有序鏈表AB的第一個元素

然后對比兩個指針所指節點是否相同，這可能出現三種情況

兩者id相同則是公共元素，直接歸并即可，然后P1 P2后移

p1元素小于p2元素，p1后裔，指向A鏈表的下一個元素

p1元素大于p2元素，p2后裔，指向B鏈表中下一個元素

重復第二步 直到p1和p2移動到鏈表尾

鏈表公共元素你說使用過kafka，那么使用消息隊列的時候如何保證只消費一次？

首先引入kafka等消息隊列是為了對峰值寫流量做削峰填谷，對不同系統做解耦合。

舉個例子，我們開發了一個電商系統，其中一個功能是當用戶購買了A產品5份就送一個紅包從而鼓勵用戶消費。但是如果在消息傳遞的過程中丟失了，用戶很可能會因為沒有收到紅包而不開心，甚至取消訂單，在這里如何保證消息被消費到且一次？

我們先看看這個消息寫入消息隊列會有幾個階段，首先有消息從生產者寫入消息到隊列，消息存儲在消息隊列，消息被消費者消費這個階段，任何一個階段都有可能丟失，我們分別查看這幾個階段

丟失的三種可能

第一個階段：消息生產

消息的生產通常會是業務服務器，業務服務器和獨立部署的消息隊列服務器通過內網通信，很可能因為網絡抖動導致消息的丟失，這樣可以采用消息重傳的機制保證消息的送達。但是容易出現重復消費的情況，意思收到兩個紅包，用戶開心了，但是。。。

第二個階段：在隊列中丟失

kafka為了減少消息存儲對磁盤的隨機IO，采用的異步刷盤的方式將消息存儲在磁盤中。我看你簡歷上打過acm，說說你的策略或者經歷吧

寫個驗證郵箱的正則

當時沒有寫出來，確實記不住，每次都是用的時候才去查，誰知道面試的時候遇見誰呢，手撕KMP?這里給大家個答案，后續我詳細安排一篇正則的套路

實現驗證郵箱的正則了解內存映射？說說，盡量說

既然是盡量說，就不客氣了。從什么是內存到如何查看服務器內存，最后怎么能夠更好地用好內存來答就完事

首先內存作為存儲系統和應用程序的指令，數據等。在Linux中，管理內存使用到了內存映射。平時我們經常說的內存容量，主要指的是物理內存，也叫做主存。只有內核才能直接訪問，那么問題來了，進城如果要訪問內存怎么辦呢？

Linux內核為每個進程提供了一個虛擬地址空間且空間地址連續，這樣的話，進程訪問虛擬內存將非常的方便。

虛擬地址又分為內核空間和用戶空間，不同字長的處理器地址范圍也不同。我們下面分別看看32位和64位的虛擬地址空間

內核空間與用戶空間

從這個圖很明顯的看出32位系統中內核空間1G，而64位的內核空間與用戶空間都是128T。

內存映射即虛擬內存地址映射到物理內存地址，完了順利完成映射，需要給每個進程維護一張頁表記錄兩者的關系。

虛擬地址到物理地址的轉化

這樣，如果進程訪問的虛擬地址不在則通過缺頁異常進入內核空間分配物理內存，更新進程頁表，最終返回用戶空間。

說到虛擬內存又不得不說說用戶空間的各個段

用戶空間各個段

忍不住悄悄咪咪問了下HR，二面面試官對我的評價，基礎和code的能力不錯，項目講述的不清楚我自己可能沒有把項目更本質的東西理解清楚

從事的不同的方向，有些專業術語的理解的不同)

三面

三面面試官，真的不能用"禿"來描述了，就感覺我的眼睛被閃了一分鐘，怎么說，面嘛線程的鎖有哪些，我說到了讀寫鎖打斷我了，問我讀寫鎖會有什么些問題，無非就是寫鎖饑餓問題，我說沒看過內核源碼，然后如果讓我來實現，我怎么來避免

分布式Hash表，當進行擴容的時候(會花費很長的時間)，我說P肯定一定要保證的，CA只能選其一，但是我們可以使用弱一致性來保證其可用性

多個隨機Request請求，然后不同的請求有不同的權重，進行隨機抽樣，要求權重大更可能被抽到有了解過RPC？

RPC翻譯過來為遠程過程調用。幫助我們屏蔽網絡細節，實現調用遠程方法就跟調用本地一樣的體驗。舉個例子，如果沒有橋，我們要過河只好劃船，繞道等方式，如果有橋，我們就像在路面行走一樣自如到目的地。RPC的通信流程是怎樣的？

剛才說RPC屏蔽了網絡細節，也就是意味著它處理好了網絡部分，它為了保證可靠性，默認采用TCP傳輸，網絡傳輸的數據是二進制，但是調用所請求的參數是對象，所以需要將對象轉換為二進制，這就需要用到序列化技術

服務提供方接收到數據以后，并不知道哪里是結尾，所以需要一些邊界條件來標識請求的數據哪里是開始，哪里是結束，就像高速路上各種指路牌引領我們前進的方向。這種格式的約定叫做“協議”

根據協議規定的格式，就可以正確的提取出相應的請求，根據請求的類型和序列化的類型，將二進制消息體逆向還原為請求對象，這叫做反序列化

服務提供方通過反序列化的對象找到對應的實現類完成整正的調用，這樣就是一次rcp的調用。畫個圖加深下印象

RPC過程

其他問的一些問題感覺在前面的面試問過了就沒有寫在這部分內容了，還問了幾個數據庫的問題，很常規的了，之前的文章寫過，篇幅太長，看著累，要不先三連，我們下期再見？么么噠

總結

以上是生活随笔為你收集整理的小红书java算法难吗_Java面试系列之记一次小红书之旅的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。