這里我針對這些面試題也給大家整理了相關的解答，分享給大家學習參考，

這里的答案有些只給了大致的方向或者相關知識點，由于篇幅原因（小聲 bb：以及作者知識有限），這里就不全部展開去談了～
對了，補充說明一下，我這位朋友面試的是 后端開發，不過這里我還想再說一點，就是對于應屆生來說，面試官更注重你的基礎，也就是對于相關技術堆疊的底層的一些知識，所以不管是前端、后端、測驗，又或者是嵌入式相關崗位，都離不開以下這幾個方面的內容：
- 計算機網路
- 作業系統
- 演算法與資料結構

除了這幾個內容之外，就是針對不同的崗位的一些相對應的技術堆疊、知識點，這些都需要有所準備，

1.一面

主要聚集點：Mysql、Redis、作業系統、計算機網路等

1.1自我介紹

1.2專案經歷

1.3演算法題

1.4行程和執行緒的區別？

行程：資源分配的最小單位，
執行緒：獨立調度的最小單位，

1.5你了解哪些鎖？

1.6 死鎖的四個必要條件？

1.7 volatie與sychronized的對比？

1.8 volatie的應用場景？

單例模式（懶漢式）

public class Singleton {
	
	private volatile static Singleton  instance = null;
	
	private Singleton(){}
	
	public static Singleton getInstance(){
      if(instance == null){
            synchronized (Singleton.class) {
              if(instance == null){
                  instance = new Singleton();
              }
            }
      }
		return instance;
	}
}

1.9 虛擬記憶體了解嗎？與物理記憶體的區別？

虛擬記憶體就是一塊虛擬的空間可以給用戶存放資料，如果讓用戶直接去操作物理記憶體的話，不同用戶彼此不知道他使用了哪塊物理記憶體空間，就會造成沖突，

有了虛擬記憶體之后用戶就可以將資料直接在虛擬記憶體操作，而不需要關心這些記憶體最侄訓映射到作業系統哪些物理記憶體上，這個映射的操作是作業系統完成的，用戶不感知，那下面就順便講下作業系統是如何完成虛擬地址和物理地址之間的映射的，

這里面涉及到一個叫做 “頁表” 的概念，行程訪問虛擬記憶體，CPU 執行時通過分頁機制轉換成物理記憶體訪問，虛擬地址到物理記憶體的轉換表稱為頁表，這個轉換是個查表的程序，

同一程式運行起來的兩個行程，虛擬地址空間相同，但對應的物理空間是不相同的，OS 需要給每個行程設定一份頁表，在行程調度程序中，背景關系切換階段會做頁表的切換，

小總結：頁表就是一個用于將虛擬地址轉換為物理地址的工具，
此時又來了一個新的家伙，叫做 “快表”，**那快表是干嘛用的呢？**快表是為了加快虛擬地址到物理地址這個轉換程序而存在的，快表一般存放在 CPU 內部的高速緩沖存盤器 Cache 中，
快表與頁表功能很類似，就是將一部分頁表存到 CPU 內部的 Cache 中，CPU 尋址時先根據虛擬地址中的頁號，到快表查詢相應的頁表項對應的物理地址，如果查詢不到，則到物理記憶體中去找，找到了就將頁表項調入快表，
但是如果快表的存盤空間，即 Cache 滿了，就按照一定的淘汰策略將頁表換出，因為高速緩沖存盤器的訪問速度要比記憶體的訪問速度快很多，因此使用快表可以大大加快虛擬地址轉換成物理地址，

1.10 Java分配記憶體兩種方式？（指標碰撞、空閑串列）

Java在堆上分配記憶體有兩種方式，分別是 “指標碰撞” 和 “空閑串列”，

（1）指標碰撞
假設JVM堆中記憶體是規整的，所有用過的記憶體放在一邊，沒用過的記憶體放在另一邊，中間放著一個指標作為分界點的指示器，那么分配記憶體的程序就僅僅是把那個指標向空閑空間的方向挪動一段與物件大小相等的距離，這種分配方式叫做指標碰撞，
（2）空閑串列
如果JVM堆中記憶體不規整，使用過的記憶體和未使用過的記憶體相互交錯，就無法用指標碰撞分配物件了，虛擬機就必須維護一個串列，記錄哪些記憶體塊是可用的，分配的時候在串列中找到一段足夠大的記憶體空間分配給物件實體，并更新串列中的記錄，

1.11 OSI七層協議講一講？

1.12 應用層協議有哪些？

1.13 TCP與UDP區別？

簡單來說
（1）TCP
傳輸控制協議TCP（Transmission Control Protocol）是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向位元組流（把應用層傳下來的報文看成位元組流，把位元組流組織成大小不等的資料塊），每一條TCP連接只能是點對點的（一對一），

