你知道Thread线程是如何运作的吗?

移动开发 Android
我们在Android开发过程中,几乎都离不开线程。但是你对线程的了解有多少呢?它完美运&#..

[[194846]]

【引自CoorChice的博客】背景介绍

我们在Android开发过程中,几乎都离不开线程。但是你对线程的了解有多少呢?它***运行的背后,究竟隐藏了多少不为人知的秘密呢?线程间互通暗语,传递信息究竟是如何做到的呢?Looper、Handler、MessageQueue究竟在这背后进行了怎样的运作。本期,让我们一起从Thread开始,逐步探寻这个***的线程链背后的秘密。

注意,大部分分析在代码中,所以请仔细关注代码哦!

从Thread的创建流程开始

在这一个环节,我们将一起一步步的分析Thread的创建流程。

话不多说,直接代码里看。

线程创建的起始点init()

  1. // 创建Thread的公有构造函数,都调用的都是这个私有的init()方法。我们看看到底干什么了。 
  2. /** 
  3.      * 
  4.      * @param 线程组 
  5.      * @param 就是我们平时接触最多的Runnable同学 
  6.      * @param 指定线程的名称 
  7.      * @param 指定线程堆栈的大小 
  8.      */ 
  9. private void init(ThreadGroup g, Runnable target, String name, long stackSize) { 
  10.         Thread parent = currentThread();             
  11. //先获取当前运行中的线程。这一个Native函数,暂时不用理会它怎么做到的。黑盒思想,哈哈! 
  12.         if (g == null) { 
  13.             g = parent.getThreadGroup();            
  14.  //如果没有指定ThreadGroup,将获取父线程的TreadGroup 
  15.         } 
  16.  
  17.         g.addUnstarted();                           
  18.  //将ThreadGroup中的就绪线程计数器增加一。注意,此时线程还并没有被真正加入到ThreadGroup中。 
  19.         this.group = g;                             
  20.  //将Thread实例的group赋值。从这里开始线程就拥有ThreadGroup了。 
  21.  
  22.         this.target = target;                       
  23.  //给Thread实例设置Runnable。以后start()的时候执行的就是它了。 
  24.         this.priority = parent.getPriority();        
  25. //设置线程的优先权重为父线程的权重 
  26.         this.daemon = parent.isDaemon();            
  27.  //根据父线程是否是守护线程来确定Thread实例是否是守护线程。 
  28.         setName(name);                              
  29.  //设置线程的名称   
  30.  
  31.         init2(parent);                             
  32.   //纳尼?又一个初始化,参数还是父线程。不急,稍后在看。 
  33.  
  34.         /* Stash the specified stack size in case the VM cares */ 
  35.         this.stackSize = stackSize;                 
  36.  //设置线程的堆栈大小 
  37.         tid = nextThreadID();                       
  38.  //线程的id。这是个静态变量,调用这个方法会自增,然后作为线程的id。 
  39.     }  

第二个init2()

  1. private void init2(Thread parent) { 
  2.         this.contextClassLoader = parent.getContextClassLoader();           
  3.  //设置ClassLoader成员变量 
  4.         this.inheritedAccessControlContext = AccessController.getContext(); 
  5.  //设置访问权限控制环境 
  6.         if (parent.inheritableThreadLocals != null) { 
  7.             this.inheritableThreadLocals = ThreadLocal.createInheritedMap(  
  8.  //创建Thread实例的ThreadLoacaleMap。需要用到父线程的ThreadLocaleMap,目的是为了将父线程中的变量副本拷贝一份到当前线程中。 
  9.             //ThreadLocaleMap是一个Entry型的数组,Thread实例会将变量副本保存在这里面。 
  10.                     parent.inheritableThreadLocals);         
  11.         } 
  12.     }  

至此,我们的Thread就初始化完成了,Thread的几个重要成员变量都赋值了。

启动线程,开车啦!

通常,我们这样了启动一条线程。

  1. Thread threadDemo = new Thread(() -> { 
  2.  
  3.     }); 
  4. threadDemo.start();  

