互联网大厂 Java 求职者面试实战

角色：严肃面试官（以下简称 官） & 搞笑“水货”程序员 谢飞机（以下简称 谢）

场景概述

面试位于某知名互联网大厂的研发部门，业务涉及电商、内容社区与 AIGC 场景的微服务系统。面试官围绕全栈技术栈进行提问，考察候选人的系统设计能力、技术深度与实战经验。

第 1 轮提问（基础层）

| 序号 | 面试官提问 | 谢的回答 | |------|-----------|----------| | 1 | 请简述 Java SE 与 Jakarta EE 的区别，以及在实际项目中何时选用它们？ | “Java SE 是标准的核心语言运行时，提供集合、并发、IO 等基础库；Jakarta EE（原 Java EE）在此之上提供企业级规范，例如 Servlet、JPA、EJB。我们一般在轻量服务里直接用 Spring Boot（基于 Java SE），而在需要统一事务、消息服务的传统大型业务系统会选 Jakarta EE。” | | 2 | Maven 与 Gradle 的主要区别是什么？请举例说明在构建大型微服务项目时的最佳实践。 | “Maven 基于 XML，依赖管理明确；Gradle 用 Groovy/Kotlin DSL，增量编译更快。大型微服务建议统一使用 Maven，因为它的依赖锁定更稳定，且 CI 环境兼容性好；但如果项目需要自定义任务或多语言混编，可考虑 Gradle。” | | 3 | Spring Boot 与 Spring MVC 的关系以及你们在实际项目中如何划分使用？ | “Spring Boot 是约定式的快速启动脚手架，内部默认使用 Spring MVC 作为 Web 框架。我们在所有新建的微服务里首选 Spring Boot，内部的控制层仍然写 @RestController，即使用 Spring MVC。” |

解释（第 1 轮答案详解）

1. Java SE vs Jakarta EE：Java SE 提供语言层面的 API，适用于任何 Java 程序；Jakarta EE 为企业级规范（如 JAX‑RS、JPA），适合统一事务与容器管理的大型系统。
2. Maven 与 Gradle：Maven 的确定性适合团队协作，Gradle 的灵活性好，适合需要高度自定义的项目。大型微服务通常选 Maven 统一规范。
3. Spring Boot 与 Spring MVC：Spring Boot 通过自动配置隐藏了大量 XML 配置，快速启动；Spring MVC 仍是实现控制层的核心技术。两者不是竞争关系，而是包含关系。

第 2 轮提问（持久化 & 测试）

| 序号 | 面试官提问 | 谢的回答 | |------|-----------|----------| | 1 | 在使用 MyBatis 与 Hibernate 时，如何决定选择哪一种？请结合事务和性能给出判断依据。 | “MyBatis 更手动映射，SQL 可控，适合对查询性能要求极高的业务；Hibernate（JPA）提供 ORM 自动化，适合业务模型复杂、CRUD 较多的场景。事务上，两者都可以配合 Spring Transaction，差别不大。” | | 2 | 请解释 Flyway 与 Liquibase 的区别，并说明在 CI/CD 流水线中如何使用它们进行数据库迁移。 | “Flyway 基于版本化的 SQL 脚本，简单直观；Liquibase 支持 XML/YAML/SQL，功能更丰富。CI 中我们通常在 Jenkins/GitLab CI 中执行 flyway migrate 或 liquibase update，确保每次部署前 DB 与代码版本保持一致。” | | 3 | JUnit 5 与 TestNG 在设计理念上有什么不同？在编写微服务单元测试时，你更倾向于哪一个？ | “JUnit 5 引入了模块化的 Jupiter，支持动态测试、标签等；TestNG 支持并发、依赖测试。因为 Spring Boot 官方示例基于 JUnit 5，我更倾向于 JUnit 5，配合 SpringBootTest 能快速启动上下文。” | | 4 | Mockito 与 PowerMock 的使用场景分别是什么？请给出一个使用 PowerMock 的实际案例。 | “Mockito 用于普通的接口/类的 mock，不能 mock final 类或 static 方法；PowerMock 可以突破这些限制。例如我们需要 mock java.lang.System.getenv 读取环境变量时，就需要 PowerMock。” |

解释（第 2 轮答案详解）

1. MyBatis vs Hibernate：MyBatis 适合对 SQL 性能高度控制的场景（如大数据查询），Hibernate 适合 CRUD 主导的业务。事务可统一交给 Spring。
2. Flyway vs Liquibase：Flyway 简洁、SQL‑first；Liquibase 功能更全，支持声明式变更。CI/CD 中的典型做法是将迁移脚本放在代码库，构建完成后自动执行。
3. JUnit 5 vs TestNG：JUnit 5 受社区广泛支持，尤其与 Spring Boot 的集成更自然；TestNG 在并发和依赖测试上更灵活。
4. Mockito vs PowerMock：PowerMock 只在必须对 final、static、private 方法进行 mock 时使用，避免滥用导致测试脆弱。

第 3 轮提问（分布式、容错与安全）