（2）UDP
用戶資料報協議UDP（User Datagram Protocol）是無連接的，盡最大可能交付，沒有擁塞控制，面向報文（對于應用程式傳下來的報文不合并也不拆分，只是添加UDP首部），支持一對一、一對多、多對一、多對多的互動通信，

（3）應用場景
如果我們是發送訊息、瀏覽網頁之類的場景，因為要確保用戶訊息不丟失，所以要使用TCP協議，

如果是在視頻聊天或看直播，那可以用UDP協議，因為即使幾個畫面丟失，對用戶來說也影響不大，

1.14 聚簇索引與非聚簇索引對比？

Innodb 中索引的組織形式是B+樹，非葉子結點存key，資料data都保存在葉子結點，葉子結點之間用指標鏈接，

• 聚簇索引：資料都記錄在葉子結點，
• 非聚簇索引：葉子結點存放的是主鍵的值，得到主鍵后還需要在聚集索引上再查詢一次，
  
  在效率方面最好使用聚集索引，并給表設定唯一主鍵，在資料索引的存盤有序的情況下，可以大大提高效率，
  
  

1.15 Redis的記憶體淘汰機制說一說？

1.16 Redis的key的過期洗掉策略？

1.17 Redis兩種持久化方式講一下？

• RDB（默認持久化方式）
  （1）概述：在指定時間間隔內，將記憶體中的資料集快照寫入磁盤（恢復就是恢復這個快照）
  （2）程序：Redis會創建一個子行程來進行持久化操作，子行程會先將資料寫入臨時檔案（快照），再用這個臨時檔案替換上次持久化好的檔案，整個程序，父行程不進行任何IO操作，性能極高，
  （3）存在的問題：最后一次資料可能丟失，因為最后的那部分還沒持久化，
  （4）觸發方式：save / flushall命令 / 退出Redis
  

• AOF
  （1）概述：將所有命令都記錄下來，恢復時就把這個檔案全部再執行一遍（讀操作不記錄）
  （2）存在的問題：可能丟失最后1s的資料
  （3）觸發方式：默認每秒執行一次同步
  
  
  
  

  2. 二面

  主要聚集點：專案經歷、Redis、計算機網路

  2.1 自我介紹

  2.2 專案經歷

  2.3 演算法題

  2.4 Redis 五種資料結構底層實作都了解嗎？

2.5 ConcurrentHashMap 了解嗎？

2.6 HTTPS的加密方式？

• HTTP直接運行在TCP上；

• HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸的內容都經過加密的，

• HTTP的通信沒有加密；

• HTTPS采用非對稱加密+對稱加密的形式，（對稱加密速度快，非對稱加密安全，所以折衷方案，結合兩種模式使用）

1.某網站（服務器）擁有用于非對稱加密的公鑰A、私鑰A’，
2.瀏覽器向網站服務器請求，服務器把公鑰A明文給傳輸瀏覽器，
3.瀏覽器隨機生成一個用于對稱加密的密鑰X，用公鑰A加密后傳給服務器，
4.服務器拿到后用私鑰A’解密得到密鑰X，
5.這樣雙方就都擁有密鑰X了，且別人無法知道它，之后雙方所有資料都通過密鑰X加密解密即可，（對稱加密）

HTTPS這樣使用 對稱加密+非對稱加密 就真的安全嗎？
不安全，
這個程序是使用非對稱加密進行鏈接，使用對稱加密進行通信，
在建立連接之初，服務器將公鑰(A)明文傳輸給瀏覽器，在這個程序中公鑰可能會被劫持，黑客將這個公鑰(A)替換成他自己的公鑰(B)，當然黑客自己也有私鑰(B)，然后將公鑰B傳送給瀏覽器，
瀏覽器生成一個用于對稱加密的密鑰X，用公鑰B加密傳給服務器，
中間人劫持后用私鑰B解密得到密鑰X，再用公鑰A加密后傳給服務器，
服務器拿到后用私鑰A解密得到密鑰X，
經過了這個程序，在瀏覽器看來就是已經與服務器建立連接了，所以接下來瀏覽器會用這個密鑰X與服務器進行對稱加密傳輸，但是此時黑客已經是知道了這個密鑰X，所以接下來瀏覽器與服務器的一切資料傳輸操作都會暴露給黑客，非常不安全，

那如何解決這個問題呢，如何證明瀏覽器收到的公鑰一定是該網站的的公鑰？
找CA機構，頒發數字證書，
以后使用https通信時，服務器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，（這樣就不會發生公鑰被劫持的問題了）

那怎么防止數字證書被篡改呢？
利用防偽技術——“數字簽名”，
把證書原來的內容生成一份“簽名”（即 數字簽名），瀏覽器比對證書內容和簽名是否一致就能判別是否被篡改，（瀏覽器使用CA機構的公鑰S解密，得到S’，然后對證書的明文T用指明的hash演算法計算得到T’，如果S’==T’，則證明證書可信）