那么start()背后究竟隐藏着什么样不可告人的秘密呢?是人性的扭曲?还是道德的沦丧?让我们一起点进start()。探寻start()背后的秘密。

  1. //如我们所见,这个方法是加了锁的。 
  2. //原因是避免开发者在其它线程调用同一个Thread实例的这个方法,从而尽量避免抛出异常。 
  3. //这个方法之所以能够执行我们传入的Runnable里的run()方法, 
  4. //是应为JVM调用了Thread实例的run()方法。 
  5. public synchronized void start() { 
  6.         //检查线程状态是否为0,为0表示是一个新状态,即还没被start()过。不为0就抛出异常。 
  7.         //就是说,我们一个Thread实例,我们只能调用一次start()方法。 
  8.         if (threadStatus != 0) 
  9.             throw new IllegalThreadStateException(); 
  10.  
  11.         //从这里开始才真正的线程加入到ThreadGroup组里。 
  12. //再重复一次,前面只是把nUnstartedThreads这个计数器进行了增量,并没有添加线程。 
  13.         //同时,当线程启动了之后,nUnstartedThreads计数器会-1。因为就绪状态的线程少了一条啊! 
  14.         group.add(this); 
  15.  
  16.         started = false
  17.         try { 
  18.             nativeCreate(this, stackSize, daemon);   
  19. //又是个Native方法。这里交由JVM处理,会调用Thread实例的run()方法。 
  20.             started = true
  21.         } finally { 
  22.             try { 
  23.                 if (!started) { 
  24.                     group.threadStartFailed(this);   
  25. //如果没有被启动成功,Thread将会被移除ThreadGroup, 
  26. //同时,nUnstartedThreads计数器又增量1了。 
  27.                 } 
  28.             } catch (Throwable ignore) { 
  29.  
  30.             } 
  31.         } 
  32.     }  

好把,最精华的函数是native的,先当黑盒处理吧。只要知道它能够调用到Thread实例的run()方法就行了。那我们再看看run()方法到底干了什么神奇的事呢?

  1. //没错,就是这么简单!仅仅调用了Runnable类型的成员变量target的run()方法。 
  2. //至此,我们需要执行的代码就执行起来了。 
  3. //至于这个@Overrid的存在,完全是因为Thread本身也是一个Runnable! 
  4. //就是说,我们的Thread也可以作为一个Runnable来使用。 
  5. @Override 
  6. public void run() { 
  7.         if (target != null) { 
  8.             target.run(); 
  9.         } 
  10.     }  

黑实验

  1. public void test_1() { 
  2.     Thread thread1 = new Thread(() -> { 
  3.       System.out.println(Thread.currentThread().getName()); 
  4.     }, "Thread_1"); 
  5.  
  6.  
  7.     Thread thread2 = new Thread(thread1, "Thread_2"); 
  8.     thread2.start(); 
  9.   } 
  10.  
  11.  
  12. --- 
  13. 输出: 
  14. Thread_2  

上面的实验表明了,我们完全可以用Thread来作为Runnable。

几个常见的线程手段(操作)

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

我们平时使用Thread.sleep()的频率也比较高,所以我们在一起研究研究Thread.sleep()被调用的时候发生了什么。

