Java Concurrency programming

Synchronized is a keyword in Java that is called a built-in lock or monitor lock in concurrent programming. When you use it to decorate a method or a block of code, you can guarantee that at most one thread at a time executes the code.

Java's built-in lock is equivalent to a mutex, where at most one thread can hold such a lock, the synchronous block of code protected by the lock is atomically executed, and multiple threads do not interfere with each other when executing the code.

However, because the lock-protected synchronization block code is accessed in serial form, that is, multiple threads access the object exclusively, which also results in concurrency undesirable if the lock-protected synchronization code block is scoped.

Here it is necessary to briefly talk about the principle of synchronous implementation of built-in locks: Every object in Java can be used as a lock, and the synchronized lock actually exists in the Java object Header (which is why it is called a built-in lock).

And according to the method of synchronized modification or the method block different, its lock form also varies.

• For the normal synchronization method, the lock is the current instance object;
• For the static synchronization method, the lock is the class object of the current classes;
• For a synchronous method block, the lock is an object configured within synchronized brackets;

The following is a simple example of a synchronized that acquires different locks depending on the object it modifies.

The public class Test {        /**     * Adornment method locks An instance of the class, and all synchronized methods of that instance must be     * Waiting for the current lock to be released before     accessing    the */public synchronized void Syn1 () {        //todo            }        /**     * Synchronizes static methods, locks the class object, and the synchronized method of other instances of the class must wait until the current lock is released to access the     * /public    synchronized static void  syn3 () {        //todo    }    /**     * Synchronizes the specified object, locks the object, Other synchronized methods that use this object must wait until the current lock is released before accessing the     *    /public void  Syn4 () {
        Obj only represents the specific object name        synchronized (obj) {                    }}/** * To be decorated to synchronize the     specified class, which locks the class object. The Synchronized method for other instances of the class must wait until the current lock is released before accessing the     *    /public void Syn5 () {
        ClassName only represents the specific class to be decorated        synchronized (classname.class) {            //todo        }    }}

In addition, the implementation of synchronization is a significant cost of the system, and may even cause a deadlock (lock nesting), so as far as possible to avoid unnecessary synchronization control. In addition, for concurrent performance considerations, when actually using the Synchronized keyword, it is important to make sure that the synchronized protected synchronization code block is reasonable in size.

Why focus on synchronized this keyword?

1. As mentioned in Java concurrency Programming, synchronized, as a built-in property of the JVM, can perform optimizations such as lock-out optimizations for thread-closed lock objects, eliminate the synchronization of built-in locks by increasing the granularity of locks, and the possibility of using class library-based locks to implement these functions is unlikely.
2. The performance of the built-in lock has been improved in JAVA6 and is already closer to Reentrantlock. (and Reentrantlock in the Java5 is far from winning)
3. Built-in locks are compact and less risky (Reentrantlock may forget to call unlock)

So when the built-in lock can meet the requirements, use the built-in lock whenever possible, but only if the built-in lock does not meet the requirements (such as interruptible, timed, polling, fairness, etc.). In simple terms, consider using reentrantlock when there is a need for more precise control over the acquisition and release of Locks.

Java Concurrency programming