2015在實習(xí)的時候，當(dāng)時一個一起實習(xí)的朋友在2019年3月份的時候突然在微信上找我，問我要不要面試下螞蟻金服。問了下相關(guān)信息才知道他在2018年11月的時候進到螞蟻金服，現(xiàn)在招人就想到了我，問我要不要試一下。

剛開始還是有所顧慮的，因為畢竟是大廠，進去應(yīng)該不容易，但是這個朋友進去了，想想應(yīng)該也沒有很難吧，畢竟當(dāng)時實習(xí)的時候，他技術(shù)并不怎么樣。但是畢竟過去好幾年了，現(xiàn)在人家可能變厲害了。

所以一開始并沒有急著提交簡歷，而是說準(zhǔn)備下再提交簡歷。然后就準(zhǔn)備了一周，寫簡歷，刷題，在網(wǎng)上找螞蟻金服的面經(jīng)。提交了一份簡歷，然后發(fā)現(xiàn)簡歷上面沒有寫學(xué)歷，幸好他還沒提交，就修改了下重新發(fā)了一份，然后他又給我提了幾個建議，所以又改了一版，才最終提交。

提交簡歷后的第二天下午，上班的時候螞蟻金服的面試官打電話過來了，說要面試，當(dāng)時正在上班，就說了下不方便，就約了當(dāng)天晚上再面試。誰知道當(dāng)天小組因為來了新人，晚上要聚餐，所以沒辦法，就厚著臉皮給面試官發(fā)了短信，說了下晚上臨時有事不能參加，想約下第二天或者周末。沒想到面試官很理解，主要提出第二天晚上八點面試，短信上還讓我好好準(zhǔn)備，好好加油。

題外話： 有時間沖突的時候及時跟面試官溝通，往往第一面是技術(shù)面，大家都是做技術(shù)的，能理解的。 平時多交點朋友往往會有意外的驚喜

電面一

第二天晚上六點多快七點的時候面試官提前打電話了，這天是周五幸好及時下班，原本是想著早點下班回去再準(zhǔn)備準(zhǔn)備，誰知道電話來的那么突然，剛點好晚飯，還沒來得及吃。既然電話都打來了，那就面唄，就到店外面面試了。

流程

1、2分鐘的自我介紹

大致講了自己的姓名，畢業(yè)院校，哪年畢業(yè)，個人愛好以及平時空閑時間做點什么，這個如實回答就好。因為之前有面試過，所以準(zhǔn)備過。建議可以自己提前寫下來，多說幾遍，找點感覺。

2、你自己認為自己最熟悉的技術(shù)是什么？

這個就因人而異了，每個人熟悉的東西都不一樣，一定要說自己最擅長的東西，不要給自己挖坑。因為面試官下一步就會根據(jù)你的回答進行提問。對于我來是，工作了幾年學(xué)的東西多而雜，沒有什么很深入的，但是總不能說沒有吧，所以就說了 Java 開發(fā)比較多，所以 Java 語言熟悉多一點。然后面試官就說：“好，那我就問你一點 Java 語言方面的。”

3、 HashMap 底層實現(xiàn)原理是什么？

這個作為一個面試必問的題目，所以我還是提前準(zhǔn)備過的，看過源碼。所以這個問題不是問題，答完，面試官說回答的對了。

HashMap，HashTable，ConcurrentHashMap 面試必備，針對1.7和1.8的不同實現(xiàn)加以說明。包括底層的數(shù)據(jù)結(jié)構(gòu)，Hash 碰撞生成鏈表，Java8的鏈表轉(zhuǎn)紅黑樹。

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

根據(jù)自身情況，用過就用過，沒用過就沒有用過。我回答有簡單的使用過，但是使用的場景不多。面試官也就沒追問了，說了沒關(guān)系，就繼續(xù)。

5、講一下線程池，以及實現(xiàn)固定大小線程池底層是如何實現(xiàn)的？

講了下四中線程池，單一線程池，固定大小線程池，緩存線程池，定時線程池。但是關(guān)于固定大小線程池底層是如何實現(xiàn)的，回答的不好，面試官直接問底層的源碼是不是沒看過，就說是的。面試官說沒關(guān)系。。。