在开始之前,先介绍一个概念——纳秒。1纳秒=十亿分之一秒。可见用它计时将会非常的精准。但是由于设备限制,这个值有时候并不是那么准确,但还是比毫秒的控制粒度小很多。

  1. //平时我们调用的Thread.sleep(long)***调用到这个方法来,后一个陌生一点的参数就是纳秒。 
  2. //你可以在纳秒级控制线程。 
  3. public static void sleep(long millis, int nanos) 
  4.     throws InterruptedException { 
  5.         //下面三个检测毫秒和纳秒的设置是否合法。 
  6.         if (millis < 0) { 
  7.             throw new IllegalArgumentException("millis < 0: " + millis); 
  8.         } 
  9.         if (nanos < 0) { 
  10.             throw new IllegalArgumentException("nanos < 0: " + nanos); 
  11.         } 
  12.         if (nanos > 999999) { 
  13.             throw new IllegalArgumentException("nanos > 999999: " + nanos); 
  14.         } 
  15.  
  16.  
  17.         if (millis == 0 && nanos == 0) { 
  18.             if (Thread.interrupted()) {    
  19. //当睡眠时间为0时,检测线程是否中断, 
  20. //并清除线程的中断状态标记。这是个Native的方法。 
  21.               throw new InterruptedException();  
  22.  //如果线程被设置了中断状态为true了(调用Thread.interrupt())。 
  23. //那么他将抛出异常。如果在catch住这个异常之后return线程,那么线程就停止了。   
  24.  //需要注意,在调用了Thread.sleep()之后,再调用isInterrupted()得到的结果永远是False。 
  25. //别忘了Thread.interrupted()在检测的同时还会清除标记位置哦! 
  26.             } 
  27.             return
  28.         } 
  29.  
  30.         long start = System.nanoTime();  
  31.  //类似System.currentTimeMillis()。但是获取的是纳秒,可能不准。 
  32.         long duration = (millis * NANOS_PER_MILLI) + nanos;   
  33.  
  34.         Object lock = currentThread().lock;  
  35.  //获得当前线程的锁。 
  36.  
  37.         synchronized (lock) {    
  38. //对当前线程的锁对象进行同步操作 
  39.             while (true) { 
  40.                 sleep(lock, millis, nanos);  
  41.  //这里又是一个Native的方法,并且也会抛出InterruptedException异常。 
  42.                 //据我估计,调用这个函数睡眠的时长是不确定的。 
  43.  
  44.                 long now = System.nanoTime(); 
  45.                 long elapsed = now - start;   
  46. //计算线程睡了多久了 
  47.  
  48.                 if (elapsed >= duration) {    
  49. //如果当前睡眠时长,已经满足我们的需求,就退出循环,睡眠结束。 
  50.                     break; 
  51.                 } 
  52.  
  53.                 duration -= elapsed;    
  54. //减去已经睡眠的时间,重新计算需要睡眠的时长。 
  55.                 start = now; 
  56.                 millis = duration / NANOS_PER_MILLI;  
  57.  //重新计算毫秒部分 
  58.                 nanos = (int) (duration % NANOS_PER_MILLI);  
  59. //重新计算微秒部分 
  60.             } 
  61.         } 
  62.     }  

通过上面的分析可以知道,使线程休眠的核心方法就是一个Native函数sleep(lock, millis, nanos),并且它休眠的时常是不确定的。因此,Thread.sleep()方法使用了一个循环,每次检查休眠时长是否满足需求。

同时,需要注意一点,如果线程的interruted状态在调用sleep()方法时被设置为true,那么在开始休眠循环前会抛出InterruptedException异常。

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

这个方法是Native的。调用这个方法可以提示cpu,当前线程将放弃目前cpu的使用权,和其它线程重新一起争夺新的cpu使用权限。当前线程可能再次获得执行,也可能没获得。就酱。

无处不在的wait()究竟是什么?

大家一定经常见到,不论是哪一个对象的实例,都会在最下面出现几个名为wait()的方法。等待?它们究竟是怎样的一种存在,让我们一起点击去看看。

哎哟我去,都是Native函数啊。 

 

 

[[194847]] 

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

根据文档的描述,wait()配合notify()和notifyAll()能够实现线程间通讯,即同步。在线程中调用wait()必须在同步代码块中调用,否则会抛出IllegalMonitorStateException异常。因为wait()函数需要释放相应对象的锁。当线程执行到wait()时,对象会把当前线程放入自己的线程池中,并且释放锁,然后阻塞在这个地方。直到该对象调用了notify()或者notifyAll()后,该线程才能重新获得,或者有可能获得对象的锁,然后继续执行后面的语句。

呃。。。好吧,在说明一下notify()和notifyAll()的区别。

  • notify()

调用notify()后,对象会从自己的线程池中(也就是对该对象调用了wait()函数的线程)随机挑选一条线程去唤醒它。也就是一次只能唤醒一条线程。如果在多线程情况下,只调用一次notify(),那么只有一条线程能被唤醒,其它线程会一直在

  • notifyAll()

调用notifyAll()后,对象会唤醒自己的线程池中的所有线程,然后这些线程就会一起抢夺对象的锁。

扒一扒Looper、Handler、MessageQueue之间的爱恨情仇

我们可能过去都写过形如这样的代码:

  1. new Thread(()->{ 
  2.  
  3.     ... 
  4.     Looper.prepare(); 
  5.     Handler handler = new Handler(){ 
  6.         @Override 
  7.         public void handleMessage(Message msg) { 
  8.           super.handleMessage(msg); 
  9.         } 
  10.       }; 
  11.     Looper.loop(); 
  12.  
  13. }).start()  

很多同学知道,在线程中使用Handler时(除了Android主线程)必须把它放在Looper.prepare()和Looper.loop()之间。否则会抛出RuntimeException异常。但是为什么要这么做呢?下面我们一起来扒一扒这其中的内幕。 

 

 

