Java 中同步的使用令人困惑：模式还是反模式？

发布于 2024-12-07 13:45:59 字数 216 浏览 0 评论 0原文

我正在对不属于我的 Java 产品中的更改进行代码审查。我不是 Java 专家，但我强烈怀疑这是毫无意义的，并且表明了对同步工作原理的根本误解。

synchronized (this) {
    this.notify();
}

但我可能是错的，因为 Java 不是我的主要游乐场。也许这样做是有原因的。如果您能告诉我开发人员的想法，我将不胜感激。

原文

I'm doing a code review for a change in a Java product I don't own. I'm not a Java expert, but I strongly suspect that this is pointless and indicates a fundamental misunderstanding of how synchronization works.

synchronized (this) {
    this.notify();
}

But I could be wrong, since Java is not my primary playground. Perhaps there is a reason this is done. If you can enlighten me as to what the developer was thinking, I would appreciate it.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

皇甫轩 2024-12-14 13:45:59

这当然不是毫无意义的，您可以让另一个线程引用包含上述代码的对象，

synchronized(foo) {
    foo.wait();
}

以便在发生某些情况时被唤醒。不过，在许多情况下，在内部/私有锁对象而不是 this 上进行同步被认为是很好的做法。

然而，仅在同步块中执行 .notify() 可能是非常错误的 - 您通常有一些工作要做并在完成时发出通知，在正常情况下也需要以原子方式完成到其他线程。我们必须查看更多代码才能确定它是否真的是错误的。

It certainly is not pointless, you can have another thread that has a reference to the object containing the above code doing

synchronized(foo) {
    foo.wait();
}

in order to be woken up when something happens. Though, in many cases it's considered good practice to synchronize on an internal/private lock object instead of this.

However, only doing a .notify() within the synchronization block could be quite wrong - you usually have some work to do and notify when it's done, which in normal cases also needs to be done atomically in regards to other threads. We'd have to see more code to determine whether it really is wrong.

回复收藏 0 原文

我为君王 2024-12-14 13:45:59

如果这就是同步块中的全部内容，那么它是一个反模式，同步的要点是在块内执行某些操作，设置一些条件，然后调用“通知”或notifyAll 唤醒一个或多个等待线程。

当您使用等待和通知时，您必须使用条件变量，请参阅此 Oracle教程：

注意：始终在循环内调用 wait 来测试正在等待的条件。不要假设中断是针对您正在等待的特定条件的，或者条件仍然为真。

您不应该仅仅因为线程从对 Object#wait 的调用中退出而假设您收到通知，原因有多种：

当调用采用超时值的 wait 版本时，无法知道等待是否由于以下原因而结束：收到通知或由于超时。
您必须考虑到线程可以在没有收到通知的情况下从等待中唤醒的可能性（“虚假唤醒”）。
收到通知的等待线程仍然必须重新获取它开始等待时放弃的锁，这两个事件没有原子链接；在收到通知和重新获取锁之间的时间间隔内，另一个线程可能会采取行动，并可能更改系统的状态，从而使通知现在无效。
您可能会遇到这样的情况：通知线程在任何线程等待之前执行操作，因此通知无效。假设一个线程在另一个线程发出通知之前进入等待状态是危险的，如果您错了，则等待线程将无限期挂起。

因此，通知本身还不够好，当等待/通知 API 没有提供足够的信息来了解发生了什么情况时，您最终会猜测是否发生了通知。即使通知线程正在执行的其他工作不需要同步，更新条件变量也需要同步；同步块中至少应该更新共享条件变量。