追加：線程池底層都是通過ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)來實現(xiàn)的。

corePoolSize: 表示需要設(shè)置的線程個數(shù)； maximumPoolSize: 線程池允許的最大線程個數(shù)； keepAliveTime: 空閑線程存活的時間，超過這個時間就會被回收； unit: 存活時間的單位；workQueue: 需要執(zhí)行的任務(wù)隊列。threadFactory: 線程工廠，用于創(chuàng)建線程，一般用默認的即可； handler: 拒絕策略，當(dāng)任務(wù)太多來不及處理，如何拒絕任務(wù)； 拒絕策略： 直接丟棄（DiscardPolicy） 丟棄隊列中最老的任務(wù)(DiscardOldestPolicy) 拋異常(AbortPolicy) 將任務(wù)分給調(diào)用線程來執(zhí)行(CallerRunsPolicy)

6、Redis 為什么這么高效，使用的場景是什么？

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

1、完全基于內(nèi)存，大多數(shù)請求都是內(nèi)存操作，非?？焖?； 2、數(shù)據(jù)結(jié)構(gòu)簡單，操作簡單； 3、采用單線程，避免了不必要的上下文切換和競爭條件，不存在多進程或者多線程的切換，不用考慮鎖帶來的性能消耗； 4、使用多路 I/O復(fù)用模型，非阻塞 IO

7、分布式服務(wù)是否了解，zookeeper，dubbo 是否使用過？

關(guān)于 zk 和 dubbo 這塊用的不多，zk 主要是在使用 kafka 的時候會用到，但是不涉及原理上面的研究。dubbo 雖然項目中有用過，但是并不是很深入，就沒說用過，直接說沒用過。

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

冪等性是數(shù)學(xué)上的含義是對于參數(shù) x，f(x)=f(f(x));比如絕對值函數(shù)。 在分布式環(huán)境下表示的是對于同樣的請求，在一次或者多次請求的情況下對系統(tǒng)的使用資源是一樣的。保證失敗重試不會導(dǎo)致提交兩次。 方法： 帶版本號的方式； 采用數(shù)據(jù)庫唯一索引方式；

9、常用的數(shù)據(jù)庫是什么？

我們常用的數(shù)據(jù)庫是 MySQL，所以就回答了 MySQL。

10、MySQL 的事務(wù)特性有哪些？

•首先事務(wù)是作為單個邏輯工作單元執(zhí)行的一系列操作，這些操作作為一個整體一起向系統(tǒng)提交，要么都執(zhí)行，要么都不執(zhí)行。事務(wù)是一個不可分割的邏輯單元。•A（原子性）事務(wù)的各步操作是不可分的，保證一系列的操作要么都完成，要么都不完成；•C（一致性）事務(wù)完成，數(shù)據(jù)必須處于一致的狀態(tài)；•I（隔離性）對數(shù)據(jù)進行修改的所有并發(fā)事務(wù)彼此之間是相互隔離，這表明事務(wù)必須是獨立的，不應(yīng)以任何方式依賴或影響其他事務(wù)；•D（持久性）表示事務(wù)對數(shù)據(jù)處理結(jié)束后，對數(shù)據(jù)更改必須持久化，不管是事務(wù)成功還是回滾。事務(wù)日志都能夠保持事務(wù)的永久性。

11、如果現(xiàn)在一臺生產(chǎn)的數(shù)據(jù)庫掛了怎么處理？

首先這題沒有 get 的面試官想問的點是什么，所以就根據(jù)自己項目本身的情況做答了。我們項目生產(chǎn)上的數(shù)據(jù)庫是有主備的，在主數(shù)據(jù)庫掛掉的情況下是會切換到備數(shù)據(jù)庫，先保證業(yè)務(wù)的穩(wěn)定性，然后在對崩潰現(xiàn)場進行保留，方便后續(xù)分析問題，找到原因。這里面試官追問了一下，我們主備的切換是自動的還是手動的，這個由于是公司運維團隊負責(zé)的，自己本身不是特別清楚，但是根據(jù)對公司運維團隊的了解，應(yīng)該是自動的。所以就這樣如實的回答了。

