這篇文章將為大家詳細(xì)講解有關(guān)Thread線程是如何運(yùn)作的,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個(gè)參考,希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。
線程創(chuàng)建的起始點(diǎn)init()
// 創(chuàng)建Thread的公有構(gòu)造函數(shù),都調(diào)用的都是這個(gè)私有的init()方法。我們看看到底干什么了。 /** * * @param 線程組 * @param 就是我們平時(shí)接觸最多的Runnable同學(xué) * @param 指定線程的名稱 * @param 指定線程堆棧的大小 */ private void init(ThreadGroup g, Runnable target, String name, long stackSize) { Thread parent = currentThread(); //先獲取當(dāng)前運(yùn)行中的線程。這一個(gè)Native函數(shù),暫時(shí)不用理會(huì)它怎么做到的。黑盒思想,哈哈! if (g == null) { g = parent.getThreadGroup(); //如果沒有指定ThreadGroup,將獲取父線程的TreadGroup } g.addUnstarted(); //將ThreadGroup中的就緒線程計(jì)數(shù)器增加一。注意,此時(shí)線程還并沒有被真正加入到ThreadGroup中。 this.group = g; //將Thread實(shí)例的group賦值。從這里開始線程就擁有ThreadGroup了。 this.target = target; //給Thread實(shí)例設(shè)置Runnable。以后start()的時(shí)候執(zhí)行的就是它了。 this.priority = parent.getPriority(); //設(shè)置線程的優(yōu)先權(quán)重為父線程的權(quán)重 this.daemon = parent.isDaemon(); //根據(jù)父線程是否是守護(hù)線程來確定Thread實(shí)例是否是守護(hù)線程。 setName(name); //設(shè)置線程的名稱 init2(parent); //納尼?又一個(gè)初始化,參數(shù)還是父線程。不急,稍后在看。 /* Stash the specified stack size in case the VM cares */ this.stackSize = stackSize; //設(shè)置線程的堆棧大小 tid = nextThreadID(); //線程的id。這是個(gè)靜態(tài)變量,調(diào)用這個(gè)方法會(huì)自增,然后作為線程的id。 }
第二個(gè)init2()
private void init2(Thread parent) { this.contextClassLoader = parent.getContextClassLoader(); //設(shè)置ClassLoader成員變量 this.inheritedAccessControlContext = AccessController.getContext(); //設(shè)置訪問權(quán)限控制環(huán)境 if (parent.inheritableThreadLocals != null) { this.inheritableThreadLocals = ThreadLocal.createInheritedMap( //創(chuàng)建Thread實(shí)例的ThreadLoacaleMap。需要用到父線程的ThreadLocaleMap,目的是為了將父線程中的變量副本拷貝一份到當(dāng)前線程中。 //ThreadLocaleMap是一個(gè)Entry型的數(shù)組,Thread實(shí)例會(huì)將變量副本保存在這里面。 parent.inheritableThreadLocals); } }
至此,我們的Thread就初始化完成了,Thread的幾個(gè)重要成員變量都賦值了。
啟動(dòng)線程,開車?yán)?
通常,我們這樣了啟動(dòng)一條線程。
Thread threadDemo = new Thread(() -> { }); threadDemo.start();
那么start()背后究竟隱藏著什么樣不可告人的秘密呢?是人性的扭曲?還是道德的淪喪?讓我們一起點(diǎn)進(jìn)start()。探尋start()背后的秘密。
//如我們所見,這個(gè)方法是加了鎖的。 //原因是避免開發(fā)者在其它線程調(diào)用同一個(gè)Thread實(shí)例的這個(gè)方法,從而盡量避免拋出異常。 //這個(gè)方法之所以能夠執(zhí)行我們傳入的Runnable里的run()方法, //是應(yīng)為JVM調(diào)用了Thread實(shí)例的run()方法。 public synchronized void start() { //檢查線程狀態(tài)是否為0,為0表示是一個(gè)新狀態(tài),即還沒被start()過。不為0就拋出異常。 //就是說,我們一個(gè)Thread實(shí)例,我們只能調(diào)用一次start()方法。 if (threadStatus != 0) throw new IllegalThreadStateException(); //從這里開始才真正的線程加入到ThreadGroup組里。 //再重復(fù)一次,前面只是把nUnstartedThreads這個(gè)計(jì)數(shù)器進(jìn)行了增量,并沒有添加線程。 //同時(shí),當(dāng)線程啟動(dòng)了之后,nUnstartedThreads計(jì)數(shù)器會(huì)-1。因?yàn)榫途w狀態(tài)的線程少了一條??! group.add(this); started = false; try { nativeCreate(this, stackSize, daemon); //又是個(gè)Native方法。這里交由JVM處理,會(huì)調(diào)用Thread實(shí)例的run()方法。 started = true; } finally { try { if (!started) { group.threadStartFailed(this); //如果沒有被啟動(dòng)成功,Thread將會(huì)被移除ThreadGroup, //同時(shí),nUnstartedThreads計(jì)數(shù)器又增量1了。 } } catch (Throwable ignore) { } } }
好把,最精華的函數(shù)是native的,先當(dāng)黑盒處理吧。只要知道它能夠調(diào)用到Thread實(shí)例的run()方法就行了。那我們?cè)倏纯磖un()方法到底干了什么神奇的事呢?
//沒錯(cuò),就是這么簡單!僅僅調(diào)用了Runnable類型的成員變量target的run()方法。 //至此,我們需要執(zhí)行的代碼就執(zhí)行起來了。 //至于這個(gè)@Overrid的存在,完全是因?yàn)門hread本身也是一個(gè)Runnable! //就是說,我們的Thread也可以作為一個(gè)Runnable來使用。 @Override public void run() { if (target != null) { target.run(); } }
黑實(shí)驗(yàn)
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
上面的實(shí)驗(yàn)表明了,我們完全可以用Thread來作為Runnable。
幾個(gè)常見的線程手段(操作)
Thread.sleep()那不可告人的秘密
我們平時(shí)使用Thread.sleep()的頻率也比較高,所以我們?cè)谝黄鹧芯垦芯縏hread.sleep()被調(diào)用的時(shí)候發(fā)生了什么。
在開始之前,先介紹一個(gè)概念——納秒。1納秒=十億分之一秒。可見用它計(jì)時(shí)將會(huì)非常的精準(zhǔn)。但是由于設(shè)備限制,這個(gè)值有時(shí)候并不是那么準(zhǔn)確,但還是比毫秒的控制粒度小很多。
//平時(shí)我們調(diào)用的Thread.sleep(long)***調(diào)用到這個(gè)方法來,后一個(gè)陌生一點(diǎn)的參數(shù)就是納秒。 //你可以在納秒級(jí)控制線程。 public static void sleep(long millis, int nanos) throws InterruptedException { //下面三個(gè)檢測(cè)毫秒和納秒的設(shè)置是否合法。 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()) { //當(dāng)睡眠時(shí)間為0時(shí),檢測(cè)線程是否中斷, //并清除線程的中斷狀態(tài)標(biāo)記。這是個(gè)Native的方法。 throw new InterruptedException(); //如果線程被設(shè)置了中斷狀態(tài)為true了(調(diào)用Thread.interrupt())。 //那么他將拋出異常。如果在catch住這個(gè)異常之后return線程,那么線程就停止了。 //需要注意,在調(diào)用了Thread.sleep()之后,再調(diào)用isInterrupted()得到的結(jié)果永遠(yuǎn)是False。 //別忘了Thread.interrupted()在檢測(cè)的同時(shí)還會(huì)清除標(biāo)記位置哦! } return; } long start = System.nanoTime(); //類似System.currentTimeMillis()。但是獲取的是納秒,可能不準(zhǔn)。 long duration = (millis * NANOS_PER_MILLI) + nanos; Object lock = currentThread().lock; //獲得當(dāng)前線程的鎖。 synchronized (lock) { //對(duì)當(dāng)前線程的鎖對(duì)象進(jìn)行同步操作 while (true) { sleep(lock, millis, nanos); //這里又是一個(gè)Native的方法,并且也會(huì)拋出InterruptedException異常。 //據(jù)我估計(jì),調(diào)用這個(gè)函數(shù)睡眠的時(shí)長是不確定的。 long now = System.nanoTime(); long elapsed = now - start; //計(jì)算線程睡了多久了 if (elapsed >= duration) { //如果當(dāng)前睡眠時(shí)長,已經(jīng)滿足我們的需求,就退出循環(huán),睡眠結(jié)束。 break; } duration -= elapsed; //減去已經(jīng)睡眠的時(shí)間,重新計(jì)算需要睡眠的時(shí)長。 start = now; millis = duration / NANOS_PER_MILLI; //重新計(jì)算毫秒部分 nanos = (int) (duration % NANOS_PER_MILLI); //重新計(jì)算微秒部分 } } }
通過上面的分析可以知道,使線程休眠的核心方法就是一個(gè)Native函數(shù)sleep(lock, millis, nanos),并且它休眠的時(shí)常是不確定的。因此,Thread.sleep()方法使用了一個(gè)循環(huán),每次檢查休眠時(shí)長是否滿足需求。
同時(shí),需要注意一點(diǎn),如果線程的interruted狀態(tài)在調(diào)用sleep()方法時(shí)被設(shè)置為true,那么在開始休眠循環(huán)前會(huì)拋出InterruptedException異常。
Thread.yield()究竟隱藏了什么?
這個(gè)方法是Native的。調(diào)用這個(gè)方法可以提示cpu,當(dāng)前線程將放棄目前cpu的使用權(quán),和其它線程重新一起爭(zhēng)奪新的cpu使用權(quán)限。當(dāng)前線程可能再次獲得執(zhí)行,也可能沒獲得。就醬。
無處不在的wait()究竟是什么?
大家一定經(jīng)常見到,不論是哪一個(gè)對(duì)象的實(shí)例,都會(huì)在最下面出現(xiàn)幾個(gè)名為wait()的方法。等待?它們究竟是怎樣的一種存在,讓我們一起點(diǎn)擊去看看。
哎喲我去,都是Native函數(shù)啊。
那就看看文檔它到底是什么吧。
根據(jù)文檔的描述,wait()配合notify()和notifyAll()能夠?qū)崿F(xiàn)線程間通訊,即同步。在線程中調(diào)用wait()必須在同步代碼塊中調(diào)用,否則會(huì)拋出IllegalMonitorStateException異常。因?yàn)閣ait()函數(shù)需要釋放相應(yīng)對(duì)象的鎖。當(dāng)線程執(zhí)行到wait()時(shí),對(duì)象會(huì)把當(dāng)前線程放入自己的線程池中,并且釋放鎖,然后阻塞在這個(gè)地方。直到該對(duì)象調(diào)用了notify()或者notifyAll()后,該線程才能重新獲得,或者有可能獲得對(duì)象的鎖,然后繼續(xù)執(zhí)行后面的語句。
呃。。。好吧,在說明一下notify()和notifyAll()的區(qū)別。
notify()
調(diào)用notify()后,對(duì)象會(huì)從自己的線程池中(也就是對(duì)該對(duì)象調(diào)用了wait()函數(shù)的線程)隨機(jī)挑選一條線程去喚醒它。也就是一次只能喚醒一條線程。如果在多線程情況下,只調(diào)用一次notify(),那么只有一條線程能被喚醒,其它線程會(huì)一直在
notifyAll()
調(diào)用notifyAll()后,對(duì)象會(huì)喚醒自己的線程池中的所有線程,然后這些線程就會(huì)一起搶奪對(duì)象的鎖。
扒一扒Looper、Handler、MessageQueue之間的愛恨情仇
我們可能過去都寫過形如這樣的代碼:
new Thread(()->{ ... Looper.prepare(); Handler handler = new Handler(){ @Override public void handleMessage(Message msg) { super.handleMessage(msg); } }; Looper.loop(); }).start()
很多同學(xué)知道,在線程中使用Handler時(shí)(除了Android主線程)必須把它放在Looper.prepare()和Looper.loop()之間。否則會(huì)拋出RuntimeException異常。但是為什么要這么做呢?下面我們一起來扒一扒這其中的內(nèi)幕。
從Looper.prepare()開始
當(dāng)Looper.prepare()被調(diào)用時(shí),發(fā)生了什么?
public static void prepare() { prepare(true); //最終其實(shí)執(zhí)行的是私有方法prepare(boolean quitAllowed)中的邏輯 } private static void prepare(boolean quitAllowed) { if (sThreadLocal.get() != null) { //先嘗試獲取是否已經(jīng)存在一個(gè)Looper在當(dāng)前線程中,如果有就拋個(gè)異常。 //這就是為什么我們不能在一個(gè)Thread中調(diào)用兩次Looper.prepare()的原因。 throw new RuntimeException("Only one Looper may be created per thread"); } sThreadLocal.set(new Looper(quitAllowed)); //***調(diào)用的話,就創(chuàng)建一個(gè)新的Looper。 } //Looper的私有構(gòu)造函數(shù) private Looper(boolean quitAllowed) { mQueue = new MessageQueue(quitAllowed); //創(chuàng)建新的MessageQueue,稍后在來扒它。 mThread = Thread.currentThread(); //把當(dāng)前的線程賦值給mThread。 }
經(jīng)過上面的分析,我們已經(jīng)知道Looper.prepare()調(diào)用之后發(fā)生了什么。
但是問題來了!sThreadLocal是個(gè)靜態(tài)的ThreadLocal<Looper> 實(shí)例(在Android中ThreadLocal的范型固定為Looper)。就是說,當(dāng)前進(jìn)程中的所有線程都共享這一個(gè)ThreadLocal<Looper>。那么,Looper.prepare()既然是個(gè)靜態(tài)方法,Looper是如何確定現(xiàn)在應(yīng)該和哪一個(gè)線程建立綁定關(guān)系的呢?我們接著往里扒。
來看看ThreadLocal的get()、set()方法。
public T get() { Thread t = Thread.currentThread(); //重點(diǎn)??!獲取到了當(dāng)前運(yùn)行的線程。 ThreadLocalMap map = getMap(t); //取出當(dāng)前線程的ThreadLocalMap。這個(gè)東西是個(gè)重點(diǎn),前面已經(jīng)提到過。 //忘了的同學(xué)在前面再看看。 if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); //可以看出,每條線程的ThreadLocalMap中都有一個(gè)<ThreadLocal,Looper>鍵值對(duì)。 //綁定關(guān)系就是通過這個(gè)鍵值對(duì)建立的。 if (e != null) return (T)e.value; } return setInitialValue(); } public void set(T value) { Thread t = Thread.currentThread(); //同樣先獲取到當(dāng)前的線程 ThreadLocalMap map = getMap(t); //獲取線程的ThreadLocalMap if (map != null) map.set(this, value); //儲(chǔ)存鍵值對(duì) else createMap(t, value); }
創(chuàng)建Handler
Handler可以用來實(shí)現(xiàn)線程間的通行。在Android中我們?cè)谧泳€程作完數(shù)據(jù)處理工作時(shí),就常常需要通過Handler來通知主線程更新UI。平時(shí)我們都使用new Handler()來在一個(gè)線程中創(chuàng)建Handler實(shí)例,但是它是如何知道自己應(yīng)該處理那個(gè)線程的任務(wù)呢。下面就一起扒一扒Handler。
public Handler() { this(null, false); } public Handler(Callback callback, boolean async) { //可以看到,最終調(diào)用了這個(gè)方法。 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(); //重點(diǎn)啊!在這里Handler和當(dāng)前Thread的Looper綁定了。 //Looper.myLooper()就是從ThreadLocale中取出當(dāng)前線程的Looper。 if (mLooper == null) { //如果子線程中new Handler()之前沒有調(diào)用Looper.prepare(),那么當(dāng)前線程的Looper就還沒創(chuàng)建。 //就會(huì)拋出這個(gè)異常。 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創(chuàng)建之后,還需要調(diào)用一下Looper.loop(),不然發(fā)送消息到Handler沒有用!接下來,扒一扒Looper究竟有什么樣的魔力,能夠把消息準(zhǔn)確的送到Handler中處理。
public static void loop() { final Looper me = myLooper(); //這個(gè)方法前面已經(jīng)提到過了,就是獲取到當(dāng)前線程中的Looper對(duì)象。 if (me == null) { //沒有Looper.prepare()是要報(bào)錯(cuò)的! throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); } final MessageQueue queue = me.mQueue; //獲取到Looper的MessageQueue成員變量,這是在Looper創(chuàng)建的時(shí)候new的。 //這是個(gè)Native方法,作用就是檢測(cè)一下當(dāng)前線程是否屬于當(dāng)前進(jìn)程。并且會(huì)持續(xù)跟蹤其真實(shí)的身份。 //在IPC機(jī)制中,這個(gè)方法用來清除IPCThreadState的pid和uid信息。并且返回一個(gè)身份,便于使用restoreCallingIdentity()來恢復(fù)。 Binder.clearCallingIdentity(); final long ident = Binder.clearCallingIdentity(); for (;;) { //重點(diǎn)(敲黑板)!這里是個(gè)死循環(huán),一直等待抽取消息、發(fā)送消息。 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的跟蹤標(biāo)記 if (traceTag != 0) { Trace.traceBegin(traceTag, msg.target.getTraceName(msg)); //開始跟蹤本線程的MessageQueue中的當(dāng)前消息,是Native的方法。 } try { msg.target.dispatchMessage(msg); //嘗試分派消息到和Message綁定的Handler中 } finally { if (traceTag != 0) { Trace.traceEnd(traceTag); //這個(gè)和Trace.traceBegin()配套使用。 } } if (logging != null) { logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); } final long newIdent = Binder.clearCallingIdentity(); //what?又調(diào)用這個(gè)Native方法了。這里主要是為了再次驗(yàn)證,線程所在的進(jìn)程是否發(fā)生改變。 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(); //回收釋放消息。 } }
從上面的分析可以知道,當(dāng)調(diào)用了Looper.loop()之后,線程就就會(huì)被一個(gè)for(;;)死循環(huán)阻塞,每次等待MessageQueue的next()方法取出一條Message才開始往下繼續(xù)執(zhí)行。然后通過Message獲取到相應(yīng)的Handler (就是target成員變量),Handler再通過dispatchMessage()方法,把Message派發(fā)到handleMessage()中處理。
這里需要注意,當(dāng)線程loop起來是時(shí),線程就一直在循環(huán)中。就是說Looper.loop()后面的代碼就不能被執(zhí)行了。想要執(zhí)行,需要先退出loop。
Looper myLooper = Looper.myLoop(); myLooper.quit(); //普通退出方式。 myLooper.quitSafely(); //安全的退出方式。
現(xiàn)在又產(chǎn)生一個(gè)疑問,MessageQueue的next()方法是如何阻塞住線程的呢?接下來,扒一扒這個(gè)幕后黑手MessageQueue。
幕后黑手MessageQueue
MessageQueue是一個(gè)用單鏈的數(shù)據(jù)結(jié)構(gòu)來維護(hù)消息列表。
Message next() { //檢查loop是否已經(jīng)為退出狀態(tài)。mPrt是Native層的MessageQueue的地址。 //通過這個(gè)地址可以和Native層的MessageQueue互動(dòng)。 final long ptr = mPtr; if (ptr == 0) { return null; } int pendingIdleHandlerCount = -1; int nextPollTimeoutMillis = 0; //時(shí)間標(biāo)記,當(dāng)且僅當(dāng)***次獲取消息時(shí)才為0。因?yàn)樗谒姥h(huán)外面??! for (;;) { if (nextPollTimeoutMillis != 0) { Binder.flushPendingCommands(); //如果不是***次獲取消息,調(diào)用Native的函數(shù),讓虛擬機(jī)刷新所有的餓Binder命令, //確保進(jìn)程在執(zhí)行可能阻塞的任務(wù)之前,釋放之前的對(duì)象。 } //這是一個(gè)Native的方法。 nativePollOnce(ptr, nextPollTimeoutMillis); synchronized (this) { //鎖住MessageQueue //獲取當(dāng)前的系統(tǒng)時(shí)間,用于后面和msg.when進(jìn)行比較。 final long now = SystemClock.uptimeMillis(); Message prevMsg = null; Message msg = mMessages; //獲得當(dāng)前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) { //這個(gè)判斷的意義在于只有到了Message應(yīng)該被發(fā)送的時(shí)刻才去發(fā)送,否則繼續(xù)循環(huán)。 //計(jì)算下一條消息的時(shí)間。注意***就是Integer.MAX_VALUE。 nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE); } else { //應(yīng)該發(fā)送一條消息了。 // 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(); //轉(zhuǎn)換消息標(biāo)記為使用過的 return msg; //返回一條消息給Looper。 } } else { // 如果取到的Message為null,將時(shí)間標(biāo)記設(shè)置為-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在取消息(調(diào)用next())時(shí),會(huì)進(jìn)入一個(gè)死循環(huán),直到取出一條Message返回。這就是為什么Looper.loop()會(huì)在queue.next()處等待的原因。
那么,一條Message是如何添加到MessageQueue中呢?要弄明白***的真相,我們需要調(diào)查一下mHandler.post()這個(gè)方法。
Handler究竟對(duì)Message做了什么?
Handler的post()系列方法,最終調(diào)用的都是下面這個(gè)方法:
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { msg.target = this; //在這里給Message的target賦值。 if (mAsynchronous) { msg.setAsynchronous(true); //如果是異步,就標(biāo)記為異步 } return queue.enqueueMessage(msg, uptimeMillis); //就是這個(gè)方法把Message添加到線程的MessageQueue中的。 }
接下來就看看MessageQueue的enqueueMessage()作了什么。
boolean enqueueMessage(Message msg, long when) { if (msg.target == null) { //沒Handler調(diào)用是會(huì)拋異常的啊 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被標(biāo)記為退出,就返回。 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的使用狀態(tài)為未使用。 msg.when = when; //我們?cè)O(shè)置的延遲發(fā)送的時(shí)間。 //經(jīng)過下面的邏輯,Message將會(huì)被“儲(chǔ)存”在MessageQueue中。 //實(shí)際上,Message在MessageQueue中的儲(chǔ)存方式, //是使用Message.next逐個(gè)向后指向的單鏈表結(jié)構(gòu)來儲(chǔ)存的。 //比如:A.next = B, B.next = C... Message p = mMessages; //嘗試獲取當(dāng)前Message boolean needWake; if (p == null || when == 0 || when < p.when) { // 如果為null,說明是***條。 msg.next = p; mMessages = msg; //設(shè)置當(dāng)前的Message為傳入的Message,也就是作為***條。 needWake = mBlocked; } else { needWake = mBlocked && p.target == null && msg.isAsynchronous(); Message prev; //不滿足作為***條Message的條件時(shí),通過下面的逐步變換,將它放在***面。 //這樣便把Message“儲(chǔ)存”到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; }
至此,我們已經(jīng)揭露了Looper、Handler、MessageQueue隱藏的秘密。
另一個(gè)疑問?
也許你已經(jīng)注意到在主線程中可以直接使用Handler,而不需要Looper.prepare()和Looper.loop()。為什么可以做到這樣呢?根據(jù)之前的分析可以知道,主線程中必然存在Looper.prepare()和Looper.loop()。既然如此,為什么主線程沒有被loop()阻塞呢?看一下ActivityThread來弄清楚到底是怎么回事。
//這個(gè)main()方法可以認(rèn)為是Android應(yīng)用的起點(diǎn) public static void main(String[] args) { 。 。 。 Looper.prepareMainLooper(); //主要作用和我們平時(shí)調(diào)用的Looper.prepare()差不多 ActivityThread thread = new ActivityThread(); //創(chuàng)建本類實(shí)例 thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); //重點(diǎn)??!這里取得了處理主線程事物的Handler。 } if (false) { Looper.myLooper().setMessageLogging(new LogPrinter(Log.DEBUG, "ActivityThread")); } // End of event ActivityThreadMain. Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); Looper.loop(); //開始循環(huán)??梢钥吹剑骶€程本質(zhì)上是阻塞的! 。 。 。 }
注意ActivityThread并沒有繼承Thread,它的Handler是繼承Handler的私有內(nèi)部類H.class。在H.class的handleMessage()中,它接受并執(zhí)行主線程中的各種生命周期狀態(tài)消息。UI的16ms的繪制也是通過Handler來實(shí)現(xiàn)的。也就是說,主線程中的所有操作都是在Looper.prepareMainLooper()和Looper.loop()之間進(jìn)行的。進(jìn)一步說是在主Handler中進(jìn)行的。
關(guān)于Thread線程是如何運(yùn)作的就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò),可以把它分享出去讓更多的人看到。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。