1. CountDownLatch 计数器作用让一个线程等待其他 N 个线程全部执行完，再继续运行。 一次性门栓，用完就废，不能重置。 核心原理 基于 AQS 共享模式 初始化传入 count 每次 countDown() → count -1 await() 会阻塞，直到 count = 0 典型场景 主线程等待多个子线程初始化完成 分布式接口：等待多个下游调用全部返回 代码示例1

一、死锁1. 死锁定义多个线程互相持有对方需要的锁，又都不释放自己的锁， 互相无限等待，程序彻底卡死、无法继续执行。 2. 死锁四个必要条件（缺一不可） 互斥条件 资源是独占的，同一时刻只能被一个线程持有。 请求与保持 线程已经持有一把锁，不释放旧锁，又去申请新锁。 不可剥夺 锁只能自己主动释放，不能被其他线程强行抢走。 循环等待 线程之间形成环路锁依赖：T1 等 T2 的锁，T2 等 T1

一、wait /notify/notifyAll 底层原理1. 核心前提 必须在synchronized 锁内部使用，否则直接抛 IllegalMonitorStateException 调用 wait() 会自动释放当前锁，进入对象的 WaitSet 等待池 被唤醒后不会立刻执行，需要重新竞争锁，抢到锁才会继续往下走 2. 方法作用 obj.wait() 当前线程进入无限等

Java 读写锁ReentrantReadWriteLock 读写锁核心特性 读写分离：分为读锁（共享锁）和写锁（独占锁） 互斥规则 读 + 读：不互斥，多个线程可以同时加读锁 读 + 写：互斥，读锁持有时写锁阻塞，写锁持有时读锁阻塞 写 + 写：互斥，完全独占 可重入：同一个线程可以重复获取锁 支持锁降级：写锁可以降级为读锁（先获取写锁 → 获取读锁 → 释放写锁） 致命缺点读多写少时，会

一、ReentrantLock 使用与 API核心使用流程： 手动加锁、手动解锁，必须在 finally 释放锁，避免死锁。 1234567ReentrantLock lock = new ReentrantLock();lock.lock(); // 加锁try { // 临界区业务} finally { lock.unlock(); /

AQS 核心原理AQS（AbstractQueuedSynchronizer） 是 Java 并发包的核心基石，ReentrantLock、CountDownLatch、Semaphore 等锁 / 同步工具底层都基于 AQS 实现。 它的核心设计：用一个 state 变量控制同步状态 + 一个 CLH 双向队列管理等待线程，通过 CAS 实现无锁竞争，高效实现线程阻塞 / 唤

1. park /unpark 工作机制 LockSupport.park() 阻塞当前线程，直到被 unpark 或线程中断。 LockSupport.unpark(Thread t) 给指定线程发放一个「许可」，让它从 park 中返回。 核心机制：许可机制（类似 0/1 信号量）LockSupport.park() 尝试拿走这张令牌 当前令牌 = 1：拿

1. CAS 原理：Compare And SwapCAS = 比较并交换，是一条CPU 原子指令（CMPXCHG），流程： 先比较：内存当前值 V == 预期旧值 A？ 若相等：把内存值 V 改为新值 B 若不等：说明被别人改过，本次失败，可重试 伪代码逻辑（原子执行）： 1234567boolean cas(V, A, B) { if (V =

一、线程安全基础：竞态条件 & 临界区1. 竞态条件（Race Condition）多个线程同时操作、修改同一个共享变量，执行结果依赖线程执行的先后顺序，最终导致结果错误。 根本原因：读 - 改 - 写三步不是原子操作。 典型例子：i++ 多线程下计数错误。 2. 临界区（Critical Section）会发生线程安全问题的代码块，就是临界区。 多个线程同时进入临界区 → 线程不安

Java 内存模型（JMM）Java 内存模型（JMM）是一套规范，用来屏蔽不同硬件和操作系统的内存访问差异，让 Java 程序在各种平台下都能实现一致的并发效果。它的核心目标是解决多线程下的原子性、可见性、有序性问题，定义了线程和主内存之间的抽象关系。 一、JMM 核心：三大特性JMM 围绕原子性、可见性、有序性三大特性设计，这是多线程并发安全的基础。 1. 原子性（Atomicity）定义：一