面試 | 阿里問的相當基礎！

大家好，我是小林。

今天分享一篇一位同學暑期實習面試阿里Java后端崗位的一面的面經(jīng)。

主要拷打了項目+Java 集合+Java并發(fā)+網(wǎng)絡+mysql，一場面試大概問了 20 個題目，問的還是比較基礎，不算太難。

問題記錄

自我介紹

balabala（略）

簡歷上有兩個項目，選一個你比較熟悉的介紹

balabala（略）

項目用到了哪個線程實現(xiàn)類？

用了ScheduledThreadPool這個線程實現(xiàn)類

為什么要使用這個線程類？

這個實現(xiàn)類可以設置定期的執(zhí)行任務，它支持定時或周期性執(zhí)行任務，比如每隔 10 秒鐘執(zhí)行一次任務，我通過這個實現(xiàn)類設置定期執(zhí)行任務的策略。

你還了解別的線程實現(xiàn)類嗎?

除了這個之外，還有就是newSingleThreadExecuter，別的就不太熟悉了。

小林補充：

除了 ScheduledThreadPool 線程池之外，還有 4 種常見的線程池如下：

FixedThreadPool：它的核心線程數(shù)和最大線程數(shù)是一樣的，所以可以把它看作是固定線程數(shù)的線程池，它的特點是線程池中的線程數(shù)除了初始階段需要從 0 開始增加外，之后的線程數(shù)量就是固定的，就算任務數(shù)超過線程數(shù)，線程池也不會再創(chuàng)建更多的線程來處理任務，而是會把超出線程處理能力的任務放到任務隊列中進行等待。而且就算任務隊列滿了，到了本該繼續(xù)增加線程數(shù)的時候，由于它的最大線程數(shù)和核心線程數(shù)是一樣的，所以也無法再增加新的線程了。CachedThreadPool：可以稱作可緩存線程池，它的特點在于線程數(shù)是幾乎可以無限增加的（實際最大可以達到 Integer.MAX_VALUE，為 2^31-1，這個數(shù)非常大，所以基本不可能達到），而當線程閑置時還可以對線程進行回收。也就是說該線程池的線程數(shù)量不是固定不變的，當然它也有一個用于存儲提交任務的隊列，但這個隊列是 SynchronousQueue，隊列的容量為0，實際不存儲任何任務，它只負責對任務進行中轉和傳遞，所以效率比較高。SingleThreadExecutor：它會使用唯一的線程去執(zhí)行任務，原理和 FixedThreadPool 是一樣的，只不過這里線程只有一個，如果線程在執(zhí)行任務的過程中發(fā)生異常，線程池也會重新創(chuàng)建一個線程來執(zhí)行后續(xù)的任務。這種線程池由于只有一個線程，所以非常適合用于所有任務都需要按被提交的順序依次執(zhí)行的場景，而前幾種線程池不一定能夠保障任務的執(zhí)行順序等于被提交的順序，因為它們是多線程并行執(zhí)行的。SingleThreadScheduledExecutor：它實際和 ScheduledThreadPool 線程池非常相似，它只是 ScheduledThreadPool 的一個特例，內(nèi)部只有一個線程。

看你項目上有用到雪花算法，你為什么要使用雪花算法？

除了考慮使用主鍵自增保持主鍵的唯一性外，我就使用到了雪花算法，算出一個不會重復的數(shù)做為id，保證主鍵唯一。

那你還了解別的生成主鍵的策略嗎，你覺得他們能代替雪花算法嗎

除了主鍵自增和雪花算法，別的我暫時沒了解的，但是只要是能保證主鍵唯一的主鍵生成策略都可以使用

小林補充：

除了雪花算法之外，還有很多優(yōu)秀的互聯(lián)網(wǎng)公司也提供了唯一 ID 生成的方案或框架，比如美團開源的 Leaf ，百度開源的 UidGenerator 等等。UUID 雖然也可以保證唯一性，但是 UUID 的值是隨機的，無序的，不太適合作為主鍵，因為隨機插入，可能會引起頁分裂的問題，從而影響查詢性能。

