前言

去年，我进行了一个多月的面试之旅。

面试的公司并不多，但从体量上来看，基本算是一二三线的大厂都囊括了，其中还包括BAT，当然，最后顺利的拿到了阿里的offer，我也挺满意的，毕竟对我这种一直向往大厂的人来说，能进大厂已经算是很好的一次职业跃迁。

在这个过程中，我也积累了不少面试经验，并且跟很多朋友交流过，不少人都说让我写篇面经分享下经验（其中也就几个人）。

那我也不负君期，舍弃一天假期来写篇实战面经分享下。

个人背景

本人是18年毕业的，算到去年年底的话大概是 三年半的工作经验，我当时第一个面试的公司是广州这边的欢聚时代集团，也就是yy直播的前身，后来还面试了字节、阿里、腾讯、网易等公司，最后拿到阿里和网易的offer 。

结果不算圆满吧，但怎么说呢，体验这么一圈下来，感觉大厂的面试难度也没想象中那么夸张，其中字节和Lazada我都是在技术终面被刷的，询问过内推的朋友，可能未必是技术方面的原因。当然，这是后话了，我想说的是，就算是面试大厂，只要准备充足的话，还是可以从容应对的。

每一次面试完之后我都有做问题的记录和复盘，基于篇幅原因，本文只会分享阿里的面经，其他公司的面经后面再给大家整理好了。

阿里一面（1h）

说⼀下ArrayList和LinkedList区别

1. ⾸先，他们的底层数据结构不同，ArrayList底层是基于数组实现的，LinkedList底层是基于链表实现的

2. 由于底层数据结构不同，他们所适⽤的场景也不同，ArrayList更适合随机查找，LinkedList更适合删除和添加，查询、添加、删除的时间复杂度不同

3. 另外ArrayList和LinkedList都实现了List接⼝，但是LinkedList还额外实现了Deque接⼝，所以LinkedList还可以当做队列来使⽤

说⼀下HashMap的Put⽅法

先说HashMap的Put⽅法的⼤体流程：

1. 根据Key通过哈希算法与与运算得出数组下标

2. 如果数组下标位置元素为空，则将key和value封装为Entry对象（JDK1.7中是Entry对象，JDK1.8中是Node对象）并放⼊该位置

3. 如果数组下标位置元素不为空，则要分情况讨论

a. 如果是JDK1.7，则先判断是否需要扩容，如果要扩容就进⾏扩容，如果不⽤扩容就⽣成Entry对象，并使⽤头插法添加到当前位置的链表中

b. 如果是JDK1.8，则会先判断当前位置上的Node的类型，看是红⿊树Node，还是链表Noe

i. 如果是红⿊树Node，则将key和value封装为⼀个红⿊树节点并添加到红⿊树中去，在这个过程中会判断红⿊树中是否存在当前key，如果存在则更新value

ii. 如果此位置上的Node对象是链表节点，则将key和value封装为⼀个链表Node并通过尾 插法插⼊到链表的最后位置去，因为是尾插法，所以需要遍历链表，在遍历链表的过程中会判断是否存在当前key，如果存在则更新value，当遍历完链表后，将新链表Node插⼊到链表中，插⼊到链表后，会看当前链表的节点个数，如果⼤于等于8，那么则会将该链表转成红⿊树

iii. 将key和value封装为Node插⼊到链表或红⿊树中后，再判断是否需要进⾏扩容，如果需要就扩容，如果不需要就结束PUT⽅法

说⼀下ThreadLocal

1. ThreadLocal是Java中所提供的线程本地存储机制，可以利⽤该机制将数据缓存在某个线程内部，该线程可以在任意时刻、任意⽅法中获取缓存的数据

2. ThreadLocal底层是通过ThreadLocalMap来实现的，每个Thread对象（注意不是ThreadLocal对象）中都存在⼀个ThreadLocalMap，Map的key为ThreadLocal对象，Map的value为需要缓存的值

3. 如果在线程池中使⽤ThreadLocal会造成内存泄漏，因为当ThreadLocal对象使⽤完之后，应该要把设置的key，value，也就是Entry对象进⾏回收，但线程池中的线程不会回收，⽽线程对象是通过强引⽤指向ThreadLocalMap，ThreadLocalMap也是通过强引⽤指向Entry对象，线程不被回收，Entry对象也就不会被回收，从⽽出现内存泄漏，解决办法是，在使⽤了ThreadLocal对象之后，⼿动调⽤ThreadLocal的remove⽅法，⼿动清楚Entry对象

