JUC

一、并发的第一性问题空间（Why 并发工具存在）

所有 Java 并发工具，本质上都在解决有限计算资源在多执行主体之间的分配与协调问题。

从第一性原理出发，并发系统只存在五类不可约的问题：

1. 互斥（Mutual Exclusion）

2. 可见性（Visibility）

3. 协调（Coordination）

4. 资源限流（Throttling）

5. 上下文隔离与传播（Context Management）

所有 JUC 工具，都可以被映射回上述问题之一或组合。

二、Java 并发的总体架构分层（How Java 解决并发）

并发问题空间   ↓并发抽象模型（锁 / 同步器 / 限流器 / 上下文）   ↓并发框架（AQS）   ↓具体工具类（ReentrantLock / Semaphore / CountDownLatch ...）

这一分层体现了 稳定性递增原则：

三、AQS：Java 并发的“内核抽象”

3.1 AQS 的设计哲学

AQS（AbstractQueuedSynchronizer）并不是“锁”，而是：

竞争失败线程的统一管理框架

它抽象了并发控制中最稳定的三件事：

  1. **资源状态（state）**：资源是否可用
  2. **等待队列（FIFO）**：竞争失败者排队
  3. **阻塞 / 唤醒机制**：最小化 CPU 空转

3.2 AQS 的核心模型

state（int）        → 资源状态机同步队列（CLH变体） → 管理竞争失败线程条件队列           → 管理协作型等待

AQS 通过模板方法模式，将策略交给子类：

而将调度、排队、阻塞统一托管。

四、互斥问题：ReentrantLock 与 synchronized

4.1 抽象模型

4.2 公平性：一种资源分配哲学

策略价值取向代价
公平锁顺序正义吞吐下降
非公平锁系统效率局部饥饿

公平性不是技术问题，而是系统价值判断。

4.3 synchronized vs ReentrantLock

维度synchronizedReentrantLock
实现层JVMJDK
锁释放自动手动
公平性非公平可配置
中断不支持支持

工程哲学：

能用 synchronized，就不要用 Lock。

五、读写分离：ReentrantReadWriteLock 与 StampedLock

5.1 读写锁的核心矛盾

5.2 ReentrantReadWriteLock

5.3 StampedLock：乐观并发的引入

这是从“锁竞争”向“冲突检测”的范式迁移。

六、协作而非竞争：同步器模型

6.1 CountDownLatch —— 一次性门闩

6.2 CyclicBarrier —— 阶段性对齐

6.3 两者的本质区别

维度CountDownLatchCyclicBarrier
关注点完成对齐
是否可复用否是
思维模型门闩栅栏

七、资源限流：Semaphore

7.1 抽象模型

7.2 工程意义

八、线程间数据交换与通信

8.1 Exchanger

8.2 LockSupport

九、上下文管理：ThreadLocal 及其演进

9.1 ThreadLocal 的本质

9.2 核心风险

9.3 InheritableThreadLocal 的局限

9.4 TransmittableThreadLocal（TTL）

十、工具选型的稳定方法论

并发问题首选工具原因
简单互斥synchronized简单、安全
高并发互斥ReentrantLock可控策略
读多写少StampedLock乐观并发
任务协作CountDownLatch一次性同步
阶段并行CyclicBarrier可复用
资源保护Semaphore配额控制
上下文传递TTL线程池友好

关联内容（自动生成）