Shocking secrets! Starting from Thread, revealing the tricks of Android thread communication and the conspiracy of the main thread

Background

In the process of Android development, we almost cannot do without threads. But how much do you know about threads? How many unknown secrets are hidden behind its operation? How do threads communicate with each other and pass information? How do Looper, Handler, and MessageQueue operate behind the scenes? In this issue, let's start with Thread and gradually explore the secrets behind this powerful thread chain.

Note that most of the analysis is in the code, so pay close attention to it!

Start with the Tread creation process

In this section, we will analyze the Thread creation process step by step.

Without further ado, let’s look at the code directly.

The starting point of thread creation is init()

 // The public constructor that creates Thread calls this private init() method. Let's see what it does. 
 
 /** 
 
 * 
 
 * @param thread group 
 
 * @param is the Runnable classmate we usually come into contact with most 
 
 * @param specifies the name of the thread 
 
 * @param specifies the size of the thread stack 
 
 */ 
 
 private void init(ThreadGroup g, Runnable target, String name , long stackSize) { 
 
 Thread parent = currentThread(); //First get the currently running thread. This is a native function, so don't worry about how it does it for now. Black box thinking, haha! 
 
 if (g == null ) { 
 
 g = parent.getThreadGroup(); //If ThreadGroup is not specified, the parent thread's TreadGroup will be obtained 
 
 } 
 
 g.addUnstarted(); //Increase the ready thread counter in ThreadGroup by one. Note that the thread has not yet been actually added to the ThreadGroup. 
 
 this.group = g; // Assign the group of the Thread instance . From here on, the thread owns the ThreadGroup. 
 
 this.target = target; //Set Runnable to the Thread instance. It will be executed when start() is called later. 
 
 this.priority = parent.getPriority(); //Set the thread's priority weight to the parent thread's weight 
 
 this.daemon = parent.isDaemon(); //Determine whether the Thread instance is a daemon thread based on whether the parent thread is a daemon thread. 
 
 setName( name ); //Set the name of the thread 
 
 init2(parent); // What? Another initialization, the parameter is still the parent thread. Don't worry, I'll look at it later. 
 
        /* Stash the specified stack size   in   case the VM cares */ 
 
 this.stackSize = stackSize; //Set the thread stack size 
 
 tid = nextThreadID(); //Thread ID. This is a static variable. Calling this method will increment it and then use it as the thread ID. 
 
 }

The second init2()

At this point, our Thread has been initialized and several important member variables of Thread have been assigned values.

Start the thread and drive!

Usually, we start a thread like this.

 Thread threadDemo = new Thread(() -> { 
 
 }); 
 
 threadDemo.start();

So what kind of secret is hidden behind start()? Is it the distortion of human nature? Or the decline of morality? Let's click on start() and explore the secret behind start().

 //As we can see, this method is locked. The reason is to prevent developers from calling this method of the same Thread instance from other threads, thereby avoiding exceptions as much as possible. 
 
 //The reason why this method can execute the run() method in the Runnable we passed in is that the JVM calls the run() method of the Thread instance. 
 
 public synchronized void start() { 
 
 // Check if the thread status is 0. If it is 0, it means it is a new state, that is, it has not been started (). If it is not 0, an exception is thrown. 
 
 //That is to say, for a Thread instance, we can only call the start() method once. 
 
        if (threadStatus != 0) 
 
            throw new IllegalThreadStateException(); 
 
 //From here on, the real thread is added to the ThreadGroup group. To repeat, the previous step only increments the nUnstartedThreads counter, but does not add threads. 
 
 //At the same time, when the thread is started, the nUnstartedThreads counter will be -1. Because there is one less thread in the ready state! 
 
 group . add ( this ); 
 
 started = false ; 
 
 try { 
 
 nativeCreate(this, stackSize, daemon); //Another Native method. This is handled by the JVM, which calls the run() method of the Thread instance. 
 
 started = true ; 
 
 finally 
 
 try { 
 
                if (!started) { 
 
 group .threadStartFailed(this); //If the thread is not started successfully, it will be removed from the ThreadGroup and the nUnstartedThreads counter will be incremented by 1. 
 
 } 
 
            } catch (Throwable ignore ) { 
 
                
 
 } 
 
 } 
 
 }

Well, the most essential function is native, so let's treat it as a black box. Just know that it can call the run() method of the Thread instance. Then let's see what magical things the run() method does?

Black Experiment

The above experiment shows that we can use Thread as Runnable.

Several common thread methods (operations)

The untold secret of Thread.sleep()

