上周在拉勾上收到一個螞蟻金服的大哥要我的簡歷，當(dāng)時很驚訝，居然有螞蟻金服的找到我，然后想都沒想就給了。
受寵若驚呀，我知道自己的水平跟阿里的差距有多遠(yuǎn)，以前一直沒用勇氣去投，連試試都不敢。這次居然主動找過來了，當(dāng)時就再想，難道阿里這么缺人么？還是只是為了完成某些KPI，當(dāng)然了，我這種想法比較幼稚。
沒想到的是第二天居然收到了阿里巴巴的面試邀請郵件，里面說到會在10個工作日內(nèi)進(jìn)行第一次面試。
不管怎么樣吧，既然面試來了，就試試吧。能面一次這種級別的技術(shù)公司，看看自己真實的差距，也是三生有幸了。從離職的這段時間也補了補JVM，基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)算法什么的，還有一些高頻的Java 基礎(chǔ)問題。
周一晚上 8：25 接到了螞蟻大哥來的電話，果然，跟傳說中的一樣，還在上班。當(dāng)時很意外，沒想到是電話面試，因為郵件中沒提到，后面回想，貌似一面基本上都是電話面試，有些朋友二面也是電面。
進(jìn)入正題，下面是整個內(nèi)容。順序有些不一致，我按照模塊來整理的。
自我介紹就先介紹 多大了、畢業(yè)多久了、做了什么些東西、最近做的什么內(nèi)容，擅長的部分呀 等等。
這里說一下，自我介紹的內(nèi)容如實說就好，不要太過于夸大，自我介紹的內(nèi)容建議大家提前準(zhǔn)備好，不要說的時候想到哪兒說到哪兒。
1、多線程的實現(xiàn)方式有哪些？
這個題目在一面的時候基本上都會碰到吧，繼承 Thread 類、實現(xiàn)Runnable 接口，最后調(diào)用 的是 start() 方法來啟動線程。
這里還有個知識點是 start() 跟 run() 方法的區(qū)別和聯(lián)系。
直接調(diào)用 start() 方法，此時線程處于一個就緒（可運行）的狀態(tài)，但是并沒有真正的運行。而是得到CPU 的時間片后，開始執(zhí)行 run() 方法，run() 方法里面的是我們的線程體。
我們直接 運行 run() 方法，它其實就是一個普通的方法調(diào)用，在主線程中執(zhí)行，是不會開啟多線程的。
2、描述一些線程死鎖的情況？
這個問題在平常項目基本上沒怎么接觸到，但是我有過部分了解?；卮鸬氖牵簝蓚€線程在持有自己的鎖的時候，還要去持有對方持有的鎖時，由于別人的鎖已經(jīng)被對方持有，造成彼此等待對方釋放鎖的情況?；卮鸬帽容^片面，還有一些類型的死鎖問題沒有答出來，后面直接交底了，面試官說沒關(guān)系的。
建議大家在準(zhǔn)備這個問題的時候能說出來產(chǎn)生死鎖的條件、現(xiàn)象、解決辦法等。然后配上一些實例說明，在面試過程中，面試官就提到說根據(jù)我們平常遇到死鎖問題的場景實例來說。
大家可以搜一下下面這兩個死鎖場景問題：
1、三個人 三根筷子：每個人需要拿到身邊的兩根筷子才能開始吃飯
2、銀行轉(zhuǎn)賬問題：線程 A 從 X 賬戶向 Y 賬戶轉(zhuǎn)賬，線程 B 從賬戶 Y 向賬戶 X 轉(zhuǎn)賬，那么就會發(fā)生死鎖。
3、項目中有沒有用過線程池 ？怎么用的 ？
回答了我們項目里面有些接口需要組裝多個服務(wù)的數(shù)據(jù)進(jìn)行封裝，然后返回。這里面我們會使用多線程去并行拉取數(shù)據(jù)，減少接口響應(yīng)時間。
面試官說：“ok，那么你有沒有看過線程池里面的源碼呢 ？有哪幾種線程池 ？”
源碼這里我遲疑了一下，我說不太熟，然后我說了幾種類型的線程池?newSingleThreadExecutor、newFixedThreadPool、newCachedThreadPool?但是還漏了一種?newScheduledThreadPool?沒想起來。
4、線程池的原理是什么樣子？底層方法的參數(shù)分別是什么意思？
回答這個問題的時候，當(dāng)時我卡住了。我知道這幾個底層都是對 調(diào)用的?ThreadPoolExecutor?，但是我死活沒有想起來名字，這時候面試官提醒了一下，然后說沒關(guān)系的。
接著就問：“那你知道他的參數(shù)都有哪些嗎 ？都分別代表什么意思嗎 ？”
我回答的是 有個 線程的個數(shù) 和 線程存活的時間，其他的沒說上來。然后面試官說：“沒關(guān)系的”。
補充一下：線程池底層都是通過 ThreadPoolExecutor 來實現(xiàn)的。
幾個參數(shù)的意思分別為：
corePoolSize：線程池里最小線程數(shù)
maximumPoolSize：線程池里最大線程數(shù)量，超過最大線程時候會使用 RejectedExecutionHandler
keepAliveTime：線程最大的存活時間，超過這個時間就會被回收
unit：線程最大的存活時間的單位
workQueue：緩存需要執(zhí)行的異步任務(wù)的隊列
threadFactory：新建線程工廠
handler：拒絕策略，表示當(dāng)workQueue已滿，且池中的線程數(shù)達(dá)到maximumPoolSize時，線程池拒絕添加新任務(wù)時采取的策略。DiscardPolicy：拋棄當(dāng)前任務(wù)，DiscardOldestPolicy：扔掉最舊的，CallerRunsPolicy：由向線程池提交任務(wù)的線程來執(zhí)行該任務(wù)，AbortPolicy：拋出 RejectedExecutionException 異常。
問到這里，我回答的確實太有限，面試官就沒有再細(xì)問了，還是說：“沒關(guān)系的”。
如果你這里答出來了，那么我認(rèn)為你還需要掌握的是，這幾種線程池在哪些情況下使用什么類型的，以及要注意什么問題，很大可能面試官會繼續(xù)深挖。
這里就不給出答案了，我相信你自己去搜一下，體會會更深刻些。
5、mybatis 的 $ 與 # 的區(qū)別？
回答：他們兩都可以來傳遞參數(shù)，不過 # 可以方式 sql 注入，而 $ 就是字符串拼接的方式處理，可能會有sql 注入的問題。
上面還有一個關(guān)鍵的點沒有答出來，那就是 #{} 在預(yù)處理時，會把參數(shù)部分用一個占位符 ? 代替 ，變成了如下的 sql 語句：
select?*?from?user?where?name = ?;
而 ${} 則只是簡單的字符串拼接，在動態(tài)解析階段就直接拼接成了 最終的sql 語句：
select?*?from?user?where?name =?'zhouq';
6、$ 跟 # 的使用場景 ？
這個問題我沒有怎么理解得到，然后回答的就是 $ 在拼接表名的時候用，其他時候傳遞參數(shù)值的時候用 #。
7、mybatis 的 dao 接口跟 xml 文件里面的sql 是如何建立關(guān)系的？
這里問到的時候比較蒙圈，然后回答的是：mybatis 會先解析這些xml 文件，xml 文件里面有命名空間 （namespace），這里可以跟dao 建立關(guān)系，然后 xml 中的每段 sql 會有一個id 跟 dao 中的接口進(jìn)行關(guān)聯(lián)。。。
然后面試官說: "如果 我有兩個這個xml 文件 都跟這個dao 建立關(guān)系了，那不是就是沖突了？",然后，我認(rèn)慫了。
我上面的回答太籠統(tǒng)，肯定是有問題的，建議你好好去了解一下mybatis 的原理。
mybatis 到這里就沒了。
先問的是，你平常使用得做多的是什么數(shù)據(jù)庫，當(dāng)然了，mysql 。
8、mysql 鎖機制 ？
面試官問的是，你了解mysql 的鎖機制么？我就只答出來一個行鎖。然后其他的沒想起，就認(rèn)了，其他的忘記了。
建議你去了解了解還有表鎖、頁面鎖 等等。
9、排它鎖 & 共享鎖你了解嗎 ？
這個地方我想了一會，說平時了解得不多。實時上，平常我們的小業(yè)務(wù)系統(tǒng)基本上沒有用到這些，可能有用到的地方，也沒有去在意吧。
接著，面試官說了下面這個場景題，然后讓出解決方案。
10、場景問題：在A線程處理一條數(shù)據(jù)，比如扣款，或者是更新狀態(tài)時候，其他的線程比如 B 需要對它進(jìn)行阻塞，不能夠再對這條數(shù)據(jù)進(jìn)行操作，包括查詢也不行，得等A 線程處理完成以后，B才能進(jìn)行處理。A 跟 B 是同樣的業(yè)務(wù)代碼產(chǎn)生的，非不同的業(yè)務(wù)。要使用數(shù)據(jù)庫的鎖來實現(xiàn)，怎么實現(xiàn) ？
問這個問題的時候，面試官很耐心的解釋了這個場景，然后問我有沒有想起點什么來？其實就是想考察上面的關(guān)于數(shù)據(jù)庫鎖的問題。
11、mysql 索引是怎么實現(xiàn)的？
回答的是 B+ 樹，接著面試官繼續(xù)問：“能否大致描述一下 B+ 樹的大致結(jié)構(gòu) ？”。這塊內(nèi)容沒怎么了解，直接認(rèn)慫了。
這塊內(nèi)容是我項目上寫得有使用了多級緩存的方案，然后面試官就這一塊問了下面的這些關(guān)于使用緩存可能會遇到的問題。
12、緩存擊穿、緩存穿透 、緩存雪崩 ？
13、熱點數(shù)據(jù)失效怎么解決？
這兩個問題，以前好好了解過，但是沒整理成自己的東西，面試的時候也說得云里霧里。
14、先刪緩存還是先更新數(shù)據(jù)庫，為什么？
這里我說的：是先刪緩存，然后再更新數(shù)據(jù)庫，但這是錯誤的，這里有非常大的問題。
想想這樣一個場景：
如果一個線程 A 先把緩存刪除了,然后去更新數(shù)據(jù)庫，那么在它刪了緩存還沒有更新到數(shù)據(jù)庫的這個中間時間，線程B進(jìn)來了，發(fā)現(xiàn)緩存沒有，就去讀庫，這時候還是讀取還是舊的數(shù)據(jù)，然后又更新到緩存去了。此時A 才把新數(shù)據(jù)寫到數(shù)據(jù)庫。
此時就產(chǎn)生了一個典型的問題就是“雙寫不一致”。
關(guān)于這塊問題的討論：《緩存更新的套路》-陳皓老師
15、kafka 的架構(gòu)，包含了哪些角色？
這個問題我開始不知道怎么回答，就說了個 Broker，然后面試官提醒了一下：“不是我們平常還有生產(chǎn)者，消費呀什么的嗎 ？”額，我說還有生產(chǎn)者、消費者、主題呀等等。
這過程中面試官還提到說平常我們在搭建的時候要配置寫什么東西呀等等，按照官網(wǎng)的介紹說也行。
這里還有其他的比如Partition、消費者組、還有一個主要的 就是 zk 了。
這里建議大家好好的把 kafka 里面的這些概念、屬于、架構(gòu)圖好好自己畫一下。不然真是關(guān)鍵時候真說不出來，但是他一提你又明白。這樣子肯定是不行的，面試是你說，不是面試官說。
16、kafka 的最小工作單元？
這個問題問得也是蒙圈，其實就是說我們在寫代碼的時候，要用kafka的時候。我們需要使用那些最基礎(chǔ)的組件，比如生產(chǎn)者、消費者、主題、偏移量 等等。
這個問題如果你們遇到，最好向面試官問清楚。
17、kafka 消息重復(fù)消費的問題？冪等怎么做的？
剛開始面試官說，你知道kafka 消息重復(fù)的問題嗎？有沒遇到。
我回答的是，會存在消息重復(fù)消費的問題。我們在消費數(shù)據(jù)這端做了冪等處理來解決。
然后面試官繼續(xù)才問的是：冪等怎么來做的， 我說通過設(shè)置數(shù)據(jù)版本號，還有數(shù)據(jù)庫唯一索引等等。
面試官：“ok”。
這個問題，如果你能告訴面試官產(chǎn)生重復(fù)消費的情況，比如說投遞的時候重復(fù)了，消費的時候由于 offset 沒處理好等等問題導(dǎo)致的話，我想可能會更好。
18、kafka ack 機制？集群中的ack 是怎么實現(xiàn)的？
這里我只回答上了 ack 機制是啥，但是實現(xiàn)原理沒有回答上來。
19、Redis 中有哪些數(shù)據(jù)結(jié)構(gòu)
平常使用得最多的是 String , 還有 List 、Hash、Set、ZSet 。
沒有再問其他的內(nèi)容。
但是像Redis 為什么這么快這種問題，我認(rèn)為你應(yīng)該要去了解，其他小伙伴經(jīng)常遇到。也就是多路復(fù)用是個什么玩意兒？
20、這里面試官問 你平常有沒有看過一些源碼？框架的也行？JDK 的也行。
然后我說看了 HashMap 的源碼,然后就巴拉巴拉的說了一哈大體的 put、get 流程 ，它的結(jié)構(gòu)是什么樣子的。
這過程中還問到了 怎么判斷兩個對象是否相等？也就是 == 和 equals 的知識點。
其他的就沒再繼續(xù)問了。到這里整個電面過程結(jié)束了，說10個工作日內(nèi)會給我答復(fù)此次面試情況。整個過程大概持續(xù)了40分鐘的樣子。
我知道，涼涼。
上面的模塊雖然順序有變化，但是每個大塊里面的問題都是按照順序來的，基本上都是由淺入深、循序漸進(jìn)的來問。
像數(shù)據(jù)庫鎖、線程池、緩存問題?這些內(nèi)容幾乎都是那種連環(huán)炮的形式，直到摸到你的底。
通過這次面試，親身體會到了差距。不過，更有方向了。
告誡大家一點東西：
平常多積累輸出：輸出或者教會別人是最好的學(xué)習(xí)方式，光看不練，幾天就忘。
先深后廣：深入學(xué)習(xí)，而不是只停留在使用API 的層面，一塊一塊系統(tǒng)的深入了解，再去搞其他的。
建立知識體系：把自己學(xué)習(xí)的內(nèi)容形成博客也好，什么導(dǎo)圖也罷，記得把這些零散的內(nèi)容，整理成自己的知識。
別抱有僥幸心理：別裸面，如果自己有整理的還是多看一下，多準(zhǔn)備準(zhǔn)備。大廠的面試會挖到你最深的部分，不要覺得只背一些面試題就是 ok的，題是背不完的。臨時抱佛腳基本上過不了關(guān)。如果你是靠背面試題進(jìn)去的，那么你厲害，佩服。
隔一段時間就去面試吧：不要學(xué)我，待一家公司三年多，中途都沒有出去面過，出去面面才知道，哪些是需要去補充的。
來源：CSDN
原文：https://blog.csdn.net/ityouknow/article/details/89507147