4. ThreadLocal经典的应⽤场景就是连接管理（⼀个线程持有⼀个连接，该连接对象可以在不同的⽅法之间进⾏传递，线程之间不共享同⼀个连接）

说⼀下JVM中，哪些是共享区，哪些可以作为gc root

1、堆区和⽅法区是所有线程共享的，栈、本地⽅法栈、程序计数器是每个线程独有的

2、什么是gc root，JVM在进⾏垃圾回收时，需要找到“垃圾”对象，也就是没有被引⽤的对象，但是直接找“垃圾”对象是⽐较耗时的，所以反过来，先找“⾮垃圾”对象，也就是正常对象，那么就需要从某些“根”开始去找，根据这些“根”的引⽤路径找到正常对象，⽽这些“根”有⼀个特征，就是它只会引⽤其他对象，⽽不会被其他对象引⽤，例如：栈中的本地变量、⽅法区中的静态变量、本地⽅法栈中的变量、正在运⾏的线程等可以作为gc root。

你们项⽬如何排查JVM问题

对于还在正常运⾏的系统：

1. 可以使⽤jmap来查看JVM中各个区域的使⽤情况

2. 可以通过jstack来查看线程的运⾏情况，⽐如哪些线程阻塞、是否出现了死锁

3. 可以通过jstat命令来查看垃圾回收的情况，特别是fullgc，如果发现fullgc⽐较频繁，那么就得进⾏调优了

4. 通过各个命令的结果，或者jvisualvm等⼯具来进⾏分析

5. ⾸先，初步猜测频繁发送fullgc的原因，如果频繁发⽣fullgc但是⼜⼀直没有出现内存溢出，那么表示fullgc实际上是回收了很多对象了，所以这些对象最好能在younggc过程中就直接回收掉，避免这些对象进⼊到⽼年代，对于这种情况，就要考虑这些存活时间不⻓的对象是不是⽐较⼤，导致年轻代放不下，直接进⼊到了⽼年代，尝试加⼤年轻代的⼤⼩，如果改完之后，fullgc减少，则证明修改有效

6. 同时，还可以找到占⽤CPU最多的线程，定位到具体的⽅法，优化这个⽅法的执⾏，看是否能避免某些对象的创建，从⽽节省内存你们项⽬如何排查JVM问题

对于已经发⽣了OOM的系统：

1. ⼀般⽣产系统中都会设置当系统发⽣了OOM时，⽣成当时的dump⽂件（-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）

2. 我们可以利⽤jsisualvm等⼯具来分析dump⽂件

3. 根据dump⽂件找到异常的实例对象，和异常的线程（占⽤CPU⾼），定位到具体的代码

4. 然后再进⾏详细的分析和调试

总之，调优不是⼀蹴⽽就的，需要分析、推理、实践、总结、再分析，最终定位到具体的问题

如何查看线程死锁

1. 可以通过jstack命令来进⾏查看，jstack命令中会显示发⽣了死锁的线程

2. 或者两个线程去操作数据库时，数据库发⽣了死锁，这是可以查询数据库的死锁情况

线程之间如何进⾏通讯的

1. 线程之间可以通过共享内存或基于⽹络来进⾏通信

2. 如果是通过共享内存来进⾏通信，则需要考虑并发问题，什么时候阻塞，什么时候唤醒

3. 像Java中的wait()、notify()就是阻塞和唤醒

4. 通过⽹络就⽐较简单了，通过⽹络连接将通信数据发送给对⽅，当然也要考虑到并发问题，处理⽅式就是加锁等⽅式

说⼀下Spring的事务机制

1. Spring事务底层是基于数据库事务和AOP机制的

2. ⾸先对于使⽤了@Transactional注解的Bean，Spring会创建⼀个代理对象作为Bean

3. 当调⽤代理对象的⽅法时，会先判断该⽅法上是否加了@Transactional注解

4. 如果加了，那么则利⽤事务管理器创建⼀个数据库连接