We usually use Thread.sleep() frequently, so let's study what happens when Thread.sleep() is called.

Before we begin, let me introduce a concept - nanoseconds. 1 nanosecond = one billionth of a second. It can be seen that using it to time will be very accurate. However, due to equipment limitations, this value is sometimes not so accurate, but it is still much smaller than the control granularity of milliseconds.

 //The Thread.sleep(long) method we usually call is called this method, and the last unfamiliar parameter is nanoseconds. 
 
 // You can control threads at nanosecond level. 
 
 public   static void sleep(long millis, int nanos) 
 
    throws InterruptedException { 
 
 //The following three tests are to see if the millisecond and nanosecond settings are legal. 
 
 if (millis < 0) { 
 
            throw new IllegalArgumentException( "millis < 0: " + millis); 
 
 } 
 
 if (nanos < 0) { 
 
            throw new IllegalArgumentException( "nanos < 0: " + nanos); 
 
 } 
 
 if (nanos > 999999) { 
 
            throw new IllegalArgumentException( "nanos > 999999: " + nanos); 
 
 } 
 
     
 
        if (millis == 0 && nanos == 0) { 
 
 if (Thread.interrupted()) { //When the sleep time is 0, check whether the thread is interrupted and clear the thread's interrupt status flag. This is a Native method. 
 
 throw new InterruptedException(); //If the thread is set to interrupted state as true (call Thread.interrupt()), then it will throw an exception. If you return the thread after catching this exception , the thread will stop. 
 
 //Note that after calling Thread.sleep(), the result of calling isInterrupted() is always False . Don't forget that Thread.interrupted() will also clear the mark position while detecting! 
 
 } 
 
 return ; 
 
 } 
 
 long start = System.nanoTime(); //Similar to System.currentTimeMillis(). But it gets nanoseconds, which may not be accurate. 
 
        long duration = (millis * NANOS_PER_MILLI) + nanos; 
 
 Object lock = currentThread().lock; //Get the lock of the current thread. 
 
 synchronized (lock) { //Synchronize the lock object of the current thread 
 
 while ( true ) { 
 
 sleep(lock, millis, nanos); //This is another Native method, and it will also throw an InterruptedException. 
 
 // According to my estimation, the duration of sleep after calling this function is uncertain. 
 
                long now = System.nanoTime(); 
 
 long elapsed = now - start; //Calculate how long the thread has been sleeping 
 
 if (elapsed >= duration) { //If the current sleep duration has met our needs, exit the loop and the sleep ends. 
 
 break; 
 
 } 
 
 duration -= elapsed; //Subtract the time you have slept and recalculate the time you need to sleep. 
 
 start = now; 
 
 millis = duration / NANOS_PER_MILLI; //Recalculate the millisecond part 
 
 nanos = ( int ) (duration % NANOS_PER_MILLI); //Recalculate the microsecond part 
 
 } 
 
 } 
 
 }

From the above analysis, we can know that the core method of making a thread sleep is a Native function sleep(lock, millis, nanos), and its sleep duration is uncertain. Therefore, the Thread.sleep() method uses a loop to check whether the sleep duration meets the requirement each time.

At the same time, it should be noted that if the thread's interrupted state is set to true when calling the sleep() method, an InterruptedException will be thrown before starting the sleep loop.

What is Thread.yield() hiding?

This method is native. Calling this method can prompt the CPU that the current thread will give up the current CPU usage rights and compete with other threads for new CPU usage rights. The current thread may or may not be able to execute again. That's it.

What is the ubiquitous wait()?

You must have often seen that no matter which object instance, there will be several methods named wait() at the bottom. Wait? What kind of existence are they? Let's click to see.

Oh my god, they are all Native functions.

[[186444]]

Then take a look at the documentation to see what it is.

According to the description in the document, wait(), together with notify() and notifyAll(), can realize inter-thread communication, i.e. synchronization. When calling wait() in a thread, it must be called in a synchronized code block, otherwise an IllegalMonitorStateException will be thrown. This is because the wait() function needs to release the lock of the corresponding object. When the thread executes wait(), the object will put the current thread into its own thread pool, release the lock, and then block it. Until the object calls notify() or notifyAll(), the thread can regain, or possibly obtain, the lock of the object and continue to execute the following statements.

Uh... OK, let me explain the difference between notify() and notifyAll().

• notify()

After calling notify(), the object will randomly select a thread from its own thread pool (that is, the thread that called the wait() function on the object) to wake it up. That is, only one thread can be woken up at a time. If you only call notify() once in a multi-threaded environment, only one thread can be woken up, and the other threads will always be in the same thread pool.

