最新Java校招面试题及答案

10）还有一些问题，如 MySQL 和 SQL Server 用法上的区别、limit 关键字的使用等问题。

小结：数据库方面还是事务机制、隔离级别比较重要，当然了数据库索引是必考的问题。偶尔也会给你几个表，让你现场写 SQL 语句，主要考察 group by 和 having 等关键字。

（八）MVC 框架相关知识点

我在项目中使用的框架有 Spring MVC 和 MyBatis，所以在简历上只写了这两种框架，面试官主要针对这两种框架进行提问。以下问题供小伙伴们参考。

JavaWeb 开发经典的 3 层框架：Web 层、Service 层（业务逻辑层）和 Dao 层（数据访问层）

• Web 层：包含 JSP 和 Servlet 等与 Web 相关的内容；

• 业务层：只关心业务逻辑；

• 数据层：封装了对数据库的访问细节。

Spring 知识点

1）Spring 的 IOC 和 AOP 有了解吗？

答：

• IOC：控制反转，（解耦合）将对象间的依赖关系交给 Spring 容器，使用配置文件来创建所依赖的对象，由主动创建对象改为了被动方式；

• AOP：面向切面编程，将功能代码从业务逻辑代码中分离出来。

2）AOP 的实现方式有哪几种？如何选择？（必考）

答：JDK 动态代理实现和 cglib 实现。

选择：

1. 如果目标对象实现了接口，默认情况下会采用 JDK 的动态代理实现 AOP，也可以强制使用 cglib 实现 AOP；

2. 如果目标对象没有实现接口，必须采用 cglib 库，Spring 会自动在 JDK 动态代理和 cglib 之间转换。

扩展：JDK 动态代理如何实现？（加分点）

答：JDK 动态代理，只能对实现了接口的类生成代理，而不是针对类，该目标类型实现的接口都将被代理。原理是通过在运行期间创建一个接口的实现类来完成对目标对象的代理。

1. 定义一个实现接口 InvocationHandler 的类；

2. 通过构造函数，注入被代理类；

3. 实现 invoke（ Object proxy,Method method,Object[] args）方法；

4. 在主函数中获得被代理类的类加载器；

5. 使用 Proxy.newProxyInstance( ) 产生一个代理对象；

6. 通过代理对象调用各种方法。

解析：关于 IOC 和 AOP 的详细阐述，请各位参阅我的博客：Spring 核心 AOP（面向切面编程）总结，Spring 框架学习—控制反转（IOC）

3）Spring MVC 的核心控制器是什么？消息处理流程有哪些？

答：核心控制器为 DispatcherServlet。消息流程如下：

<img src="https://www.52php.cn/res/2019/03-16/23/fa0a33b96b08d7ffc6ded52cf4c2996a.jpg" alt="">

4）其他问题包括：重定向和转发的区别、动态代理和静态代理的区别等。

Mybatis 知识点

关于 MyBatis 主要考察占位符#和 $ 的区别，区别如下：

1. 符号将传入的数据都当做一个字符串，会对自动传入的数据加一个双引号；

2. $ 符号将传入的数据直接显示生成 SQL 中；

3. 符号存在预编译的过程，，对问号赋值，防止 SQL 注入；

4. $ 符号是直译的方式，一般用在 order by ${列名}语句中；

5. 能用#号就不要用 $ 符号。

小结：限于作者水平，MVC 框架方面了解不是太多，实战能力欠缺。面试官偶尔问框架底层实现原理等都知之甚少，有能力的小伙伴可以多加学习。

（九）大数据相关知识点

大数据相关是因为我的简历上写了 KafKa 相关项目，所以面试官会进行提问 KafKa 相关知识点，我也进行了一些简单概念总结，深层次的实现原理因为并没有特别多的实战经验，所以并不了解。

以下概念总结供小伙伴参考。

1）KafKa 基本特性：

答：快速持久化、支持批量读写消息、支持消息分区，提高了并发能力、支持在线增加分区、支持为每个分区创建多个副本。

扩展：为什么可以实现快速持久化？

答：KafKa 将消息保存在磁盘中，并且读写磁盘的方式是顺序读写，避免了随机读写磁盘（寻道时间过长）导致的性能瓶颈；磁盘的顺序读写速度超过内存随机读写。

2）核心概念：

答：

• 生产者（Producer）： 生产消息，并且按照一定的规则推送到 Topic 的分区中。

• 消费者（Consumer）： 从 Topic 中拉去消息，并且进行消费。

• 主题（Topic）： 用于存储消息的逻辑概念，是一个消息集合。

• 分区（partition）：

1. 每个 Topic 可以划分为多个分区，每个消息在分区中都会有一个唯一编号 offset

2. kafka 通过 offset 保证消息在分区中的顺序

3. 同一 Topic 的不同分区可以分配在不同的 Broker 上

4. partition 以文件的形式存储在文件系统中。

副本（replica）：

1. KafKa 对消息进行了冗余备份，每个分区有多个副本，每个副本中包含的消息是 “一样” 的。

2. 每个副本中都会选举出一个 Leader 副本，其余为 Follower 副本，Follower 副本仅仅将数据从 Leader 副本拉去到本地，然后同步到自己的 Log 中。

消费者组（Consumer Group）： 每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。

Broker：

1. 一个单独的 server 就是一个 Broker；

2. 主要工作：接收生产者发过来的消息，分配 offset，并且保存到磁盘中；

Cluster&Controller：

1. 多个 Broker 可以组成一个 Cluster，每个集群选举一个 Broker 来作为 Controller，充当指挥中心

2. Controller 负责管理分区的状态，管理每个分区的副本状态，监听 ZooKeeper 中数据的变化等工作

保留策略和日志压缩：

1. 不管消费者是否已经消费了消息，KafKa 都会一直保存这些消息（持久化到磁盘）；

2. 通过保留策略，定时删除陈旧的消息；

3. 日志压缩，只保留最新的 Key-Value 对。

关于副本机制：（加分点）

ISR 集合 ：表示当前 “可用” 且消息量与 Leader 相差不多的副本集合。满足条件如下：

1. 副本所在节点必须维持着与 ZooKeeper 的连接；

2. 副本最后一条信息的 offset 与 Leader 副本的最后一条消息的 offset 之间的差值不能超过指定的阈值。

HW&LEO：

1. HW 标记了一个特殊的 offset，当消费者处理消息的时候，只能拉取到 HW 之前的消息；

2. HW 也是由 Leader 副本管理的；

3. LEO（Log End Offset）是所有副本都会有的一个 offset 标记。

ISR、HW 和 LEO 的工作配合：

1. producer 向此分区中推送消息；

2. Leader 副本将消息追加到 Log 中，并且递增其 LEO；

3. Follower 副本从 Leader 副本中拉取消息进行同步；

4. Follower 副本将消息更新到本地 Log 中，并且递增其 LEO；

5. 当 ISR 集合中的所有副本都完成了对 offset 的消息同步，Leader 副本会递增其 HW

（编辑：武汉站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!