关于java:三月鏖战三年后端终获阿里腾讯offer

送大家以下 bat 大厂面试题，文末有支付形式

1、根本状况

博主 17 届双非一本毕业, 次要是搞Java 开发 的, 没有大厂教训. 2021 本人也马上快 4 年工作教训 了. 如果再不找找机会进大厂深造一下, 前面的竞争力和集体的晋升将会更难. 因而在当初公司磨砺了两年之后, 开始向大厂迈进~  这篇博客次要是想分享一下本人在面试过程中所遇到的问题, 绝对比拟崎岖, 前后经验了 3 个多月. 心愿大家也能在找工作的过程中, 保持下来!

2、面试后果

• 阿里 - 蚂蚁支付宝 P6 offer
• 腾讯 -pcg 2-3 offer
• 字节 2 面 后放弃

3、面试过程

3.1、阿里 - 天猫超市

一面

1、动态代理, 动静代理

简略形容区别, 而后能够引出 jdk 动静代理 和cglib 的底层实现原理(Proxy 和 InvocationHandler).

再引入 Spring AOP 在不同状况下采纳的代理实现形式

最初举例我的项目中动静代理的 应用场景 (常见的 日志打印)

2、future (重点)

Future用来代表异步的后果. 能够引出 ExecutorService.submit 和 ExecutorService.execute 的区别

如果有钻研过一些框架的源码, 能够说一下 Future 在其中起的作用 ( 超时管制)

3、线程池实现形式 - 销毁线程

这里反对须要指出 Executors 和 ThreadPoolExecutor 之间的关系

通过设置不同的入参, 实现不同的线程池. 比拟有意思的 SynchronousQueue 实现原理能够深刻学习一下

线程池回收: 传送门

4、mysql 联结索引

先介绍一下什么是 联结索引 , 索引应用场景和生效状况, 如果理解 索引下推 能够说一下

引出 联结索引 和 主键索引 有什么区别. 而后能够深刻比照一下 Innodb 和 MYISAM 的区别

点睛之笔 : 本人去写几条 sql 查看索引的抉择规定,  你会发现并不是建设了索引就会走, 也并不是有索引下推就肯定会去采纳, 这就能够波及到 mysql 一条 sql 的执行过程

5、redis 集群

次要的几种集群: 主从 , 哨兵 和redis Cluster 这几种服务端集群. 相似 Twemproxy 和 Codis这种代理实现, 如果理解能够说一下.

细问: 以后公司采纳哪种计划(哨兵), 为什么(数据量较少, 主从 + 哨兵能撑持业务场景), 介绍哨兵的工作原理.

过后问了一个问题: 如果主挂了之后, 选主完结后, 怎么去告诉客户端. 客户端和哨兵是什么样的关系(有无关联)

6、mysql 分库分表

先问: 目前数据库的容量大略是多少, 有没有做分库分表设计.

答曰: 目前单表数据量在 5000w 左右, 日增长在 10w 以内, 临时没有这方面的思考( 劣大于优).

再引出: 分库分表有哪些形式 ( 垂直分库 , 垂直 / 程度分表 ), 解说一下区别. 能够再说一下 分布式自增 id 的实现计划, 常见的比方 雪花算法, 美团 -Leaf

7、我的项目内容

我的项目介绍, 次要是开掘你在工作中的思考以及亮点. 前面对立介绍, 因为每轮面试根本都会说一次

二面

二面流程比拟快, 没有什么特点

• 介绍我的项目和以后公司的盈利模式
• 我的项目遇到最大的艰难
• 我的项目的方案设计等

总共 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) – 会比拟长

集体的剖析步骤, 感兴趣能够参考一下. 次要也是依据实践根底进行剖析, 而后一步步排查.

1、jvm oom 排查 (Java heap space)
排查过程:
1、剖析 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.

优化过程:
1、jvm 的优化, 次要有做了, 一个是减少内存, 调整新生代和老年代的比例(批改成 1:1), 批改垃圾回收器
2、代码下面进行优化解决: 
缩小聚合数据对象的创立, 这个能够通过提前生成相应的报告数据
缩小接口耗时

为什么要应用 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）的面试官意识，因而理解我的整体状况。整个面试过程有点相似领导吧，指出我的有余，而后给我一些倡议。也有问一下比拟惯例的问题，也是下面有提到的一些内容。

三面

我的项目介绍

我的项目介绍次要从：1、业务场景
 2、性能数据
 3、问题难点
 4、性能瓶颈
这几个方面进行剖析吧

1、业务场景

