Android Advanced: Thorough Understanding of the Synchronized Keyword

[[417605]]

This article is reprinted from the WeChat public account "Android Development Programming", the author is Android Development Programming. Please contact the Android Development Programming public account for reprinting this article.

1. Synchronized Detailed Explanation

Synchronized is a keyword in Java. When multiple threads operate shared resources together, it can ensure that only one thread can operate the shared resources at the same time, thereby achieving thread safety of shared resources.

2. Characteristics of Synchronized

1. Atomicity. Synchronized can ensure mutually exclusive access to shared resources under multiple threads, and the synchronized code can achieve atomicity.
2. Visibility. Synchronized ensures that changes to shared resources can be seen in a timely manner. In the Java memory model, after operating on a shared variable, before releasing the lock, that is, before performing the unlock operation, the changes must be synchronized to the main memory. If a shared resource is locked, that is, before the lock operation, the value of the shared variable in the working memory must be cleared (because the shared variable obtained by each thread is a copy of the shared variable in the main memory, if it is not cleared, data inconsistency will occur, that is, the shared variable in the current thread is inconsistent with the shared variable in the main memory). When using this shared variable, it is necessary to reload this shared variable from the main memory to obtain the latest value of the shared variable.
3. Orderliness. Synchronized can effectively solve the reordering problem, that is, an unlock operation must occur before the lock operation of the same lock by the subsequent thread, which will ensure that the shared variables of the main memory value are always the latest.

3. Use of Synchronized

When using the Synchronized keyword, you need to keep the following points in mind:

A lock can only be acquired by one thread at a time, and the thread that has not acquired the lock can only wait;

Each instance has its own lock (this), and different instances do not affect each other; exception: when the lock object is *.class and the synchronized method is a static method, all objects share the same lock;

The synchronized modified method will release the lock regardless of whether the method is executed normally or throws an exception.

Object Lock

Including method lock (the default lock object is this, the current instance object) and synchronized code block lock (self-specified lock object lock)

Code block form: manually specify the lock object, which can be this or a custom lock

 .println( "block1 lock, I am a thread" + Thread.currentThread().getName()); try { Thread.sleep(3000); } catch ( InterruptedException e) { e.printStackTrace(); } System. out .println ( "block1 lock," + Thread.currentThread().getName() + "end" ); } synchronized (block2) { System. out .println( "block2 lock, I am a thread" + Thread.currentThread().getName()); try { Thread.sleep ( 3000 ) ; } catch (InterruptedException e) { e.printStackTrace(); } System. out .println( "block2 lock," +Thread.currentThread().getName() + "End" ); } } public   static void main(String[] args) { Thread t1 = new Thread(instence); Thread t2 = new Thread(instence); t1.start(); t2.start(); } } Copy code

Output:

 block1 lock, I am thread Thread-0 block1 lock, Thread-0 ends block2 lock, I am thread Thread-0 // You can see that after the first thread executes the first synchronized code block, the second synchronized code block can be executed immediately because they use different locks block1 lock, I am thread Thread-1 block2 lock, Thread-0 ends block1 lock, Thread-1 ends block2 lock, I am thread Thread-1 block2 lock, Thread-1 ends

Method lock form: synchronized modifies ordinary methods, and the lock object defaults to this

 public class SynchronizedObjectLock implements Runnable { static SynchronizedObjectLock instance = new SynchronizedObjectLock(); @Override public void run() { method(); } public synchronized void method() { System. out .println( "I am a thread" + Thread.currentThread().getName()); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } System. out .println(Thread.currentThread().getName() + "End" ); } public   static void main(String[] args) { Thread t1 = new Thread(instence); Thread t2 = new Thread(instence); t1.start(); t2.start(); } }

Class Lock

Including method lock (the default lock object is this, the current instance object) and synchronized code block lock (specify the lock object yourself)

