Java线程协作方法与实例解析

Java线程协作的本质在于精准控制“谁该等、等什么、谁来通知”，而非单纯追求执行速度；本文系统解析了synchronized+wait/notify、Lock+Condition、CountDownLatch、CyclicBarrier、Semaphore和BlockingQueue六大核心机制，结合生产者-消费者、多任务同步启动等典型场景，深入剖析各方案的适用边界与关键陷阱——如wait必须置于while循环防虚假唤醒、notifyAll优于notify、Condition支持多条件独立等待、CountDownLatch不可重用、BlockingQueue如何将协调逻辑内化为阻塞式API；无论你是想快速落地高可靠协作逻辑，还是深入理解底层唤醒原理，这篇文章都为你划清了选型红线与实践雷区。

Java中线程协调的核心是让多个线程按预期顺序执行、共享资源时不冲突、等待特定条件满足后再继续——关键不在于“谁跑得快”，而在于“谁该等、等什么、谁来通知”。常用方式有 synchronized + wait/notify、Lock + Condition、CountDownLatch、CyclicBarrier、Semaphore 和 BlockingQueue 等，选哪种取决于协作场景。

用 wait/notify 实现简单生产者-消费者

适合一对一或简单条件等待。必须在 synchronized 块中调用，且 wait 会释放锁，notify 不释放锁。

• wait() 让当前线程进入等待队列，直到被 notify 或 notifyAll 唤醒
• notify() 随机唤醒一个等待线程；notifyAll() 唤醒所有——**推荐用 notifyAll，避免虚假唤醒导致死锁**
• wait 必须写在 while 循环里判断条件，不能用 if（防止被意外唤醒后条件仍不成立）

示例：缓冲区容量为 1 的队列

用 ReentrantLock + Condition 精确控制等待队列

比 wait/notify 更灵活，支持多个独立条件变量，适合多角色协作（如生产者/消费者/监控线程各自等待不同条件）。

• Lock 替代 synchronized，Condition 代替 wait/notify
• 每个 Condition 对应一个等待队列，可分别 signal 而不互相干扰
• 必须显式 lock()/unlock()，建议用 try-finally 保证解锁

示例：区分“缓冲区满”和“缓冲区空”两个条件

用 CountDownLatch 做一次性“齐步走”

适用于：一个线程等待 N 个其他线程全部完成后再执行（比如主线程等所有子任务结束）。

• 构造时指定计数，countDown() 减一，await() 阻塞直到计数归零
• 计数为 0 后，所有 await 线程立即唤醒，且之后再 await 也不会阻塞——**不可重用**
• 常用于启动阶段的初始化同步、测试中模拟并发起点

示例：主线程等 3 个下载任务都完成后统一处理

用 BlockingQueue 实现天然线程安全的协作管道

最实用的高阶协作方式，把“协调逻辑”封装进队列本身，开发者只关注生产和消费逻辑。

• ArrayBlockingQueue（有界）、LinkedBlockingQueue（可选界）、SynchronousQueue（无缓冲，直接交接）等都线程安全
• put() 在满时阻塞，take() 在空时阻塞——无需手动 wait/notify
• 适合典型生产者-消费者模型，代码简洁、不易出错

示例：使用 LinkedBlockingQueue 构建消息通道

基本上就这些。实际开发中，优先考虑 BlockingQueue 或 CountDownLatch 这类语义明确、不易误用的工具；只有需要精细控制唤醒逻辑时，才上 Condition；传统 wait/notify 仅建议用于学习原理或极简场景。不复杂但容易忽略细节——比如忘了循环检查条件、没配对加锁解锁、或误用 notify 导致部分线程永远等下去。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java线程协作方法与实例解析》文章吧，也可关注golang学习网公众号了解相关技术文章。