[[194848]] 

从Looper.prepare()开始

当Looper.prepare()被调用时,发生了什么?

  1. public static void prepare() { 
  2.         prepare(true);   
  3. //最终其实执行的是私有方法prepare(boolean quitAllowed)中的逻辑 
  4.     } 
  5.  
  6.     private static void prepare(boolean quitAllowed) { 
  7.         if (sThreadLocal.get() != null) {   
  8.  //先尝试获取是否已经存在一个Looper在当前线程中,如果有就抛个异常。 
  9.         //这就是为什么我们不能在一个Thread中调用两次Looper.prepare()的原因。 
  10.             throw new RuntimeException("Only one Looper may be created per thread"); 
  11.         } 
  12.         sThreadLocal.set(new Looper(quitAllowed));   
  13. //***调用的话,就创建一个新的Looper。 
  14.     } 
  15.  
  16.     //Looper的私有构造函数 
  17.     private Looper(boolean quitAllowed) { 
  18.         mQueue = new MessageQueue(quitAllowed);   
  19.  //创建新的MessageQueue,稍后在来扒它。 
  20.         mThread = Thread.currentThread();         
  21.  //把当前的线程赋值给mThread。 
  22.     }  

经过上面的分析,我们已经知道Looper.prepare()调用之后发生了什么。

