阿里騰訊後臺Java社招面經（已拿offer）

一、基本狀況

博主17屆雙非一本畢業, 主要是搞Java開發的, 沒有大廠經驗. 2020 本身也立刻快3年工做經驗了. 若是再不找找機會進大廠深造一下, 後面的競爭力和我的的提高將會更難.所以在如今公司磨礪了兩年以後, 開始向大廠邁進~ 這篇博客主要是想分享一下本身在面試過程當中所遇到的問題,相對比較坎坷,先後經歷了3個多月.但願你們也能在找工做的過程當中,堅持下來!

二、面試結果

• 阿里-螞蟻支付寶 P6 offer
• 騰訊-pcg 2-3 offer
• 字節 2面 後放棄

三、面試過程

3.一、阿里-天貓超市

一面

一、靜態代理,動態代理

簡單描述區別, 而後能夠引出 jdk動態代理和cglib 的底層實現原理(Proxy 和 InvocationHandler).

再引入 Spring AOP 在不一樣狀況下采用的代理實現方式

最後舉例項目中動態代理的使用場景(常見的 日誌打印)

二、future (重點)

Future用來表明異步的結果.能夠引出 ExecutorService.submit 和 ExecutorService.execute 的區別

若是有研究過一些框架的源碼, 能夠說一下 Future 在其中起的做用(超時控制)

三、線程池實現方式-銷燬線程

這裏支持須要指出 Executors 和 ThreadPoolExecutor 之間的關係

經過設置不一樣的入參,實現不一樣的線程池. 比較有意思的 SynchronousQueue 實現原理能夠深刻學習一下

線程池回收: 傳送門

四、mysql 聯合索引

先介紹一下什麼是 聯合索引, 索引使用場景和失效狀況, 若是瞭解 索引下推 能夠說一下

引出 聯合索引 和 主鍵索引 有什麼區別. 而後能夠深刻對比一下 Innodb 和 MYISAM 的區別

點睛之筆 : 本身去寫幾條sql 查看索引的選擇規則, 你會發現並非創建了索引就會走, 也並非有索引下推就必定會去採用, 這就能夠涉及到 mysql 一條sql 的執行過程

五、redis 集羣

主要的幾種集羣: 主從,哨兵和redis Cluster 這幾種服務端集羣. 相似 Twemproxy 和 Codis這種代理實現,若是瞭解能夠說一下.

細問: 當前公司採用哪一種方案(哨兵),爲何(數據量較少,主從+哨兵能支撐業務場景),介紹哨兵的工做原理.

當時問了一個問題: 若是主掛了以後,選主結束後,怎麼去通知客戶端. 客戶端和哨兵是什麼樣的關係(有無關聯)

六、mysql 分庫分表

先問: 目前數據庫的容量大概是多少,有沒有作分庫分表設計.

答曰: 目前單表數據量在5000w左右, 日增加在10w之內, 暫時沒有這方面的考慮(劣大於優).

再引出: 分庫分表有哪些方式(垂直分庫, 垂直/水平分表),講解一下區別. 能夠再說一下 分佈式自增id 的實現方案,常見的好比 雪花算法, 美團-Leaf

七、項目內容

項目介紹,主要是挖掘你在工做中的思考以及亮點. 後面統一介紹, 由於每輪面試基本都會說一次
複製代碼

二面

二面流程比較快, 沒有什麼特色
複製代碼

• 介紹項目和當前公司的盈利模式
• 項目遇到最大的困難
• 項目的方案設計等

總共20多分鐘, 感受應該沒什麼大問題.

結果

爲啥那麼快到結果呢, 就是涼了~

面試完沒幾天, 跟二面面試官溝通, 是經過了, 還讓我準備一下後續的筆試

多是表現稍差,對比被 幹掉 或者 沒hc 了

3.2 騰訊TEG

一面

HashMap 底層實現

介紹基本結構,對比 1.7和1.8的區別

建議深刻閱讀 1.8 resize()的源碼, 還有紅黑素轉換的過程

HashMap 是否線程安全,若是須要使用線程安全的呢

對比 HashMap,HashTable 和 CurrentHashMap的區別和使用場景

給出一 個HashMap 要在線程安全的狀況下使用, 經過加鎖和 Collections.SynchronizedMap 對當前 HashMap 進行封裝

介紹一下紅黑樹

原理: 紅黑樹傳送門

應用場景: JDK1.8 HashMap , 對比 B+樹 和 跳躍表

