昨天 16:45 门头沟学院 Java 发布于广东

关注

《JAVA八股真解》十一、项目

Java八股文面试文章（续）

#JAVA##JAVA面经##JAVA内推#

1. 你的项目是什么性质的公司？公司主要业务是什么？

常见回答：

我所在的公司是一家小型外包公司。
公司的主要业务包括在线课程平台、智能学习系统、教师培训等。
技术栈主要包括Spring Boot、MyBatis、Redis、RabbitMQ、MySQL等。
项目采用了微服务架构，使用Docker进行容器化部署，Kubernetes管理集群。

提示：根据实际情况调整描述，突出公司的行业特点和技术优势。

2. 技术团队组成，认为自己的技术在团队属于什么水平？

常见回答：

我们团队共有8人，其中3名后端开发、2名前端开发、1名测试工程师、1名产品经理、1名项目经理。
我的技术水平处于中上等，能够独立完成模块开发，并参与系统设计与优化。
在团队中，我主要负责高并发场景下的性能优化和分布式事务处理。

建议：客观评价自己在团队中的位置，避免过度谦虚或自夸。

3. 你们团队的开发流程是什么样的？

alt

常见流程：

需求评审：产品经理提出需求，开发人员参与讨论并确认需求细节。
技术方案设计：架构师或资深开发人员设计整体技术方案，确定数据库结构、接口规范等。
代码开发：
- 使用Git进行版本控制，分支管理采用feature分支。
- 开发完成后提交Pull Request，由其他成员进行Code Review。
测试验证：
- 单元测试：使用JUnit进行单元测试。
- 集成测试：使用Postman进行接口测试。
- 系统测试：由测试团队进行全面测试。
上线发布：
- 使用Jenkins自动化构建和部署。
- 发布前进行灰度发布，逐步扩大用户范围。

图示说明：

需求 → 设计 → 开发 → 测试 → 上线

4. 项目周期为什么这么长？要干七个月？

常见回答：

项目周期较长主要是因为涉及多个模块的重构和新功能开发。
前期需要进行充分的需求调研和技术选型，确保方案可行。
中期进行了多次迭代优化，提升了系统的稳定性和用户体验。
后期重点在于性能调优和安全加固，确保上线后平稳运行。

补充：可以结合具体项目情况说明，如数据迁移、第三方系统对接等复杂操作导致周期延长。

5. 你们项目做了这么久才去考核？

常见回答：

项目初期以功能实现为主，后期重点放在性能优化和稳定性保障上。
考核时间安排在项目交付阶段，确保所有功能完整且稳定。
期间进行了多次内部评审和阶段性验收，保证质量可控。

提示：强调项目的阶段性目标和质量控制机制。

6. 为什么用微服务项目而不是单体服务？为什么选择这么多个技术栈？

常见回答：

微服务架构便于独立部署和扩展，每个服务可独立升级和维护。
采用多种技术栈是为了适应不同业务场景的需求，例如：
- 使用Spring Boot构建核心业务逻辑。
- 使用Redis作为缓存层，提升响应速度。
- 使用RabbitMQ实现异步通信，解耦系统组件。
多技术栈组合提高了系统的灵活性和可维护性。

优势：

每个服务可独立部署，降低故障影响范围。
支持快速迭代和持续交付。
易于横向扩展，应对高并发场景。

7. 为什么你用的是这个 RabbitMQ 而不是 Kafka？

常见回答：

RabbitMQ 和 Kafka 都是优秀的消息中间件，但我们在项目中选择了 RabbitMQ，原因如下：
- 简单易用：RabbitMQ 的配置和使用相对简单，适合中小型项目。
- 成熟稳定：RabbitMQ 在金融、电商等领域有广泛应用，社区支持完善。
- 功能满足需求：我们主要使用其基本的消息队列功能，无需 Kafka 的复杂流处理能力。
当然，如果未来需要处理海量数据或实时流处理，我们会考虑引入 Kafka。

对比总结： | 特性 | RabbitMQ | Kafka | |------|----------|-------| | 吞吐量 | 中等 | 高 | | 延迟 | 低 | 较高 | | 可靠性 | 高 | 高 | | 适用场景 | 一般消息队列 | 大数据流处理 |

8. 你做第一个项目甲方是哪家公司？你们用的物理服务器吗？云服务器的账号是甲方还是你们的？

常见回答：

第一个项目是为某电商平台开发的订单管理系统，甲方是XX集团。
我们使用的是阿里云ECS实例，账号由公司统一管理。
服务器部署在VPC网络中，通过SLB负载均衡对外提供服务。
数据库使用RDS，支持主从复制和自动备份。

