This has a potential data race, and I will fix it soon.

You can use tools Like pmap to see the exact reserved (i.e. virtual) and committed (i.e. physical or RSS) memory consumption of each thread.

Interesting facts, but I think the study would be more reliable if it was also conducted on different operating systems and/or machines with different capacities.

Thank you for pointing out the oversight in the ReentrantLock example. You’re absolutely correct; I’ve updated the example to reflect the correction.

Thank you for your feedback, and I apologize for not meeting your expectations with the article. Your comments are taken seriously, and they provide valuable insights for improvement.

To address your concerns:

ReentrantLock Over Synchronization: In Java, ReentrantLock provides more functionalities than traditional synchronized blocks. For instance, it allows you to back out of an attempt to acquire a lock, interrupt thread waiting for a lock, or try to acquire a lock for a specific amount of time. This gives you greater control over lock acquisition and release, potentially leading to more efficient concurrent code.

Unsafe and VarHandle: These are low-level classes that offer fine-grained control over memory operations and concurrency control. Unsafe allows you to perform operations like direct memory access, which bypasses the JVM’s safety checks. VarHandle provides similar capabilities but in a safer manner. However, these should be used with caution because the absence of safety checks can lead to complex and error-prone code.

I hope this clears up some of your questions. Once again, I appreciate your feedback and will strive to improve the quality of future articles. If you have more questions or need further clarification, feel free to ask.