Thread線程是如何運作的

這篇文章將為大家詳細講解有關Thread線程是如何運作的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

線程創建的起始點init()

// 創建Thread的公有構造函數，都調用的都是這個私有的init()方法。我們看看到底干什么了。 /**      *      * @param 線程組      * @param 就是我們平時接觸最多的Runnable同學      * @param 指定線程的名稱      * @param 指定線程堆棧的大小      */ private void init(ThreadGroup g, Runnable target, String name, long stackSize) {         Thread parent = currentThread();             //先獲取當前運行中的線程。這一個Native函數，暫時不用理會它怎么做到的。黑盒思想，哈哈！         if (g == null) {             g = parent.getThreadGroup();             //如果沒有指定ThreadGroup，將獲取父線程的TreadGroup         }          g.addUnstarted();                            //將ThreadGroup中的就緒線程計數器增加一。注意，此時線程還并沒有被真正加入到ThreadGroup中。         this.group = g;                              //將Thread實例的group賦值。從這里開始線程就擁有ThreadGroup了。          this.target = target;                        //給Thread實例設置Runnable。以后start()的時候執行的就是它了。         this.priority = parent.getPriority();        //設置線程的優先權重為父線程的權重         this.daemon = parent.isDaemon();             //根據父線程是否是守護線程來確定Thread實例是否是守護線程。         setName(name);                               //設置線程的名稱            init2(parent);                               //納尼？又一個初始化，參數還是父線程。不急，稍后在看。          /* Stash the specified stack size in case the VM cares */         this.stackSize = stackSize;                  //設置線程的堆棧大小         tid = nextThreadID();                        //線程的id。這是個靜態變量，調用這個方法會自增，然后作為線程的id。     }

第二個init2()

