Speed of Synchronization vs Normal

I have a class which is written for a single thread with no methods being synchronized.

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

But we also needed a synchronized version of the class. So we made a wrapper class that implements the same interface but has a constructor that takes an instance of MyClass. Any call to the methods of the synchronized class are delegated to the instance of MyClass. Here is my synchronized class..

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
}

After all this I ran numerous amounts of test runs with both the classes. The tests involve reading log files and counting URLs in each line. The problem is that the synchronized version of the class is consistently taking less time for the parsing. I am using only one thread for the teste, so there is no chance of开发者_Python百科 deadlocks, race around condition etc etc. Each log file contains more than 5 million lines which means calling the methods more than 5 million times. Can anyone explain why synchronized versiuon of the class migt be taking less time than the normal one?

First you should read about making benchmarks in Java: How do I write a correct micro-benchmark in Java?

Assuming that the benchmark is good, then here are some possible reasons:

• Lock elision: If the JVM can notice that the method can only be called from one thread, it may optimize away the synchronization.

• Lock coarsening: The JVM may combine multiple synchronized blocks into one block, which improves performance. Maybe the JVM is able to optimize your synchronized version of the method a bit better.

• Non-contending synchronized blocks in Java are fast, so it might be hard to notice the difference (although there should anyways be some overhead) and the reason for performance difference could be caused by something else . Synchronized blocks become slow when there is contention (i.e. many threads try to access it at the same time), in which case java.util.concurrent.locks and other synchonization mechanisms might be faster.

The reason could also be something else. Maybe the JVM optimizes the methods differently. To see what is really happening, have a look at what native code the JIT generates: How to see JIT-compiled code in JVM?

As already pointed out, micro-benchmarking is not that trivial with Java.

IMO There's no reason to be worried about the overhead of synchronization itself and even in that case I would save the optimizations to the time when you find out you actually have a bottleneck.

The interesting part of synchronization is how your code works in a multithreaded environment. I'd definitely focus on making sure the synchronization is used correctly in the right places.

Frankly it sounds a bit odd to need both fully synchronized and unsynchronized versions of the same class.