redis 速度快是由於什麼緣由

• 內存
• 單線程
• 數據結構
• io多路服複用

性能瓶頸(內存,網絡io), 能夠指出 爲解決 網絡IO 的瓶頸,在 redis 6.0 提出的 單主線程,多工做線程的設計.能夠對比 Memecached 的多線程模型進行對比.

mysql 索引介紹

• 彙集索引和非聚索引的區別(InnoDb 和 MyISAM 對比)
• 索引選擇(優化器怎麼選擇索引)
• 索引失效
• 索引下推

爲何選擇b+樹

介紹 b+樹和b樹的區別, 對比b+樹在磁盤IO上面的優點(單頁能存更多的索引),能夠提一下mongodb 採用的是B樹索引 .

能夠參考: 爲何 MongoDB 索引選擇B樹，而 Mysql 選擇B+樹

彙集索引和非彙集索引

參考: 彙集索引和非彙集索引 簡析與對比

當時踩了個坑, 彙集索引和聚簇索引 實際上是一個東西

默認主鍵索引

若是沒有設置主鍵索引, innodb 會默認添加一個隱藏列做爲主鍵索引

爲何須要這個隱藏列, 能夠參考innodb的數據存儲結構

如何設計主鍵索引: MySQL主鍵設計

虛擬內存和物理內存

參考: 虛擬內存和物理內存的理解

簡而言之:

物理內存有限, 虛擬內存經過磁盤映射的形式進行分配物理內存
從而解決多個進程同時運行的狀況下內存不足的問題.
複製代碼

僞共享

僞共享原理

能夠結合 volatile 和 ConcurrenthashMap.countercell 進行解答

TCP如何確保可靠傳輸

• 數據包校驗
• 重排序
• 丟棄重複數據
• 應答機制
• 超時重傳
• 流量控制

擁塞控制

• 慢開始。
• 擁塞避免。
• 快重傳。
• 快恢復

計算機網絡這部分的內容相對來講比較考驗背誦理解.
須要你用本身的語言表達出來
複製代碼

項目設計

後續補充
複製代碼

kafka /es 有沒有使用過

有沒有了解最新版本的redis(支持多線程)

筆試題

筆試題的內容比較多, 有編程題,算法題 和程序運行結果的選擇題等

二面

項目遇到最大的問題(OOM) - 會比較長

我的的分析步驟, 感興趣能夠參考一下. 主要也是根據理論基礎進行分析, 而後一步步排查.

一、jvm oom排查 (Java heap space)
排查過程:
一、分析oom 的緣由: 主要分爲內存泄漏和內存溢出
內存泄漏: 對象分配了內存, 在方法調用結束以後沒有進行回收,直接進入了老年代中
內存溢出: 咱們的內存容量不夠,致使內存分配不足
主要從這兩方面進行排查

首先排查的是內存溢出:咱們機器的配置是 2核4g 的機器, 堆內存分配的是3G,按照1:2的比例進行分配
這裏經過
jmap -heap 能夠查看到咱們的堆內存使用狀況.
而後根據 jstat -gc 查看咱們的gc 次數, 能夠粗略的查看到咱們的系統gc 狀況

當時經過分析 gc.log 文件看到fgc的次數相對來講仍是比較少的, 所以能夠暫時排除咱們內存溢出致使的oom 的可能性.

其次就是排查內存泄漏了.這裏使用到了 -XX:HeapDumpOnOutOfMemoryError 命令來保存 oom 時產生的堆棧信息.
經過 MAT 工具來進行分析 內存使用狀況.
當時分析看到佔用比較多內存的是 java.util.map 對象比較多. 經過 MAT 工具的 leak suspects 進行分析內存泄漏可能存在的緣由.
當時定位到的是咱們的一個學生做業報告的接口的方法. 

而後查看了一下 這個接口的調用狀況,發現一天的調用量在20萬次左右,平均響應時間是在400毫秒.

根據分析到的有效信息, 初步排查就是因爲這個接口調用量比較多,而後致使生成比較多的一些聚合數據(主要經過map 來進行聚合), 而後因爲響應時間比較長,可能會致使在ygc 的時候,根據可達性分析(gc root)判斷這個對象仍是存活的,而後分配到了老年代,當方法調用結束了, 就會致使這部分對象會一隻存活在老年代,直到觸發fgc.