List的實現(xiàn)類

ArrayList、Vector、LinkedList

小林補充：

Java中的List接口有多個實現(xiàn)類，常用的包括：

ArrayList：基于動態(tài)數(shù)組實現(xiàn)，優(yōu)勢在于支持隨機訪問和快速插入/刪除元素，適用于頻繁讀取和遍歷的場景。

LinkedList：基于雙向鏈表實現(xiàn)，優(yōu)勢在于支持快速插入/刪除元素，適用于頻繁插入/刪除元素的場景。

Vector：和ArrayList類似，但由于其線程安全性，適用于多線程環(huán)境。

Stack：基于Vector實現(xiàn)，是一個后進先出（LIFO）的數(shù)據(jù)結構，適用于需要按照后進先出順序處理元素的場景。

List和Set的區(qū)別

List是有序的，Set是無序的

List可以存放相同的元素，Set不可以存放重復的元素

小林補充：

順序：List是有序的集合，它可以按照元素插入的順序進行存儲和訪問。而Set是無序的集合，元素在集合中的位置是不固定的。

重復元素：List允許存儲重復的元素，即可以有多個相同的對象。Set不允許存儲重復的元素，即每個對象在集合中只能出現(xiàn)一次。

實現(xiàn)類：List的常用實現(xiàn)類有ArrayList和LinkedList，分別使用數(shù)組和鏈表作為底層數(shù)據(jù)結構。Set的常用實現(xiàn)類有HashSet、LinkedHashSet和TreeSet，分別基于哈希表、鏈表+哈希表和紅黑樹實現(xiàn)。

性能：由于底層數(shù)據(jù)結構的差異，List和Set在增加、刪除、查找等操作上的性能表現(xiàn)有所不同。例如，ArrayList在隨機訪問元素時性能較好，而LinkedList在插入和刪除元素時性能較好。HashSet在查找、添加和刪除元素時性能較好，但不保證元素順序。TreeSet在保持元素排序的同時，也能提供較好的查找性能。

針對你說的List和Set的性質(zhì)，那你會用這兩種結構解決哪些問題

對于取消重復數(shù)據(jù)的場景，選擇set，對于只是保存數(shù)據(jù)、或者需要按存儲順序進行訪問的場景使用List。

小林補充：

List（列表）適用于以下場景：

有序數(shù)據(jù)：列表中的元素按照插入順序存儲，因此適用于需要保持元素順序的場景。允許重復元素：列表允許存儲重復的元素，因此適用于需要統(tǒng)計元素出現(xiàn)次數(shù)的場景。需要根據(jù)索引進行查找、插入和刪除操作：列表允許通過索引值直接訪問、插入或刪除元素，適用于需要頻繁進行這些操作的場景。

Set（集合）適用于以下場景：

去重：集合中的元素不能重復，因此適用于去除數(shù)據(jù)中重復元素的場景。無需關心元素順序：集合中的元素沒有固定順序，適用于元素順序無關緊要的場景。快速判斷元素是否存在：集合提供了高效率的查找算法，適用于需要快速判斷某個元素是否存在于數(shù)據(jù)集中的場景。集合運算：集合支持交集、并集、差集等運算，適用于需要進行這些運算的場景。

常用的網(wǎng)絡狀態(tài)碼有哪些

100開頭是表示協(xié)議執(zhí)行的中間狀態(tài)，一般不常用，400開頭的表示協(xié)議執(zhí)行失敗，例如404是指服務端找不到頁面的請求地址，500是協(xié)議的完成（這個沒記住答錯了，面試官提示了，說那200表示什么）。

小林補充：

常用的網(wǎng)絡狀態(tài)碼分為五類，分別是：

1xx（信息）：表示接收到請求，需要繼續(xù)處理。

100 Continue：繼續(xù)，客戶端應繼續(xù)其請求。