博主这边做的我的项目是一个教育行业的零碎，次要是形容了一下 学生在线答题的业务场景。各位能够依据本人的我的项目进行梳理。

2、性能数据

性能数据这一块应该是社招比拟看重的问题，根本每一轮面试都会有面试官问 性能怎么样，须要咱们平时对本人零碎有肯定的理解，并且分明理论数据怎么样。具体包含：每天 访问量，服务 qps/tps, 用户量和机器数量（机器配置）等多方面的数据。

3、问题难点

这里我次要将两个中央吧，一个是下面说到的 oom 问题定位解决，一个是 RocketMQ 解耦。

下面介绍了 oom，上面简略介绍一下联合我的项目引入 RocketMQ。

1、为什么引入 RocketMQ
通过对外围接口的压测，发现接口 tps 绝对较低，通过排查发现主流程中操作步骤绝对较多。一次写申请解决了比拟多内容，导致整个申请的响应迟缓。通过将外围的流程和辅助性能进行拆分，通过异步的形式实现后续的工作，从而进步接口的吞吐量。问题：响应迟缓，吞吐量低
冀望：疾速响应，进步 tps
解决形式：通过引入 RocketMQ 进行异步操作 / 解耦

2、为什么应用 RocketMQ
技术选型：RabbitMQ，RocketMQ 和 Kafka 
次要从：音讯沉积，响应速度，底层语言和应用场景进行剖析

3、如何保障音讯的可靠性
从 客户端，MQ 和生产端来进行保障音讯牢靠。客户端: 通过事务音讯来进行保障，或者失败重试（sendResult 判断）MQ：通过 RocketMQ 集群，进行保障，次要由运维负责（可能会牵扯到 MQ 音讯保留的问题）生产端：1、生产幂等和 2、流水表的模式 
这个问题须要联合到我的项目中的理论场景进行剖析，不能硬套

4、优化后的吞吐量
这个是比拟外围的问题，你优化完之后，没有做性能的测试，凭什么说引入就好了（引入中间件本来就会升高系统可靠性，进步复杂度）因而须要在优化后，进行一轮的压测（留神测试场景要放弃和生产或上一次测试场景统一）和音讯的生产速度（防止生产过慢导致沉积）5、优化后的性能瓶颈在哪？次要从：cpu，内存和 IO 三方面进行剖析吧，具体零碎具体分析。

4、问题难点

cpu，内存和 IO 三方面进行剖析吧，具体零碎具体分析。应该没有啥零碎是没有瓶颈的。

hr 面

工作内容

团队身份

学习布局

职业规划

集体绩效

offer

含辛茹苦，终获腾讯 offer，下面尽管只写了两个部门的面试内容，然而我至多面了 4 个部门了（2 个月内），所以，没什么岁月安好，只有负重前行，能力实现幻想。

3.3 阿里蚂蚁

一面

1、匿名类, 外部类动态外部类

2、HashMap 1.7 和 1.8 区别

3、BlockingQueue 相干常识

4、线程池的创立模式, 应用场景

5、多线程下实现一个计数器

6、wait 和 notify

7、B+ 树和红黑树

8、数据库的隔离级别

9、数据库如何解决幻读

10、mysql 索引

11、redis 分布式锁

12、redis 哨兵集群

13、rpc 调用过程

14、zookeeper 是怎么服务发现的

15、zookeeper 心跳检测

总体来说，跟下面的面试过程也是大体下面类似，也没有什么难点的。因而也不做详细分析了～

二面

二面进行的也是比拟快，次要是两个问题吧

我的项目介绍

也是跟下面的差不多内容

场景题

用户的资源权限数据库设计

三面

三面面试官问题次要是跟业务场景和架构方面的，整体跟腾讯的三面差不多（实际上是因为遗记了问了啥，次要也是跟我的项目相干的）

四面

整个流程下来大略 10 分钟左右，过后刚面完头条，有点忽然。

我的项目难点

问题解决

团队角色

学习办法

hr 面

hr 面一共面了 10 分钟左右，过后面完也是慌的一批，咋那么快呢。问的问题次要就是：

到职起因

职业规划

薪资程度

offer

最初也是胜利拿到了 ali 的 offer，实现本人的现实了吧！当前便以 九灵 行走江湖了~~

4、总结与倡议

楼主在面试过程中也不是一帆风顺，也是乘风破浪走过去的，2021 不是一个安稳的工夫，每天在产生在各种各样的变动。只有 保持 ， 把握 , 不放弃 方能达到本人的指标。

加油吧，少年！