在构建高并发、低延迟的分布式系统时，Java 并发编程是核心中的核心。从线程的生命周期管理到锁的底层优化，再到线程池的精细调优，每一个环节都直接关系到系统的吞吐量（TPS）和稳定性。

在构建高并发、低延迟的分布式系统时，Java 并发编程是核心中的核心。从线程的生命周期管理到锁的底层优化，再到线程池的精细调优，每一个环节都直接关系到系统的吞吐量（TPS）和稳定性。

以下结合具体业务场景，深度解析这些机制的内部原理与设计哲学。

---

一、线程生命周期：状态的流转与资源调度

1. 核心状态解析

• NEW: 创建但未启动 (start() 未调用)。
• RUNNABLE: 正在运行或等待 CPU 时间片（注意：在 Java 中，阻塞于 IO 或锁的状态不属于 RUNNABLE）。
• BLOCKED: 等待获取 synchronized 对象锁（进入同步块/方法时锁被占用）。
• WAITING: 无限期等待其他线程动作（Object.wait(), Thread.join(), LockSupport.park()）。
• TIMED_WAITING: 限期等待（Thread.sleep(ms), Object.wait(ms)）。
• TERMINATED: 执行结束或异常退出。

2. 业务场景实战

场景 A：电商大促期间的“订单处理积压”

• 现象：监控显示大量订单处理线程处于 BLOCKED 状态，系统吞吐量骤降。
• 深度分析：
  • 代码中存在粗粒度的 synchronized 锁（如锁住了整个“库存扣减”方法，而不是具体的 SKU 对象）。
  • 当高并发请求涌入，99% 的线程在争抢同一把锁，导致它们从 RUNNABLE 变为 BLOCKED。
  • CPU 空闲（因为线程都在等锁），但业务停滞。
• 解决方案：
  • 缩小锁粒度：改为锁具体的商品 ID (synchronized (skuId)).
  • 升级锁机制：使用 ReentrantLock 配合 tryLock(timeout)，避免无限期阻塞，快速失败并降级。
  • 无锁化：对于简单计数，使用 LongAdder 或 CAS 操作。

---

二、通信机制与锁升级：从偏向锁到重量级锁

1. 核心机制演进

• volatile:
  • 作用：保证可见性（修改后立即刷新到主存）和禁止指令重排（通过内存屏障）。
  • 局限：不保证原子性（如 i++ 仍不安全）。
• synchronized (JVM 内置锁):
  • 锁升级过程（为了减少获取锁的开销）：
    1. 偏向锁 (Biased Locking): 假设只有一个线程访问。记录线程 ID 到对象头。无竞争，零开销。
    2. 轻量级锁 (Lightweight Locking): 出现轻微竞争。线程自旋（Spin Lock），不挂起，尝试 CAS 获取锁。
    3. 重量级锁 (Heavyweight Locking): 竞争激烈或自旋超时。膨胀为对象监视器（Monitor），线程阻塞挂起，依赖操作系统互斥量，开销大。
• Lock (显式锁):
  • ReentrantLock: 基于 AQS。支持公平/非公平锁，可中断，支持多条件变量 (Condition)。

2. 业务场景实战

场景 B：高频计数器（如文章阅读量、点赞数）

• 需求：每秒数万次递增，读多写少（或写多但逻辑简单）。
• 选型对比：
  • synchronized: 即使有锁升级，在高并发写场景下，最终会膨胀为重量级锁，导致线程频繁上下文切换，性能瓶颈明显。
  • volatile: 无法解决 count++ 的原子性问题，数据会丢失。
  • AtomicLong: 基于 CAS。但在极高并发下，CAS 失败率高，线程会不断自旋重试，消耗大量 CPU（“忙等”）。
  • 最佳方案: LongAdder。
    • 原理：分段累加。内部维护一个 Cell 数组，不同线程哈希到不同的 Cell 上进行累加，最后求和。
    • 优势：将热点分散，极大降低 CAS 冲突，吞吐量远超 AtomicLong。
• 价值：在“双 11”实时大屏场景中，LongAdder 能支撑百万级 QPS 的计数更新而不成为瓶颈。

场景 C：银行转账系统的“死锁避免”