• notifyAll()

After calling notifyAll(), the object will wake up all threads in its thread pool, and then these threads will grab the lock of the object together.

Digging the love-hate relationship between Looper, Handler, and MessageQueue

We may have written code like this in the past:

Many students know that when using Handler in a thread (except the Android main thread), it must be placed between Looper.prepare() and Looper.loop(). Otherwise, a RuntimeException will be thrown. But why do we do this? Let's take a look at the inside story.

[[186445]]

Start with Looper.prepare()

What happens when Looper.prepare() is called?

After the above analysis, we already know what happens after Looper.prepare() is called.

But here comes the problem! sThreadLocal is a static ThreadLocal instance (in Android, the type of ThreadLocal is fixed as Looper). That is, all threads in the current process share this ThreadLocal. So, since Looper.prepare() is a static method, how does Looper determine which thread it should establish a binding relationship with now? Let's dig deeper.

Let's take a look at ThreadLocal's get() and set() methods.

Creating a Handler

Handler can be used to achieve communication between threads. In Android, when we finish data processing in the child thread, we often need to use Handler to notify the main thread to update the UI. Usually we use new Handler() to create a Handler instance in a thread, but how does it know which thread's task it should handle? Let's take a look at Handler together.

 public Handler() { 
 
 this( null , false ); 
 
 } 
 
     
 
 public Handler(Callback callback, boolean async) { //As you can see, this method is finally called. 
 
        if (FIND_POTENTIAL_LEAKS) { 
 
            final Class<? extends Handler> klass = getClass(); 
 
            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) && 
 
                    (klass.getModifiers() & Modifier. STATIC ) == 0) { 
 
                Log.w(TAG, "The following Handler class should be static or leaks might occur: " + 
 
                    klass.getCanonicalName()); 
 
 } 
 
 } 
 
 mLooper = Looper.myLooper(); //The key point! Here the Handler is bound to the Looper of the current Thread. Looper.myLooper() is to get the Looper of the current thread from ThreadLocale. 
 
        if (mLooper == null ) { 
 
 //If Looper.prepare () is not called before new Handler() in the child thread, the Looper of the current thread has not been created yet. This exception will be thrown. 
 
            throw new RuntimeException( 
 
 "Can't create handler inside thread that has not called Looper.prepare()" ); 
 
 } 
 
 mQueue = mLooper.mQueue; //Assign Looper's MessageQueue to Handler. 
 
 mCallback = callback; 
 
        mAsynchronous = async; 
 
 }

Looper.loop()

We all know that after the Handler is created, Looper.loop() needs to be called, otherwise sending messages to the Handler is useless! Next, let's take a look at what kind of magic Looper has that can accurately send messages to the Handler for processing.

 public   static void loop() { 
 
 final Looper me = myLooper(); //This method has been mentioned before, which is to get the Looper object in the current thread. 
 
 if (me == null ) { 
 
 //If there is no Looper.prepare (), an error will be reported! 
 
            throw new RuntimeException( "No Looper; Looper.prepare() wasn't called on this thread." ); 
 
 } 
 
 final MessageQueue queue = me.mQueue; //Get the MessageQueue member variable of Looper, which is new when Looper is created. 
 
 //This is a native method, which is used to detect whether the current thread belongs to the current process. And it will continue to track its true identity. 
 
 //In the IPC mechanism, this method is used to clear the pid and uid information of IPCThreadState. And return an identity to facilitate restoration using restoreCallingIdentity(). 
 
        Binder.clearCallingIdentity(); 
 
        final long ident = Binder.clearCallingIdentity(); 
 
 for (;;) { //Key point (knock on the blackboard)! This is an infinite loop, waiting to extract messages and send messages. 
 
 Message msg = queue.next (); // Extract a message from the MessageQueue. We will see how to extract it later. 
 
            if (msg == null ) { 
 
                // No message indicates that the message queue is quitting. 
 
 return ; 
 
 } 
 
            // This must be in a local variable, in   case a UI event sets the logger 
 
            final Printer logging = me.mLogging; 
 
            if (logging != null ) { 
 
                logging.println( ">>>>> Dispatching to " + msg.target + " " + 
 
                        msg.callback + ": " + msg.what); 
 
 } 
 
 final long traceTag = me.mTraceTag; //Get the trace tag of MessageQueue 
 
            if (traceTag != 0) { 
 
 Trace.traceBegin(traceTag, msg.target.getTraceName(msg)); //Start tracing the current message in the MessageQueue of this thread. This is a Native method. 
 
 } 
 
 try { 
 
 msg.target.dispatchMessage(msg); //Try to dispatch the message to the Handler bound to Message 
 
 finally 
 
                if (traceTag != 0) { 
 
 Trace.traceEnd(traceTag); //This is used in conjunction with Trace.traceBegin(). 
 
 } 
 
 } 
 
            if (logging != null ) { 
 
                logging.println( "<<<<< Finished to " + msg.target + " " + msg.callback); 
 
 } 
 
             
 
 final long newIdent = Binder.clearCallingIdentity(); //what？ This Native method is called again. The main purpose here is to verify again whether the process where the thread is located has changed. 
 
            if (ident != newIdent) { 
 
                Log.wtf(TAG, "Thread identity changed from 0x"   
 
                        + Long.toHexString(ident) + " to 0x"   
 
                        + Long.toHexString(newIdent) + " while dispatching to "   
 
                        + msg.target.getClass().getName() + " "   
 
                        + msg.callback + " what=" + msg.what); 
 
 } 
 
 msg.recycleUnchecked(); //Recycle and release messages. 
 
 } 
 
 }