5. 并且修改数据库连接的autocommit属性为false，禁⽌此连接的⾃动提交，这是实现Spring事务⾮常重要的⼀步

6. 然后执⾏当前⽅法，⽅法中会执⾏sql

7. 执⾏完当前⽅法后，如果没有出现异常就直接提交事务

8. 如果出现了异常，并且这个异常是需要回滚的就会回滚事务，否则仍然提交事务

9. Spring事务的隔离级别对应的就是数据库的隔离级别

10. Spring事务的传播机制是Spring事务⾃⼰实现的，也是Spring事务中最复杂的

11. Spring事务的传播机制是基于数据库连接来做的，⼀个数据库连接⼀个事务，如果传播机制配置为需要新开⼀个事务，那么实际上就是先建⽴⼀个数据库连接，在此新数据库连接上执⾏sql

什么时候@Transactional失效

因为Spring事务是基于代理来实现的，所以某个加了@Transactional的⽅法只有是被代理对象调⽤时，那么这个注解才会⽣效，所以如果是被代理对象来调⽤这个⽅法，那么@Transactional是不会⽣效的。

同时如果某个⽅法是private的，那么@Transactional也会失效，因为底层cglib是基于⽗⼦类来实现的，⼦类是不能重载⽗类的private⽅法的，所以⽆法很好的利⽤代理，也会导致@Transactianal失效

Dubbo是如何做系统交互的

Dubbo底层是通过RPC来完成服务和服务之间的调⽤的，Dubbo⽀持很多协议，⽐如默认的dubbo协议，⽐如http协议、⽐如rest等都是⽀持的，他们的底层所使⽤的技术是不太⼀样的，⽐如dubbo协议底层使⽤的是netty，也可以使⽤mina，http协议底层使⽤的tomcat或jetty。

服务消费者在调⽤某个服务时，会将当前所调⽤的服务接⼝信息、当前⽅法信息、执⾏⽅法所传⼊的⼊参信息等组装为⼀个Invocation对象，然后不同的协议通过不同的数据组织⽅式和传输⽅式将这个对象传送给服务提供者，提供者接收到这个对象后，找到对应的服务实现，利⽤反射执⾏对应的⽅法，得到⽅法结果后再通过⽹络响应给服务消费者。

当然，Dubbo在这个调⽤过程中还做很多其他的设计，⽐如服务容错、负载均衡、Filter机制、动态路由机制等等，让Dubbo能处理更多企业中的需求。

Dubbo的负载均衡策略

1. 平衡加权轮询算法

2. 加权随机算法

3. ⼀致性哈希算法

4. 最⼩活跃数算法

还读过哪些框架源码介绍⼀下你还熟悉的

这个问题⽐较⼴泛，你即可以说：HashMap、线程池等JDK⾃带的源码，也可以说Mybatis、SpringBoot、Spring Cloud、消息队列等开发框架或中间件的源码

总的来说，第一面的问题难度不算高吧，虽然针对的点比较多，但也基本是常见的八股文，项目场景方面没什么考究，准备好的话还是很好面对的，不出意外，第二天hr那边就通知我一面通过，然后就约了二面的时间。

二面（1h）

Jdk1.7到Jdk1.8 HashMap 发⽣了什么变化(底层)?

1. 1.7中底层是数组+链表，1.8中底层是数组+链表+红⿊树，加红⿊树的⽬的是提⾼HashMap插⼊和查询整体效率

2. 1.7中链表插⼊使⽤的是头插法，1.8中链表插⼊使⽤的是尾插法，因为1.8中插⼊key和value时需要判断链表元素个数，所以需要遍历链表统计链表元素个数，所以正好就直接使⽤尾插法

3. 1.7中哈希算法⽐较复杂，存在各种右移与异或运算，1.8中进⾏了简化，因为复杂的哈希算法的⽬的就是提⾼散列性，来提供HashMap的整体效率，⽽1.8中新增了红⿊树，所以可以适当的简化哈希算法，节省CPU资源

Jdk1.7到Jdk1.8 java虚拟机发⽣了什么变化?

