signalall会唤醒当前condition等待队列中所有调用过await()的线程，将其移入aqs同步队列竞争锁，但不保证执行顺序，且必须在持有对应reentrantlock前提下调用。
Condition 的 signalAll 会唤醒所有在该 Condition 上等待的线程，但不保证立即执行，它们需重新竞争锁后才能继续运行。
signalAll 唤醒的是“等待队列”里的线程
每个 Condition 对象内部维护一个独立的等待队列（FIFO），只有调用过 await() 进入该 Condition 等待状态的线程，才会被 signalAll() 唤醒。它不会影响其他 Condition 或 synchronized 中的 wait 线程。
- 线程调用
await()时，会释放当前持有的 Lock，并被加入该 Condition 的等待队列 -
signalAll()不释放锁，只是把等待队列里所有节点标记为“可唤醒”，并转移到同步队列（AQS 的 CLH 队列）中 - 被唤醒的线程不会立刻执行，而是和其他竞争者一起抢锁；只有成功获取锁后，
await()才返回，继续往下执行
必须在持有 lock 的前提下调用 signalAll
和 signal() 一样，signalAll() 是一个“条件操作”，必须在当前线程已获得关联 Lock 的前提下才能安全调用，否则抛出 IllegalMonitorStateException。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 正确写法：先
lock.lock()，再condition.signalAll()，最后lock.unlock() - 不能在 synchronized 块里调用 —— Condition 必须配合
ReentrantLock使用，与Object.wait/notify机制无关 - 即使等待队列为空，
signalAll()也不会报错，只是无效果
唤醒后线程的执行顺序不等于等待顺序
虽然等待队列是 FIFO，但 signalAll() 把所有线程移入同步队列后，谁先抢到锁取决于操作系统调度和 AQS 的争抢逻辑，不是严格的先唤醒先执行。
- 例如：三个线程 A、B、C 按序 await，signalAll 后可能 C 先获取锁并执行
- 若业务逻辑依赖严格顺序（如生产者-消费者中的批次处理），需额外加控制（比如用计数器或状态变量判断是否轮到自己）
- 避免假设唤醒顺序，应基于条件重检（即 await 通常写在 while 循环中）
和 signal 的关键区别
signalAll() 唤醒全部，signal() 只唤醒一个。选择哪个取决于业务语义：
- 用
signal()：当只有一个线程能推进状态（如缓冲区新增一个元素，只需唤醒一个消费者） - 用
signalAll()：当状态变化影响所有等待者（如关闭开关、重置条件、广播通知） - 注意：过度使用 signalAll 可能引发“惊群效应”，多个线程争锁失败又阻塞，降低吞吐量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
