c# - 锁定 .NET 与 Java 的成本

Question

我在玩Disruptor框架及其用于 .NET 平台的端口，并发现了一个有趣的案例。可能是我完全错过了一些东西，所以我正在向全能的社区寻求帮助。

        long iterations = 500*1000*1000;
        long testValue = 1;

        //.NET 4.0. Release build. Mean time - 26 secs;
        object lockObject = new object();
        Stopwatch sw = Stopwatch.StartNew();
        for (int i = 0; i < iterations; i++)
        {
            lock (lockObject)
            {
                testValue++;    
            }
        }
        sw.Stop();

        //Java 6.25. Default JVM params. Mean time - 17 secs.
        Object lock = new Object();
        long start = System.currentTimeMillis();
        for (int i = 0; i < iterations; i++)
        {
                synchronized (lock)
                {
                    testValue++;
                }
        }
        long stop = System.currentTimeMillis();

似乎在 .NET 中使用单线程获取锁的成本仅比 Java 高 50%。起初我对计时器持怀疑态度，但我已经进行了几次相同的测试，结果与上述平均值差不多。然后我对 synchronized 代码块感到怀疑，但它不仅仅是 monitorenter/monitorexit 字节码指令 - 与 lock .NET 中的关键字。任何其他想法为什么在 .NET 与 Java 中获取锁如此昂贵？

Answer 1

是的，在 .NET 中获取非竞争锁似乎比在 Java 中更昂贵。 (我上网本上的结果仍然稍微显着。)

在一个平台上的性能会比另一个平台更快，有时会达到这个程度。 HotSpot JIT 和 .NET JIT 在很多方面都有很大的不同——尤其是因为 .NET JIT 只在 IL 上运行一次，而 HotSpot 能够越来越多地优化为一个特定的代码运行越来越频繁。

重要的问题是这是否真的重要。如果您在现实生活中的应用程序确实每分钟花费 5 亿次未满足的锁，这可能很重要 - 您可能应该重新设计您的应用程序。如果您的实际应用程序确实在锁内(或在获取锁之间)进行实际工作，那么它不太可能成为真正的瓶颈。

我最近发现了两个 .NET 陷阱( part one ; part two )，因为我正在编写“系统级库”，所以当我编写“系统级库”时它们会产生重大影响很多日期/时间解析 - 但这种微优化很少值得做。