1.7中存在永久代，1.8中没有永久代，替换它的是元空间，元空间所占的内存不是在虚拟机内部，⽽是本地内存空间，这么做的原因是，不管是永久代还是元空间，他们都是⽅法区的具体实现，之所以元空间所占的内存改成本地内存，官⽅的说法是为了和JRockit统⼀，不过额外还有⼀些原因，⽐如⽅法区所存储的类信息通常是⽐较难确定的，所以对于⽅法区的⼤⼩是⽐较难指定的，太⼩了容易出现⽅法区溢出，太⼤了⼜会占⽤了太多虚拟机的内存空间，⽽转移到本地内存后则不会影响虚拟机所占⽤的内存

说说常⽤的SpringBoot注解，及其实现

1. @SpringBootApplication注解：这个注解标识了⼀个SpringBoot⼯程，它实际上是另外三个注解的组合，这三个注解是：

a. @SpringBootConfiguration：这个注解实际就是⼀个@Configuration，表示启动类也是⼀个配置类

b. @EnableAutoConfiguration：向Spring容器中导⼊了⼀个Selector，⽤来加载ClassPath下

SpringFactories中所定义的⾃动配置类，将这些⾃动加载为配置Bean

c. @ComponentScan：标识扫描路径，因为默认是没有配置实际扫描路径，所以SpringBoot扫描的路径是启动类所在的当前⽬录

2. @Bean注解：⽤来定义Bean，类似于XML中的<bean>标签，Spring在启动时，会对加了@Bean注解的⽅法进⾏解析，将⽅法的名字做为beanName，并通过执⾏⽅法得到bean对象

3. @Controller、@Service、@ResponseBody、@Autowired都可以说

说说你了解的分布式锁实现

分布式锁所要解决的问题的本质是：能够对分布在多台机器中的线程对共享资源的互斥访问。在这个原理上可以有很多的实现⽅式：

1. 基于Mysql，分布式环境中的线程连接同⼀个数据库，利⽤数据库中的⾏锁来达到互斥访问，但是Mysql的加锁和释放锁的性能会⽐较低，不适合真正的实际⽣产环境

2. 基于Zookeeper，Zookeeper中的数据是存在内存的，所以相对于Mysql性能上是适合实际环境的，并且基于Zookeeper的顺序节点、临时节点、Watch机制能⾮常好的来实现的分布式锁

3. 基于Redis，Redis中的数据也是在内存，基于Redis的消费订阅功能、数据超时时间，lua脚本等功能，也能很好的实现的分布式锁

Redis的数据结构及使⽤场景

Redis的数据结构有：

1. 字符串：可以⽤来做最简单的数据缓存，可以缓存某个简单的字符串，也可以缓存某个json格式的字符串，Redis分布式锁的实现就利⽤了这种数据结构，还包括可以实现计数器、Session共享、分布式ID

2. 哈希表：可以⽤来存储⼀些key-value对，更适合⽤来存储对象

3. 列表：Redis的列表通过命令的组合，既可以当做栈，也可以当做队列来使⽤，可以⽤来缓存类似微信公众号、微博等消息流数据

4. 集合：和列表类似，也可以存储多个元素，但是不能重复，集合可以进⾏交集、并集、差集操作，从⽽可以实现类似，我和某⼈共同关注的⼈、朋友圈点赞等功能

5. 有序集合：集合是⽆序的，有序集合可以设置顺序，可以⽤来实现排⾏榜功能

Redis集群策略

Redis提供了三种集群策略：

1. 主从模式：这种模式⽐较简单，主库可以读写，并且会和从库进⾏数据同步，这种模式下，客户端直接连主库或某个从库，但是但主库或从库宕机后，客户端需要⼿动修改IP，另外，这种模式也⽐较难进⾏扩容，整个集群所能存储的数据受到某台机器的内存容量，所以不可能⽀持特⼤数据量

2. 哨兵模式：这种模式在主从的基础上新增了哨兵节点，但主库节点宕机后，哨兵会发现主库节点宕机，然后在从库中选择⼀个库作为进的主库，另外哨兵也可以做集群，从⽽可以保证但某⼀个哨兵节点宕机后，还有其他哨兵节点可以继续⼯作，这种模式可以⽐较好的保证Redis集群的⾼可⽤，但是仍然不能很好的解决Redis的容量上限问题。