12、數(shù)據(jù)庫如何實現(xiàn) rollback 的？

數(shù)據(jù)庫在寫入數(shù)據(jù)之前是先講對數(shù)據(jù)的改動寫入 redo log 和 undo log，然后在操作數(shù)據(jù)，如果成功提交事務(wù)就會講操作寫入磁盤；如果失敗就會根據(jù)redo log 和 undo log 逆向還原到事務(wù)操作之前的狀態(tài)。

13、工作這么久你遇到的最難的技術(shù)點是什么？

我這邊根據(jù)具體的工具經(jīng)理，回答的是 kafka 的初次使用，因為當(dāng)時是公司內(nèi)部第一個引入 kafka，之前沒有小組使用過，所以要采很多坑。并且那個時候 kafka 還沒有發(fā)布1.0版本，官網(wǎng)和網(wǎng)上提供的版本很雜亂不兼容。

14、用過Kafka 的話說下 Kafka優(yōu)缺點有哪些？

•Kafka 是一個高吞吐量的消息隊列?；镜慕M件有生產(chǎn)者，消費者，node 節(jié)點，生產(chǎn)者負責(zé)生產(chǎn)消息，將消息發(fā)送到指定的 topic 或者 partition 當(dāng)中。•每個 partition 可以有多個分區(qū)副本，并且存放在不同的 broker 節(jié)點上，保證數(shù)據(jù)的安全。partiton 的底層是根據(jù) segment 段存放的一系列日志文件，文件里面存放的具體的消息內(nèi)容，每條消息都有一個唯一的 offset 偏移量，并且是按照磁盤順序存放的。由于磁盤是順序讀寫，所以 kafka 可以有很高的吞吐量。磁盤的順序讀寫比隨機讀寫的性能高很多。•每個消費者都屬于一個消費者組，可以消費指定 topic 下的數(shù)據(jù)。

15、TCP/IP 協(xié)議是如何保證數(shù)據(jù)可靠性的？

首先 TCP是面向連接的傳輸協(xié)議。主要通過消息確認和重試機制來保證數(shù)據(jù)傳輸?shù)目煽啃浴?/p>

電面二

二面的時間是在第二周，周四下午的時候打電話過來，問是否可以面試。但是當(dāng)時在上班就說不方便，能否周五晚上面試。面試官說可以。誰知道，第二天中午還沒下班就打電話過來說面試，可能本來周五大家各自事情都多吧，他也想盡快搞完。我這邊被突然的面試電話給搞懵了一下，想著不是約好了晚上么，怎么搞突擊。。。但是沒辦法，已經(jīng)推過一次，沒好意思再推掉。就說了我要找個安靜地方，稍等下。

整個面試過程不是很好，主要是在公司內(nèi)部找了個沒人的地方，說話聲音都不敢大，而且還經(jīng)常有人經(jīng)過，來來回回的。感覺這點沒有決策好，也是這次的一個遺憾。所以大家電話面試的時候一定要找個沒人的地方。

流程

1、先進行自我介紹，然后介紹自己做過的項目，從項目流程架構(gòu)設(shè)計等方面介紹

根據(jù)個人經(jīng)歷說了自己所做的項目，以及流程和架構(gòu)方面，因為是自己參與的項目，所以整個流程說的還是很流暢的。畢竟自己很熟悉。這塊盡量多從幾個方面講，流程，架構(gòu)，設(shè)計等。

2、HashMap 的查詢時間復(fù)雜度

理想情況下是 O(1)的，但是實際中會出現(xiàn) hash 碰撞，導(dǎo)致無法達到效果。

3、LinkedList和ArrayList的區(qū)別

• LinkedList 底層是基于雙向鏈表實現(xiàn)的，而 ArrayList 底層是基于動態(tài)數(shù)組實現(xiàn)的；
• 查詢的時候 LinkedList 的效率要低于 ArrayList，因為 LinkedList 需要遍歷鏈表，而 ArrayList 底層數(shù)組根據(jù)下標(biāo)直接獲取數(shù)據(jù)。
• 插入刪除數(shù)據(jù)的時候，LinkedList 效率比ArrayList 效率高，因為 ArrayList 在數(shù)據(jù)多的情況下會進行數(shù)組擴容或移動數(shù)組。
• 多進程與多線程在編程上面有什么需要注意的