private void init2(Thread parent) {         this.contextClassLoader = parent.getContextClassLoader();            //設置ClassLoader成員變量         this.inheritedAccessControlContext = AccessController.getContext();  //設置訪問權限控制環境         if (parent.inheritableThreadLocals != null) {             this.inheritableThreadLocals = ThreadLocal.createInheritedMap(   //創建Thread實例的ThreadLoacaleMap。需要用到父線程的ThreadLocaleMap，目的是為了將父線程中的變量副本拷貝一份到當前線程中。             //ThreadLocaleMap是一個Entry型的數組，Thread實例會將變量副本保存在這里面。                     parent.inheritableThreadLocals);                 }     }

至此，我們的Thread就初始化完成了，Thread的幾個重要成員變量都賦值了。

啟動線程，開車啦!

通常，我們這樣了啟動一條線程。

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

那么start()背后究竟隱藏著什么樣不可告人的秘密呢?是人性的扭曲?還是道德的淪喪?讓我們一起點進start()。探尋start()背后的秘密。

//如我們所見，這個方法是加了鎖的。 //原因是避免開發者在其它線程調用同一個Thread實例的這個方法，從而盡量避免拋出異常。 //這個方法之所以能夠執行我們傳入的Runnable里的run()方法， //是應為JVM調用了Thread實例的run()方法。 public synchronized void start() {         //檢查線程狀態是否為0，為0表示是一個新狀態，即還沒被start()過。不為0就拋出異常。         //就是說，我們一個Thread實例，我們只能調用一次start()方法。         if (threadStatus != 0)             throw new IllegalThreadStateException();          //從這里開始才真正的線程加入到ThreadGroup組里。 //再重復一次，前面只是把nUnstartedThreads這個計數器進行了增量，并沒有添加線程。         //同時，當線程啟動了之后，nUnstartedThreads計數器會-1。因為就緒狀態的線程少了一條啊！         group.add(this);          started = false;         try {             nativeCreate(this, stackSize, daemon);   //又是個Native方法。這里交由JVM處理，會調用Thread實例的run()方法。             started = true;         } finally {             try {                 if (!started) {                     group.threadStartFailed(this);   //如果沒有被啟動成功，Thread將會被移除ThreadGroup， //同時，nUnstartedThreads計數器又增量1了。                 }             } catch (Throwable ignore) {              }         }     }

好把，最精華的函數是native的，先當黑盒處理吧。只要知道它能夠調用到Thread實例的run()方法就行了。那我們再看看run()方法到底干了什么神奇的事呢?

//沒錯，就是這么簡單！僅僅調用了Runnable類型的成員變量target的run()方法。 //至此，我們需要執行的代碼就執行起來了。 //至于這個@Overrid的存在，完全是因為Thread本身也是一個Runnable！ //就是說，我們的Thread也可以作為一個Runnable來使用。 @Override public void run() {         if (target != null) {             target.run();         }     }

黑實驗

public void test_1() {     Thread thread1 = new Thread(() -> {       System.out.println(Thread.currentThread().getName());     }, "Thread_1");       Thread thread2 = new Thread(thread1, "Thread_2");     thread2.start();   }   --- 輸出： Thread_2

上面的實驗表明了，我們完全可以用Thread來作為Runnable。

幾個常見的線程手段(操作)

Thread.sleep()那不可告人的秘密

我們平時使用Thread.sleep()的頻率也比較高，所以我們在一起研究研究Thread.sleep()被調用的時候發生了什么。

在開始之前，先介紹一個概念——納秒。1納秒=十億分之一秒。可見用它計時將會非常的精準。但是由于設備限制，這個值有時候并不是那么準確，但還是比毫秒的控制粒度小很多。

//平時我們調用的Thread.sleep(long)***調用到這個方法來，后一個陌生一點的參數就是納秒。 //你可以在納秒級控制線程。 public static void sleep(long millis, int nanos)     throws InterruptedException {         //下面三個檢測毫秒和納秒的設置是否合法。         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()) {    //當睡眠時間為0時，檢測線程是否中斷， //并清除線程的中斷狀態標記。這是個Native的方法。               throw new InterruptedException();   //如果線程被設置了中斷狀態為true了(調用Thread.interrupt())。 //那么他將拋出異常。如果在catch住這個異常之后return線程，那么線程就停止了。    //需要注意，在調用了Thread.sleep()之后，再調用isInterrupted()得到的結果永遠是False。 //別忘了Thread.interrupted()在檢測的同時還會清除標記位置哦！             }             return;         }          long start = System.nanoTime();   //類似System.currentTimeMillis()。但是獲取的是納秒，可能不準。         long duration = (millis * NANOS_PER_MILLI) + nanos;            Object lock = currentThread().lock;   //獲得當前線程的鎖。          synchronized (lock) {    //對當前線程的鎖對象進行同步操作             while (true) {                 sleep(lock, millis, nanos);   //這里又是一個Native的方法，并且也會拋出InterruptedException異常。                 //據我估計，調用這個函數睡眠的時長是不確定的。                  long now = System.nanoTime();                 long elapsed = now - start;   //計算線程睡了多久了                  if (elapsed >= duration) {    //如果當前睡眠時長，已經滿足我們的需求，就退出循環，睡眠結束。                     break;                 }                  duration -= elapsed;    //減去已經睡眠的時間，重新計算需要睡眠的時長。                 start = now;                 millis = duration / NANOS_PER_MILLI;   //重新計算毫秒部分                 nanos = (int) (duration % NANOS_PER_MILLI);  //重新計算微秒部分             }         }     }

通過上面的分析可以知道，使線程休眠的核心方法就是一個Native函數sleep(lock, millis,  nanos)，并且它休眠的時常是不確定的。因此，Thread.sleep()方法使用了一個循環，每次檢查休眠時長是否滿足需求。

同時，需要注意一點，如果線程的interruted狀態在調用sleep()方法時被設置為true，那么在開始休眠循環前會拋出InterruptedException異常。

Thread.yield()究竟隱藏了什么?

這個方法是Native的。調用這個方法可以提示cpu，當前線程將放棄目前cpu的使用權，和其它線程重新一起爭奪新的cpu使用權限。當前線程可能再次獲得執行，也可能沒獲得。就醬。

無處不在的wait()究竟是什么?

大家一定經常見到，不論是哪一個對象的實例，都會在最下面出現幾個名為wait()的方法。等待?它們究竟是怎樣的一種存在，讓我們一起點擊去看看。

哎喲我去，都是Native函數啊。

那就看看文檔它到底是什么吧。

根據文檔的描述，wait()配合notify()和notifyAll()能夠實現線程間通訊，即同步。在線程中調用wait()必須在同步代碼塊中調用，否則會拋出IllegalMonitorStateException異常。因為wait()函數需要釋放相應對象的鎖。當線程執行到wait()時，對象會把當前線程放入自己的線程池中，并且釋放鎖，然后阻塞在這個地方。直到該對象調用了notify()或者notifyAll()后，該線程才能重新獲得，或者有可能獲得對象的鎖，然后繼續執行后面的語句。

呃。。。好吧，在說明一下notify()和notifyAll()的區別。

• notify()

調用notify()后，對象會從自己的線程池中(也就是對該對象調用了wait()函數的線程)隨機挑選一條線程去喚醒它。也就是一次只能喚醒一條線程。如果在多線程情況下，只調用一次notify()，那么只有一條線程能被喚醒，其它線程會一直在

• notifyAll()

調用notifyAll()后，對象會喚醒自己的線程池中的所有線程，然后這些線程就會一起搶奪對象的鎖。

扒一扒Looper、Handler、MessageQueue之間的愛恨情仇

我們可能過去都寫過形如這樣的代碼：

new Thread(()->{      ...     Looper.prepare();     Handler handler = new Handler(){         @Override         public void handleMessage(Message msg) {           super.handleMessage(msg);         }       };     Looper.loop();  }).start()

很多同學知道，在線程中使用Handler時(除了Android主線程)必須把它放在Looper.prepare()和Looper.loop()之間。否則會拋出RuntimeException異常。但是為什么要這么做呢?下面我們一起來扒一扒這其中的內幕。

從Looper.prepare()開始

當Looper.prepare()被調用時，發生了什么?

public static void prepare() {         prepare(true);   //最終其實執行的是私有方法prepare(boolean quitAllowed)中的邏輯     }      private static void prepare(boolean quitAllowed) {         if (sThreadLocal.get() != null) {    //先嘗試獲取是否已經存在一個Looper在當前線程中，如果有就拋個異常。         //這就是為什么我們不能在一個Thread中調用兩次Looper.prepare()的原因。             throw new RuntimeException("Only one Looper may be created per thread");         }         sThreadLocal.set(new Looper(quitAllowed));   //***調用的話，就創建一個新的Looper。     }      //Looper的私有構造函數     private Looper(boolean quitAllowed) {         mQueue = new MessageQueue(quitAllowed);    //創建新的MessageQueue，稍后在來扒它。         mThread = Thread.currentThread();          //把當前的線程賦值給mThread。     }

經過上面的分析，我們已經知道Looper.prepare()調用之后發生了什么。

但是問題來了!sThreadLocal是個靜態的ThreadLocal<Looper>  實例(在Android中ThreadLocal的范型固定為Looper)。就是說，當前進程中的所有線程都共享這一個ThreadLocal<Looper>。那么，Looper.prepare()既然是個靜態方法，Looper是如何確定現在應該和哪一個線程建立綁定關系的呢?我們接著往里扒。

來看看ThreadLocal的get()、set()方法。

public T get() {         Thread t = Thread.currentThread();    //重點啊！獲取到了當前運行的線程。         ThreadLocalMap map = getMap(t);       //取出當前線程的ThreadLocalMap。這個東西是個重點，前面已經提到過。 //忘了的同學在前面再看看。         if (map != null) {             ThreadLocalMap.Entry e = map.getEntry(this);               //可以看出，每條線程的ThreadLocalMap中都有一個<ThreadLocal,Looper>鍵值對。 //綁定關系就是通過這個鍵值對建立的。             if (e != null)                 return (T)e.value;         }         return setInitialValue();     }  public void set(T value) {         Thread t = Thread.currentThread();   //同樣先獲取到當前的線程         ThreadLocalMap map = getMap(t);      //獲取線程的ThreadLocalMap         if (map != null)             map.set(this, value);            //儲存鍵值對         else             createMap(t, value);     }

創建Handler

Handler可以用來實現線程間的通行。在Android中我們在子線程作完數據處理工作時，就常常需要通過Handler來通知主線程更新UI。平時我們都使用new  Handler()來在一個線程中創建Handler實例，但是它是如何知道自己應該處理那個線程的任務呢。下面就一起扒一扒Handler。

public Handler() {         this(null, false);  }  public Handler(Callback callback, boolean async) {      //可以看到，最終調用了這個方法。         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();                     //重點啊！在這里Handler和當前Thread的Looper綁定了。 //Looper.myLooper()就是從ThreadLocale中取出當前線程的Looper。         if (mLooper == null) {  //如果子線程中new Handler()之前沒有調用Looper.prepare()，那么當前線程的Looper就還沒創建。 //就會拋出這個異常。             throw new RuntimeException(                 "Can't create handler inside thread that has not called Looper.prepare()");         }         mQueue = mLooper.mQueue;   //賦值Looper的MessageQueue給Handler。         mCallback = callback;         mAsynchronous = async;     }

Looper.loop()

我們都知道，在Handler創建之后，還需要調用一下Looper.loop()，不然發送消息到Handler沒有用!接下來，扒一扒Looper究竟有什么樣的魔力，能夠把消息準確的送到Handler中處理。

public static void loop() {         final Looper me = myLooper();    //這個方法前面已經提到過了，就是獲取到當前線程中的Looper對象。         if (me == null) {              //沒有Looper.prepare()是要報錯的！             throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");         }         final MessageQueue queue = me.mQueue;        //獲取到Looper的MessageQueue成員變量，這是在Looper創建的時候new的。   //這是個Native方法，作用就是檢測一下當前線程是否屬于當前進程。并且會持續跟蹤其真實的身份。  //在IPC機制中，這個方法用來清除IPCThreadState的pid和uid信息。并且返回一個身份，便于使用restoreCallingIdentity()來恢復。         Binder.clearCallingIdentity();         final long ident = Binder.clearCallingIdentity();          for (;;) {   //重點(敲黑板)！這里是個死循環，一直等待抽取消息、發送消息。             Message msg = queue.next();  //  從MessageQueue中抽取一條消息。至于怎么取的，我們稍后再看。             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;   //取得MessageQueue的跟蹤標記             if (traceTag != 0) {                 Trace.traceBegin(traceTag, msg.target.getTraceName(msg));   //開始跟蹤本線程的MessageQueue中的當前消息，是Native的方法。             }             try {                 msg.target.dispatchMessage(msg);    //嘗試分派消息到和Message綁定的Handler中             } finally {                 if (traceTag != 0) {                     Trace.traceEnd(traceTag);       //這個和Trace.traceBegin()配套使用。                 }             }              if (logging != null) {                 logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);             }               final long newIdent = Binder.clearCallingIdentity();    //what？又調用這個Native方法了。這里主要是為了再次驗證，線程所在的進程是否發生改變。             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();    //回收釋放消息。         }     }

從上面的分析可以知道，當調用了Looper.loop()之后，線程就就會被一個for(;;)死循環阻塞，每次等待MessageQueue的next()方法取出一條Message才開始往下繼續執行。然后通過Message獲取到相應的Handler  (就是target成員變量)，Handler再通過dispatchMessage()方法，把Message派發到handleMessage()中處理。

這里需要注意，當線程loop起來是時，線程就一直在循環中。就是說Looper.loop()后面的代碼就不能被執行了。想要執行，需要先退出loop。

Looper myLooper = Looper.myLoop(); myLooper.quit();        //普通退出方式。 myLooper.quitSafely();  //安全的退出方式。

現在又產生一個疑問，MessageQueue的next()方法是如何阻塞住線程的呢?接下來，扒一扒這個幕后黑手MessageQueue。

幕后黑手MessageQueue

MessageQueue是一個用單鏈的數據結構來維護消息列表。

Message next() {  //檢查loop是否已經為退出狀態。mPrt是Native層的MessageQueue的地址。 //通過這個地址可以和Native層的MessageQueue互動。         final long ptr = mPtr;         if (ptr == 0) {             return null;         }          int pendingIdleHandlerCount = -1;         int nextPollTimeoutMillis = 0;       //時間標記，當且僅當***次獲取消息時才為0。因為它在死循環外面啊！         for (;;) {             if (nextPollTimeoutMillis != 0) {                 Binder.flushPendingCommands();      //如果不是***次獲取消息，調用Native的函數，讓虛擬機刷新所有的餓Binder命令， //確保進程在執行可能阻塞的任務之前，釋放之前的對象。             }              //這是一個Native的方法。             nativePollOnce(ptr, nextPollTimeoutMillis);              synchronized (this) {       //鎖住MessageQueue                 //獲取當前的系統時間，用于后面和msg.when進行比較。                 final long now = SystemClock.uptimeMillis();                 Message prevMsg = null;                 Message msg = mMessages;         //獲得當前MessageQueue中的***條消息                 if (msg != null && msg.target == null) {                      do {                         prevMsg = msg;                         msg = msg.next;                     } while (msg != null && !msg.isAsynchronous());                 }                 if (msg != null) {                     if (now < msg.when) {   //這個判斷的意義在于只有到了Message應該被發送的時刻才去發送，否則繼續循環。  //計算下一條消息的時間。注意***就是Integer.MAX_VALUE。                         nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);                     } else {  //應該發送一條消息了。                         // Got a message.                         mBlocked = false;                         if (prevMsg != null) {                             prevMsg.next = msg.next;                         } else {                             mMessages = msg.next;                         }                         msg.next = null;                         if (DEBUG) Log.v(TAG, "Returning message: " + msg);                         msg.markInUse();    //轉換消息標記為使用過的                         return msg;          //返回一條消息給Looper。                     }                 } else {                     // 如果取到的Message為null，將時間標記設置為-1。                     nextPollTimeoutMillis = -1;                 }                  // Process the quit message now that all pending messages have been handled.                 if (mQuitting) {                     dispose();                     return null;                 }                  // If first time idle, then get the number of idlers to run.                 // Idle handles only run if the queue is empty or if the first message                 // in the queue (possibly a barrier) is due to be handled in the future.                 if (pendingIdleHandlerCount < 0                         && (mMessages == null || now < mMessages.when)) {                     pendingIdleHandlerCount = mIdleHandlers.size();                 }                 if (pendingIdleHandlerCount <= 0) {                     // No idle handlers to run.  Loop and wait some more.                     mBlocked = true;                     continue;                 }                  if (mPendingIdleHandlers == null) {                     mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];                 }                 mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);             }              // Run the idle handlers.             // We only ever reach this code block during the first iteration.             for (int i = 0; i < pendingIdleHandlerCount; i++) {                 final IdleHandler idler = mPendingIdleHandlers[i];                 mPendingIdleHandlers[i] = null; // release the reference to the handler                  boolean keep = false;                 try {                     keep = idler.queueIdle();                 } catch (Throwable t) {                     Log.wtf(TAG, "IdleHandler threw exception", t);                 }                  if (!keep) {                     synchronized (this) {                         mIdleHandlers.remove(idler);                     }                 }             }              // Reset the idle handler count to 0 so we do not run them again.             pendingIdleHandlerCount = 0;              // While calling an idle handler, a new message could have been delivered             // so go back and look again for a pending message without waiting.             nextPollTimeoutMillis = 0;         }     }

可以看到。MessageQueue在取消息(調用next())時，會進入一個死循環，直到取出一條Message返回。這就是為什么Looper.loop()會在queue.next()處等待的原因。

那么，一條Message是如何添加到MessageQueue中呢?要弄明白***的真相，我們需要調查一下mHandler.post()這個方法。

Handler究竟對Message做了什么?

Handler的post()系列方法，最終調用的都是下面這個方法：

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {         msg.target = this;       //在這里給Message的target賦值。         if (mAsynchronous) {             msg.setAsynchronous(true);       //如果是異步，就標記為異步         }         return queue.enqueueMessage(msg, uptimeMillis);      //就是這個方法把Message添加到線程的MessageQueue中的。     }

接下來就看看MessageQueue的enqueueMessage()作了什么。

boolean enqueueMessage(Message msg, long when) {         if (msg.target == null) {    //沒Handler調用是會拋異常的啊             throw new IllegalArgumentException("Message must have a target.");         }         if (msg.isInUse()) {         //不能使用一條正在使用中的Message。             throw new IllegalStateException(msg + " This message is already in use.");         }          synchronized (this) {        //鎖住MessageQueue再往里添加消息。             if (mQuitting) {         //如果MessageQueue被標記為退出，就返回。                 IllegalStateException e = new IllegalStateException(                         msg.target + " sending message to a Handler on a dead thread");                 Log.w(TAG, e.getMessage(), e);                 msg.recycle();                 return false;             }              msg.markInUse();         //切換Message的使用狀態為未使用。             msg.when = when;         //我們設置的延遲發送的時間。  //經過下面的邏輯，Message將會被“儲存”在MessageQueue中。 //實際上，Message在MessageQueue中的儲存方式， //是使用Message.next逐個向后指向的單鏈表結構來儲存的。 //比如：A.next = B, B.next = C...             Message p = mMessages;   //嘗試獲取當前Message             boolean needWake;             if (p == null || when == 0 || when < p.when) {                 // 如果為null，說明是***條。                 msg.next = p;                    mMessages = msg;     //設置當前的Message為傳入的Message，也就是作為***條。                 needWake = mBlocked;             } else {                  needWake = mBlocked && p.target == null && msg.isAsynchronous();                 Message prev; //不滿足作為***條Message的條件時，通過下面的逐步變換，將它放在***面。 //這樣便把Message“儲存”到MessageQueue中了。                 for (;;) {                     prev = p;                     p = p.next;                     if (p == null || when < p.when) {                         break;                     }                     if (needWake && p.isAsynchronous()) {                         needWake = false;                     }                 }                 msg.next = p;                  prev.next = msg;             }               if (needWake) {                 nativeWake(mPtr);             }         }         return true;     }

至此，我們已經揭露了Looper、Handler、MessageQueue隱藏的秘密。

另一個疑問?

也許你已經注意到在主線程中可以直接使用Handler，而不需要Looper.prepare()和Looper.loop()。為什么可以做到這樣呢?根據之前的分析可以知道，主線程中必然存在Looper.prepare()和Looper.loop()。既然如此，為什么主線程沒有被loop()阻塞呢?看一下ActivityThread來弄清楚到底是怎么回事。

//這個main()方法可以認為是Android應用的起點 public static void main(String[] args) {                 。                 。                 。         Looper.prepareMainLooper();                              //主要作用和我們平時調用的Looper.prepare()差不多          ActivityThread thread = new ActivityThread();            //創建本類實例         thread.attach(false);          if (sMainThreadHandler == null) {             sMainThreadHandler = thread.getHandler();            //重點啊！這里取得了處理主線程事物的Handler。         }          if (false) {             Looper.myLooper().setMessageLogging(new                     LogPrinter(Log.DEBUG, "ActivityThread"));         }          // End of event ActivityThreadMain.         Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);         Looper.loop();                                           //開始循環。可以看到，主線程本質上是阻塞的！                 。                 。                 。         }

注意ActivityThread并沒有繼承Thread，它的Handler是繼承Handler的私有內部類H.class。在H.class的handleMessage()中，它接受并執行主線程中的各種生命周期狀態消息。UI的16ms的繪制也是通過Handler來實現的。也就是說，主線程中的所有操作都是在Looper.prepareMainLooper()和Looper.loop()之間進行的。進一步說是在主Handler中進行的。

關于Thread線程是如何運作的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。