java - Does empty synchronized(this){} have any meaning to memory visibility between threads?

Question

I read this in an upvoted comment on StackOverflow:

But if you want to be safe, you can add simple synchronized(this) {} at the end of you @PostConstruct [method]

[note that variables were NOT volatile]

I was thinking that happens-before is forced only if both write and read is executed in synchronized block or at least read is volatile.

Is the quoted sentence correct? Does an empty synchronized(this) {} block flush all variables changed in current method to "general visible" memory?

Please consider some scenerios

• what if second thread never calls lock on this? (suppose that second thread reads in other methods). Remember that question is about: flush changes to other threads, not give other threads a way (synchronized) to poll changes made by original thread. Also no-synchronization in other methods is very likely in Spring @PostConstruct context - as original comment says.

• is memory visibility of changes forced only in second and subsequent calls by another thread? (remember that this synchronized block is a last call in our method) - this would mark this way of synchronization as very bad practice (stale values in first call)

Answer 1

Much of what's written about this on SO, including many of the answers/comments in this thread, are, sadly, wrong.

The key rule in the Java Memory Model that applies here is: an unlock operation on a given monitor happens-before a subsequent lock operation on that same monitor. If only one thread ever acquires the lock, it has no meaning. If the VM can prove that the lock object is thread-confined, it can elide any fences it might otherwise emit.

The quote you highlight assumes that releasing a lock acts as a full fence. And sometimes that might be true, but you can't count on it. So your skeptical questions are well-founded.

See Java Concurrency in Practice, Ch 16 for more on the Java Memory Model.