互联网大厂 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 脚本）实现跨进程锁。