| 序号 | 面试官提问 | 谢的回答 | |------|-----------|----------| | 1 | 请谈谈 Spring Cloud 与 Netflix OSS（Eureka、Zuul）在服务注册/网关方面的区别，并说明在高并发场景下的选型策略。 | “Spring Cloud 对 Eureka、Ribbon、Feign 等做了统一封装；Netflix OSS 原生是独立的组件。我们在高并发时倾向使用 Spring Cloud 的 Sleuth + OpenFeign 进行轻量化调用，同时把 Zuul 换成 Spring Cloud Gateway，以获得更好的响应式支持。” | | 2 | 在微服务之间实现幂等性，你会选用哪些技术或模式？请结合 Redis 与数据库事务说明实现细节。 | “可以在入口层使用唯一请求 ID（UUID）并存入 Redis 幂等键；业务层使用 DB 唯一约束或乐观锁防止重复写。具体实现：请求到达后先 SETNX 锁定 ID，成功则继续业务，否则直接返回成功响应。” | | 3 | 解释 JWT 与 OAuth2 的区别，并给出在前后端分离系统中如何安全地存储 JWT 的最佳实践。 | “JWT 是一种自包含的 token，携带用户信息；OAuth2 是授权框架，常配合 JWT 作为 Access Token。前端存储 JWT 最安全的方式是放在 HttpOnly、Secure 的 Cookie 中，避免 XSS 劫持。” | | 4 | 在高可用的 Kafka 消费者设计中，如何利用 Spring Cloud Stream 或原生 Kafka Client 实现消费位移（offset）的精确控制？ | “我们可以关闭自动提交 enable.auto.commit=false，在业务处理成功后手动 commitSync 或使用 AckMode.MANUAL_IMMEDIATE 配合 Spring Cloud Stream 的 ConsumerCustomizer，确保每条消息仅在成功处理后提交 offset，避免重复消费。” | | 5 | 请说明在使用 Prometheus + Grafana 进行微服务监控时，如何设计自定义指标（如业务成功率）并在代码中上报。 | “使用 Micrometer 提供的 Timer、Counter，并通过 @Timed 注解或手动 meterRegistry.counter('service.success', Tags.of('service','order')) 记录成功次数；Grafana 中基于 PromQL 计算成功率 sum(rate(service_success[1m])) / sum(rate(service_total[1m]))。” |

解释（第 3 轮答案详解）

1. Spring Cloud vs Netflix OSS：Spring Cloud 把 Eureka、Zuul 等封装为更易用的 starter，且提供统一的配置中心、熔断等功能；在高并发场景推荐使用 Spring Cloud Gateway 代替 Zuul，支持响应式编程。
2. 幂等性实现：利用 Redis 分布式锁或唯一键防止重复执行；在业务层使用数据库唯一键或乐观锁保障数据唯一。
3. JWT vs OAuth2：OAuth2 为授权框架，常配合 JWT 作为 token；Jwt 建议放在 HttpOnly Cookie，防止 XSS。
4. Kafka Offset 控制：关闭自动提交，手动提交以确保业务成功后再更新 offset，避免消息丢失或重复。
5. Prometheus 自定义指标：通过 Micrometer 在代码中上报 Counter/Timer，Grafana 使用 PromQL 计算业务成功率，实现业务监控全链路可观测。

综合答案（所有问题的技术要点与业务场景剖析）

1. 语言与平台：Java SE 为底层语言，Jakarta EE 为企业级规范，二者在不同业务层次的适配决定系统的弹性与维护成本。
2. 构建工具：Maven 的确定性适合大型微服务统一管理，Gradle 在需要高度自定义时更具优势。
3. Web 框架：Spring Boot 为主流快速开发框架，内部依赖 Spring MVC 实现 HTTP 交互；其他框架（Micronaut、Quarkus）可用于云原生轻量服务。
4. 持久化：MyBatis 与 Hibernate 各有优势，项目需根据查询性能与业务模型复杂度选型；Flyway/Liquibase 确保数据库版本一致性。
5. 测试：JUnit 5 为主流单元测试框架，TestNG 可用于更细粒度的并发/依赖测试；Mockito 与 PowerMock 搭配满足不同 mock 场景。
6. 微服务 & 云原生：Spring Cloud 提供完整生态（服务注册、负载均衡、熔断、配置中心），Netflix OSS 为底层实现；OpenFeign 与 Resilience4j 增强调用的容错性。
7. 安全：JWT 用于无状态认证，OAuth2 负责授权，建议放在 HttpOnly Cookie 防止 XSS；Spring Security 与 Shiro 为底层安全框架。
8. 消息队列：Kafka 适合高吞吐日志与事件流，RabbitMQ 适合可靠的点对点消息；幂等性通过 Redis 锁、唯一键实现。
9. 缓存：Redis 为分布式缓存，Ehcache/Caffeine 为本地缓存，结合 Spring Cache 可实现多层缓存策略。
10. 日志 & 监控：Log4j2/Logback 负责日志落盘，SLF4J 为统一 API；Prometheus + Grafana + Micrometer 完成指标采集、告警与可视化。
11. CI/CD：Jenkins、GitLab CI、GitHub Actions 与 Docker/Kubernetes 完成持续集成、容器化部署与滚动升级。
12. 大数据：Hadoop、Spark、Flink 为离线、流式计算框架，Cassandra、Elasticsearch 为 NoSQL 与搜索引擎。

结语：通过本次模拟面试，候选人展示了对全栈技术的宏观把握与细节实现的能力。面试官通过循序渐进的提问，引导候选人阐述从语言层到微服务治理的完整链路，并在关键环节考察了候选人的实战经验与思考深度。

面试官总结：
“谢飞机，今天的面试你把大多数基础概念说得很清楚，尤其是对 Spring Boot 与微服务治理的理解让我满意。但在幂等性与高并发容错的细节上还有提升空间。后续请继续深化对分布式事务和监控指标的实践经验。今天先到这里，回去加油，祝你早日上岸！”