若是是正常狀況下, 應該會在fgc 的時候就會觸發垃圾回收, 而不是發生oom. 這裏是根據查看咱們ygc 產生的剩餘對象佔用內存來進行分析的, 即若是ygc 產生了大量的存活對象,而oldgc 沒有足夠的內存存放這部分對象,就會致使oom.

優化過程:
一、jvm 的優化,主要有作了, 一個是增長內存,調整新生代和老年代的比例(修改爲1:1),修改垃圾回收器
二、代碼上面進行優化處理: 
減小聚合數據對象的建立, 這個能夠經過提早生成相應的報告數據
減小接口耗時
複製代碼

爲何要使用 redis

引入中間件都是爲了解決目前存在的問題. 好比 數據庫訪問壓力比較大, 數據存儲變化頻繁,數據訪問頻率高和數據時效性低等.

能夠進一步說明,引入redis 帶來的問題 和如何解決的. 好比: 引入了 redis 如何確保數據一致, redis 不可用如何保證服務可用.

改善後的吞吐量,數據庫的qps

這裏考驗的是數據敏感性, 每次改動以後要求對系統進行測評. 判斷此次修改是否對服務性能進行了提高,提高了多少, 哪裏還有瓶頸等

數據庫的事務, innodb 的索引實現原理

事務隔離級別 和 如何實現的.

如何實現這一塊須要去了解一下 mvcc

io多路複用

select、poll 和epoll 對比

有遇到深刻問 epoll 事件通知是如何實現的.

推薦: Linux IO模式及 select、poll、epoll詳解

性能瓶頸,如何再優化

主要圍繞這三個點進行分析:

• cpu
• 內存
• io

rpc 調用過程, (爲何看dubbo源碼)

rpc 調用過程這個問的挺多的, 能夠參考 dubbo 的架構設計, 而後一步步跟着源碼走一遍就理解了.

爲何看: 提升本身的編碼能力和設計能力 (要帶着問題去看源碼, 否則很容易忘記)

小組內的工做職責

三面

工做內容

• 版本開發
• 問題處理
• 需求分配
• 技術評審

重構(思路,實現)

建議閱讀: 《重構-改善既有代碼的設計》

性能優化作了什麼

jvm 調優 ,sql 優化/重建索引 和 MQ 解耦

同步和異步的區別

Linux io多路複用/aio

參考上述 面試二

linux select 通知

B+樹和紅黑樹

HashMap 紅黑樹

進程間通訊的方式

• 管道
• 匿名管道
• 信號
• 信號量
• 消息隊列
• 共享內存
• 套接字

系統性能瓶頸

主要圍繞這三個點進行分析:

• cpu
• 內存
• io

結果

TEG 這邊的面試, 也是N 了

3.3 騰訊PCG

一面

rocketmq 如何保證消息可靠

從生產, MQ 和消費三端進行分析

消息隊列技術選型

對比常見的 RabbitMQ，RockerMQ 和 Kafka 技術特色， 結合公司的實際場景抉擇。

rocketmq half message

介紹 half message ,失敗如何回調等

rocketmq 消費失敗

如何解決消費失敗的問題，和消費失敗可能致使的 n+1 問題

dubbo 通訊過程

rpc調用過程

dubbo 本地緩存地址

dubbo 底層源碼

redis 集羣模式

redis 主從同步

spring 事務傳播機制

mysql 隔離級別

redis 跳躍表 層數的設置

上述可能有比較多重複的內容， 所以沒有再作詳細的介紹了， 你們能夠自行再去學習一下~

二面

二面的過程有點像聊天，面試官跟 我前面別的部門（不是上面的TEG）的面試官認識，所以瞭解個人總體狀況。
整個面試過程有點相似指導吧，指出個人不足，而後給我一些建議。
也有問一下比較常規的問題，也是上面有提到的一些內容。
複製代碼

三面

項目介紹

項目介紹主要從：
 一、業務場景
 二、性能數據
 三、問題難點
 四、性能瓶頸
這幾個方面進行分析吧
複製代碼

一、業務場景

博主這邊作的項目是一個教育行業的系統， 主要是描述了一下 學生在線答題的業務場景。各位能夠根據本身的項目進行梳理。

二、性能數據

性能數據這一塊應該是社招比較看重的問題， 基本每一輪面試都會有面試官問 性能怎麼樣， 須要咱們平時對本身系統有必定的瞭解，而且清楚實際數據怎麼樣。 具體包括： 天天訪問量，服務 qps/tps,用戶量和機器數量（機器配置）等多方面的數據。