3. Cluster模式：Cluster模式是⽤得⽐较多的模式，它⽀持多主多从，这种模式会按照key进⾏槽位的分配，可以使得不同的key分散到不同的主节点上，利⽤这种模式可以使得整个集群⽀持更⼤的数据容量，同时每个主节点可以拥有⾃⼰的多个从节点，如果该主节点宕机，会从它的从节点中选举⼀个新的主节点。

对于这三种模式，如果Redis要存的数据量不⼤，可以选择哨兵模式，如果Redis要存的数据量⼤，并且需要持续的扩容，那么选择Cluster模式。

Mysql数据库中，什么情况下设置了索引但⽆法使⽤?

1. 没有符合最左前缀原则

2. 字段进⾏了隐式数据类型转化

3. ⾛索引没有全表扫描效率⾼

Innodb是如何实现事务的

Innodb通过Buffer Pool，LogBuffer，Redo Log，Undo Log来实现事务，以⼀个update语句为例：

1. Innodb在收到⼀个update语句后，会先根据条件找到数据所在的⻚，并将该⻚缓存在Buffer Pool中

2. 执⾏update语句，修改Buffer Pool中的数据，也就是内存中的数据

3. 针对update语句⽣成⼀个RedoLog对象，并存⼊LogBuffer中

4. 针对update语句⽣成undolog⽇志，⽤于事务回滚

5. 如果事务提交，那么则把RedoLog对象进⾏持久化，后续还有其他机制将Buffer Pool中所修改的数据⻚持久化到磁盘中

6. 如果事务回滚，则利⽤undolog⽇志进⾏回滚

聊聊你最有成就感的项⽬

1. 项⽬是做什么的

2. ⽤了什么技术

3. 你在项⽬中担任的职位

4. 收获了什么

⾃⼰最有挑战的项⽬、难点

1. 使⽤什么技术解决了什么项⽬难点

2. 使⽤什么技术优化了什么项⽬功能

3. 使⽤什么技术节省了多少成本

结论：这一面八股文问的不多，项目方面问的比较多，软实力方面也有涉及，总的来说，难度是有的，面试的流程也挺顺利，几天后就通知面试通过。

三面（2h）

三面的面试官是阿里的技术总监，也是视频面试， 这一面没问技术问题，更多像是在聊天一样 ，说实话，面试官是真能聊啊，整个面试过程长达两个小时，我面试岗位那个部门的业务情况，同时还对我未来的技术方向做了一些建议，让我受益匪浅。

总的来说，这一面虽然在技术面试上没什么收获，但能遇到这么一位热心的面试官也算是我的运气了，这里不胜感激。

hr面

hr面也没什么好说的，交流了我的职业情况和期待薪资，几天后给完流水就发了offer。

总结

整个面试过程就大概是这样了，我想对大家来说，看完文章有收获的可能是一面和二面的分享， 总的来说，都是比较常规的面试考察点，一面特别多 八股文 方面的知识点，二面主要在 项目 ，我个人的话还是那句话，只要事先准备充足，还是可以从容应对的。

个人体会上的话也没什么好说的，毕竟整个过程比较顺利，没什么刁钻的题，后面我还会写几篇面经介绍下我面试其他公司遇到的难题，希望能帮到各位看官少遇点坑。好了，今天就这样了，我们下期再见。

为了帮助大家~

给大家分享一 个非常系统且专业的Java学习资料 ，这份资料 覆盖面极广 ，都是 最新前沿刚需知识点 ，并得到 阿里p8大佬 的认可，最适合忙于工作，时间不是那么充裕的朋友学习，是 精简中的重点 ，错过这次，很难分享第二次了！

主要分为两大模块： 阿里等30多家大厂的面试真题 、 Java面试重点知识+300道冲击大厂必备算法 ，新鲜出炉，赶紧藏起来~争取在最有效的时间做最高效的努力！

说明

整份文档一共有将近 500 页，全部为大家展示出来肯定是不太现实的，为了不影响大家的阅读体验就只展示了部分内容，大家一定要记得收藏！

PS：干货满满 不带任何水分！内容还有很多很多，就不一 一展示了。需要的小伙伴可自行领取。希望可以帮助大家在学习和面试的路上更加顺畅！2022进大厂 拿高薪！

如果需要获取到这个【核心知识手册】文档的话帮忙转发一下然后再关注我私信回复“文档”得到获取方式吧！