补充：强调安全性措施，如访问控制、日志审计等。

9. 你的技术栈是怎样的？你参与过项目架构设计吗？

常见回答：

我的技术栈主要包括：
- 后端：Spring Boot、MyBatis Plus、Redis、RabbitMQ、Elasticsearch
- 前端：Vue.js、Element UI
- 数据库：MySQL、MongoDB
- 运维：Docker、Kubernetes、Jenkins
在项目中，我参与了部分模块的设计，包括接口定义、数据库表结构设计等。
对于复杂业务逻辑，我会与架构师讨论并提出优化建议。

建议：列出具体技术点，并说明其应用场景。

10. 你的工作是谁安排的？

常见回答：

日常工作任务由项目经理或技术负责人分配。
每周召开站会，明确本周重点任务和优先级。
对于紧急问题，我会主动沟通并协调资源解决。

提示：体现主动性与协作意识。

11. 你写过技术文档吗？

常见回答：

是的，我编写过以下类型的技术文档：
- 接口文档：使用Swagger生成API文档，方便前后端联调。
- 数据库设计文档：包含表结构、字段说明、索引策略等。
- 系统部署手册：详细记录环境配置、启动命令、监控方式等。
文档通常存储在Git仓库中，供团队成员查阅。

建议：展示文档写作能力和规范意识。

12. 你设计过API接口文档吗？说了怎么设计的？

常见回答：

是的，我使用Swagger设计API接口文档。
设计步骤如下：
1. 定义接口路径（如 /api/user/login）。
2. 明确请求方法（GET/POST/PUT/DELETE）。
3. 描述请求参数（JSON格式、必填项、默认值等）。
4. 定义响应结果（成功状态码200，失败状态码4xx/5xx）。
5. 添加注释说明业务逻辑和异常处理。

示例：

POST /api/user/login
{
  "username": "string",
  "password": "string"
}

13. 接口文档给谁看的？

常见回答：

接口文档主要用于以下人员参考：
- 前端开发：了解接口调用方式和参数格式。
- 测试人员：编写测试用例，验证接口功能。
- 运维人员：排查接口异常，查看错误码含义。
- 第三方开发者：集成外部系统时使用。

建议：强调文档的通用性和实用性。

14. 开发接口文档是会提前写的？用的什么软件，接口文档有什么？

常见回答：

是的，接口文档会在开发前或开发初期撰写，确保前后端同步。
使用工具：Swagger、Postman、YAPI。
接口文档内容包括：
- 接口名称
- 请求方式
- 请求URL
- 请求参数
- 响应结果
- 错误码说明

优点：提高协作效率，减少沟通成本。

15. 你在项目中设计过表吗？具体设计过哪些表，表都有哪些字段？

常见回答：

是的，我参与了用户表、订单表、商品表等核心表的设计。
用户表（user）：
- 字段：id（主键）、username、password、email、phone、create_time、update_time
订单表（order）：
- 字段：id（主键）、user_id、total_amount、status、create_time、pay_time
商品表（product）：
- 字段：id（主键）、name、price、description、stock、category_id

设计原则：

符合第三范式，避免冗余。
设置合理索引，提升查询性能。
考虑扩展性，预留字段空间。

16. 你在项目中写过前端页面吗？前端水平怎么样？前端技术栈知道吗？

常见回答：

我主要负责后端开发，但具备一定的前端基础。
使用过HTML、CSS、JavaScript进行简单页面布局。
熟悉Vue.js框架，能配合前端完成接口对接。
前端技术栈了解：React、Angular、Bootstrap、Axios等。

建议：如实说明技能水平，不夸大。

17. 么判断程序员代码写的不好？

常见回答：

代码质量差的表现包括：
- 缺乏注释：代码没有清晰的注释，难以理解意图。
- 命名混乱：变量名不规范，如a、b、temp等。
- 重复代码：相同逻辑被多次复制粘贴。
- 违反单一职责原则：一个类承担过多功能。
- 缺乏异常处理：未对可能的异常情况进行捕获。
- SQL注入风险：拼接SQL语句，存在安全隐患。

改进建议：

使用Git进行版本控制，定期Code Review。
编写单元测试，覆盖关键逻辑。
遵循编码规范，使用Lint工具检查代码风格。

18. 接口的健壮性如何保障？

常见回答：