但是问题来了!sThreadLocal是个静态的ThreadLocal<Looper> 实例(在Android中ThreadLocal的范型固定为Looper)。就是说,当前进程中的所有线程都共享这一个ThreadLocal<Looper>。那么,Looper.prepare()既然是个静态方法,Looper是如何确定现在应该和哪一个线程建立绑定关系的呢?我们接着往里扒。

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

  1. public T get() { 
  2.         Thread t = Thread.currentThread();  
  3.   //重点啊!获取到了当前运行的线程。 
  4.         ThreadLocalMap map = getMap(t);      
  5.  //取出当前线程的ThreadLocalMap。这个东西是个重点,前面已经提到过。 
  6. //忘了的同学在前面再看看。 
  7.         if (map != null) { 
  8.             ThreadLocalMap.Entry e = map.getEntry(this);   
  9.             //可以看出,每条线程的ThreadLocalMap中都有一个<ThreadLocal,Looper>键值对。 
  10. //绑定关系就是通过这个键值对建立的。 
  11.             if (e != null
  12.                 return (T)e.value; 
  13.         } 
  14.         return setInitialValue(); 
  15.     } 
  16.  
  17. public void set(T value) { 
  18.         Thread t = Thread.currentThread();   
  19. //同样先获取到当前的线程 
  20.         ThreadLocalMap map = getMap(t);      
  21. //获取线程的ThreadLocalMap 
  22.         if (map != null
  23.             map.set(this, value);           
  24.  //储存键值对 
  25.         else 
  26.             createMap(t, value); 
  27.     }  

创建Handler

Handler可以用来实现线程间的通行。在Android中我们在子线程作完数据处理工作时,就常常需要通过Handler来通知主线程更新UI。平时我们都使用new Handler()来在一个线程中创建Handler实例,但是它是如何知道自己应该处理那个线程的任务呢。下面就一起扒一扒Handler。

  1. public Handler() { 
  2.         this(nullfalse);  
  3.  
  4. public Handler(Callback callback, boolean async) {      //可以看到,最终调用了这个方法。 
  5.         if (FIND_POTENTIAL_LEAKS) { 
  6.             final Class<? extends Handler> klass = getClass(); 
  7.             if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) && 
  8.                     (klass.getModifiers() & Modifier.STATIC) == 0) { 
  9.                 Log.w(TAG, "The following Handler class should be static or leaks might occur: " + 
  10.                     klass.getCanonicalName()); 
  11.             } 
  12.         } 
  13.  
  14.         mLooper = Looper.myLooper();                    
  15.  //重点啊!在这里Handler和当前Thread的Looper绑定了。 
  16. //Looper.myLooper()就是从ThreadLocale中取出当前线程的Looper。 
  17.         if (mLooper == null) { 
  18.  //如果子线程中new Handler()之前没有调用Looper.prepare(),那么当前线程的Looper就还没创建。 
  19. //就会抛出这个异常。 
  20.             throw new RuntimeException( 
  21.                 "Can't create handler inside thread that has not called Looper.prepare()"); 
  22.         } 
  23.         mQueue = mLooper.mQueue; 
  24.   //赋值Looper的MessageQueue给Handler。 
  25.         mCallback = callback; 
  26.         mAsynchronous = async; 
  27.     }  

Looper.loop()

我们都知道,在Handler创建之后,还需要调用一下Looper.loop(),不然发送消息到Handler没有用!接下来,扒一扒Looper究竟有什么样的魔力,能够把消息准确的送到Handler中处理。

  1. public static void loop() { 
  2.         final Looper me = myLooper();    
  3. //这个方法前面已经提到过了,就是获取到当前线程中的Looper对象。 
  4.         if (me == null) {  
  5.             //没有Looper.prepare()是要报错的! 
  6.             throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); 
  7.         } 
  8.         final MessageQueue queue = me.mQueue;      
  9.   //获取到Looper的MessageQueue成员变量,这是在Looper创建的时候new的。 
  10.  
  11.  //这是个Native方法,作用就是检测一下当前线程是否属于当前进程。并且会持续跟踪其真实的身份。 
  12.  //在IPC机制中,这个方法用来清除IPCThreadState的pid和uid信息。并且返回一个身份,便于使用restoreCallingIdentity()来恢复。 
  13.         Binder.clearCallingIdentity(); 
  14.         final long ident = Binder.clearCallingIdentity(); 
  15.  
  16.         for (;;) {  
  17.  //重点(敲黑板)!这里是个死循环,一直等待抽取消息、发送消息。 
  18.             Message msg = queue.next(); 
  19.  //  从MessageQueue中抽取一条消息。至于怎么取的,我们稍后再看。 
  20.             if (msg == null) { 
  21.                 // No message indicates that the message queue is quitting. 
  22.                 return
  23.             } 
  24.  
  25.             // This must be in a local variable, in case a UI event sets the logger 
  26.             final Printer logging = me.mLogging; 
  27.             if (logging != null) { 
  28.                 logging.println(">>>>> Dispatching to " + msg.target + " " + 
  29.                         msg.callback + ": " + msg.what); 
  30.             } 
  31.  
  32.             final long traceTag = me.mTraceTag;   //取得MessageQueue的跟踪标记 
  33.             if (traceTag != 0) { 
  34.                 Trace.traceBegin(traceTag, msg.target.getTraceName(msg));  
  35.  //开始跟踪本线程的MessageQueue中的当前消息,是Native的方法。 
  36.             } 
  37.             try { 
  38.                 msg.target.dispatchMessage(msg);   
  39.  //尝试分派消息到和Message绑定的Handler中 
  40.             } finally { 
  41.                 if (traceTag != 0) { 
  42.                     Trace.traceEnd(traceTag);      
  43.  //这个和Trace.traceBegin()配套使用。 
  44.                 } 
  45.             } 
  46.  
  47.             if (logging != null) { 
  48.                 logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); 
  49.             } 
  50.  
  51.  
  52.             final long newIdent = Binder.clearCallingIdentity();    
  53. //what?又调用这个Native方法了。这里主要是为了再次验证,线程所在的进程是否发生改变。 
  54.             if (ident != newIdent) { 
  55.                 Log.wtf(TAG, "Thread identity changed from 0x" 
  56.                         + Long.toHexString(ident) + " to 0x" 
  57.                         + Long.toHexString(newIdent) + " while dispatching to " 
  58.                         + msg.target.getClass().getName() + " " 
  59.                         + msg.callback + " what=" + msg.what); 
  60.             } 
  61.  
  62.             msg.recycleUnchecked();   
  63.  //回收释放消息。 
  64.         } 
  65.     }  

从上面的分析可以知道,当调用了Looper.loop()之后,线程就就会被一个for(;;)死循环阻塞,每次等待MessageQueue的next()方法取出一条Message才开始往下继续执行。然后通过Message获取到相应的Handler (就是target成员变量),Handler再通过dispatchMessage()方法,把Message派发到handleMessage()中处理。

这里需要注意,当线程loop起来是时,线程就一直在循环中。就是说Looper.loop()后面的代码就不能被执行了。想要执行,需要先退出loop。

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

现在又产生一个疑问,MessageQueue的next()方法是如何阻塞住线程的呢?接下来,扒一扒这个幕后黑手MessageQueue。

