代码之家  ›  专栏  ›  技术社区  ›  dimo414

单线程应用程序中的同步方法是否较慢?

  •  11
  • dimo414  · 技术社区  · 17 年前

    在过去的几分钟里,我一直在和自己辩论这个问题,我看到了赞成和反对的理由。这是因为我看到了问题的答案 Java HashMap vs. Hashtable 看到一些人说Hashtable实际上慢了一些。

    应该 如果在单个线程中运行,则其操作与未同步的对应操作完全相同,因为同步操作不应阻止任何内容。也就是说,我认为编译器处理这两种情况的方式是不同的,这就是为什么人们说synchronized比较慢的原因。

    这并不是说它是决定性的,但我在HashMap和Hashtable上运行了一些简单的测试,并发现在速度上几乎没有差别。

    3 回复  |  直到 9 年前
        1
  •  15
  •   Eddie    17 年前

    是的,使用同步的单端Java程序 也许 要比没有同步时稍微慢一点。对于早期的Java版本,同步成本很高。但是,对于任何现代版本, 无争议 同步非常便宜。我不担心这个。

    • 锁粗化
    • 锁省略

    有关更多信息,请参阅 Java SE 6 Performance White Paper . 还请注意,多核CPU上的非竞争性同步似乎比单核CPU上的更昂贵,这可能是因为Java内存模型对同步的要求迫使本地CPU缓存与其他CPU共享,或者其他一些内存障碍。例如,阅读 Do Java 6 threading optimizations actually work? - Part II . (第一部分没有第二部分那么有见地。)

        2
  •  5
  •   Mitch Wheat    17 年前

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

        3
  •  0
  •   user57368    17 年前

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