同步速度与正常速度

Question

我有一个为单个线程编写的类，没有同步任何方法。

class MyClass implements MyInterface{
//interface implementation methods, not synchronized
}

但是我们也需要一个同步版本的类。因此，我们创建了一个包装类，它实现了相同的接口，但具有一个接受MyClass实例的构造函数。对同步类的方法的任何调用都被委托给MyClass的实例。这是我的同步类..

class SynchronizedMyClass implements MyInterface{
//the constructor
public SynchronizedMyClass(MyInterface i/*this is actually an instance of MyClass*/)
//interface implementation methods; all synchronized; all delegated to the MyInterface instance
}

在这之后，我用这两个类运行了大量的测试。测试包括读取日志文件和计算每行中的URL。问题在于，类的同步版本始终占用较少的解析时间。我只使用了一个线程进行测试，所以不会出现死锁、竞态等情况。每个日志文件包含超过500万行，这意味着调用这些方法超过500万次。有没有人能解释为什么同步版本的migt比普通版本花费的时间更少？

Answer 1

首先，您应该阅读有关在Java语言中进行基准测试的内容：How do I write a correct micro-benchmark in Java?

假设基准测试是好的，那么以下是一些可能的原因：

• Lock elision：如果JVM注意到该方法只能从一个线程调用，它可能会优化掉synchronization.
• Lock coarsening：。JVM可能会将多个同步的块组合成一个块，从而提高性能。也许JVM能够优化你的同步版本的方法，在better.
• Non-contending中同步块很快，所以可能很难注意到差异(尽管无论如何都会有一些开销)，性能差异的原因可能是其他原因造成的。当存在争用(即多个线程试图同时访问它)时，同步的块会变得很慢，在这种情况下，java.util.concurrent.locks和其他同步机制可能会更快。

原因也可能是其他原因。也许JVM会以不同的方式优化这些方法。要了解实际发生了什么，请看一下JIT生成的本机代码：How to see JIT-compiled code in JVM?

Answer 2

正如已经指出的，微型基准测试对于Java来说并不是那么简单。

我没有理由担心同步本身的开销，即使在这种情况下，我也会将优化保存到您发现自己实际上遇到瓶颈的时候。

同步的有趣之处在于代码在多线程环境中的工作方式。我绝对会专注于确保在正确的地方正确地使用同步。

坦率地说，同时需要同一个类的完全同步和非同步版本听起来有点奇怪。