Synchronized methods and virtual threads

[Robert Engels]

Sure. People used synchronized to create “lock objects” long before java.util.concurrent - routinely for higher level debugging.

You have to also remember a bit of history regarding when Java was created and the relative performance of the machines then. Having an intrinsic lock that the JVM could optimize was highly beneficial - especially when there was no optimizing JIT. There is a LOT of code in the JVM/JDK that uses synchronized...

Implementing j.u.c requires compiler/intrinsics/atomics/LockSupport - basically making these objects special anyway. I don’t know of any Java developer that had a problem using synchronized. That being said, if j.u.c can achieve the performance of monitors then the only reason to support it is backward compatibility.

Tbh, I am not a fan of the loosey-goosey release every 6 months change anything in Java the way the wind blows mentality. The only aspects that allowed Java to succeed were backwards compatibility and cross platform (and then the JIT for performance) - my opinion of course.

> On Jun 3, 2024, at 3:09 PM, Cay Horstmann <cay.horstmann at gmail.com> wrote:
> 
> A bit of history. The motivation for synchronized methods was to bring Per Brinch Hansen's monitor construct to a mainstream language. In a monitor, all methods are synchronized, and you have mechanisms that in Java are called wait/notifyAll. The way this was done in Java is a bit odd. Why have a lock for potentially every instance, when most classes clearly aren't monitors? And why allow public data and a mix of synchronized and non-synchronized methods? And why make the lock be "this" so it leaks to the public? Per Brinch Hansen wasn't amused: "It is astonishing to me that Java 's insecure parallelism is taken seriously by the programming community, a quarter of a century after the invention of monitors and Concurrent Pascal. It has no merit."
> 
> Still, with a bit of discipline, you can implement a monitor in Java. As long as nobody does "client-side locking" with synchronized (obj) { ... } And sure, if a method does synchronized (this) for a shorter time than the whole method, that's cool too as an optimization.
> 
> But that has not been a mainstream thing for a long time. How many synchronized methods do you find in j.u.c.ConcurrentHashMap?	
> 
> Now, admittedly, there are several instances of synchronized (someSeeminglyRandomObject) in the implementation. Also, check out the use of lock objects in Writer/PrintWriter. It's complicated.
> 
> Nothing wrong with an expert using synchronized because it performs better. But that begs the question. Why does it perform better? Objects typed as locks are surely more suitable as locks than any old object. Their performance should be on par with intrinsic locks.
> 
> Cheers,
> 
> Cay
> 
> On 03/06/2024 15.26, robert engels wrote:
>> They are one and the same when they lock on the object itself. Synchronized block statements allow the lock duration to be minimized while maintaining the natural code structure (I.e not adding additional methods).
>>> On Jun 3, 2024, at 8:24 AM, Cay Horstmann <cay at horstmann.com> wrote:
>>> 
>>> I am not talking about synchronized methods but about block statements (JLS 14.19).
>>> 
>>> synchronized (obj) {
>>> 
>>> }
>>> 
>>>> On 03/06/2024 14.31, robert engels wrote:
>>>> Reference for synchronized being a code smell?
>>>> Synchronized methods can be much more efficient than locks as the runtime can optimize them away, bias locking, etc.
>>>>>> On Jun 3, 2024, at 2:21 AM, Cay Horstmann <cay.horstmann at gmail.com> wrote:
>>>>> 
>>>>> On 02/06/2024 13.07, Andrew Haley wrote:
>>>>>>> On 6/1/24 17:56, Alex wrote:
>>>>>>> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods?
>>>>>> I'd use Lock for the future. Synchronized plays very badly with Value
>>>>>> Objects, for example. Being able to synchronize on any object is something
>>>>>> of a legacy feature.
>>>>> 
>>>>> At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.)
>>>>> 
>>>>> --
>>>>> 
>>>>> Cay S. Horstmann | https://horstmann.com
>>> 
>>> --
>>> 
>>> --
>>> 
>>> Cay S. Horstmann | https://horstmann.com
> 
> -- 
> 
> --
> 
> Cay S. Horstmann | https://horstmann.com