爆料一手面经，我在腾讯的硬核面试！
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 了
来源：牛客网