本人最近面的被问的比较多的java八股先完成再完美1.如何设计一个扣减库存或者说秒杀抢券系统2.最近问这个问的比较多多线程-线程池-并发安全-场景2.锁-synconiezed,retranlock-可重入吗-怎么实现的2.1读写锁 怎么实现的AQS底层分布式锁用于什么场景2.2redis怎么自己去设计一个分布式锁某讯今天面试题目2.3多线程并发的线程安全问题2.3.1比如多线程去计数i2.3.2两个线程同时对arrayList进行一个add操作这个时候会出现什么情况2.3.3这里就会出现像扣减库存或者对立的一个对数据一致性要求高的或者低的场景-悲观锁2.4怎么去保证线程安全 锁机制的深度考察锁是并发编程的核心面试官会从多个维度考察你对锁的理解。1.synchronized的演进与锁升级面试官不仅会问synchronized的用法更会关注其底层原理和优化。锁升级过程JDK 1.6 之后synchronized进行了大量优化引入了偏向锁、轻量级锁和重量级锁的概念。你需要清晰描述从偏向锁到轻量级锁再到重量级锁的升级过程。偏向锁线程首次获取锁时会将锁对象的标记偏向该线程后续再次获取锁时无需进行任何同步操作。轻量级锁当有第二个线程尝试获取已被偏向的锁时偏向锁就会升级为轻量级锁。此时线程会通过 CAS 自旋的方式尝试获取锁避免了线程阻塞。重量级锁当轻量级锁的竞争加剧例如 CAS 多次失败锁会升级为重量级锁未获取到锁的线程会被阻塞进入等待队列。常见误区很多人认为只有在多线程激烈竞争时才会升级但实际上只要有另一个线程尝试获取锁偏向锁就会升级。2.ReentrantLock与 AQSReentrantLock是synchronized之外最常用的显式锁其核心是 AQS (AbstractQueuedSynchronizer)。AQS 原理AQS 是 Java 并发包的基石ReentrantLock、CountDownLatch、Semaphore等都是基于它实现的。它的核心是一个state状态变量和一个 FIFO 线程等待队列。你需要理解 AQS 如何通过 CAS 操作来修改state以及线程如何在获取锁失败后进入等待队列。公平锁 vs 非公平锁ReentrantLock可以指定为公平锁或非公平锁默认。性能差异非公平锁性能通常优于公平锁因为它允许新来的线程“插队”减少了线程唤醒和上下文切换的开销。公平锁则严格按照请求顺序分配锁避免了线程饥饿但性能开销更大。应用场景在对锁获取顺序有严格要求的场景下如银行交易系统应选择公平锁。3. 读写锁与StampedLock针对读多写少的场景面试官会考察你对读写锁的理解。ReadWriteLock的写锁饥饿问题标准的读写锁如ReentrantReadWriteLock遵循“读读共享读写互斥写写互斥”的原则。但在读操作非常频繁时写线程可能因为一直有读线程获取锁而无法执行导致“写锁饥饿”。StampedLock的引入为了解决ReadWriteLock的饥饿问题Java 8 引入了StampedLock。它提供了三种模式写锁、读锁和乐观读。乐观读是一种非阻塞的读操作性能极高但需要配合validate()方法检查在读期间数据是否被修改如果被修改则需要升级为读锁重新读取。 并发基石CAS 与原子类无锁并发是高性能并发的关键CAS 是其核心思想。CAS 原理CAS (Compare-And-Swap) 是一种硬件级别的原子指令。它的操作逻辑是比较内存中的值与期望值如果相等则更新为新值否则不操作。这个过程是原子的由 CPU 指令保证。原子类实现AtomicInteger、AtomicLong等原子类就是通过 CAS volatile实现的。它们在不使用重量级锁的情况下保证了线程安全在低竞争场景下性能非常高。CAS 的缺点ABA 问题一个值从 A 变成 B又变回 ACAS 会认为它没有变化。可以通过AtomicStampedReference带版本号的引用来解决。循环时间长开销大如果 CAS 长时间不成功会一直自旋给 CPU 带来很大开销。️ 并发工具与场景题面试官会结合具体场景考察你如何选择和使用并发工具。1. 线程池线程池是管理线程、复用资源的核心工具。核心参数必须熟练掌握ThreadPoolExecutor的 7 个核心参数核心线程数、最大线程数、空闲线程存活时间、时间单位、工作队列、线程工厂、拒绝策略及其作用。工作流程理解任务提交后线程池是如何根据当前线程数和队列状态来决定是创建新线程、放入队列还是执行拒绝策略的。2. 并发容器ConcurrentHashMap面试官会问它如何保证线程安全。你需要了解它在 JDK 1.7分段锁和 1.8synchronized CAS 红黑树中实现方式的演变。ThreadLocal考察其原理每个线程维护一个ThreadLocalMap以及可能导致的内存泄漏问题弱引用 Entry 的 key但 value 是强引用需要手动remove。3. 常见并发问题死锁能够说出死锁产生的四个必要条件互斥、请求与保持、不可剥夺、循环等待并给出解决方案如统一加锁顺序、使用tryLock()设置超时等。线程饥饿低优先级线程因为高优先级线程长期占用 CPU 而无法执行。使用公平锁是避免饥饿的一种方式。 高并发场景与 JVM 优化当面试进入高级阶段会涉及到系统层面的设计。1. 高并发场景设计面试官可能会抛出一些经典的系统设计题考察你的综合能力。秒杀系统如何应对瞬时高并发核心思路包括前端静态资源 CDN 缓存、按钮置灰、限流。网关层使用 Sentinel 等工具进行熔断降级。服务层Redis 预减库存使用 Lua 脚本保证原子性、消息队列如 Kafka异步下单削峰。缓存问题如何处理缓存穿透、击穿、雪崩穿透查询不存在的数据使用布隆过滤器 空值缓存。击穿热点 Key 失效使用互斥锁如 Redisson。雪崩大量 Key 同时过期设置随机过期时间 多级缓存。2. JVM 层面的锁优化JVM 会在运行时对锁进行优化以减少性能开销。锁消除JVM 在即时编译时如果发现某些锁对象不可能被其他线程访问到即不存在共享就会将这些锁操作直接消除。例如方法内部的StringBuffer操作。锁粗化JVM 会探测到一连串对同一对象的加锁和解锁操作并将它们合并为一次加锁和解锁操作减少锁的获取和释放次数。 2025 新趋势随着技术发展一些新的并发特性也成为面试考点。虚拟线程 (Virtual Threads)作为 Java 21 的重要特性虚拟线程也称协程旨在以极低的开销创建海量线程非常适合 I/O 密集型的高并发应用。理解它与平台线程传统线程的区别是未来的加分项。响应式编程通过异步和非阻塞的方式处理数据流也是应对高并发场景的一种重要范式。显式锁和隐式锁的概念1.lock是个类还是接口还是apiapi和接口一样吗Lockinterface语法接口ReentrantLockclass实现类lock() / unlock() / tryLock()API方法调用入口所以Lock 是 interface同时它也是 JUC 提供的一套锁 API。我们常说 “Lock API”指的是以 Lock 接口为核心的整套锁机制。2.Lock和它的一些实现类1.ReentrantLock最常用、独占可重入锁独占锁、可重入支持公平 / 非公平底层AQS用途替代 synchronized更灵活2.ReentrantReadWriteLock.ReadLock读锁共享锁共享锁多线程可同时加读锁底层AQS共享模式3.ReentrantReadWriteLock.WriteLock写锁独占锁独占锁写的时候完全互斥底层AQS独占模式3.AQS -Sync -实现类(四个) -Lock接口面向接口编程规范如何防止超卖在图片描述的秒杀流程中“通过唯一标识防止重复消费”是确保数据一致性的关键一环其核心思想就是幂等性Idempotence。简单来说幂等性就是同一个操作无论执行多少次产生的结果都是一样的。在秒杀场景中这意味着无论这条“扣减库存”的消息被消费多少次哪怕因为网络抖动、服务重启导致重复消费最终数据库里的库存只会被扣减一次。为了实现这一点通常有两种主流的技术方案它们都依赖于“唯一标识”唯一标识的构成首先你需要生成一个全局唯一的 ID 作为标识。这个 ID 通常由业务关键字段拼接而成例如用户ID_商品ID_订单号业务类型_时间戳_随机数这个唯一标识会随着消息一起传递。方案一数据库唯一索引推荐强一致性这是最简单、最可靠的方法。原理在数据库的订单表或库存流水表中添加一个字段例如order_no或deduction_id并为这个字段建立唯一索引Unique Key。执行过程当后台服务消费消息时首先尝试向数据库插入一条记录或者更新库存。这条记录包含了刚才生成的“唯一标识”。第一次执行数据库中没有这个 ID插入成功库存扣减。重复执行如果消息重复到达服务再次尝试插入。此时数据库检测到唯一索引冲突Duplicate Key会抛出异常。结果服务捕获到这个异常认为这是重复请求直接返回成功因为第一次已经处理过了不再执行扣减逻辑。优点利用数据库的原子性绝对可靠不会出现超扣。缺点会有一次数据库的写入冲突开销虽然很小。方案二Redis 标记位高性能防重利用 Redis 的原子性来拦截重复请求。原理利用 Redis 的SETNXSET if Not eXists命令。这个命令是原子性的只有当 key 不存在时才设置成功如果 key 已存在则设置失败。执行过程消费者拿到消息提取“唯一标识”。尝试执行SETNX deduplication:unique_id 1。第一次执行Redis 中没有这个 key设置成功。服务继续执行扣减库存逻辑。重复执行如果消息重复SETNX返回 0设置失败说明这个请求已经处理过了。结果服务直接返回成功不再执行后续的数据库操作。优点速度快不用写数据库就能拦截。缺点需要考虑 Redis 本身的可用性虽然概率极低且需要设置合理的过期时间防止 Redis 中堆积太多垃圾 key。