最新一手鹅厂硬核面经，来试试！

hello，大家好！

很多小伙伴在后台催面经系列，

之前的阿里面经和字节跳动面经，

大家都学习了吗

今天分享的是腾讯系列，

这位大佬面试了好几个腾讯项目组，

面试题也都提供了解题思路。

老规矩，

更多优秀的腾讯面经，

下方公众号回复【腾讯】

即可免费领取

背 景

17届双非一本毕业, 主要是搞Java开发的, 没有大厂经验。

如果再不找找机会进大厂深造一下, 后面的竞争力和个人的提升将会更难。因此在现在公司磨砺了两年之后, 开始向大厂迈进~ 

腾讯TEG一面

1.HashMap 底层实现

介绍基本结构,对比 1.7和1.8的区别

建议深入阅读 1.8 resize()的源码, 还有红黑素转换的过程

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

对比 HashMap,HashTable 和 CurrentHashMap的区别和使用场景

给出一个HashMap 要在线程安全的情况下使用, 通过加锁和 Collections.SynchronizedMap 对当前 HashMap 进行封装

3.介绍一下红黑树

原理: 红黑树传送门

应用场景: JDK1.8 HashMap , 对比 B+树 和 跳跃表

4.redis 速度快是因为什么原因

内存、单线程、数据结构、io多路服复用 

性能瓶颈(内存,网络io), 可以指出 为解决 网络IO 的瓶颈,在 redis 6.0 提出的 单主线程,多工作线程的设计.可以对比 Memecached 的多线程模型进行对比.

5.mysql 索引介绍

（前两天刚准备了一份MySQL资料，正好有这部分的详细答案，点击即可领取）

• 聚集索引和非聚索引的区别(InnoDb 和 MyISAM 对比) 

• 索引选择(优化器怎么选择索引) 

• 索引失效 

• 索引下推 

6.为什么选择b+树

介绍 b+树和b树的区别, 对比b+树在磁盘IO上面的优势(单页能存更多的索引),可以提一下mongodb 采用的是B树索引 .

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

当时踩了个坑, 聚集索引和聚簇索引 其实是一个东西

8.默认主键索引

如果没有设置主键索引, innodb 会默认添加一个隐藏列作为主键索引

为什么需要这个隐藏列, 可以参考innodb的数据存储结构

9.虚拟内存和物理内存

• 物理内存有限, 虚拟内存通过磁盘映射的形式进行分配物理内存

• 从而解决多个进程同时运行的情况下内存不足的问题.

10.伪共享

可以结合 volatile 和 ConcurrenthashMap.countercell 进行解答

11.TCP如何确保可靠传输

• 数据包校验 

• 重排序 

• 丢弃重复数据 

• 应答机制 

• 超时重传 

• 流量控制 

12.拥塞控制

• 慢开始。 

• 拥塞避免。 

• 快重传。 

• 快恢复 

• 计算机网络这部分的内容相对来说比较考验背诵理解.

• 需要你用自己的语言表达出来

13.项目设计

14.kafka /es 有没有使用过

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

16.笔试题

笔试题的内容比较多, 有编程题,算法题 和程序运行结果的选择题等。

最近整理了一份简历资料，里面收录了几位大佬的简历模板，打算跳槽的小伙伴可以参考下，点击免费领取！

二面

1、项目遇到最大的问题(OOM) - 会比较长 

个人的分析步骤, 感兴趣可以参考一下. 主要也是根据理论基础进行分析, 然后一步步排查.

1、为什么引入RocketMQ  通过对核心接口的压测， 发现接口 tps 相对较低，经过排查发现主流程中操作步骤相对较多。一次写请求处理了比较多内容，导致整个请求的响应缓慢。通过将核心的流程和辅助功能进行拆分， 通过异步的方式完成后续的工作，从而提高接口的吞吐量。  问题：响应缓慢，吞吐量低  期望：快速响应，提高tps  解决方式：通过引入 RocketMQ 进行异步操作/解耦    2、为什么使用RocketMQ  技术选型：RabbitMQ，RocketMQ和Kafka   主要从：消息堆积，响应速度，底层语言和使用场景进行分析    3、如何保证消息的可靠性  从 客户端，MQ和消费端来进行保证消息可靠。客户端: 通过事务消息来进行保证，或者失败重试（sendResult判断）  MQ ：通过RocketMQ 集群，进行保证，主要由运维负责（可能会牵扯到MQ消息保存的问题）  消费端：1、消费幂等和2、流水表的形式   这个问题需要结合到项目中的实际场景进行分析， 不能硬套    4、优化后的吞吐量  这个是比较核心的问题， 你优化完之后， 没有做性能的测试，凭什么说引入就好了  （引入中间件原本就会降低系统可靠性，提高复杂度）    因此需要在优化后，进行一轮的压测（注意测试场景要保持和生产或上一次测试场景一致）和消息的消费速度（避免消费过慢导致堆积）      5、优化后的性能瓶颈在哪？主要从：cpu，内存和IO 三方面进行分析吧， 具体系统具体分析。

2、为什么要使用 redis

引入中间件都是为了解决目前存在的问题. 比如 数据库访问压力比较大, 数据存储变化频繁,数据访问频率高和数据时效性低等.

可以进一步说明,引入redis 带来的问题 和如何解决的. 比如: 引入了 redis 如何确保数据一致, redis 不可用如何保证服务可用.

3、改善后的吞吐量,数据库的qps

这里考验的是数据敏感性, 每次改动之后要求对系统进行测评. 判断这次修改是否对服务性能进行了提升,提升了多少, 哪里还有瓶颈等

4、数据库的事务, innodb 的索引实现原理

事务隔离级别 和 如何实现的.

如何实现这一块需要去了解一下 mvcc 

5、io多路复用

select、poll 和epoll 对比

有遇到深入问 epoll 事件通知是如何实现的. 

6、性能瓶颈,如何再优化

主要围绕这三个点进行分析:

cpu 、内存 、io 

7、rpc 调用过程, (为什么看dubbo源码)

rpc 调用过程这个问的挺多的, 可以参考 dubbo 的架构设计, 然后一步步跟着源码走一遍就理解了.

为什么看: 提高自己的编码能力和设计能力 (要带着问题去看源码, 不然很容易忘记)

8、小组内的工作职责

三面

1.工作内容

• 版本开发 

• 问题处理 

• 需求分配 

• 技术评审 

2.重构(思路,实现)

3.性能优化做了什么

jvm 调优 ,sql 优化/重建索引 和 MQ 解耦

4.同步和异步的区别

5.Linux io多路复用/aio

参考上述 面试二

6.linux select 通知

7.B+树和红黑树

8.HashMap 红黑树

9.进程间通信的方式

• 管道 

• 匿名管道 

• 信号 

• 信号量 

• 消息队列 

• 共享内存 

• 套接字 

10.系统性能瓶颈

主要围绕这三个点进行分析:

cpu 、内存 、io 

结果

TEG 这边的面试, N 了

来源：牛客网

（剧透：最终拿到了offer）。