• 问题：线程 A 锁住账户 1 想转给账户 2；线程 B 锁住账户 2 想转给账户 1。互相等待，形成死锁。
• synchronized 的局限：一旦死锁，只能重启或手动干预（jstack 分析）。
• ReentrantLock 的优势：
  • 使用 tryLock(time, unit)。如果在规定时间内没拿到锁，主动放弃，释放已持有的锁，稍后重试。
  • 设计哲学：“带超时的礼貌”。避免无限期僵持，提高系统的自愈能力。

---

三、AQS (AbstractQueuedSynchronizer)：并发包的基石

1. 核心原理

• 双组件：
  1. state (volatile int): 同步状态。例如：锁的重入次数、信号量的剩余 permits、倒计时器的剩余 count。
  2. FIFO 等待队列 (CLH 变体): 存储因获取资源失败而阻塞的线程。
• 工作流程：
  • 线程尝试 CAS 修改 state。
  • 成功 -> 获取资源，执行逻辑。
  • 失败 -> 封装成 Node 加入队列尾部，调用 LockSupport.park() 挂起。
  • 前驱节点释放资源 -> 唤醒后继节点 (unpark)。

2. 业务场景实战

场景 D：微服务启动时的“依赖就绪检查”

• 需求：主服务启动时，必须等待 3 个下游配置服务（Config, Registry, DB）全部初始化完成后，才能开始接收流量。
• 工具：CountDownLatch (基于 AQS)。
  • 实现：初始化 new CountDownLatch(3)。
  • 三个下游服务初始化完毕，分别调用 countDown() (AQS 中 CAS state--)。
  • 主线程调用 await() (若 state > 0 则进入 AQS 队列阻塞)。
  • 当 state 变为 0，AQS 唤醒主线程，系统正式对外服务。
• 价值：避免了复杂的 wait/notify 手写逻辑，利用 AQS 的标准模板安全地协调多线程协作。

场景 E：数据库连接池的“限流保护”

• 需求：数据库最大允许 50 个并发连接，防止被打挂。
• 工具：Semaphore (基于 AQS)。
  • 实现：new Semaphore(50)。
  • 业务线程获取连接前 semaphore.acquire() (AQS state--，若 <0 则排队)。
  • 使用完归还 semaphore.release() (AQS state++，唤醒排队者)。
• 价值：在系统过载时，通过 AQS 队列平滑缓冲请求，而非直接抛出异常或拖垮数据库。

---

四、CAS 与原子类：无锁并发的双刃剑

1. 核心机制

• CAS (Compare-And-Swap): 硬件指令（如 x86 的 CMPXCHG）。比较内存值与预期值，相同则更新，否则失败。
• ABA 问题:
  • 现象：线程 1 读取 A，线程 2 将 A->B->A，线程 1 CAS 成功。看似没变，实则中间发生过变化（可能导致链表节点复用错误）。
  • 解决：版本号机制。AtomicStampedReference 在比较值的同时比较版本戳。

2. 业务场景实战

场景 F：高性能缓存框架的“无锁更新”

• 背景：本地缓存（如 Caffeine/Guava）需要高频更新元数据。
• 策略：大量使用 Unsafe 类的 CAS 操作更新指针。
• 风险：若逻辑复杂（如需同时更新多个变量），单纯 CAS 难以保证一致性，需退化为锁或采用不可变对象（Copy-On-Write 思想）。

---

五、并发容器：特定场景的最优解

1. 核心选型

• CopyOnWriteArrayList:
  • 原理：写时复制。写操作加锁，复制新数组，修改后替换引用；读操作无锁。
  • 适用：读多写极少（如配置列表、白名单）。
  • 禁忌：写频繁场景（会导致频繁 GC 和数据不一致窗口）。
• BlockingQueue (ArrayBlockingQueue, LinkedBlockingQueue):
  • 原理：生产者 - 消费者模型。队列满时生产者阻塞，队列空时消费者阻塞。
  • 适用：任务缓冲、流量削峰。

2. 业务场景实战

场景 G：日志采集系统的“异步写入”

• 需求：业务线程产生日志，不能阻塞业务逻辑；后台线程负责刷盘。
• 实现：使用 ArrayBlockingQueue。
  • 业务线程 queue.put(log)。若队列满（磁盘慢），业务线程阻塞（背压机制，防止内存溢出）。
  • 后台线程 queue.take() 批量写入磁盘。
• 价值：解耦生产与消费，利用 BlockingQueue 的内建锁和条件变量高效协调，避免手动 wait/notify 的陷阱。

---

六、线程池 (ThreadPoolExecutor)：资源的守门人