2xx（成功）：表示請求已成功被服務器接收、理解和接受。

200 OK：請求成功，請求所希望的響應頭或數(shù)據(jù)體將隨此響應返回。201 Created：請求已成功，并因此創(chuàng)建了一個新的資源。204 No Content：無內(nèi)容，服務器成功處理，但未返回內(nèi)容。

3xx（重定向）：需要后續(xù)操作才能完成這一請求。

301 Moved Permanently：永久重定向，請求的資源已被永久移動到新位置。302 Found：臨時重定向，請求的資源臨時從不同位置響應。304 Not Modified：資源未修改，使用緩存的資源。

4xx（客戶端錯誤）：請求包含錯誤語法或無法完成。

400 Bad Request：客戶端請求的語法錯誤，服務器無法理解。401 Unauthorized：請求需要用戶驗證。403 Forbidden：服務器理解請求客戶端的請求，但是拒絕執(zhí)行它。404 Not Found：請求的資源無法在服務器上找到。

5xx（服務器錯誤）：服務器未能實現(xiàn)合法的請求。

500 Internal Server Error：服務器內(nèi)部錯誤，無法完成請求。501 Not Implemented：服務器不支持請求的功能。503 Service Unavailable：服務器暫不可用，可能是服務器過載或停機維護。

ps：《HTTP 常見面試題》完整詳細講解：https://xiaolincoding.com/network/2_http/http_interview.html

流量控制和擁塞控制的原理

流量控制是服務端和客戶端協(xié)議的窗口實現(xiàn)，在客戶端發(fā)送數(shù)據(jù)的時候，服務端返回窗口的容量，客戶端通過容量來調(diào)整發(fā)送信息的大小

擁塞控制是通過滑動窗口實現(xiàn)，服務端只接收擁塞窗口大小內(nèi)的數(shù)據(jù)，客服端發(fā)送的報文丟失后，沒有收到服務端的確認信息，就將沒有收到確認信息的保溫再發(fā)送。

小林補充：

TCP一種面向連接的、可靠的傳輸層協(xié)議。為了確保數(shù)據(jù)的有效傳輸，TCP 提供了兩種重要的控制機制：流量控制和擁塞控制。

流量控制（Flow Control）

流量控制的主要目的是防止發(fā)送方向接收方發(fā)送過多數(shù)據(jù)，導致接收方處理不過來。TCP 使用滑動窗口機制來實現(xiàn)流量控制。在 TCP 連接中，接收方為每個連接分配一個接收緩沖區(qū)。接收方通過通知發(fā)送方自己的窗口大小，告知發(fā)送方可以發(fā)送的數(shù)據(jù)量。窗口大小表示接收方當前能接受的數(shù)據(jù)字節(jié)數(shù)。

滑動窗口的工作原理如下：

發(fā)送方根據(jù)接收方的窗口大小來確定發(fā)送的數(shù)據(jù)量。當接收方收到數(shù)據(jù)后，發(fā)送確認報文，同時更新窗口大小。發(fā)送方收到確認報文后，更新已發(fā)送但未確認的數(shù)據(jù)量，并根據(jù)新的窗口大小調(diào)整發(fā)送速率。

擁塞控制（Congestion Control）

擁塞控制的目的是防止過多的數(shù)據(jù)進入網(wǎng)絡，導致網(wǎng)絡擁塞。TCP 使用四種算法來實現(xiàn)擁塞控制：慢開始、擁塞避免、快速重傳和快速恢復。

