Vfrdtyky

Consider this code:

void A() {

    synchronized (obj) {

        for (int i = 0; i < 1000; i++) {

            B();

        }

    }

}



void B() {

    synchronized (obj) {

        // Do something

    }

}

How much will be the overhead of "synchronized" in calling A? Will it be close to the overhead of only one "synchronized"?

The answer to this (legitimate) question depends on the OS, hardware and specific VM implementation.

Putting aside the cost of a function call, it may cost near to nothing on one OS/architecture (consider modern processor/OS/VM) and much more on another (consider purely software processor emulation). On a single green thread VM it may cost near to zero (except the call overhead). The cost will differ even between ARM and Intel of a comparable power.

synchronized() is usually implemented inside a VM by using OS synchronization primitives, with some heuristics to speed up common cases. OS, in turn, uses hardware instructions and heuristics to perform this task. Usually, subsequent acquisition of an already acquired synchronization primitive is exceptionally efficient in an OS and is very efficient on a typical production grade VM.

On modern Windows/Linux VM and Intel/AMD processor, usually, it doesn't cost a lot of CPU cycles (assuming otherwise idle machine) and is in the low nanoseconds range.

Note, in general, it is a very complex topic. Multiple layers of software, hardware (and the effect of other tasks running on the same hardware resources) are involved. Rigorous research of even a small sub-topic here can compose multiple Ph.D. thesis.

In practice, though, my advice is to assume the cost of a second synchronized in small loops to be zero unless you encounter a particular bottleneck (which is quite unlikely).

If there is a large number of iterations, it definitely will increase the cost vs single synchronized, and the overall effect depends on what you are doing inside the loop. Usually, there is some work in each iteration making the relative overhead negligible. But for some cases, it may prevent loop optimization and add a substantial overhead (substantial comparing to single synchronized, not as a practical measure). However, in common practical cases of huge loops, one should think about different design and avoid performing the outer synchronized to reduce lock contention.

To get a sense about VM implementation you may look, for example, into the Synchronization section of this paper. It is a bit outdated but is straightforward to understand.

synchronized locks are re-entrant and acquiring a lock when a thread is already holding a lock is a) the time to check it already hols the lock, b) the time to increment a counter and later decrement it.

The first one takes the longest and adds about 10 - 50 ns each time.