接口健壮性保障措施包括：
- 输入校验：对请求参数进行合法性验证，防止非法数据进入系统。
- 异常处理：统一异常处理机制，返回标准错误码。
- 限流熔断：使用Sentinel或Hystrix防止雪崩效应。
- 日志记录：详细记录请求日志，便于问题排查。
- 接口监控：使用Prometheus+Grafana监控接口性能。
- 压力测试：使用JMeter进行高并发测试，确保稳定性。

示例：

@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody LoginRequest request) {
    if (request.getUsername() == null || request.getPassword() == null) {
        return ResponseEntity.badRequest().body("用户名或密码不能为空");
    }
    // 登录逻辑
}

19. 接口的幂等性如何设计？具体说说

常见回答：

幂等性是指多次执行同一操作的结果与一次执行相同。
实现方式：
- 数据库唯一约束：如订单创建时，使用订单号作为唯一键。
- Token机制：每次请求生成唯一Token，服务器验证后失效。
- 状态机控制：如订单状态只能从“待支付”变为“已支付”，不能重复支付。
示例：支付接口通过订单号判断是否已支付，避免重复扣款。

重要性：防止因网络波动或客户端重试导致重复操作。

20. API接口性能如何解决（API接口的性能如何提升）？

常见回答：

优化数据库查询：
- 添加合适的索引。
- 避免N+1查询，使用JOIN或批量查询。
缓存机制：
- 使用Redis缓存热点数据。
- 设置合理的过期时间，避免脏读。
异步处理：
- 将耗时操作放入消息队列，如发送邮件、短信。
压缩传输：
- 使用Gzip压缩响应体，减少带宽消耗。
CDN加速：
- 静态资源托管至CDN，提升加载速度。

示例：

@GetMapping("/users/{id}")
@Cacheable(value = "userCache", key = "#id")
public User getUser(@PathVariable Long id) {
    return userService.findById(id);
}

21. MySQL 查询语句，如何定位慢的原因？

常见回答：

查看慢查询日志：

SET long_query_time = 1;
SET slow_query_log = ON;

使用EXPLAIN分析执行计划：

EXPLAIN SELECT * FROM users WHERE username = 'example';

优化建议：
- 添加适当索引。
- 避免全表扫描。
- 减少不必要的子查询。
- 使用覆盖索引。

示例分析：

EXPLAIN SELECT * FROM users WHERE username = 'example';

如果显示type: ALL，表示全表扫描，需添加索引。
如果key: NULL，表示未使用索引，需优化查询条件。

22. MySQL中EXPLAIN执行计划的用途

常见回答：

EXPLAIN用于查看SQL语句的执行计划，帮助优化查询性能。
主要用途：
- 查看是否使用了索引。
- 判断是否有全表扫描。
- 分析连接顺序和类型。
关键字段：
- type：访问类型（ALL、index、range、ref等）。
- key：使用的索引。
- rows：估计扫描行数。
- Extra：额外信息（Using temporary, Using filesort）。

示例：

EXPLAIN SELECT * FROM users WHERE username = 'example';

23. MySQL中超过1000万条数据会有啥问题？

常见回答：

性能下降：查询变慢，尤其是无索引的全表扫描。
内存占用高：大量数据加载到内存，可能导致OOM。
锁竞争加剧：写操作频繁，容易出现死锁。
备份恢复慢：大表备份和恢复耗时长。

解决方案：

分库分表：按业务或时间维度拆分表。
读写分离：主库写入，从库读取。
缓存策略：使用Redis缓存热点数据。
索引优化：合理设计索引，避免无效查询。

24. MySQL表中有1亿条数据如何优化？

常见回答：

索引优化：
- 为常用查询字段建立索引。
- 避免过度索引，影响写入性能。
分区表：
- 按时间或业务逻辑分区，提升查询效率。
分库分表：
- 水平拆分，将数据分散到多个表或库。
缓存策略：
- 使用Redis缓存热点数据。
- 设置合理的过期时间。
读写分离：
- 主库写入，从库读取，减轻主库压力。

示例：

-- 按时间分区
ALTER TABLE user_data PARTITION BY RANGE (YEAR(create_time));

25. 项目中变更如何管理的？只有一个分支吗？

常见回答：

使用Git进行版本控制，遵循Git Flow工作流。
主要分支：
- main/master：生产环境代码。
- develop：开发分支，集成各功能分支。
- feature/*：功能开发分支。
- hotfix/*：紧急修复分支。
变更流程：
1. 创建功能分支。
2. 开发完成后提交PR。
3. Code Review通过后合并到develop。
4. 定期发布到main。