慢開始：發(fā)送方初始擁塞窗口設置為一個較小的值。隨后，每收到一個確認報文，擁塞窗口大小加倍。這樣，發(fā)送速率會以指數(shù)形式增長，直到達到一個閾值（ssthresh）。擁塞避免：當擁塞窗口到達閾值后，發(fā)送方轉入擁塞避免階段，窗口大小每經(jīng)過一個往返時間（RTT）就增加1。這樣，擁塞窗口的大小呈線性增長，避免了網(wǎng)絡擁塞。快速重傳：當發(fā)送方連續(xù)收到三個重復的確認報文，表示可能有一個數(shù)據(jù)包丟失。此時，發(fā)送方立即重傳丟失的數(shù)據(jù)包，而不是等待超時重傳。快速恢復：快速重傳后，發(fā)送方降低擁塞窗口閾值，然后進入擁塞避免階段。這樣可以在丟包后盡快恢復傳輸速率。

通過這兩種控制機制，TCP 能確保在各種網(wǎng)絡條件下有效、可靠地傳輸數(shù)據(jù)。

ps：《TCP 重傳、滑動窗口、流量控制、擁塞控制》完整詳細講解：https://xiaolincoding.com/network/3_tcp/tcp_feature.html

一條url請求頁面的執(zhí)行過程

（這塊我答的不太好，忘了dns服務器的名字）瀏覽器先解析url地址，然后生成http消息，生成的消息需要知道ip地址才能發(fā)送，就先去瀏覽器的緩存中查詢，沒有的話查看操作系統(tǒng)的緩存，如果還是沒有就在本地dns中查詢，本地dns查詢不到后會先訪問根dns，根dns查詢的是存放這個ip的二級dns服務器（忘了名字），二級dns服務器會向對應的權威dns服務器查詢，權威dns服務器會向本地返回ip地址，然后本地通過這個ip地址和請求的服務端建立起tcp連接，服務端向本地發(fā)送請求的資源。

小林補充：

ps：《鍵入網(wǎng)址到網(wǎng)頁顯示，期間發(fā)生了什么？》完整詳細講解：https://xiaolincoding.com/network/1_base/what_happen_url.html

TCP是如何建立連接的

三次握手

1、客戶端發(fā)送請求建立連接報文，報文的SYN=1

2、服務端收到后，發(fā)送連接報文，報文的SYN=1，并且發(fā)送一個序號字段

3、客戶端收到后報文后，客戶端到服務端的連接已經(jīng)建立，客戶端發(fā)送報文對上一個報文的序號端進行確認

小林補充：

TCP 是面向連接的協(xié)議，所以使用 TCP 前必須先建立連接，而建立連接是通過三次握手來進行的。三次握手的過程如下圖：

TCP 三次握手

• 一開始，客戶端和服務端都處于

CLOSE

• 狀態(tài)。先是服務端主動監(jiān)聽某個端口，處于

LISTEN

• 狀態(tài)客戶端會隨機初始化序號（

client_isn

• ），將此序號置于 TCP 首部的「序號」字段中，同時把

SYN

• 標志位置為

1

• ，表示

SYN

• 報文。接著把第一個 SYN 報文發(fā)送給服務端，表示向服務端發(fā)起連接，該報文不包含應用層數(shù)據(jù)，之后客戶端處于

SYN-SENT

• 狀態(tài)。服務端收到客戶端的

SYN

• 報文后，首先服務端也隨機初始化自己的序號（

server_isn

• ），將此序號填入 TCP 首部的「序號」字段中，其次把 TCP 首部的「確認應答號」字段填入

client_isn + 1

• , 接著把

SYN

• 和

ACK

• 標志位置為

1

• 。最后把該報文發(fā)給客戶端，該報文也不包含應用層數(shù)據(jù)，之后服務端處于

SYN-RCVD

• 狀態(tài)?？蛻舳耸盏椒斩藞笪暮?，還要向服務端回應最后一個應答報文，首先該應答報文 TCP 首部

ACK

• 標志位置為

1

• ，其次「確認應答號」字段填入

server_isn + 1

• ，最后把報文發(fā)送給服務端，這次報文可以攜帶客戶到服務端的數(shù)據(jù)，之后客戶端處于

ESTABLISHED

• 狀態(tài)。服務端收到客戶端的應答報文后，也進入

ESTABLISHED

狀態(tài)。