首先進程是資源分配的最小單元，線程是任務(wù)調(diào)度的最小單元

5、ThreadLocal的使用場景

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

6、堆內(nèi)存和棧內(nèi)存有什么區(qū)別

• 堆內(nèi)存是線程共享的，棧內(nèi)存是線程私有的；
• 堆內(nèi)存用來存放由new創(chuàng)建的對象和數(shù)組，棧內(nèi)存中存放一些基本類型的變量和對象的引用變量；

7、堆排序時間復(fù)雜度

8、如果優(yōu)化數(shù)據(jù)庫的數(shù)據(jù)查詢，另外應(yīng)用層上還能如何優(yōu)化？

1）數(shù)據(jù)庫層面上：

除了主鍵索引，唯一索引之外，對于常用的查詢字段也要加索引。查詢的時候盡量使用主鍵索引，因為MySQL 的 InnoDB 的主鍵索引索引的是整行數(shù)據(jù)，而普通索引索引的是主鍵，會有回表操作。當(dāng)然索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時也降低了 insert 及 update 的效率，需要酌情考慮。 2、優(yōu)化查詢語句，盡量采用確認性查詢語句，減少 or，in，not in，%xxx%語法的使用。

2）應(yīng)用層面上：

• 采用緩存機制，將常用的數(shù)據(jù)進行緩存，增加訪問速度；
• 分庫分表，讀寫分離，將數(shù)據(jù)分開讀寫，提升性能

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

• 強一致性：對于更新后的數(shù)據(jù)，要求后續(xù)所有節(jié)點的任何操作都要獲取最新值的情況；
• 弱一致性：對于更新后的數(shù)據(jù)，后續(xù)節(jié)點的數(shù)據(jù)操作可以是新值，也可以是舊值，通過一段時間后后續(xù)節(jié)點對數(shù)據(jù)的操作都是新值；
• 最終一致性：是弱一致性的特殊形式，存儲系統(tǒng)保證在沒有新的更新的條件下，最終所有的訪問都是最后更新的值。

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

思路：首先考察的肯定是大數(shù)據(jù)處理方案，這些數(shù)據(jù)肯定不能一次性讀取到內(nèi)存，那就需要拆分，將數(shù)據(jù)分隔處理。假設(shè)要分隔為 n 個文件。

分隔：如果 ID 是整型的話，可以直接采用取模（id % n）的方式；如果 ID 是字符串可以先計算 hash 值然后再取模（hash(x) % n）的方式，將相同 ID 的商品分到同一個文件中。

針對每個小文件進行 top100的排序，返回購買最多的100個商品 ID•根據(jù) n 個文件中的100個 ID，在進行一次排序，即可得到需要的數(shù)據(jù)。

小結(jié)

首先很感謝內(nèi)推的那個朋友才有了這次的面試機會，雖然結(jié)果不盡人意，但是為自己的學(xué)習(xí)成長之旅增加了一些精彩。

然后說下這次的面試體驗，總得來說，感覺不是很好，因為幾次打電話都是在公司上班期間，畢竟在公司接到面試電話還是很不好的。沒有按照約定的時間點打電話，可能是我接觸的少，不知道其他公司是怎么樣的，總覺得這樣不太好。

身為一個目前在職三年，工作在深圳這樣的大環(huán)境下，還是有很大壓力的。以前上學(xué)的時候想著什么時候能月入過萬應(yīng)該就不愁什么的，但是漸漸的發(fā)現(xiàn)，及時月入過萬也還是過不好生活。周圍比你厲害比你強的人多了去了，你能做的就只有不斷的學(xué)習(xí)，不斷的進步。

到此這篇關(guān)于記一次螞蟻金服的面試經(jīng)歷(小結(jié))的文章就介紹到這了,更多相關(guān)螞蟻金服面試內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！

最新評論