【面试笔记-Java开发岗】

发布于:2025-09-14 ⋅ 阅读:(18) ⋅ 点赞:(0)

1. synchronized 和 ReentrantLock 的区别及应用场景

(1) 实现机制

  • synchronized:Java 内置关键字,依赖 JVM 监视器锁(Monitor),隐式加锁/解锁,不可中断。
  • ReentrantLock:显式锁(需手动调用 lock()/unlock()),支持尝试锁(tryLock)、超时、公平锁(构造函数指定)、条件变量(Condition)。

(2) 灵活性

  • synchronized 简单但功能有限;ReentrantLock 更灵活,支持复杂场景(如定时锁、中断响应)。
    性能
  • JDK 1.6+ 后 synchronized 性能优化(偏向锁、轻量级锁),高竞争下 ReentrantLock 可能更优。

(3)应用场景:

  • synchronized:简单同步需求(如单例模式、小临界区)。
  • ReentrantLock:需要公平锁、超时控制或复杂条件变量的场景(如线程池任务调度、高并发资源竞争)。

2. HashMap 与 LinkedHashMap 的区别

(1) 数据结构

  • HashMap:基于哈希表实现,无序。
  • LinkedHashMap:继承自 HashMap,通过双向链表维护插入顺序或访问顺序(LRU 缓存)。

(2)应用场景

  • HashMap:常规键值对存储,无需顺序控制。
  • LinkedHashMap:需遍历顺序与插入/访问顺序一致(如缓存、历史记录)。

3. ConcurrentHashMap 的数据结构及 JDK1.7 与 JDK1.8 区别

JDK 1.7

  • 分段锁(Segment):将数据分为多个 Segment,每个 Segment 独立加锁,提升并发度(默认 16 个 Segment)。
  • 数据结构:数组 + 链表。

JDK 1.8

  • CAS + synchronized:使用 CAS(无锁操作)和 synchronized(锁单个链表头节点),减少锁粒度。
  • 红黑树优化:链表长度超过阈值(默认 8)时转为红黑树,查询时间从 O(n) 降为 O(log n)。
    核心改进:减少内存开销,提升高并发性能。

4. Spring 常用的模式及应用场景

在这里插入图片描述
Spring 各模块中设计模式的体现
在这里插入图片描述
我在项目中使用过 Spring 的代理模式(AOP)实现日志记录和权限控制,使用模板方法模式封装通用数据库操作,使用观察者模式实现业务事件通知。这些设计模式提升了代码的可维护性和扩展性。

5. 事务的四大特性(ACID)

  • 原子性(Atomicity):事务内操作要么全成功,要么全失败回滚。
  • 一致性(Consistency):事务执行前后,数据库完整性约束不变(如外键约束)。
  • 隔离性(Isolation):多个事务并发执行时,相互隔离(隔离级别:读未提交、读已提交、可重复读、串行化)。
  • 持久性(Durability):事务提交后,修改永久保存到数据库。

