阿里腾讯后台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）进群学习~