2009-06-10 27 views
11

最近几分钟我一直在为自己辩论,我看到了“是”和“不是”的原因。这源于对Java HashMap vs. Hashtable的回答,看到几个人说Hashtable实际上比较慢。同步方法在单线程应用程序中速度较慢吗?

在我看来,一个同步方法应该绝对没有不同步比它的非同步对手,如果运行在一个单一的线程,因为同步的行动不应该阻止任何东西。也就是说,我会想象编译器处理这两种情况的方式不同,这就是为什么人们说同步更慢。

并不是说这是任何方式的结论,但我对HashMap vs Hashtable进行了一些简单的测试,并且看到速度没什么区别。

+1

瓶颈将出现在你的算法中。因此,同步开销应该很小。 – sybreon 2009-06-10 03:26:50

回答

15

是,使用同步单theaded Java程序可以略慢于他们将不同步。对于早期的Java版本,同步代价很高。然而,对于任何现代版本,无约束同步相当便宜。我不会为此担心。

需要注意的是Java 6中具有和Java 7是有大约锁定良好的优化:

  • 锁粗
  • 锁省略
  • 自适应自旋锁
  • 偏向锁

欲了解更多信息,请参阅Java SE 6 Performance White Paper。另请注意,多核CPU上的无争用同步似乎比单核CPU上的更昂贵,这可能是由于同步的Java内存模型要求强制本地CPU高速缓存与其他CPU共享或其他内存屏障。例如,请阅读Do Java 6 threading optimizations actually work? - Part II。 (第一部分并不像第二部分那样富有洞察力)。

5

是的。由于维护锁的额外开销,它们会稍微慢一些。

+3

只是如此轻微。 +1 – sybreon 2009-06-10 03:25:50

+0

...如果JIT无法确定它不需要在这种情况下维护锁... – 2009-06-10 03:40:49

0

使用同步数据结构时,减速并不取决于“多少”被阻止。获取或释放锁的行为很慢,因为它通常涉及类似系统调用的事情(上下文切换在任何平台上都很慢)。在JIT环境(如典型的JVM)中,理论上可以在只有一个线程运行时优化所有锁定/解锁调用,但只要另一个线程启动就必须正确无效。

请注意,像Linux的futexes这样的东西不需要进行系统调用,除非存在争用,但使用它们仍然比没有运行时慢。

+0

除非操作系统是CPU热插拔我猜;那么JVM将无法做出这样的假设? – 2009-06-10 03:20:31

相关问题