6. 锁机制:行级锁与游标锁

  • 行级锁
    锁定特定行(如 MySQL InnoDB 的 SELECT … FOR UPDATE),减少锁冲突,提升并发。
  • 游标锁(悲观锁
    在读取数据时锁定整个结果集(如 SQL Server 的 HOLDLOCK),防止其他事务修改,适用于高写入冲突场景。

7. 索引的种类与使用场景

1. 种类

  • B+ 树索引:默认索引类型,适用于范围查询(如 WHERE id > 100)。
  • 哈希索引:仅支持等值查询(如 Redis、Memory 引擎)。
  • 全文索引:文本模糊匹配(如 MATCH() AGAINST())。
  • 组合索引:多列联合索引(遵循最左前缀原则)。

2. 使用场景

  • 主键索引:唯一标识记录。
  • 唯一索引:防止重复值(如用户名)。
  • 组合索引:优化多条件查询(如 WHERE name=‘A’ AND age=20)。

8. 慢 SQL 优化

  • 分析工具:EXPLAIN 查看执行计划,定位全表扫描或临时表。
EXPLAIN SELECT * FROM your_table WHERE your_condition;
  • 判断哪些索引是无效的?
    (1)使用 EXPLAIN 分析执行计划
    EXPLAIN SELECT * FROM orders WHERE customer_id = 123;
    查看 EXPLAIN 的输出,重点关注以下字段:
    在这里插入图片描述
    (2) 看索引是否被使用(可通过慢查询日志 + EXPLAIN 分析)
    启用慢查询日志,找出执行时间长的 SQL。
    对这些 SQL 执行 EXPLAIN,看是否使用了索引。
    如果未使用索引,可能是索引失效或设计不合理。
    (3)常见导致索引失效的 SQL 写法
    在这里插入图片描述

  • 判断哪些索引是有效的?
    (1) 看 EXPLAIN 的 type 类型
    在这里插入图片描述
    (2) 看 rows 字段
    rows 表示 MySQL 估计需要扫描的行数。
    越小越好。
    如果 rows 很大,说明索引可能不够高效。
    (3) 看 Extra 字段
    在这里插入图片描述

  • 优化策略**
    (1) 添加索引(避免在低选择性字段建索引)。
    (2) 避免 SELECT *,只查询必要字段。
    (3) 分页优化:大分页改用游标分页(如 WHERE id > 1000 LIMIT 10)。
    (4) 拆分复杂 SQL(减少子查询嵌套)。
    (5) 定期分析表(ANALYZE TABLE 更新统计信息)。

9. Git 常用命令与解决冲突

常用命令

  • git clone:克隆仓库。
  • git add:添加修改到暂存区。
  • git commit:提交本地仓库。
  • git push/pull:推送/拉取远程分支。
  • git branch:查看分支。
  • git merge:合并分支。
  • git rebase:变基(避免合并提交)。
    解决冲突
  • git pull 或 merge 时标记冲突文件。
  • 手动编辑文件,删除冲突标记(<<<<<<<, =======, >>>>>>>)。
  • git add <文件> 标记冲突已解决。
  • git commit 提交最终版本。

10. 如何保证线程安全

  • 同步机制,使用 synchronized 或 ReentrantLock 控制临界区访问。
  • 原子类:AtomicInteger、AtomicReference(CAS 操作)。
  • 线程本地变量:ThreadLocal 存储线程私有数据(如用户会话)。
  • 并发工具类:ConcurrentHashMap、CopyOnWriteArrayList。
  • volatile:保证变量可见性(适用于状态标志)。

11. MySQL 存储引擎

  • InnoDB
    支持事务、行级锁、崩溃恢复(默认引擎)。
  • MyISAM
    高速存储,不支持事务和行锁,适合只读或插入密集场景。
  • Memory
    数据存储在内存中,速度快,适合临时表。
  • Archive
    高压缩比,适合归档日志数据。

应用场景

  • InnoDB:高并发写入(如订单系统)。
  • MyISAM:只读数据(如静态资源表)。
  • Memory:临时缓存(如会话统计)。

12. Redis 如何使用及应用场景

Redis 是一个高性能的内存数据库,支持多种数据结构,常用于缓存、分布式锁、计数器、排行榜等场景。在实际项目中,我主要用 Redis 做缓存和计数器。比如在电商系统中,将商品详情缓存到 Redis,设置 5 分钟过期时间;在社交系统中,使用 Redis 统计用户的点赞和评论数,避免频繁写数据库。

典型使用场景包括:

  • 缓存:将热点数据缓存到 Redis,减少数据库压力,提升访问速度。
  • 分布式锁:使用 SETNX 或 Redlock 实现跨服务的资源互斥访问。
  • 计数器:使用 INCR 实现点赞、浏览量、订单号生成等。
  • 排行榜:使用 ZSet 实现游戏积分榜、热门文章等。
  • 消息队列:使用 List 或 Pub/Sub 实现任务队列或事件通知。
  • 限流:使用 INCR + EXPIRE 实现滑动窗口限流,保护后端服务。
  • 用户签到:使用 Bitmap 实现签到统计,节省空间。

13. Redis 缓存穿透、击穿、雪崩有什么区别?如何解决?

  • 缓存穿透:查询一个既不在缓存也不在数据库中的数据(如非法 ID),导致每次请求都打到数据库。
    • 解决:布隆过滤器(Bloom Filter)拦截非法请求;缓存空值并设置短过期时间。
  • 缓存击穿:某个热点 key 突然失效,大量并发请求直接打到数据库。
    • 解决:设置热点 key 永不过期;使用互斥锁(Mutex)或分布式锁控制重建缓存的并发。
  • 缓存雪崩:大量 key 同时过期或 Redis 宕机,导致数据库压力激增。
    • 解决:设置过期时间加随机值;使用高可用 Redis 集群;缓存降级、限流熔断。

14. 你能介绍一下你日常开发一个需求的全流程吗

日常开发一个需求的全流程,我理解为:从需求评审 → 技术设计 → 开发实现 → 代码审查 → 测试验证 → 上线部署 → 上线后维护。我会在每个阶段都保持清晰的文档和沟通,确保需求高质量落地。

15.你能简单介绍一下你常用的 Spring Cloud 微服务组件吗?

我常用的 Spring Cloud 微服务组件包括 Eureka/Nacos(服务注册)、Feign(服务调用)、Ribbon(负载均衡)、Hystrix/Sentinel(熔断限流)、Gateway(网关)、Config(配置中心)、Sleuth/Zipkin(链路追踪),它们分别承担了服务注册、通信、容错、统一入口、配置管理、链路监控等职责。
(补充知识)

  • 1. Eureka / Nacos(服务注册与发现)
    • 功能:服务注册中心,用于微服务之间的服务发现。
    • 说明:服务启动后会自动注册到 Eureka 或 Nacos,其他服务可以通过服务名发现并调用目标服务。
      区别:Nacos 还支持配置中心功能,适合需要动态配置管理的场景。
  • 2. Ribbon(客户端负载均衡)
    • 功能:在服务调用时,自动选择一个可用的服务实例,实现负载均衡。
    • 使用场景:结合 Feign 使用,支持轮询、随机等策略,实现服务调用的负载均衡。
  • 3. Feign(声明式服务调用)
    • 功能:简化服务间调用,通过声明式接口实现远程调用。
    • 使用场景:服务 A 调用服务 B 的接口时,只需定义一个接口即可完成调用,底层自动集成 Ribbon 实现负载均衡。
  • 4. Hystrix(服务熔断与降级)
    • 功能:在服务调用失败或超时时,触发熔断机制,返回降级结果,防止雪崩效应。
    • 使用场景:保护系统稳定性,避免一个服务故障导致整个系统不可用。
    • 注意:Hystrix 已进入维护模式,目前我们项目中使用 Sentinel 替代。
  • 5. Zuul / Gateway(API 网关)
    • 功能:统一入口、路由转发、权限校验、限流、鉴权等。
    • 使用场景:所有外部请求都经过网关进入系统,进行统一的鉴权、限流、日志记录等操作。
    • 区别:Zuul 是 Netflix 的网关组件,性能较差;Spring Cloud Gateway 基于 WebFlux,性能更优,是目前主流选择。
  • 6. Config(配置中心)
    • 功能:集中管理微服务的配置文件,支持不同环境(dev、test、prod)的配置。
    • 使用场景:微服务启动时从 Config Server 获取配置,支持动态刷新,避免频繁修改配置文件。
  • 7. Sleuth + Zipkin(分布式链路追踪)
    • 功能:记录请求链路,分析服务调用耗时,定位性能瓶颈。
    • 使用场景:排查慢接口、分析调用链、查看服务依赖关系。

16. 反问问题

  1. 目前团队的技术栈是怎样的?
  2. 项目中是否使用了微服务?使用的是 Spring Cloud 还是 Dubbo?
  3. 这个岗位主要负责哪些模块?是业务开发、中间件维护,还是平台开发?
  4. 目前团队正在做的项目或产品是什么?主要的业务场景有哪些?