synchronize modifies static methods (class object of the class)

 public class SynchronizedObjectLock implements Runnable { static SynchronizedObjectLock instence1 = new SynchronizedObjectLock(); static SynchronizedObjectLock instence2 = new SynchronizedObjectLock(); @Override public void run() { method(); } // synchronized is used on static methods. The default lock is the current Class class, so no matter which thread accesses it, only one public lock is required   static synchronized void method() { System. out .println( "I am a thread" + Thread.currentThread().getName()); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } System. out .println(Thread.currentThread().getName() + "End" ); } public   static void main(String[] args) { Thread t1 = new Thread(instence1); Thread t2 = new Thread(instence2); t1.start(); t2.start(); } }

Output:

I am thread Thread-0 Thread-0 ends I am thread Thread-1 Thread-1 ends Copy code

synchronized modification instance method

 /** * Synchronized modifies instance methods. When a thread gets the lock, other threads cannot get the lock of the object, so other threads cannot access other synchronized methods of the object. * But they can access other non-synchronized methods of the object. * What is locked is the instance object of the class */ public class synchronizedDemo1 implements Runnable { //Simulate a shared data private static   int total=0; //Synchronization method, after each thread acquires the lock, it executes 5 accumulation operations public synchronized void increase(){ for ( int i = 1; i < 6; i++) { System. out .println(Thread.currentThread().getName()+ "Execute accumulation operation..." + "The" +i+ "accumulation" ); try { total=total+1; Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } } } //Another synchronization method of instance object public synchronized void declare (){ System. out .println(Thread.currentThread().getName()+ "Execute total-1" ); total --; System.out.println(Thread.currentThread().getName()+"Execution total-1 completed"); } //Ordinary instance method public void simpleMethod(){ System.out.println(Thread.currentThread().getName()+ " ----Ordinary method of instance object---"); } @Override public void run() { //Thread execution body System.out.println(Thread.currentThread().getName()+"Ready to execute accumulation, not yet acquired the lock"); //Execute ordinary method simpleMethod(); //Call synchronization method to perform accumulation operation increase(); //After executing the increase synchronization method, the lock will be released, and then thread 1 and thread 2 will compete for the lock again. Whoever competes for the lock first will execute the declare synchronization method first. System.out.println(Thread.currentThread().getName()+"Complete accumulation operation"); //Call another synchronization method of instance object System.out.println(Thread.currentThread().getName()+"Ready to execute total-1"); declare(); } public static void main(String[] args) throws InterruptedException { synchronizedDemo1 syn = new synchronizedDemo1(); Thread thread1 = new Thread(syn,"线程1"); Thread thread2 = new Thread(syn,"Thread2"); thread1.start(); thread2.start(); } }  

Output:

Thread 1 is ready to perform accumulation, but has not yet obtained the lock. Thread 2 is ready to perform accumulation, but has not yet obtained the lock. Thread 2 ---- Ordinary method of instance object--- Thread 2 performs accumulation operation...1st accumulation //Thread 2 gets the lock first through competition with thread 1 and enters the increase synchronization method. Thread 2 performs accumulation operation...2nd accumulation Thread 1 ---- Ordinary method of instance object--- //From here, it can be seen that when thread 2 accesses the synchronization method, thread 1 can access the non-synchronized method, but cannot access another synchronization method. Thread 2 performs accumulation operation...3rd accumulation Thread 2 performs accumulation operation...4th accumulation Thread 2 performs accumulation operation...5th accumulation Thread 2 completes the accumulation operation //Thread 2 releases the lock after performing accumulation Thread 2 is ready to execute total-1 Thread 1 performs the accumulation operation...1st accumulation //Then thread 1 gets the lock and enters the increase synchronization method to perform the accumulation Thread 1 performs the accumulation operation...2nd accumulation Thread 1 performs the accumulation operation...3rd accumulation Thread 1 performs the accumulation operation...4th accumulation Thread 1 performs the accumulation operation...5th accumulation Thread 1 completes the accumulation operation //Thread 1 will also release the lock after completing the accumulation operation, and then thread 1 and thread 2 will compete for the lock again Thread 1 prepares to execute total-1 Thread 2 executes total-1 //Thread 2 gets the lock first through competition and enters the declear method to execute the total-1 operation Thread 2 completes the execution of total-1 Thread 1 executes total-1 Thread 1 completes the execution of total-1 Copy code

4. Synchronized Implementation Principle

Locking and releasing locks

Synchronized synchronization is implemented through instructions such as monitorenter and monitorexit, which will allow the object to execute and increase or decrease its lock counter by 1.

Monitorenter instruction: Each object is associated with only one monitor (lock) at a time, and a monitor can only be acquired by one thread at a time. When an object tries to acquire ownership of the Monitor lock associated with this object, one of the following three situations will occur:

• If the monitor counter is 0, it means that it has not been acquired yet. Then this thread will acquire it immediately and increase the lock counter by 1. Once it is +1, other threads will need to wait if they want to acquire it.
• If the monitor has already obtained the ownership of the lock and reenters the lock, the lock counter will be incremented to 2, and will continue to accumulate with the number of reentries.
• If another thread already holds the object monitor, the current thread enters a blocked state until the entry count of the object monitor is 0, and then tries to acquire ownership of the monitor again.

monitorexit instruction: releases the ownership of the monitor. The release process is very simple, which is to reduce the monitor's counter by 1. If the counter is not 0 after the reduction, it means that the thread has just reentered and the current thread continues to hold the ownership of the lock. If the counter becomes 0, it means that the current thread no longer owns the monitor, that is, the lock is released.

The relationship between objects, object monitors, synchronization queues, and execution thread states:

As can be seen from the figure, any thread that accesses an Object must first obtain the Object's monitor. If the acquisition fails, the thread enters the synchronization state and the thread state becomes BLOCKED. When the Object's monitor occupant is released, the thread in the synchronization queue will have the opportunity to reacquire the monitor.

Reentrancy principle: lock count counter

As can be seen from the figure above, when executing the static synchronization method, there is only one monitorexit instruction, and there is no monitorenter instruction to acquire the lock. This is the reentrancy of the lock, that is, in the same lock process, the thread does not need to acquire the same lock again.

Synchronized is inherently reentrant. Each object has a counter. When a thread acquires the lock of the object, the counter is incremented by one, and when the lock is released, the counter is decremented by one.

Principles of ensuring visibility: memory model and happens-before rule

The happens-before rule of Synchronized, that is, the monitor lock rule: unlocking the same monitor happens-before locking the monitor.

public class MonitorDemo { private int a = 0; public synchronized void writer() { // 1 a++; // 2 } // 3 public synchronized void reader() { // 4 int i = a; // 5 } // 6 } Copy code

The happens-before relationship is shown in the figure:

In the figure, each two nodes connected by an arrow represent the happens-before relationship between them. The black ones are derived from the program order rules, and the red ones are derived from the monitor lock rules: thread A releases the lock happens-before thread B locks it. The blue ones are the happens-before relationships inferred by the program order rules and the monitor lock rules, and the happens-before relationships are further derived by the transitivity rules.

Summarize

• The implementation of the synchronized statement block uses the monitorenter and monitorexit instructions, where the monitorenter instruction points to the starting position of the synchronized code block, and the monitorexit instruction indicates the end position of the synchronized code block.
• The synchronized modified method does not have monitorenter instruction and monitorexit instruction. Instead, it is replaced by the ACC_SYNCHRONIZED flag, which indicates that the method is a synchronized method.

However, the essence of both is to obtain the object monitor monitor.

What should I pay attention to when using Synchronized?

• The lock object cannot be empty, because the lock information is stored in the object header;
• The scope should not be too large, which will affect the speed of program execution. If the control range is too large, it is easy to make mistakes when writing code.
• Avoid deadlock;
• If you have a choice, do not use either the Lock or the synchronized keyword. Instead, use the various classes in the java.util.concurrent package. If you do not use the classes in this package, you can use the synchronized keyword if it meets your business needs, as it reduces the amount of code and helps avoid errors.