最新一手鵝廠硬核面經(jīng)，來試試！

hello，大家好！

很多小伙伴在后臺(tái)催面經(jīng)系列，

之前的阿里面經(jīng)和字節(jié)跳動(dòng)面經(jīng)，

大家都學(xué)習(xí)了嗎

今天分享的是騰訊系列，

這位大佬面試了好幾個(gè)騰訊項(xiàng)目組，

面試題也都提供了解題思路。

老規(guī)矩，

更多優(yōu)秀的騰訊面經(jīng)，

下方公眾號(hào)回復(fù)【騰訊】

即可免費(fèi)領(lǐng)取

背 景

17屆雙非一本畢業(yè), 主要是搞Java開發(fā)的, 沒有大廠經(jīng)驗(yàn)。

如果再不找找機(jī)會(huì)進(jìn)大廠深造一下, 后面的競(jìng)爭(zhēng)力和個(gè)人的提升將會(huì)更難。因此在現(xiàn)在公司磨礪了兩年之后, 開始向大廠邁進(jìn)~?

騰訊TEG一面

1.HashMap 底層實(shí)現(xiàn)

介紹基本結(jié)構(gòu),對(duì)比 1.7和1.8的區(qū)別

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

2.HashMap 是否線程安全,如果需要使用線程安全的呢

對(duì)比 HashMap,HashTable 和 CurrentHashMap的區(qū)別和使用場(chǎng)景

給出一個(gè)HashMap 要在線程安全的情況下使用, 通過加鎖和 Collections.SynchronizedMap 對(duì)當(dāng)前 HashMap 進(jìn)行封裝

3.介紹一下紅黑樹

原理: 紅黑樹傳送門

應(yīng)用場(chǎng)景: JDK1.8 HashMap , 對(duì)比 B+樹 和 跳躍表

4.redis 速度快是因?yàn)槭裁丛?/span>

內(nèi)存、單線程、數(shù)據(jù)結(jié)構(gòu)、io多路服復(fù)用?

性能瓶頸(內(nèi)存,網(wǎng)絡(luò)io), 可以指出 為解決 網(wǎng)絡(luò)IO 的瓶頸,在 redis 6.0 提出的 單主線程,多工作線程的設(shè)計(jì).可以對(duì)比 Memecached 的多線程模型進(jìn)行對(duì)比.

5.mysql 索引介紹

（前兩天剛準(zhǔn)備了一份MySQL資料，正好有這部分的詳細(xì)答案，點(diǎn)擊即可領(lǐng)?。?/span>

• 聚集索引和非聚索引的區(qū)別(InnoDb 和 MyISAM 對(duì)比)?

• 索引選擇(優(yōu)化器怎么選擇索引)?

• 索引失效?

• 索引下推?

6.為什么選擇b+樹

介紹 b+樹和b樹的區(qū)別, 對(duì)比b+樹在磁盤IO上面的優(yōu)勢(shì)(單頁(yè)能存更多的索引),可以提一下mongodb 采用的是B樹索引 .

7.聚集索引和非聚集索引

當(dāng)時(shí)踩了個(gè)坑, 聚集索引和聚簇索引 其實(shí)是一個(gè)東西

8.默認(rèn)主鍵索引

如果沒有設(shè)置主鍵索引, innodb 會(huì)默認(rèn)添加一個(gè)隱藏列作為主鍵索引

為什么需要這個(gè)隱藏列, 可以參考innodb的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)

9.虛擬內(nèi)存和物理內(nèi)存

• 物理內(nèi)存有限, 虛擬內(nèi)存通過磁盤映射的形式進(jìn)行分配物理內(nèi)存

• 從而解決多個(gè)進(jìn)程同時(shí)運(yùn)行的情況下內(nèi)存不足的問題.

10.偽共享

可以結(jié)合 volatile 和 ConcurrenthashMap.countercell 進(jìn)行解答

11.TCP如何確?？煽總鬏?/span>

• 數(shù)據(jù)包校驗(yàn)?

• 重排序?

• 丟棄重復(fù)數(shù)據(jù)?

• 應(yīng)答機(jī)制?

• 超時(shí)重傳?

• 流量控制?

12.擁塞控制

• 慢開始。?

• 擁塞避免。?

• 快重傳。?

• 快恢復(fù)?

• 計(jì)算機(jī)網(wǎng)絡(luò)這部分的內(nèi)容相對(duì)來說比較考驗(yàn)背誦理解.

• 需要你用自己的語(yǔ)言表達(dá)出來

13.項(xiàng)目設(shè)計(jì)

14.kafka /es 有沒有使用過

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

16.筆試題

筆試題的內(nèi)容比較多, 有編程題,算法題 和程序運(yùn)行結(jié)果的選擇題等。

最近整理了一份簡(jiǎn)歷資料，里面收錄了幾位大佬的簡(jiǎn)歷模板，打算跳槽的小伙伴可以參考下，點(diǎn)擊免費(fèi)領(lǐng)?。?/span>

二面

1、項(xiàng)目遇到最大的問題(OOM) - 會(huì)比較長(zhǎng)?

個(gè)人的分析步驟, 感興趣可以參考一下. 主要也是根據(jù)理論基礎(chǔ)進(jìn)行分析, 然后一步步排查.