From the above analysis, we can know that after calling Looper.loop(), the thread will be blocked by a for(;;) infinite loop, waiting for the next() method of MessageQueue to take out a Message before continuing to execute. Then the corresponding Handler (target member variable) is obtained through the Message, and the Handler dispatches the Message to handleMessage() for processing through the dispatchMessage() method.

It should be noted here that when the thread is in a loop, the thread will remain in the loop. This means that the code after Looper.loop() cannot be executed. If you want to execute it, you need to exit the loop first.

 Looper myLooper = Looper.myLoop(); 
 
 myLooper.quit(); //Normal exit method. 
 
 myLooper.quitSafely(); //Safe way to exit.

Now another question arises, how does the next() method of MessageQueue block the thread? Next, let's take a look at the MessageQueue behind the scenes.

MessageQueue behind the scenes

MessageQueue is a single-link data structure that maintains a message list.

As you can see, when MessageQueue retrieves a message (calls next()), it will enter an infinite loop until a message is retrieved and returned. This is why Looper.loop() will wait at queue.next().

So, how is a Message added to the MessageQueue? To find out the truth, we need to investigate the mHandler.post() method.

What exactly does the Handler do with the Message?

The Handler's post() series of methods ultimately call the following method:

Next, let's take a look at what enqueueMessage() of MessageQueue does.

So far, we have revealed the hidden secrets of Looper, Handler, and MessageQueue.

Another question?

Maybe you have noticed that Handler can be used directly in the main thread without Looper.prepare() and Looper.loop(). Why is this possible? According to the previous analysis, Looper.prepare() and Looper.loop() must exist in the main thread. In this case, why is the main thread not blocked by loop()? Let's take a look at ActivityThread to find out what's going on.

Note that ActivityThread does not inherit Thread. Its Handler is a private inner class H.class that inherits Handler. In handleMessage() of H.class, it receives and executes various life cycle status messages in the main thread. The 16ms drawing of the UI is also implemented through the Handler. In other words, all operations in the main thread are performed between Looper.prepareMainLooper() and Looper.loop(). In other words, they are performed in the main Handler.

Summarize

1. In Android, Thread is initialized when it is created, and the current thread is used as the parent thread and inherits some of its configurations.
2. When a Thread is initialized, it will be added to the ThreadGroup of the specified/parent thread for management.
3. Thread is actually started by a native function.
4. In the inter-thread communication of Android, you need to create a Looper first, that is, call Looper.prepare(). In this process, it will automatically depend on the current Thread and create a MessageQueue. After the previous step, you can create a Handler. By default, the Handler will automatically depend on the Looper of the current thread, and thus depend on the corresponding MessageQueue, so you know where to put the message. MessageQueue implements a single linked list structure to cache Message through Message.next. The message needs to be sent to the Handler for processing, and Looper.loop() must be called to start the thread's message pumping loop. The loop() is a *** loop inside, which is blocked on the next() method of MessageQueue, because the next() method is also a *** loop inside, until a message is successfully extracted from the linked list and returned. Then, continue processing in the loop() method, mainly sending the message to the target Handler. Then enter the next loop and wait for the next message. Due to this mechanism, the thread is equivalent to being blocked in the loop().

After the above disclosure, we have learned about the secrets of threads and their communication. After mastering these, I believe that in the future development process, we can use threads with clear ideas and absorb the essence of Android's design process.