幕后黑手MessageQueue

MessageQueue是一个用单链的数据结构来维护消息列表。

  1. Message next() { 
  2.  //检查loop是否已经为退出状态。mPrt是Native层的MessageQueue的地址。 
  3. //通过这个地址可以和Native层的MessageQueue互动。 
  4.         final long ptr = mPtr; 
  5.         if (ptr == 0) { 
  6.             return null
  7.         } 
  8.  
  9.         int pendingIdleHandlerCount = -1; 
  10.         int nextPollTimeoutMillis = 0;       
  11. //时间标记,当且仅当***次获取消息时才为0。因为它在死循环外面啊! 
  12.         for (;;) { 
  13.             if (nextPollTimeoutMillis != 0) { 
  14.                 Binder.flushPendingCommands();      
  15. //如果不是***次获取消息,调用Native的函数,让虚拟机刷新所有的饿Binder命令, 
  16. //确保进程在执行可能阻塞的任务之前,释放之前的对象。 
  17.             } 
  18.  
  19.             //这是一个Native的方法。 
  20.             nativePollOnce(ptr, nextPollTimeoutMillis); 
  21.  
  22.             synchronized (this) {       //锁住MessageQueue 
  23.                 //获取当前的系统时间,用于后面和msg.when进行比较。 
  24.                 final long now = SystemClock.uptimeMillis(); 
  25.                 Message prevMsg = null
  26.                 Message msg = mMessages;        
  27.  //获得当前MessageQueue中的***条消息 
  28.                 if (msg != null && msg.target == null) { 
  29.  
  30.                     do { 
  31.                         prevMsg = msg; 
  32.                         msg = msg.next
  33.                     } while (msg != null && !msg.isAsynchronous()); 
  34.                 } 
  35.                 if (msg != null) { 
  36.                     if (now < msg.when) {  
  37.  //这个判断的意义在于只有到了Message应该被发送的时刻才去发送,否则继续循环。 
  38.  //计算下一条消息的时间。注意***就是Integer.MAX_VALUE。 
  39.                         nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE); 
  40.                     } else {  //应该发送一条消息了。 
  41.                         // Got a message. 
  42.                         mBlocked = false
  43.                         if (prevMsg != null) { 
  44.                             prevMsg.next = msg.next
  45.                         } else { 
  46.                             mMessages = msg.next
  47.                         } 
  48.                         msg.next = null
  49.                         if (DEBUG) Log.v(TAG, "Returning message: " + msg); 
  50.                         msg.markInUse();    
  51. //转换消息标记为使用过的 
  52.                         return msg;         
  53.  //返回一条消息给Looper。 
  54.                     } 
  55.                 } else { 
  56.                     // 如果取到的Message为null,将时间标记设置为-1。 
  57.                     nextPollTimeoutMillis = -1; 
  58.                 } 
  59.  
  60.                 // Process the quit message now that all pending messages have been handled. 
  61.                 if (mQuitting) { 
  62.                     dispose(); 
  63.                     return null
  64.                 } 
  65.  
  66.                 // If first time idle, then get the number of idlers to run. 
  67.                 // Idle handles only run if the queue is empty or if the first message 
  68.                 // in the queue (possibly a barrier) is due to be handled in the future. 
  69.                 if (pendingIdleHandlerCount < 0 
  70.                         && (mMessages == null || now < mMessages.when)) { 
  71.                     pendingIdleHandlerCount = mIdleHandlers.size(); 
  72.                 } 
  73.                 if (pendingIdleHandlerCount <= 0) { 
  74.                     // No idle handlers to run.  Loop and wait some more. 
  75.                     mBlocked = true
  76.                     continue
  77.                 } 
  78.  
  79.                 if (mPendingIdleHandlers == null) { 
  80.                     mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)]; 
  81.                 } 
  82.                 mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers); 
  83.             } 
  84.  
  85.             // Run the idle handlers. 
  86.             // We only ever reach this code block during the first iteration. 
  87.             for (int i = 0; i < pendingIdleHandlerCount; i++) { 
  88.                 final IdleHandler idler = mPendingIdleHandlers[i]; 
  89.                 mPendingIdleHandlers[i] = null; // release the reference to the handler 
  90.  
  91.                 boolean keep = false
  92.                 try { 
  93.                     keep = idler.queueIdle(); 
  94.                 } catch (Throwable t) { 
  95.                     Log.wtf(TAG, "IdleHandler threw exception", t); 
  96.                 } 
  97.  
  98.                 if (!keep) { 
  99.                     synchronized (this) { 
  100.                         mIdleHandlers.remove(idler); 
  101.                     } 
  102.                 } 
  103.             } 
  104.  
  105.             // Reset the idle handler count to 0 so we do not run them again. 
  106.             pendingIdleHandlerCount = 0; 
  107.  
  108.             // While calling an idle handler, a new message could have been delivered 
  109.             // so go back and look again for a pending message without waiting. 
  110.             nextPollTimeoutMillis = 0; 
  111.         } 
  112.     }  

