記一次2020年螞蟻金服的面試經歷(小結)

這篇文章主要介紹了記一次螞蟻金服的面試經歷，文中詳細的介紹了幾回面試的記錄，對你們的學習或者工做具備必定的參考學習價值，分享給你們，也但願你們都面試成功
本文源自網絡

前言：

2016在實習的時候，當時一個一塊兒實習的朋友在2020年5月份的時候忽然在微信上找我，問我要不要面試下螞蟻金服。問了下相關信息才知道他在2019年11月的時候進到螞蟻金服，如今招人就想到了我，問我要不要試一下。

剛開始仍是有所顧慮的，由於畢竟是大廠，進去應該不容易，可是這個朋友進去了，想一想應該也沒有很難吧，畢竟當時實習的時候，他技術並不怎麼樣。可是畢竟過去好幾年了，如今人家可能變厲害了。

因此一開始並無急着提交簡歷，而是說準備下再提交簡歷。而後就準備了一週，寫簡歷，刷題，在網上找螞蟻金服的面經。提交了一份簡歷，而後發現簡歷上面沒有寫學歷，幸虧他還沒提交，就修改了下從新發了一份，而後他又給我提了幾個建議，因此又改了一版，才最終提交。

提交簡歷後的次日下午，上班的時候螞蟻金服的面試官打電話過來了，說要面試，當時正在上班，就說了下不方便，就約了當天晚上再面試。誰知道當天小組由於來了新人，晚上要聚餐，因此沒辦法，就厚着臉皮給面試官發了短信，說了下晚上臨時有事不能參加，想約下次日或者週末。沒想到面試官很理解，主要提出次日晚上八點面試，短信上還讓我好好準備，好好加油。

題外話： 有時間衝突的時候及時跟面試官溝通，每每第一面是技術面，你們都是作技術的，能理解的。 平時多交點朋友每每會有意外的驚喜。

電面一

次日晚上六點多快七點的時候面試官提早打電話了，這天是週五幸虧及時下班，本來是想着早點下班回去再準備準備，誰知道電話來的那麼忽然，剛點好晚飯，還沒來得及吃。既然電話都打來了，那就面唄，就到店外面面試了。

流程

一、2分鐘的自我介紹

大體講了本身的姓名，畢業院校，哪年畢業，我的愛好以及平時空閒時間作點什麼，這個如實回答就好。由於以前有面試過，因此準備過。建議能夠本身提早寫下來，多說幾遍，找點感受。

二、你本身認爲本身最熟悉的技術是什麼？

這個就因人而異了，每一個人熟悉的東西都不同，必定要說本身最擅長的東西，不要給本身挖坑。由於面試官下一步就會根據你的回答進行提問。對於我來是，工做了幾年學的東西多而雜，沒有什麼很深刻的，可是總不能說沒有吧，因此就說了 Java 開發比較多，因此 Java 語言熟悉多一點。而後面試官就說：「好，那我就問你一點 Java 語言方面的。」

三、 HashMap 底層實現原理是什麼？

這個做爲一個面試必問的題目，因此我仍是提早準備過的，看過源碼。因此這個問題不是問題，答完，面試官說回答的對了。
HashMap，HashTable，ConcurrentHashMap 面試必備，針對1.7和1.8的不一樣實現加以說明。包括底層的數據結構，Hash 碰撞生成鏈表，Java8的鏈表轉紅黑樹。

四、Java 的多線程有沒有使用過

根據自身狀況，用過就用過，沒用過就沒有用過。我回答有簡單的使用過，可是使用的場景很少。面試官也就沒追問了，說了不要緊，就繼續。

五、講一下線程池，以及實現固定大小線程池底層是如何實現的？

講了下四中線程池，單一線程池，固定大小線程池，緩存線程池，定時線程池。可是關於固定大小線程池底層是如何實現的，回答的很差，面試官直接問底層的源碼是否是沒看過，就說是的。面試官說不要緊。。。

• 追加：線程池底層都是經過ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)來實現的。

corePoolSize: 表示須要設置的線程個數； maximumPoolSize: 線程池容許的最大線程個數； keepAliveTime: 空閒線程存活的時間，超過這個時間就會被回收； unit: 存活時間的單位；workQueue: 須要執行的任務隊列。threadFactory: 線程工廠，用於建立線程，通常用默認的便可； handler: 拒絕策略，當任務太多來不及處理，如何拒絕任務； 拒絕策略： 直接丟棄（DiscardPolicy） 丟棄隊列中最老的任務(DiscardOldestPolicy) 拋異常(AbortPolicy) 將任務分給調用線程來執行(CallerRunsPolicy)

六、Redis 爲何這麼高效，使用的場景是什麼？

回答了一下咱們使用 redis 作緩存和登陸 session 存在的場景，以及 redis 是單線程的。

