> Practically all server applications require some sort of synchronization between multiple threads.
It could be just me but I think the author should've mentioned alternative concurrent programming models available for JVM such as Akka.
It could be just me but I think the author should've mentioned alternative concurrent programming models available for JVM such as Akka.
At a bare minimum the changes to the location of the head/tail of a queue will need to be visible to multiple threads requiring volatile variables.
The java concurrent queues don't actually use synchronization blocks, they use native CAS operations but thinking that akka removes shared thread state entirely is dangerous.
The costs of synchronised blocks is high on the JVM. They defer to the operating system for thread scheduling, they enforce a memory barrier meaning all data is flushed out to RAM rather than CPU caches, and multithreaded code dirties CPU caches, reducing performance.
More server side code should be single threaded than not in my opinion.
That said, I completely agree. Many times making a single threaded system faster will improve performance vs making it parallel.