ps：《TCP 三次握手與四次揮手面試題》完整詳細講解：https://xiaolincoding.com/network/3_tcp/tcp_interview.html

http和https的區(qū)別

1、https是需要通過CA申請才能獲得，所以數(shù)量是比較少的

2、http發(fā)送的報文是明文，所以不安全，https在傳輸層之上加了ssl協(xié)議

小林補充：

HTTP是一種用于傳輸超文本的協(xié)議，數(shù)據(jù)傳輸是明文的，不具備加密和安全性。HTTP使用的端口號是 80

HTTPS是在HTTP的基礎上加入了SSL/TLS協(xié)議進行加密和身份驗證的安全版本。它使用加密的SSL/TLS協(xié)議進行數(shù)據(jù)傳輸，保證了數(shù)據(jù)的機密性和完整性。HTTPS使用的端口號是443。

ps：《 HTTP 常見面試題》完整詳細講解：https://xiaolincoding.com/network/2_http/http_interview.html

數(shù)據(jù)庫的索引

B+樹索引，hash索引、全文索引

B+樹索引的話是innodb采用的索引，索引的葉子結點上是數(shù)據(jù)，非葉子結點是索引信息

hash索引單個的查找效率很高

為什么采用B+樹索引，它有什么優(yōu)點

這里我將B+樹和B樹、紅黑樹做了比較。

B+樹相對于B樹，只有葉子結點存儲的是數(shù)據(jù)信息，非葉子結點都是索引信息，所以在查找時加載到內(nèi)存中的數(shù)據(jù)少，B+樹的增刪相對于B樹來說比較穩(wěn)定，不會發(fā)生頻繁的父子結點替換，B+樹的葉子結點是連接的，所以很容易實現(xiàn)范圍查詢

B+樹相對于紅黑樹，首先B+樹的層高比較小，意味著讀取數(shù)據(jù)時IO磁盤的次數(shù)比較少，紅黑樹增刪結點時需要保持子樹的穩(wěn)定性，增刪的效率很低，B+樹更容易實現(xiàn)范圍查詢。

小林補充：

樹的高度決定于磁盤 I/O 操作的次數(shù)，因為樹是存儲在磁盤中的，訪問每個節(jié)點，都對應一次磁盤 I/O 操作，也就是說樹的高度就等于每次查詢數(shù)據(jù)時磁盤 IO 操作的次數(shù)，所以樹的高度越高，就會影響查詢性能。

B 樹和 B+ 都是通過多叉樹的方式，會將樹的高度變矮，所以這兩個數(shù)據(jù)結構非常適合檢索存于磁盤中的數(shù)據(jù)。

但是 MySQL 默認的存儲引擎 InnoDB 采用的是 B+ 作為索引的數(shù)據(jù)結構，原因有：

B+ 樹的非葉子節(jié)點不存放實際的記錄數(shù)據(jù)，僅存放索引，因此數(shù)據(jù)量相同的情況下，相比存儲即存索引又存記錄的 B 樹，B+樹的非葉子節(jié)點可以存放更多的索引，因此 B+ 樹可以比 B 樹更「矮胖」，查詢底層節(jié)點的磁盤 I/O次數(shù)會更少。B+ 樹有大量的冗余節(jié)點（所有非葉子節(jié)點都是冗余索引），這些冗余索引讓 B+ 樹在插入、刪除的效率都更高，比如刪除根節(jié)點的時候，不會像 B 樹那樣會發(fā)生復雜的樹的變化；B+ 樹葉子節(jié)點之間用鏈表連接了起來，有利于范圍查詢，而 B 樹要實現(xiàn)范圍查詢，因此只能通過樹的遍歷來完成范圍查詢，這會涉及多個節(jié)點的磁盤 I/O 操作，范圍查詢效率不如 B+ 樹。

ps：《為什么 MySQL 采用 B+ 樹作為索引？》完整詳細講解：https://xiaolincoding.com/mysql/index/why_index_chose_bpuls_tree.html

