2019 秋招提早批蘑菇街一面面經(帶答案)

今天給你們分享一下個人秋招提早批面試經歷，目前三面技術面已過，hr 面也面過了，正在等消息。因爲內容太多，先分享一面的面經。

自我介紹一下吧

面試官您好，我是 xxx 大學軟件工程的一名大三學生，從大一開始學習前端，產生了對編程的興趣，大二開始接觸 Java，大二下學期學了 ssm，springboot 等框架，也作了一些項目。後來發現基礎很重要，因而從大三開始一直到如今，一直在對基礎進行學習。好比：JVM，併發，操做系統，網絡等。

看你的項目是分佈式系統，那你的上游系統調用你的系統時可能會出現超時的問題，怎麼處理

在咱們的系統的話，通常有監控平臺，請求超時會拋出異常，會觸發企業微信郵件告警，開發人員知道之後去看一下對應的日誌中的異常信息。查到具體是調用哪一個接口出現的問題，這個接口裏是否調用外部系統，定位問題是外部的仍是內部的問題。

那若是你看到的日誌就是不少請求，你認爲這種是什麼問題，在外部系統沒有問題的狀況下核心線程池被打滿了

我以爲多是有人新改了一個功能並上線，不當心寫了死循環致使的 CPU 飄高。

PS：review code 的重要性

您說的線程池爆滿的緣由是可能一個接口中存在耗時的操做，致使請求這個接口的請求一直佔用線程池，線程池被打滿，從而致使後續來的其餘接口的請求也會被影響。

這種狀況通常能夠服務降級、限流來處理。

在外部流量沒有暴增的狀況下，若是你的服務每隔半個小時會出現服務不可用的狀況，這種怎麼排查

它這個是忽然每隔半個小時仍是其餘狀況?

就是這一天 11 點出現了，之後每隔半小時就會有兩分不可用，qps 都保持正常值

我猜這種狀況通常出如今，定時任務同步一些數據到其餘系統，因爲網絡的問題，那邊服務慢的話就會致使一個超時，而後就會發生這個問題。

正常接受請求，也沒有任務跑，你會往哪一個方面想

那它會不會受到部署機器其餘服務的影響呢。

沒有

想了幾分鐘.....，這個目前還想不到其餘的。

我能夠給你個提示，往內存方面想

昂，立馬 get 到點，是可能存在內存泄露嗎？是否是因爲存在內存泄露致使 full gc，gc 太頻繁致使的。

對，那這種問題怎麼排查解決

若是內存溢出的話，通常可能會有 OOM 拋出，JVM 能夠設置參數在出現 OOM 時 dump 下內存的鏡像，而後你能夠利用一些分析工具，分析這個 dump 文件，有的工具直接能夠給你一些優化建議，或者你能夠找到哪一個類的內存使用狀況，找到內存泄露的點，去看代碼。通常是 NIO 引發的，由於 Java 8 開啓方法區使用的是元空間，不是永久代了。元空間是本地內存，不是堆內存，不受 JVM 管理，由操做系統管理，因此使用不當可能會出現內存泄露的問題。

好，那下一個問題，你那邊用的是 dubbo 把

是

是借鑑 dubbo 開發的一個 rpc 框架吧

正常 Java 用的是 dubbo，以前是 php，爲了 php 和 java 微服務之間的跨語言調用，實現了一個跨語言的 rpc，如今已經所有轉爲 Java 了，都用 dubbo 調用。並且微服務架構方面又作了改進，使用了 Service Mesh，面向雲原生。

dubbo 服務的啓動、註冊流程，說一下

首先，有個服務的提供者啓動起來後，會先向服務註冊中心註冊服務，若是是 zk 的話，它就是在某個 dubbo 的目錄下注冊上下，其餘消費者想調用的話，就從 zk 上把對應的提供者的 ip 地址啥的拉下來緩存起來。而後就能夠調用了。

那提供服務的提供者 ip 更改了，消費者是如何動態感知服務提供者的改變呢

通常分佈式註冊服務能夠動態感知。若是是 zk 的話，服務提供者在 zk 上註冊服務時建立的是臨時節點，若是服務 ip 更改了或者服務掛了，服務的調用者經過 zk 的 watch 機制能夠監聽到服務提供者目錄下的節點增長、刪除、修改事件。

你用到了不少隊列，kafka、rabbitmq 瞭解嗎

我如今這邊用的是 nsq 和 kafka，kafka 通常是大數據那邊離線處理一些東西，nsq 通常是告警信息，兩個系統之間進行解耦，進行信息交互時，發消息到 nsq。區別的話，kafka 對大數據處理能力比較好，nsq 的話通常做爲一個正常的消息隊列，同步改異步就能夠用 nsq。

既然 Kafka 能夠處理大數據，那爲何不用 kafka，而用 nsq 呢？

這個問題我以前想過，問過個人 leader。kafka 通常是大數據那邊流處理什麼的，它那邊通常都只接受 kafka 的消息，和大數據集成比較好。至於選 nsq 的話，它是結合當時的業務場景選擇的，這個也沒有選哪一個好哪一個壞。

那他當時選型的時候，爲何不用 kafka

由於 kafka 貌似對於延時消息等支持的不太好，事務這些，它雖然對大數據的處理的好，可是它也有缺漏的地方，它有它的專攻方向，好比：吞吐量方面，可是也有它的不足之處，就比如計算機中的摩爾定律。通常業務系統常須要一些延時消息就須要用 nsq 了。

根據個人項目問的一些問題

......

有數據庫調優經驗嗎？對於數據庫有多索引匹配時，有什麼經驗嗎

這個匹配的話，好比：ABC 三個組合索引，必需要順序執行，好比 A = 2，C =2 。這個時候就不會執行，由於它破壞了順序性。

