互联网大厂 Java 面试:高并发秒杀系统技术问答复盘
在真实的互联网大厂面试中,候选人往往需要面对高并发场景的实战拷问。本文复盘了一场典型的 Java 后端面试,围绕电商平台的高并发秒杀系统设计展开,涵盖多线程安全、缓存与消息队列、微服务架构三大核心考点。
第一轮提问:基础知识与场景理解
面试官: 我们在设计一个电商平台的秒杀系统时,如何确保 Java 的多线程操作是线程安全的?
候选人:
通常会考虑使用 synchronized 或 ReentrantLock 来保护共享资源,通过锁机制控制并发访问。
面试官: 回答得不错。的确,这两者是常用的同步方式,但你能说说它们的区别吗?
候选人:
synchronized 是 Java 的关键字,自动管理加锁和解锁;而 ReentrantLock 是 JDK 提供的显式锁类,支持手动加锁和解锁,还能尝试获取锁。
面试官补充:
除了上述区别,还需关注性能表现、可重入性以及条件变量支持。在高竞争环境下,ReentrantLock 通常能提供更细粒度的控制。
第二轮提问:缓存与消息队列
面试官: 在秒杀场景中,我们需要用到缓存来提高查询效率,你觉得 Redis 能解决哪些问题?
候选人: Redis 读写速度快,适合做热点数据缓存,减轻数据库压力。另外,利用其原子性也可以实现分布式锁。
面试官: 对,Redis 确实能提升查询性能和实现分布式锁。那你知道如何设置 Redis 的过期策略吗?
候选人: 可以通过 TTL 命令设置生存时间,内存淘汰策略方面可以配置 LRU 算法等。
面试官补充: 是的,Redis 提供了多种过期策略,比如定期删除、惰性删除等。你提到的 LRU 属于内存淘汰策略的一种。再来一个问题,如果秒杀消息需要异步处理,你会选用哪个消息队列?
候选人: Kafka 吧,很多公司都在用,吞吐量高。
面试官补充: 选择 Kafka 确实是个不错的选择,但要注意消息堆积和消费者速度不匹配的问题,需根据业务特性权衡。
第三轮提问:分布式与微服务架构
面试官: 在高并发场景中,我们需要做负载均衡,你会如何设计?
候选人: 可以使用 Nginx 或者 F5 这样的硬件设备做反向代理和负载均衡。
面试官: 不错,那在微服务中,你会如何实现服务发现功能呢?
候选人: 以前常用 Spring Cloud 的 Eureka,不过听说它已经停止维护了,现在可能更多用 Consul 或者 Kubernetes 的内置服务发现。
面试官: 没错,Eureka 已停止维护,Consul 是一个不错的选择,另外还有 Kubernetes 的内置服务发现功能。今天就到这里吧,回去等通知。
核心知识点梳理
1. 多线程安全与锁机制
- synchronized:Java 关键字,修饰方法或代码块,JVM 层面自动管理锁,简单易用。
- ReentrantLock:JDK 显式锁,支持可重入,可手动加锁/解锁,支持公平锁、非公平锁及条件变量(Condition)。
- 对比:在高竞争环境下,
ReentrantLock性能通常更优,且灵活性更高(如尝试加锁、超时等待)。
2. Redis 应用场景与策略
- 缓存:加速数据访问,抗住读流量洪峰。
- 分布式锁:利用 Redis 原子操作(如 SETNX + Lua 脚本)实现跨进程锁。