一、徹底基於內存，大多數請求都是內存操做，很是快速；
二、數據結構簡單，操做簡單；
三、採用單線程，避免了沒必要要的上下文切換和競爭條件，不存在多進程或者多線程的切換，不用考慮鎖帶來的性能消耗；
四、使用多路 I/O複用模型，非阻塞 IO

七、分佈式服務是否瞭解，zookeeper，dubbo 是否使用過？

關於 zk 和 dubbo 這塊用的很少，zk 主要是在使用 kafka 的時候會用到，可是不涉及原理上面的研究。dubbo 雖然項目中有用過，可是並非很深刻，就沒說用過，直接說沒用過。

八、冪等概念有沒有了解過

冪等性是數學上的含義是對於參數 x，f(x)=f(f(x));好比絕對值函數。 在分佈式環境下表示的是對於一樣的請求，在一次或者屢次請求的狀況下對系統的使用資源是同樣的。保證失敗重試不會致使提交兩次。 方法： 帶版本號的方式； 採用數據庫惟一索引方式；

九、經常使用的數據庫是什麼？

咱們經常使用的數據庫是 MySQL，因此就回答了 MySQL。

十、MySQL 的事務特性有哪些？

首先事務是做爲單個邏輯工做單元執行的一系列操做，這些操做做爲一個總體一塊兒向系統提交，要麼都執行，要麼都不執行。事務是一個不可分割的邏輯單元。

• （原子性）事務的各步操做是不可分的，保證一系列的操做要麼都完成，要麼都不完成；
• （一致性）事務完成，數據必須處於一致的狀態；
• （隔離性）對數據進行修改的全部併發事務彼此之間是相互隔離，這代表事務必須是獨立的，不該以任何方式依賴或影響其餘事務；
• （持久性）表示事務對數據處理結束後，對數據更改必須持久化，無論是事務成功仍是回滾。事務日誌都可以保持事務的永久性。

十一、若是如今一臺生產的數據庫掛了怎麼處理？

首先這題沒有 get 的面試官想問的點是什麼，因此就根據本身項目自己的狀況作答了。咱們項目生產上的數據庫是有主備的，在主數據庫掛掉的狀況下是會切換到備數據庫，先保證業務的穩定性，而後在對崩潰現場進行保留，方便後續分析問題，找到緣由。這裏面試官追問了一下，咱們主備的切換是自動的仍是手動的，這個因爲是公司運維團隊負責的，本身自己不是特別清楚，可是根據對公司運維團隊的瞭解，應該是自動的。因此就這樣如實的回答了。

十二、數據庫如何實現 rollback 的？

數據庫在寫入數據以前是先講對數據的改動寫入 redo log 和 undo log，而後在操做數據，若是成功提交事務就會講操做寫入磁盤；若是失敗就會根據redo log 和 undo log 逆向還原到事務操做以前的狀態。

1三、工做這麼久你遇到的最難的技術點是什麼？

我這邊根據具體的工具經理，回答的是 kafka 的初次使用，由於當時是公司內部第一個引入 kafka，以前沒有小組使用過，因此要採不少坑。而且那個時候 kafka 尚未發佈1.0版本，官網和網上提供的版本很雜亂不兼容。

1四、用過Kafka 的話說下 Kafka優缺點有哪些？

• Kafka 是一個高吞吐量的消息隊列。基本的組件有生產者，消費者，node 節點，生產者負責生產消息，將消息發送到指定的 topic 或者 partition 當中。
• 每一個 partition 能夠有多個分區副本，而且存放在不一樣的 broker 節點上，保證數據的安全。partiton 的底層是根據 segment 段存放的一系列日誌文件，文件裏面存放的具體的消息內容，每條消息都有一個惟一的 offset 偏移量，而且是按照磁盤順序存放的。因爲磁盤是順序讀寫，因此 kafka 能夠有很高的吞吐量。磁盤的順序讀寫比隨機讀寫的性能高不少。
• 每一個消費者都屬於一個消費者組，能夠消費指定 topic 下的數據。

1五、TCP/IP 協議是如何保證數據可靠性的？

首先 TCP是面向鏈接的傳輸協議。主要經過消息確認和重試機制來保證數據傳輸的可靠性。

電面二

二面的時間是在第二週，週四下午的時候打電話過來，問是否能夠面試。可是當時在上班就說不方便，可否週五晚上面試。面試官說能夠。誰知道，次日中午還沒下班就打電話過來講面試，可能原本週五你們各自事情都多吧，他也想盡快搞完。我這邊被忽然的面試電話給搞懵了一下，想着不是約好了晚上麼，怎麼搞突擊。。。可是沒辦法，已經推過一次，沒好意思再推掉。就說了我要找個安靜地方，稍等下。
整個面試過程不是很好，主要是在公司內部找了個沒人的地方，說話聲音都不敢大，並且還常常有人通過，來來回回的。感受這點沒有決策好，也是此次的一個遺憾。因此你們電話面試的時候必定要找個沒人的地方。