1. 七大参数与工作流

• 参数：
  1. corePoolSize: 核心线程数（常驻）。
  2. maximumPoolSize: 最大线程数。
  3. keepAliveTime: 非核心线程空闲存活时间。
  4. unit: 时间单位。
  5. workQueue: 任务队列（关键！）。
  6. threadFactory: 线程命名工厂（便于排查）。
  7. handler: 拒绝策略（Abort, CallerRuns, Discard, DiscardOldest）。
• 工作流程：
  1. 提交任务 -> 若 < corePoolSize，创建核心线程执行。
  2. 若 >= corePoolSize，放入 workQueue。
  3. 若队列满 且 < maximumPoolSize，创建非核心线程执行。
  4. 若队列满 且 >= maximumPoolSize，触发拒绝策略。

2. 业务场景实战与调优

场景 H：CPU 密集型 vs IO 密集型

• 场景 1：图像压缩/加密服务 (CPU 密集型)

  • 特点：计算量大，几乎无 IO 等待。
  • 配置：corePoolSize = CPU 核数 + 1。
  • 理由：线程过多会导致频繁的上下文切换，降低 CPU 效率。+1 是为了防止某个线程偶尔缺页中断时 CPU 闲置。
  • 队列：建议使用有界队列（防止 OOM），拒绝策略可选 CallerRuns（让调用者自己跑，起到限流作用）。

• 场景 2：爬虫/HTTP 请求转发 (IO 密集型)

  • 特点：大部分时间在等待网络响应，CPU 利用率低。
  • 配置：corePoolSize = CPU 核数 * 2 甚至更多（如 50-200，视具体 IO 耗时而定）。
  • 理由：需要更多线程来填补 IO 等待期间的 CPU 空窗期，保持 CPU 满载。
  • 队列：根据内存限制设置合理大小。

场景 I：核心交易链路的“防雪崩”

• 背景：支付接口突发流量洪峰。
• 错误配置：使用 Executors.newFixedThreadPool() (默认无界队列)。
  • 后果：请求堆积，队列无限增长，最终 OutOfMemoryError，整个 JVM 崩溃。
• 正确配置：
  • 自定义线程池：明确指定 core, max, 有界队列 (如 ArrayBlockingQueue(1000))。
  • 拒绝策略：ThreadPoolExecutor.CallerRunsPolicy。
    • 效果：当系统过载时，新任务由主线程（Tomcat 线程）直接执行。这会减慢主线程处理其他请求的速度，从而自然地将压力反传给上游（网关或用户），实现背压 (Backpressure)，保护后端数据库不被压垮。
  • 监控：集成 Micrometer/Prometheus，实时监控 ActiveCount, QueueSize, RejectCount。

---

七、总结与架构师决策表

组件	核心机制	适用场景	避坑指南
锁	synchronized (JVM 升级)ReentrantLock (AQS)	一般同步用 syn；需超时/公平/条件变量用 Lock。	避免在循环内加锁；避免锁粒度过大；警惕死锁。
原子类	CAS / LongAdder (分段)	计数器、状态标志。	高并发写慎用 AtomicLong (自旋耗 CPU)，改用 LongAdder。
并发容器	COW (读写分离)BlockingQueue (生产消费)	配置列表用 COW；任务缓冲用 BlockingQueue。	COW 不适合写频繁场景；BlockingQueue 需注意容量限制防 OOM。
线程池	核心->队列->最大->拒绝	所有异步任务、IO/CPU 密集型任务。	严禁使用 Executors 默认创建（隐患大）；必须自定义参数；必须配置有界队列和合理的拒绝策略。
AQS	State + FIFO 队列	自定义同步器、Latch、Semaphore。	理解其模板方法模式，不要重复造轮子。

终极建议：
并发编程的本质是资源竞争的管理。

1. 能无锁则无锁（不可变对象、线程封闭、LongAdder）。
2. 必须加锁则细粒度（锁具体的资源，而非全局）。
3. 异步则隔离（使用线程池隔离不同业务，防止一个模块拖垮整体）。
4. 兜底则限流（通过有界队列和拒绝策略，确保系统在极端压力下“有损服务”而非“彻底崩溃”）。

深入理解这些机制，能让你在面对“线上 CPU 100%”、“线程死锁”、“内存溢出”等棘手问题时，迅速定位根源并给出优雅的解决方案。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/qq_33240556/article/details/159507061