本人最近面的被问的比较多的java八股

先完成再完美

1.如何设计一个扣减库存或者说秒杀抢券系统

2.最近问这个问的比较多

多线程->线程池->并发安全->场景

2.锁->synconiezed,retranlock->可重入吗->怎么实现的

2.1读写锁 怎么实现的；AQS底层；分布式锁用于什么场景

2.2redis怎么自己去设计一个分布式锁（某讯今天面试题目）

2.3多线程并发的线程安全问题：

2.3.1比如多线程去计数i++；

2.3.2两个线程同时对arrayList进行一个add操作，这个时候会出现什么情况

2.3.3这里就会出现像扣减库存或者对立的一个对数据一致性要求高的或者低的场景

->悲观锁

2.4怎么去保证线程安全

🔒 锁机制的深度考察

锁是并发编程的核心，面试官会从多个维度考察你对锁的理解。

1. synchronized 的演进与锁升级

面试官不仅会问 synchronized 的用法，更会关注其底层原理和优化。

• 锁升级过程：JDK 1.6 之后，synchronized 进行了大量优化，引入了偏向锁、轻量级锁和重量级锁的概念。你需要清晰描述从偏向锁到轻量级锁，再到重量级锁的升级过程。
  • 偏向锁：线程首次获取锁时，会将锁对象的标记偏向该线程，后续再次获取锁时无需进行任何同步操作。
  • 轻量级锁：当有第二个线程尝试获取已被偏向的锁时，偏向锁就会升级为轻量级锁。此时线程会通过 CAS 自旋的方式尝试获取锁，避免了线程阻塞。
  • 重量级锁：当轻量级锁的竞争加剧（例如 CAS 多次失败），锁会升级为重量级锁，未获取到锁的线程会被阻塞，进入等待队列。
• 常见误区：很多人认为只有在多线程激烈竞争时才会升级，但实际上，只要有另一个线程尝试获取锁，偏向锁就会升级。

2. ReentrantLock 与 AQS

ReentrantLock 是 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 的缺点：
  1. ABA 问题：一个值从 A 变成 B，又变回 A，CAS 会认为它没有变化。可以通过 AtomicStampedReference（带版本号的引用）来解决。
  2. 循环时间长开销大：如果 CAS 长时间不成功，会一直自旋，给 CPU 带来很大开销。

🛠️ 并发工具与场景题

面试官会结合具体场景，考察你如何选择和使用并发工具。

1. 线程池

线程池是管理线程、复用资源的核心工具。

• 核心参数：必须熟练掌握 ThreadPoolExecutor 的 7 个核心参数（核心线程数、最大线程数、空闲线程存活时间、时间单位、工作队列、线程工厂、拒绝策略）及其作用。
• 工作流程：理解任务提交后，线程池是如何根据当前线程数和队列状态来决定是创建新线程、放入队列还是执行拒绝策略的。

2. 并发容器

• ConcurrentHashMap：面试官会问它如何保证线程安全。你需要了解它在 JDK 1.7（分段锁）和 1.8（synchronized + CAS + 红黑树）中实现方式的演变。
• ThreadLocal：考察其原理（每个线程维护一个 ThreadLocalMap）以及可能导致的内存泄漏问题（弱引用 Entry 的 key，但 value 是强引用，需要手动 remove）。

3. 常见并发问题

• 死锁：能够说出死锁产生的四个必要条件（互斥、请求与保持、不可剥夺、循环等待），并给出解决方案，如统一加锁顺序、使用 tryLock() 设置超时等。
• 线程饥饿：低优先级线程因为高优先级线程长期占用 CPU 而无法执行。使用公平锁是避免饥饿的一种方式。

🚀 高并发场景与 JVM 优化

当面试进入高级阶段，会涉及到系统层面的设计。

1. 高并发场景设计

面试官可能会抛出一些经典的系统设计题，考察你的综合能力。

• 秒杀系统：如何应对瞬时高并发？核心思路包括：
  1. 前端：静态资源 CDN 缓存、按钮置灰、限流。
  2. 网关层：使用 Sentinel 等工具进行熔断降级。
  3. 服务层：Redis 预减库存（使用 Lua 脚本保证原子性）、消息队列（如 Kafka）异步下单削峰。
• 缓存问题：如何处理缓存穿透、击穿、雪崩？
  • 穿透（查询不存在的数据）：使用布隆过滤器 + 空值缓存。
  • 击穿（热点 Key 失效）：使用互斥锁（如 Redisson）。
  • 雪崩（大量 Key 同时过期）：设置随机过期时间 + 多级缓存。

2. JVM 层面的锁优化

JVM 会在运行时对锁进行优化，以减少性能开销。

• 锁消除：JVM 在即时编译时，如果发现某些锁对象不可能被其他线程访问到（即不存在共享），就会将这些锁操作直接消除。例如，方法内部的 StringBuffer 操作。
• 锁粗化：JVM 会探测到一连串对同一对象的加锁和解锁操作，并将它们合并为一次加锁和解锁操作，减少锁的获取和释放次数。

📈 2025+ 新趋势

随着技术发展，一些新的并发特性也成为面试考点。

• 虚拟线程 (Virtual Threads)：作为 Java 21 的重要特性，虚拟线程（也称协程）旨在以极低的开销创建海量线程，非常适合 I/O 密集型的高并发应用。理解它与平台线程（传统线程）的区别是未来的加分项。
• 响应式编程：通过异步和非阻塞的方式处理数据流，也是应对高并发场景的一种重要范式。

显式锁和隐式锁的概念

1.lock是个类，还是接口，还是api，api和接口一样吗

• Lock：interface（语法接口）
• ReentrantLock：class（实现类）
• 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）。

执行过程：

1. 当后台服务消费消息时，首先尝试向数据库插入一条记录（或者更新库存）。
2. 这条记录包含了刚才生成的“唯一标识”。
3. 第一次执行：数据库中没有这个 ID，插入成功，库存扣减。
4. 重复执行：如果消息重复到达，服务再次尝试插入。此时数据库检测到唯一索引冲突（Duplicate Key），会抛出异常。
5. 结果：服务捕获到这个异常，认为这是重复请求，直接返回成功（因为第一次已经处理过了），不再执行扣减逻辑。

优点：利用数据库的原子性，绝对可靠，不会出现超扣。
缺点：会有一次数据库的写入冲突开销（虽然很小）。

方案二：Redis 标记位（高性能，防重）

利用 Redis 的原子性来拦截重复请求。

原理：
利用 Redis 的 SETNX（SET if Not eXists）命令。这个命令是原子性的：只有当 key 不存在时才设置成功；如果 key 已存在，则设置失败。

执行过程：

1. 消费者拿到消息，提取“唯一标识”。
2. 尝试执行 SETNX deduplication:unique_id 1。
3. 第一次执行：Redis 中没有这个 key，设置成功。服务继续执行扣减库存逻辑。
4. 重复执行：如果消息重复，SETNX 返回 0（设置失败），说明这个请求已经处理过了。
5. 结果：服务直接返回成功，不再执行后续的数据库操作。

优点：速度快，不用写数据库就能拦截。
缺点：需要考虑 Redis 本身的可用性（虽然概率极低），且需要设置合理的过期时间（防止 Redis 中堆积太多垃圾 key）。