數(shù)據(jù)庫中事務可能帶來的問題

有臟讀、不可重復讀、幻讀三個問題：

臟讀：一個事務讀取另一個事務沒有提交的數(shù)據(jù)

不可重復讀：一個事務重復讀取一條數(shù)據(jù)時發(fā)現(xiàn)讀取到的數(shù)據(jù)不相同

幻讀：一個事務后讀取的數(shù)據(jù)相比之前讀取的數(shù)據(jù)中多了一些數(shù)據(jù)

小林補充：

MySQL 服務端是允許多個客戶端連接的，這意味著 MySQL 會出現(xiàn)同時處理多個事務的情況。

那么在同時處理多個事務的時候，就可能出現(xiàn)臟讀（dirty read）、不可重復讀（non-repeatable read）、幻讀（phantom read）的問題。

1、臟讀：如果一個事務「讀到」了另一個「未提交事務修改過的數(shù)據(jù)」，就意味著發(fā)生了「臟讀」現(xiàn)象。

舉個栗子，假設有 A 和 B 這兩個事務同時在處理，事務 A 先開始從數(shù)據(jù)庫中讀取小林的余額數(shù)據(jù)，然后再執(zhí)行更新操作，如果此時事務 A 還沒有提交事務，而此時正好事務 B 也從數(shù)據(jù)庫中讀取小林的余額數(shù)據(jù)，那么事務 B 讀取到的余額數(shù)據(jù)是剛才事務 A 更新后的數(shù)據(jù)，即使沒有提交事務。

圖片

因為事務 A 是還沒提交事務的，也就是它隨時可能發(fā)生回滾操作，如果在上面這種情況事務 A 發(fā)生了回滾，那么事務 B 剛才得到的數(shù)據(jù)就是過期的數(shù)據(jù)，這種現(xiàn)象就被稱為臟讀。

2、不可重復讀：在一個事務內(nèi)多次讀取同一個數(shù)據(jù)，如果出現(xiàn)前后兩次讀到的數(shù)據(jù)不一樣的情況，就意味著發(fā)生了「不可重復讀」現(xiàn)象。

舉個栗子，假設有 A 和 B 這兩個事務同時在處理，事務 A 先開始從數(shù)據(jù)庫中讀取小林的余額數(shù)據(jù)，然后繼續(xù)執(zhí)行代碼邏輯處理，在這過程中如果事務 B 更新了這條數(shù)據(jù)，并提交了事務，那么當事務 A 再次讀取該數(shù)據(jù)時，就會發(fā)現(xiàn)前后兩次讀到的數(shù)據(jù)是不一致的，這種現(xiàn)象就被稱為不可重復讀。

圖片

3、幻讀：在一個事務內(nèi)多次查詢某個符合查詢條件的「記錄數(shù)量」，如果出現(xiàn)前后兩次查詢到的記錄數(shù)量不一樣的情況，就意味著發(fā)生了「幻讀」現(xiàn)象。

舉個栗子，假設有 A 和 B 這兩個事務同時在處理，事務 A 先開始從數(shù)據(jù)庫查詢賬戶余額大于 100 萬的記錄，發(fā)現(xiàn)共有 5 條，然后事務 B 也按相同的搜索條件也是查詢出了 5 條記錄。

圖片

接下來，事務 A 插入了一條余額超過 100 萬的賬號，并提交了事務，此時數(shù)據(jù)庫超過 100 萬余額的賬號個數(shù)就變?yōu)?6。然后事務 B 再次查詢賬戶余額大于 100 萬的記錄，此時查詢到的記錄數(shù)量有 6 條，發(fā)現(xiàn)和前一次讀到的記錄數(shù)量不一樣了，就感覺發(fā)生了幻覺一樣，這種現(xiàn)象就被稱為幻讀。

ps：《事務隔離級別是怎么實現(xiàn)的？》完整詳細講解：https://xiaolincoding.com/mysql/transaction/mvcc.html

