通知单个线程：notify、notifyAll 还是 concurrent.locks.Condition？答案

【问题标题】：Notifying a single thread: notify, notifyAll or concurrent.locks.Condition?通知单个线程：notify、notifyAll 还是 concurrent.locks.Condition？
【发布时间】：2012-08-18 20:51:16
【问题描述】：

我有时需要唤醒或发送一个单个线程，我想知道什么是最好和最有效的方法。

第一个解决方案是信号结合wait-notify（我知道如何正确实现这种模式，这不是问题）。

我在某处读到，使用 java.concurrent 库和CountDownLatch 进行信号发送更有效。我也检查了concurrent.locks.Condition，但this 主题指出它只是（程序员方面）更安全和通用的构造，与notify/notifyAll 相比没有性能优势。 Peter Lawrey 建议在 this 评论中使用 Concurrency 库而不是 notify-notifyAll，所以现在我很困惑什么是最佳实践。

一个相关问题：在我的情况下，notify 或 notifyAll 哪个性能更好（即，如果我有一个线程）？我知道有很多类似的主题，但没有一个给出明确的答案。就我而言，从功能上讲，我使用哪个并不重要，但我想知道哪个更快。

【问题讨论】：

我几乎总是半信半疑地相信 Peter Lawrey 的建议。
我只会在逻辑论点（赞成、反对）是平衡的或者问题是经验性的并且无法通过分析解决的情况下这样做。

标签： java android multithreading performance

【解决方案1】：

IMO 他们在“性能方面”并没有太大的不同，因为他们都暂停了调用相应wait 的线程，所以很可能底层机制非常相似。为什么性能如此重要呢？除非您有一些极快的等待/信号模式，其中信号在等待之后立即发出，否则会使上下文切换过于昂贵并且可能需要自旋锁，否则无需担心性能。

您应该在编程方面实现您认为最方便的方法，然后进行基准测试，看看您是否真的需要更高性能的东西。

【讨论】：

那么我会选择 notify/notifyAll，但还有一个问题：对于一个线程，哪个更有效？这需要知道如何为他们实现 JVM。我知道差异可以忽略不计，但更喜欢其中一个不需要额外的优化工作（因为我要么写“notify”或“notifyall”），所以我想使用“理论上”更好的解决方案（因为没有理由不要这样做）。
@Thomas Calc：您希望多久在您的应用程序中使用这些机制？
一般来说，这取决于用户输入。在最坏的情况下，每秒一次。
@Thomas Calc：我正在浏览源代码，但很难从那里判断哪个更有效，因为它最终会跳转到本机方法。您只需要搜索这些机制的基准或自己做一个。但是，即使是每秒一个信号，我仍然坚持认为差异并不重要。
如果有任何差异，那肯定是亚毫秒级的，所以如果它每秒发生一次，显然没有必要担心。

【解决方案2】：

wait-notify 完全没问题。

由于等待列表中只有一个线程，notify 和 notifyAll 之间在语义或性能方面没有区别。

【讨论】：