你說這種狀況是徹底用不到嗎

是的，由於它不知足索引的最左匹配原則。

那好比說，我數據庫有多個索引，A，B，BC，一個查詢條件 A，B，C 都有，那通常怎麼查看呢

這個通常的話是用 explain 去分析一下 sql 的執行計劃，它會輸出可能走的索引，真正走的索引，掃描的行數，額外的消耗（extra），用沒用臨時表等。

那它分析出來的索引就是數據庫必定會用的索引嗎

explain 分析出來的嗎

或者說，你以爲它 explain 分析出來的就是最佳的索引嗎

通常狀況下最佳的，數據庫會根據你的 sql，經過解析器生成對應的語法分析樹，它對這個樹進行一些規則的優化後，會生成一些查詢計劃，經過基於時間成本的分析算法選出一個儘量是最佳的查詢計劃。這個具體合不合適很難說。

你沒有遇到建的索引很差，致使走的索引是最差的狀況嗎

這個通常的話，多是你對索引一無所知，致使一些索引的規則不去遵照，並且數據庫索引的匹配規則不少，很容易走坑。若是你的業務必定要走你設置的那個索引，mysql 也能夠經過設置強制走你設置的某個索引。

你對 Java8 瞭解嗎

瞭解，由於我如今參與的項目就大量用了 Java8 的特性。好比：stream，lambda 表達式，時間 API 等。具體應用場景的話，好比你一個接口要返回 VO List 集合，而你數據庫查出來的是 DO List 集合，這個時候你就能夠用集合的 stream 去作這個轉換。相比於傳統的寫法，代碼會變的很簡單和清爽。

流式編寫代碼的好處和壞處能夠說一下嘛

好處的話，寫代碼的效率快了，看和很舒服。

壞處的話，流式性能不怎麼好，併發狀況不少的狀況下才體現出好。

我以爲最主要的是，以前你本身寫的話，就面向過程化了。流式的話，Java8 提倡的是面向函數式編程嘛。編程模型以前最開始是面向過程，而後面向對象，面向元編程，面向切面編程，面向函數式編程，之後 java9 的面向模塊化編程。並且把過程封裝在函數中，經過函數去轉換數據的狀態對於線程安全方面也有很大的好處。

若是數據庫對一些記錄存在熱點更新操做，有大量的更新，怎麼解決呢

通常能夠利用多級緩存去解決。若是數據量太猛增的話，你用 redis 客戶端訪問 redis 服務端都訪問不到，由於帶寬被打滿了嘛。這種狀況能夠提早去探測某個 key 是否是熱點，而後在本地緩存操做。

你怎麼即時同步數據給其餘人呢

它會有一個算法提早探測某個 key 是不是熱點，而後框架會幫你進行本地緩存的管理。

數據庫有單熱點，那你怎麼解決

這種通常先作一個緩存，而後能夠用消息隊列削峯填谷。

操做緩存可能會超時，你怎麼保證這個數據的正確性呢？由於你加了緩存呀

對對，這個數據庫和緩存保持一致性比較難保證。並且大量數據訪問更新，也不能加鎖，由於數據庫經過行鎖保證線程併發安全問題。

我要你解決的就是行鎖等待致使的性能被拉低的問題，用緩存也是能夠的，可是不能保證 100% 的數據一致性，那個人業務場景就是想要 100% 的數據一致性，你如今有大概的解決思路嗎

這個能夠用多套數據庫主從集羣來解決嗎？經過這種方式來提高數據庫的寫性能。讓多個集羣去抗。數據庫中間件能夠把流量分散到各個主從集羣中的主庫上。

能夠，這算是一種解決方案，那還有其餘辦法嗎

你打破這個行鎖就好了

...... 我再想一想。這個 ......

主要是單條記錄引發的，它就是頻繁更新引發的。

昂，這個是否是能夠......... 我看 JDK 源碼，頻繁更新它通常是： HashMap 是非線程安全的，後來出現了線程安全版的 HashTable，可是它性能比較差，由於它直接就對整個 hash 表進行了加鎖。後來出現了 CurrentHashMap，出現了分段鎖，下降了鎖的粒度，其實就是一種思想，你對一個熱點數據的訪問的話，就是分而治之，多去搞幾個，均攤一下。難道是利用 hash 一致性算法把這些寫請求，多分幾張表。

差很少吧，思想就是分而治之，只要把單點數據拆分掉，讓它變成多條數據，而後去更新多條數據，最後再合成一條。

嗯嗯。如今大數據通常也這樣，大的搞不動就拆分。

從和你的對話來看，我以爲你基礎也不錯，基礎我就不問了，我這邊沒有什麼問題了，我看你這邊，實習經歷豐富，offer 收的也挺多。你有什麼想問的

貴公司的技術棧，還有若是我進去之後所在的產品線。

面試官講述了他們公司的技術棧和一些業務

面試官對個人一些職業規劃的建議

多鍛鍊本身的技術思惟 + 業務思惟，能夠往業務中臺方向走。更好的支持別人的業務，技術主要服務於技術，要培養業務架構思惟。

總結

我以爲面試過程當中要避免本身一直在說，能夠多和麪試官去互動，去問面試官是否是這樣子，這樣能夠避免你理解錯面試官的問題。咱們的項目可能大部分是 CRUD，可是咱們的思惟不能夠停留在 CRUD，多去結合業務，也就是結合場景去思考你項目，這多是一個很大的優點。畢竟技術是用於服務業務，去解決業務需求。

整理面經不易，花了我週末大部分的時間，若是以爲寫的好話，歡迎關注公衆號、轉發，大家的支持是我繼續寫後續面經的動力。