可以看到。MessageQueue在取消息(调用next())时,会进入一个死循环,直到取出一条Message返回。这就是为什么Looper.loop()会在queue.next()处等待的原因。

那么,一条Message是如何添加到MessageQueue中呢?要弄明白***的真相,我们需要调查一下mHandler.post()这个方法。

Handler究竟对Message做了什么?

Handler的post()系列方法,最终调用的都是下面这个方法:

  1. private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { 
  2.         msg.target = this;     
  3.   //在这里给Message的target赋值。 
  4.         if (mAsynchronous) { 
  5.             msg.setAsynchronous(true);      
  6.  //如果是异步,就标记为异步 
  7.         } 
  8.         return queue.enqueueMessage(msg, uptimeMillis);     
  9.  //就是这个方法把Message添加到线程的MessageQueue中的。 
  10.     }  

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

  1. boolean enqueueMessage(Message msg, long when) { 
  2.         if (msg.target == null) {   
  3.  //没Handler调用是会抛异常的啊 
  4.             throw new IllegalArgumentException("Message must have a target."); 
  5.         } 
  6.         if (msg.isInUse()) {       
  7.   //不能使用一条正在使用中的Message。 
  8.             throw new IllegalStateException(msg + " This message is already in use."); 
  9.         } 
  10.  
  11.         synchronized (this) {      
  12.   //锁住MessageQueue再往里添加消息。 
  13.             if (mQuitting) {         
  14. //如果MessageQueue被标记为退出,就返回。 
  15.                 IllegalStateException e = new IllegalStateException( 
  16.                         msg.target + " sending message to a Handler on a dead thread"); 
  17.                 Log.w(TAG, e.getMessage(), e); 
  18.                 msg.recycle(); 
  19.                 return false
  20.             } 
  21.  
  22.             msg.markInUse();         
  23. //切换Message的使用状态为未使用。 
  24.             msg.when = when;        
  25.  //我们设置的延迟发送的时间。 
  26.  //经过下面的逻辑,Message将会被“储存”在MessageQueue中。 
  27. //实际上,Message在MessageQueue中的储存方式, 
  28. //是使用Message.next逐个向后指向的单链表结构来储存的。 
  29. //比如:A.next = B, B.next = C... 
  30.             Message p = mMessages;   
  31. //尝试获取当前Message 
  32.             boolean needWake; 
  33.             if (p == null || when == 0 || when < p.when) { 
  34.                 // 如果为null,说明是***条。 
  35.                 msg.next = p;    
  36.                 mMessages = msg;     
  37. //设置当前的Message为传入的Message,也就是作为***条。 
  38.                 needWake = mBlocked; 
  39.             } else { 
  40.  
  41.                 needWake = mBlocked && p.target == null && msg.isAsynchronous(); 
  42.                 Message prev; 
  43. //不满足作为***条Message的条件时,通过下面的逐步变换,将它放在***面。 
  44. //这样便把Message“储存”到MessageQueue中了。 
  45.                 for (;;) { 
  46.                     prev = p; 
  47.                     p = p.next
  48.                     if (p == null || when < p.when) { 
  49.                         break; 
  50.                     } 
  51.                     if (needWake && p.isAsynchronous()) { 
  52.                         needWake = false
  53.                     } 
  54.                 } 
  55.                 msg.next = p;  
  56.                 prev.next = msg; 
  57.             } 
  58.  
  59.  
  60.             if (needWake) { 
  61.                 nativeWake(mPtr); 
  62.             } 
  63.         } 
  64.         return true
  65.     }  

至此,我们已经揭露了Looper、Handler、MessageQueue隐藏的秘密。

另一个疑问?