三、問題難點

這裏我主要將兩個地方吧， 一個是上面說到的 oom 問題定位處理 ， 一個是 RocketMQ 解耦。

上面介紹了 oom， 下面簡單介紹一下結合項目引入 RocketMQ。

一、爲何引入RocketMQ
經過對核心接口的壓測， 發現接口 tps 相對較低，通過排查發現主流程中操做步驟相對較多。
一次寫請求處理了比較多內容，致使整個請求的響應緩慢。
經過將核心的流程和輔助功能進行拆分， 經過異步的方式完成後續的工做，從而提升接口的吞吐量。

問題： 響應緩慢，吞吐量低
指望： 快速響應，提升tps
解決方式： 經過引入 RocketMQ 進行異步操做/解耦

二、爲何使用RocketMQ
技術選型： RabbitMQ，RocketMQ和Kafka 
主要從：消息堆積，響應速度，底層語言和使用場景進行分析

三、如何保證消息的可靠性
從 客戶端，MQ和消費端來進行保證消息可靠。
客戶端: 經過事務消息來進行保證，或者失敗重試（sendResult判斷）
MQ ： 經過RocketMQ 集羣，進行保證，主要由運維負責（可能會牽扯到MQ消息保存的問題）
消費端：一、消費冪等和二、流水錶的形式 
這個問題須要結合到項目中的實際場景進行分析， 不能硬套

四、優化後的吞吐量
這個是比較核心的問題， 你優化完以後， 沒有作性能的測試，憑什麼說引入就行了
（引入中間件本來就會下降系統可靠性，提升複雜度）

所以須要在優化後，進行一輪的壓測（注意測試場景要保持和生產或上一次測試場景一致）和消息的消費速度（避免消費過慢致使堆積）


五、優化後的性能瓶頸在哪？
主要從： cpu，內存和IO 三方面進行分析吧， 具體系統具體分析。

複製代碼

四、問題難點

cpu，內存和IO 三方面進行分析吧， 具體系統具體分析。應該沒有啥系統是沒有瓶頸的。

hr面

工做內容

團隊身份

學習規劃

職業規劃

我的績效

offer

千辛萬苦，終獲騰訊offer，上面雖然只寫了兩個部門的面試內容，可是我至少面了4個部門了（2個月內），因此，沒什麼歲月安好，只有負重前行，才能實現夢想。

3.3 阿里螞蟻

一面

一、匿名類,內部類靜態內部類

二、HashMap 1.7和1.8區別

三、BlockingQueue 相關知識

四、線程池的建立形式,使用場景

五、多線程下實現一個計數器

六、wait 和notify

七、B+樹和紅黑樹

八、數據庫的隔離級別

九、數據庫如何解決幻讀

十、mysql 索引

十一、redis 分佈式鎖

十二、redis 哨兵集羣

1三、rpc 調用過程

1四、zookeeper 是怎麼服務發現的

1五、zookeeper 心跳檢測

整體來講，跟上面的面試過程也是大致上面類似，也沒有什麼難點的。所以也不作詳細分析了～

二面

二面進行的也是比較快，主要是兩個問題吧

項目介紹

也是跟上面的差很少內容

場景題

用戶的資源權限數據庫設計

三面

三面面試官問題主要是跟業務場景和架構方面的， 總體跟騰訊的三面差很少（其實是由於忘記了問了啥， 主要也是跟項目相關的）

四面

整個流程下來大概10分鐘左右，當時剛面完頭條，有點忽然。

項目難點

問題處理

團隊角色

學習方法

hr面

hr面一共面了10分鐘左右，當時面完也是慌的一批，咋那麼快呢。 問的問題主要就是：

離職緣由

職業規劃

薪資水平

offer

最後也是成功拿到了ali 的offer ，完成本身的理想了吧！ 之後便以 九靈 行走江湖了~~

四、總結與建議

樓主在面試過程當中也不是一路順風，也是披荊斬棘走過來的，2020 不是一個安穩的時間， 天天在發生在各類各樣的變化。只有堅持，把握,不放棄 方能達到本身的目標。

加油吧，少年！

最後貼一個新生的公衆號 （Java 補習課），歡迎各位關注，主要會分享一下面試的內容（參考以前博主的文章），阿里的開源技術之類和阿里生活相關。 想要交流面試經驗的，能夠添加個人我的微信（Jayce-K）進羣學習~