通過什么隔離級別解決這些問題

臟讀：讀寫已提交

不可重復讀：可重復讀

幻讀：串行化

小林補充：

針對不同的隔離級別，并發(fā)事務時可能發(fā)生的現(xiàn)象也會不同。

圖片

也就是說：

在「讀未提交」隔離級別下，可能發(fā)生臟讀、不可重復讀和幻讀現(xiàn)象；在「讀提交」隔離級別下，可能發(fā)生不可重復讀和幻讀現(xiàn)象，但是不可能發(fā)生臟讀現(xiàn)象；在「可重復讀」隔離級別下，可能發(fā)生幻讀現(xiàn)象，但是不可能臟讀和不可重復讀現(xiàn)象；在「串行化」隔離級別下，臟讀、不可重復讀和幻讀現(xiàn)象都不可能會發(fā)生。

所以，要解決臟讀現(xiàn)象，就要升級到「讀提交」以上的隔離級別；要解決不可重復讀現(xiàn)象，就要升級到「可重復讀」的隔離級別，要解決幻讀現(xiàn)象不建議將隔離級別升級到「串行化」。

不同的數(shù)據(jù)庫廠商對 SQL 標準中規(guī)定的 4 種隔離級別的支持不一樣，有的數(shù)據(jù)庫只實現(xiàn)了其中幾種隔離級別，我們討論的 MySQL 雖然支持 4 種隔離級別，但是與SQL 標準中規(guī)定的各級隔離級別允許發(fā)生的現(xiàn)象卻有些出入。

MySQL 在「可重復讀」隔離級別下，可以很大程度上避免幻讀現(xiàn)象的發(fā)生（注意是很大程度避免，并不是徹底避免），所以 MySQL 并不會使用「串行化」隔離級別來避免幻讀現(xiàn)象的發(fā)生，因為使用「串行化」隔離級別會影響性能。

ps：《事務隔離級別是怎么實現(xiàn)的？》完整詳細講解：https://xiaolincoding.com/mysql/transaction/mvcc.html

mysql的隔離級別是什么?mysql是如何實現(xiàn)的？

不可重復讀，但是很大程度上避免幻讀

快照讀（只讀）：MVCC

當前讀（更新操作）：記錄鎖+間隙鎖

小林補充：

MySQL InnoDB 引擎的默認隔離級別雖然是「可重復讀」，但是它很大程度上避免幻讀現(xiàn)象（并不是完全解決了），解決的方案有兩種：

• 針對

快照讀

• （普通 select 語句），是

通過 MVCC 方式解決了幻讀

• ，因為可重復讀隔離級別下，事務執(zhí)行過程中看到的數(shù)據(jù)，一直跟這個事務啟動時看到的數(shù)據(jù)是一致的，即使中途有其他事務插入了一條數(shù)據(jù)，是查詢不出來這條數(shù)據(jù)的，所以就很好了避免幻讀問題。針對

當前讀

• （select ... for update 等語句），是

通過 next-key lock（記錄鎖+間隙鎖）方式解決了幻讀

，因為當執(zhí)行 select ... for update 語句的時候，會加上 next-key lock，如果有其他事務在 next-key lock 鎖范圍內(nèi)插入了一條記錄，那么這個插入語句就會被阻塞，無法成功插入，所以就很好了避免幻讀問題。

ps：《事務隔離級別是怎么實現(xiàn)的？》完整詳細講解：https://xiaolincoding.com/mysql/transaction/mvcc.html

算法

寫一個數(shù)據(jù)庫的多表聯(lián)查問題

沒寫出來（平時寫的少，只知道命令，不熟練），講解下思路

反問

1、咱們部門具體做什么

2、進來需要轉語言嗎

面試總結

一定要補足sql方面的知識，多寫一寫計網(wǎng)的知識回答的太模糊多看java并發(fā)相關的知識平時還是要積累，多問問為什么