1、為什么引入RocketMQ  通過對(duì)核心接口的壓測(cè)， 發(fā)現(xiàn)接口 tps 相對(duì)較低，經(jīng)過排查發(fā)現(xiàn)主流程中操作步驟相對(duì)較多。一次寫請(qǐng)求處理了比較多內(nèi)容，導(dǎo)致整個(gè)請(qǐng)求的響應(yīng)緩慢。通過將核心的流程和輔助功能進(jìn)行拆分， 通過異步的方式完成后續(xù)的工作，從而提高接口的吞吐量。  問題：響應(yīng)緩慢，吞吐量低  期望：快速響應(yīng)，提高tps  解決方式：通過引入 RocketMQ 進(jìn)行異步操作/解耦    2、為什么使用RocketMQ  技術(shù)選型：RabbitMQ，RocketMQ和Kafka   主要從：消息堆積，響應(yīng)速度，底層語(yǔ)言和使用場(chǎng)景進(jìn)行分析    3、如何保證消息的可靠性  從 客戶端，MQ和消費(fèi)端來進(jìn)行保證消息可靠。客戶端: 通過事務(wù)消息來進(jìn)行保證，或者失敗重試（sendResult判斷）  MQ ：通過RocketMQ 集群，進(jìn)行保證，主要由運(yùn)維負(fù)責(zé)（可能會(huì)牽扯到MQ消息保存的問題）  消費(fèi)端：1、消費(fèi)冪等和2、流水表的形式   這個(gè)問題需要結(jié)合到項(xiàng)目中的實(shí)際場(chǎng)景進(jìn)行分析， 不能硬套    4、優(yōu)化后的吞吐量  這個(gè)是比較核心的問題， 你優(yōu)化完之后， 沒有做性能的測(cè)試，憑什么說引入就好了  （引入中間件原本就會(huì)降低系統(tǒng)可靠性，提高復(fù)雜度）    因此需要在優(yōu)化后，進(jìn)行一輪的壓測(cè)（注意測(cè)試場(chǎng)景要保持和生產(chǎn)或上一次測(cè)試場(chǎng)景一致）和消息的消費(fèi)速度（避免消費(fèi)過慢導(dǎo)致堆積）      5、優(yōu)化后的性能瓶頸在哪？主要從：cpu，內(nèi)存和IO 三方面進(jìn)行分析吧， 具體系統(tǒng)具體分析。

2、為什么要使用 redis

引入中間件都是為了解決目前存在的問題. 比如 數(shù)據(jù)庫(kù)訪問壓力比較大, 數(shù)據(jù)存儲(chǔ)變化頻繁,數(shù)據(jù)訪問頻率高和數(shù)據(jù)時(shí)效性低等.

可以進(jìn)一步說明,引入redis 帶來的問題 和如何解決的. 比如: 引入了 redis 如何確保數(shù)據(jù)一致, redis 不可用如何保證服務(wù)可用.

3、改善后的吞吐量,數(shù)據(jù)庫(kù)的qps

這里考驗(yàn)的是數(shù)據(jù)敏感性, 每次改動(dòng)之后要求對(duì)系統(tǒng)進(jìn)行測(cè)評(píng). 判斷這次修改是否對(duì)服務(wù)性能進(jìn)行了提升,提升了多少, 哪里還有瓶頸等

4、數(shù)據(jù)庫(kù)的事務(wù), innodb 的索引實(shí)現(xiàn)原理

事務(wù)隔離級(jí)別 和 如何實(shí)現(xiàn)的.

如何實(shí)現(xiàn)這一塊需要去了解一下 mvcc?

5、io多路復(fù)用

select、poll 和epoll 對(duì)比

有遇到深入問 epoll 事件通知是如何實(shí)現(xiàn)的.?

6、性能瓶頸,如何再優(yōu)化

主要圍繞這三個(gè)點(diǎn)進(jìn)行分析:

cpu 、內(nèi)存 、io?

7、rpc 調(diào)用過程, (為什么看dubbo源碼)

rpc 調(diào)用過程這個(gè)問的挺多的, 可以參考 dubbo 的架構(gòu)設(shè)計(jì), 然后一步步跟著源碼走一遍就理解了.

為什么看: 提高自己的編碼能力和設(shè)計(jì)能力 (要帶著問題去看源碼, 不然很容易忘記)

8、小組內(nèi)的工作職責(zé)

三面

1.工作內(nèi)容

• 版本開發(fā)?

• 問題處理?

• 需求分配?

• 技術(shù)評(píng)審?

2.重構(gòu)(思路,實(shí)現(xiàn))

3.性能優(yōu)化做了什么

jvm 調(diào)優(yōu) ,sql 優(yōu)化/重建索引 和 MQ 解耦

4.同步和異步的區(qū)別

5.Linux io多路復(fù)用/aio

參考上述 面試二

6.linux select 通知

7.B+樹和紅黑樹

8.HashMap 紅黑樹

9.進(jìn)程間通信的方式

• 管道?

• 匿名管道?

• 信號(hào)?

• 信號(hào)量?

• 消息隊(duì)列?

• 共享內(nèi)存?

• 套接字?

10.系統(tǒng)性能瓶頸

主要圍繞這三個(gè)點(diǎn)進(jìn)行分析:

cpu 、內(nèi)存 、io?

結(jié)果

TEG 這邊的面試, N 了

來源：牛客網(wǎng)

（劇透：最終拿到了offer）。