流程

一、先進行自我介紹，而後介紹本身作過的項目，從項目流程架構設計等方面介紹

根據我的經歷說了本身所作的項目，以及流程和架構方面，由於是本身參與的項目，因此整個流程說的仍是很流暢的。畢竟本身很熟悉。這塊儘可能多從幾個方面講，流程，架構，設計等。

二、HashMap 的查詢時間複雜度

理想狀況下是 O(1)的，可是實際中會出現 hash 碰撞，致使沒法達到效果。

三、LinkedList和ArrayList的區別

LinkedList 底層是基於雙向鏈表實現的，而 ArrayList 底層是基於動態數組實現的；

• 查詢的時候 LinkedList 的效率要低於 ArrayList，由於 LinkedList 須要遍歷鏈表，而 ArrayList 底層數組根據下標直接獲取數據。
• 插入刪除數據的時候，LinkedList 效率比ArrayList 效率高，由於 ArrayList 在數據多的狀況下會進行數組擴容或移動數組。
• 多進程與多線程在編程上面有什麼須要注意的

首先進程是資源分配的最小單元，線程是任務調度的最小單元

四、ThreadLocal的使用場景

ThreadLocal 適用於每一個線程須要本身獨立的實例且該實例須要在多個方法中被使用，也即變量在線程間隔離而在方法或類間共享的場景。

五、堆內存和棧內存有什麼區別

堆內存是線程共享的，棧內存是線程私有的；
堆內存用來存放由new建立的對象和數組，棧內存中存放一些基本類型的變量和對象的引用變量；

六、堆排序時間複雜度

七、若是優化數據庫的數據查詢，另外應用層上還能如何優化？

1）數據庫層面上：
除了主鍵索引，惟一索引以外，對於經常使用的查詢字段也要加索引。查詢的時候儘可能使用主鍵索引，由於MySQL 的 InnoDB 的主鍵索引索引的是整行數據，而普通索引索引的是主鍵，會有回表操做。固然索引並非越多越好，索引當然能夠提升相應的 select 的效率，但同時也下降了 insert 及 update 的效率，須要酌情考慮。 二、優化查詢語句，儘可能採用確認性查詢語句，減小 or，in，not in，%xxx%語法的使用。
2）應用層面上：

• 採用緩存機制，將經常使用的數據進行緩存，增長訪問速度；
• 分庫分表，讀寫分離，將數據分開讀寫，提高性能

八、強一致性，弱一致性，最終一致性

強一致性：對於更新後的數據，要求後續全部節點的任何操做都要獲取最新值的狀況；
弱一致性：對於更新後的數據，後續節點的數據操做能夠是新值，也能夠是舊值，經過一段時間後後續節點對數據的操做都是新值；
最終一致性：是弱一致性的特殊形式，存儲系統保證在沒有新的更新的條件下，最終全部的訪問都是最後更新的值。

九、有一個一百萬行的文件，內部是購買的商品ID，如何獲取到購買最多的前一百個商品。

思路：首先考察的確定是大數據處理方案，這些數據確定不能一次性讀取到內存，那就須要拆分，將數據分隔處理。假設要分隔爲 n 個文件。

分隔：若是 ID 是整型的話，能夠直接採用取模（id % n）的方式；若是 ID 是字符串能夠先計算 hash 值而後再取模（hash(x) % n）的方式，將相同 ID 的商品分到同一個文件中。

針對每一個小文件進行 top100的排序，返回購買最多的100個商品 ID•根據 n 個文件中的100個 ID，在進行一次排序，便可獲得須要的數據。

小結

首先很感謝內推的那個朋友纔有了此次的面試機會，雖然結果不盡人意，可是爲本身的學習成長之旅增長了一些精彩。
而後說下此次的面試體驗，總得來講，感受不是很好，由於幾回打電話都是在公司上班期間，畢竟在公司接到面試電話仍是很很差的。沒有按照約定的時間點打電話，多是我接觸的少，不知道其餘公司是怎麼樣的，總以爲這樣不太好。

身爲一個目前在職三年，工做在深圳這樣的大環境下，仍是有很大壓力的。之前上學的時候想着何時能月入過萬應該就不愁什麼的，可是漸漸的發現，及時月入過萬也仍是過很差生活。周圍比你厲害比你強的人多了去了，你能作的就只有不斷的學習，不斷的進步。

全部的面試題目都不是一成不變的，像螞蟻的面試真題只是給你們一個借鑑做用，最主要的是給本身增長知識的儲備，有備無患。

最後給你們分享：Java面試題總結+各知識點學習思惟導圖
點點我：領取方式：csdn

到此這篇關於記一次螞蟻金服的面試經歷(小結)的文章就介紹到這了。