也许你已经注意到在主线程中可以直接使用Handler,而不需要Looper.prepare()和Looper.loop()。为什么可以做到这样呢?根据之前的分析可以知道,主线程中必然存在Looper.prepare()和Looper.loop()。既然如此,为什么主线程没有被loop()阻塞呢?看一下ActivityThread来弄清楚到底是怎么回事。

  1. //这个main()方法可以认为是Android应用的起点 
  2. public static void main(String[] args) { 
  3.                 。 
  4.                 。 
  5.                 。 
  6.         Looper.prepareMainLooper();                             
  7.  //主要作用和我们平时调用的Looper.prepare()差不多 
  8.  
  9.         ActivityThread thread = new ActivityThread();            
  10. //创建本类实例 
  11.         thread.attach(false); 
  12.  
  13.         if (sMainThreadHandler == null) { 
  14.             sMainThreadHandler = thread.getHandler();            
  15. //重点啊!这里取得了处理主线程事物的Handler。 
  16.         } 
  17.  
  18.         if (false) { 
  19.             Looper.myLooper().setMessageLogging(new 
  20.                     LogPrinter(Log.DEBUG, "ActivityThread")); 
  21.         } 
  22.  
  23.         // End of event ActivityThreadMain. 
  24.         Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); 
  25.         Looper.loop();                                           
  26. //开始循环。可以看到,主线程本质上是阻塞的! 
  27.                 。 
  28.                 。 
  29.                 。 
  30.         }  

注意ActivityThread并没有继承Thread,它的Handler是继承Handler的私有内部类H.class。在H.class的handleMessage()中,它接受并执行主线程中的各种生命周期状态消息。UI的16ms的绘制也是通过Handler来实现的。也就是说,主线程中的所有操作都是在Looper.prepareMainLooper()和Looper.loop()之间进行的。进一步说是在主Handler中进行的。

总结

  • Android中Thread在创建时进行初始化,会使用当前线程作为父线程,并继承它的一些配置。
  • Thread初始化时会被添加到指定/父线程的ThreadGroup中进行管理。
  • Thread正真启动是一个native函数完成的。
  • 在Android的线程间通信中,需要先创建Looper,就是调用Looper.prepare()。这个过程中会自动依赖当前Thread,并且创建MessageQueue。经过上一步,就可以创建Handler了,默认情况下,Handler会自动依赖当前线程的Looper,从而依赖相应的MessageQueue,也就知道该把消息放在哪个地方了。MessageQueue通过Message.next实现了一个单链表结构来缓存Message。消息需要送达Handler处理,还必须调用Looper.loop()启动线程的消息泵送循环。loop()内部是***循环,阻塞在MessageQueue的next()方法上,因为next()方法内部也是一个***循环,直到成功从链表中抽取一条消息返回为止。然后,在loop()方法中继续进行处理,主要就是把消息派送到目标Handler中。接着进入下一次循环,等待下一条消息。由于这个机制,线程就相当于阻塞在loop()这了。

经过上面的揭露,我们已经对线程及其相互之间通讯的秘密有所了解。掌握了这些以后,相信在以后的开发过程中我们可以思路清晰的进行线程的使用,并且能够吸收Android在设计过程中的精华思想。 

责任编辑:庞桂玉 来源: CoorChice的博客
相关推荐

2020-02-15 15:33:55

Python如何运作

2019-10-31 13:17:13

无人超市人脸识别移动支付

2022-10-14 18:19:41

YouTube

2020-09-03 06:42:12

线程安全CPU

2023-06-08 07:48:03

Java线程池

2015-09-11 15:56:52

内核构建Linux

2024-01-08 08:45:07

Spring容器Bean

2023-01-09 08:00:41

JavaScript闭包

2023-05-30 08:19:07

kafka集群leader

2021-12-17 22:52:44

物联网电信技术

2022-09-28 18:16:34

JavaJDK

2021-02-15 15:36:04

采矿加密货币区块链

2024-02-05 12:08:07

线程方式管理

2013-02-27 10:27:44

GitHub

2019-11-11 08:45:52

HTTPTCP数据

2015-08-05 13:57:05

互联网腾讯

2022-11-23 10:33:42

2023-12-20 08:23:53

NIO组件非阻塞

2015-12-01 13:33:51

UnikernelLinux运维

2021-11-12 05:59:23

容灾备份5G
点赞
收藏

51CTO技术栈公众号