Synchronization is the heaviest operation in Java. It can take thousands of CPU cycles to lock on an object and pretty much disables aggresive out-of-order execution of instructions, as the JVM has to guarantee X happened before Y.

There are however optimisations in the HotSpot JVM that can replace a 'monitor enter' with a busy-loop, or even verifying that locks are never accessed concurrently, in which case the sync can be optimized away. Once the JVM determines that a lock is contented, it will rollback these optimisations.

Having said all that, the performance overhead can be negligible, depending on how much work you actually perform within the synchronized block. So as always, it depends. Benchmark it in a realworld scenario and draw conclusions from that.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Doing lots of work inside the synchronized block is the best way to make sure your locks become bottlenecks or cause outright deadlock. The fastest solution is not sharing the lists between threads in the first place. Hard to say if that's possible from the description.

Doing lots of work inside the synchronized block is the best way to make sure your locks become bottlenecks or cause outright deadlock. The fastest solution is not sharing the lists between threads in the first place. Hard to say if that's possible from the description.

I would recommend using locks from java.util.concurrent. In all my tests they are never slower than synchronized and sometimes are faster because you have more control. The biggest gains can come from cases where there are many reads and less often writes... and its readWriteLock for the win. I have seen great performance using that on some fluid simulation stuff where many threads work on common data structures.

I have no special talents. I am only passionately curious.--Albert Einstein

In my case, I have two solutions to my problem. One is to allow the threads to modify the lists, and one is to defer the changes by saving them and execute them single-threaded after everything. I think it will be faster to use synchronization since I will not be doing many changes per update, like 80% of the time it will be 0 changes but sometimes several in a single frame. The chance of two lists being modified in the same frame is extremely low, but if synchronization is as expensive as you say...

Concerning how much work I actually do in each change, I realized that I might have to keep the lists sorted, since the order of the objects in them may have an effect if the scripts used in the game are order-dependent (I need determinism for network synchronization and replaying). I might therefore have to switch from ArrayList to some kind of sorted list or set, which would of course take more time to change...

In the end, I guess only an actual benchmark would be able to give me an answer. Thanks for all the quick responses!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org