我对 Java 真的很陌生,我读到这synchronized
在 Java 中“非常昂贵”。我只想知道什么东西贵,怎么贵?
谢谢。
它曾经很糟糕(这可能就是你读到它“非常昂贵”的原因)。这些模因可能需要很长时间才能消失
同步有多贵?
由于涉及缓存刷新和失效的规则,Java 语言中的同步块通常比许多平台提供的临界区设施更昂贵,这些设施通常使用原子“测试和设置位”机器指令实现。即使程序仅包含在单个处理器上运行的单个线程,同步方法调用仍然比非同步方法调用慢。如果同步确实需要争用锁,性能损失要大得多,因为需要多个线程切换和系统调用。
幸运的是,JVM 的持续改进既提高了 Java 程序的整体性能,又降低了与每个版本同步的相对成本,并且可以预期未来的改进。此外,同步的性能成本经常被夸大。一个众所周知的消息来源引用了同步方法调用比非同步方法调用慢 50 倍之多。尽管这种说法可能是正确的,但它也具有很大的误导性,并导致许多开发人员即使在需要同步的情况下也避免同步。
话虽如此 - 并发编程仍然可能很慢,但现在并不是纯粹是 Java 的错。精细锁定和粗糙锁定之间存在权衡。太粗显然不好,但也可能太细,因为锁的成本不为零。
考虑争用的特定资源很重要。机械硬盘就是一个例子,更多的线程会导致更差的性能。
这很昂贵,因为如果您正在使用线程,并且许多线程必须通过同步的代码部分,那么一次只能执行其中一个。
这就像一个瓶颈。
当你使用单线程时,它甚至更昂贵,因为它必须检查是否允许他运行。
如果您减少同步段的使用,您的线程将不必停止查看它们是否可以运行(当然,它们不必共享数据)
可以在此处找到有关同步工作原理的高级概述
http://img20.imageshack.us/img20/2066/monitor28synchronizatioc.png
Java 风格的监视器
这并不是 Java 特有的。如果没有正确完成,同步在任何多线程环境中都可能被认为是“昂贵的”。我不知道它在 Java 中是否特别糟糕。
如果线程使用相同的资源,它会阻止线程并发运行。但是,由于它们确实使用相同的资源,因此没有更好的选择(必须这样做)。
问题是人们经常保护范围太大的资源。例如,一个设计不佳的程序可能会同步整个对象数组,而不是数组中的每个单独元素(甚至是数组的一部分)。
这意味着试图读取元素 7 的线程必须等待线程读取或写入元素 22。没有必要。如果同步的粒度是元素级别而不是数组级别,那么这两个线程就不会相互干扰。
只有当两个线程试图访问同一个元素时,才会出现资源争用。这就是为什么一般规则是只保护尽可能小的资源(当然,受同步数量的限制)。
但是,老实说,如果替代方案是由于两个线程争夺单个资源而导致数据损坏,那么成本有多高并不重要。正确编写您的应用程序,并且只在出现性能问题时担心它们(“先让它工作,然后让它快速工作”是我最喜欢的口头禅)。
IBM 的这篇文章实际上很好地总结了同步背后的要点。
由于涉及缓存刷新和失效的规则,Java 语言中的同步块通常比许多平台提供的临界区设施更昂贵,这些设施通常使用原子“测试和设置位”机器指令实现。即使程序仅包含在单个处理器上运行的单个线程,同步方法调用仍然比非同步方法调用慢。如果同步确实需要争用锁,性能损失要大得多,因为需要多个线程切换和系统调用。
其他答案提供了很好的技术细节,我不会尝试复制。
我将建议您检查文章的日期(以及作者的隐含能力和意识)。Java 中的同步在早期的 JVM中非常慢。但是,它最近有了很大的改进,因此非竞争同步比您想象的要快得多,并且非竞争同步也得到了改进。
请注意,这个问题可能无关紧要 - 如果您需要同步以确保正确性,则需要同步以确保正确性。我唯一能看到速度是一个问题的情况是,如果您正在考虑创建一个无锁实现(使用非常高效但复杂的java.util.concurrent.locks.AbstractQueuedSynchronizer),或者可能考虑使用另一种语言来代替您的任务。
一般来说,我认为最好的结论是同步通常足够快,可以在第一次迭代中使用。与所有性能问题一样,首先为了清晰和正确而编写代码,然后只优化您衡量的内容,使其成为应用程序中昂贵的部分。通常,这不会是同步成本*。