2.7 資料庫索引簡單說一說？B+樹的結構了解嗎？

可以講一下B+樹的前世今生，也就是它的演程序序，

AVL樹 -> B樹 -> B+樹

• AVL樹：
  對二叉查找樹BST，做了一些限制，限制必須滿足任何節點的兩個子樹的最大差為1，（AVL樹是一種自平衡二叉查找樹），當樹插入/更新/洗掉時就會破壞樹的平衡，此時就需要樹進行左旋和右旋來調整平衡，AVL樹的查找效率為 O(logn) ，
  而且索引檔案（資料）是存盤在磁盤的，檔案系統在磁盤讀取資料時，一般以頁為單位進行讀取，假設一個頁內的資料過少，那么作業系統就需要讀取更多的頁，設計磁盤隨機IO訪問的次數就更多，（將資料從磁盤讀入記憶體涉及隨機I/O的訪問，成本很高）
  因為AVL樹的樹高會隨資料量增多急劇增加，每次更新資料又需要通過左旋和右旋維護平衡，所以不太適合用于存盤在磁盤上的索引檔案（因為涉及的IO操作過多，效率低），
• B樹：
  將二叉樹變成m叉樹，這個m的大小可以根據單個頁的大小做對應調整，從而使得一個頁可以存盤更多的資料，從磁盤中讀取一個頁可以讀到更多的資料，隨機IO次數變少，大大提升效率，
  缺點：B樹只能通過中序遍歷查詢全表，當進行范圍查詢時，可能需要中序回溯，
• B+樹：（針對B樹進行改進）
  
  • 改進1：
    在葉子結點增加了指標進行連接，即葉子結點間形成了鏈表（雙向鏈表），
  • 改進2：
    非葉子結點只存關鍵字key，不再存盤資料（資料只在葉子結點存盤）
    
    

優點：因為葉子結點的雙向鏈表，可以更方便進行范圍查詢；

非葉子結點只存盤索引key，相當于單個索引大小變小，所以同一個頁可以存盤更多的關鍵字，這樣可以減少隨機I/O的讀寫次數，查詢效率大大提升了，

2.8 LRU Cache了解嗎？

LRU = Least Recently Used 最近最少使用
它是一種快取的淘汰策略，
LRU 演算法是假設最近最少使用的那些資訊，將來被使用的概率也不大，所以在容量有限的情況下，就可以把這些不常用的資訊踢出去，騰地方給別人，

可以參考力扣146題：https://leetcode-cn.com/problems/lru-cache/

自己動手實作一遍，對這個演算法的理解會更加深刻，

3. 三面

主要聚集點：專案、Mysql、作業系統

3.1 自我介紹

3.2 專案經歷

3.3 演算法題

3.4 Redis單執行緒、多執行緒問題

點擊直達我之前寫的一篇文章，里面詳細描述了Redis的這個特性，
面試官：Redis 是單執行緒還是多執行緒？（你為何怎么說都不對？）

3.5 Mysql 事務的特性？

（1）原子性
事務被視為不可分割的最小單元，事務的所有操作要么全部提交成功，要么全部失敗回滾，（回滾可以用回滾日志來實作，回滾日志記錄著事務所執行的修改操作，在回滾時反向執行這些修改操作即可，）

（2）一致性
資料庫在事務執行前后都保持一致性狀態，在一致性狀態下，所有事務對一個資料的讀取結果都是相同的，

（3）隔離性
一個事物所做的的修改在最終提交之前，對其他事務是不可見的，

（4）持久性
一旦事務提交，則其所做的修改將會永遠保存到資料庫中，

當然，面試程序中遠不止出現的這些問題，面試官一般會根據你對某個問題的回答，再針對你的答案或者你答題的角度，進行更加深度的提問，
問題之間往往都是環環相扣的，我們對于一個知識的學習，我個人認為應該是一個發散的互聯的網路，現在社會在構建 “萬物互聯” 的生態場景，知識點也是一樣的，知識點之間像一張網，互相連接，互相交織在一起，構成一個龐大的知識網路，觸類旁通也是這個道理，

---

好了，這位朋友的面經就分享到這里，最后，也祝看到這里的你們，在接下來的秋招中，或者在未來的求職中，都能識訓到一份滿意的 offer，做著自己熱愛的作業，早日達成那個小目標～

如果這篇文章有幫助到你，別忘了關注 點贊 在看一鍵三連哦！
如果想要獲取文章中的圖片的源檔案（可編輯檔案），可以加微信聯系我獲取！

---

我是啊澤，一枚正在 `鵝廠` 搬磚的實習生，關注我，不斷為你分享各種干貨，我的經歷經驗，或許可以給你帶來意想不到的幫助，更多干貨內容請關注本公眾號：“`啊澤Coding`”，掃描下方二維碼關注我吧！

---

也可以后臺留言或者添加個人微信，互相交流，一起進步～