当前位置：天才代写 > tutorial > 安卓教程 > Android的消息机制之ThreadLocal的工作原理

Android的消息机制之ThreadLocal的工作原理

2021-02-20 16:37 星期六 所属： 安卓教程 浏览：654

 提及信息体制大伙儿应当也不生疏，在日常开发设计中难以避免地要牵涉到这些方面的內容。从开发设计的视角而言，Handler是Android信息体制的顶层插口，这促使开发设计全过程中只必须和Handler互动就可以。Handler的应用全过程非常简单，根据它能够轻轻松松地将一个每日任务转换到Handler所属的进程中去实行。许多人觉得Handler的功效是升级UI，这说的确实没有错，可是升级UI只是是Handler的一个独特的应用情景，从总体上是那样的：有时必须在子进程中开展用时的IO实际操作，这可能是读取文件或是浏览互联网等，当用时实际操作进行之后很有可能必须在UI上做一些更改，因为Android开发规范的限定，大家并不可以在子进程中浏览UI控制，不然便会开启程序流程出现异常，这个时候根据Handler就可以将升级UI的实际操作转换到主线任务程中实行。因而，实质上而言，Handler并并不是专业用以升级UI的，它仅仅常被大伙儿用于升级UI。

 

       Android的信息体制关键就是指Handler的管理机制，Handler的运作必须最底层的MessageQueue和Looper的支撑点。MessageQueue的翻译中文是消息队列，说白了它的內部储存了一组信息，其以序列的方式对外开放出示插进和删掉的工作中，尽管称为消息队列，可是它的內部存储结构并并不是真实的序列，只是选用单链表的算法设计来储存消息列表。Looper的翻译中文为循环系统，在这儿能够了解为信息循环系统，因为MessageQueue仅仅一个信息的数据存储器，它不可以去解决信息，而Looper就弥补了这一作用，Looper会以不断循环的方式去搜索是不是有最新动态，如果有得话就解决信息，不然就一直等候着。Looper中还有一个独特的定义，那便是ThreadLocal，ThreadLocal并并不是进程，它的功效是能够在每一个进程中储存数据信息。大伙儿了解，Handler建立的情况下会选用当今进程的Looper来结构信息循环，那麼Handler內部怎样获得到当今进程的Looper呢？这就需要应用ThreadLocal了，ThreadLocal能够在不一样的进程当中互相影响地储存并给出的数据，根据ThreadLocal能够轻轻松松获得每一个进程的Looper。自然必须留意的是，进程是默认设置沒有Looper的，假如必须应用Handler就务必为进程建立Looper。大伙儿常常提及的主线任务程，也叫UI进程，它便是ActivityThread，ActivityThread被建立时便会复位Looper，这也是在主线任务程中默认设置能够应用Handler的缘故。

 

       ThreadLocal是一个进程內部的数据储存类，根据它能够在特定的进程中储存数据信息，数据储存之后，仅有在特定进程中能够获得到储存的数据信息，针对其他进程而言没法获得到数据信息。在日常开发设计中采用ThreadLocal的地区较少，可是在一些独特的情景下，根据ThreadLocal能够轻轻松松地完成一些看上去很繁杂的作用，这一点在Android的源代码中也有一定的反映，例如Looper、ActivityThread及其AMS上都采用了ThreadLocal。实际到ThreadLocal的应用情景，这一不太好统一地来叙述，一般来说，当一些数据信息是以进程为作用域而且不一样进程具备不一样的数据信息团本的情况下，就可以考虑到选用ThreadLocal。例如针对Handler而言，它必须获得当今进程的Looper，很显而易见Looper的作用域便是进程而且不一样进程具备不一样的Looper，这个时候根据ThreadLocal就可以轻轻松松完成Looper在进程中的存储，如果不选用ThreadLocal，那麼系统软件就务必出示一个全局性的哈希表供Handler搜索特定进程的Looper，这样一来就务必出示一个类似LooperManager的类了，可是系统软件并沒有那么做只是挑选了ThreadLocal，这就是ThreadLocal的益处。

 

       ThreadLocal另一个应用情景是繁杂逻辑性下的目标传送，例如窃听器的传送，有一些情况下一个进程中的每日任务过度繁杂，这很有可能主要表现为调用函数栈较为深及其编码通道的多元性，在这类状况下，大家又必须窃听器可以围绕全部进程的实行全过程，这个时候能够怎么做呢？实际上就可以选用ThreadLocal，选用ThreadLocal能够让窃听器做为进程内的全局性目标而存有，在进程內部只需根据get方式就可以获得到窃听器。而如果不选用ThreadLocal，那麼大家能想起的可能是以下二种方式：第一种方式是将窃听器根据主要参数的方式在调用函数栈中开展传送，第二种方式便是将窃听器做为静态变量供进程浏览。所述这二种方式全是有局限的。第一种方式的难题时当调用函数栈很深的情况下，根据函数参数来传送窃听器目标这基本上是不能接纳的，这会让程序流程的设计方案看上去很槽糕。第二种方式是能够接纳的，可是这类情况不是具备可扩充性的，例如假如另外有两个进程在实行，那麼就必须出示2个静态数据的窃听器目标，如果有10个进程在高并发实行呢？出示10个静态数据的窃听器目标？这显而易见是难以置信的，而选用ThreadLocal每一个窃听器目标都是在自身的进程內部储存，依据就不容易有方式2的这类难题。

       详细介绍了那么多ThreadLocal的专业知识，很有可能還是有点儿抽象性，下边根据具体的事例为大伙儿演试ThreadLocal的真实含意。最先界定一个ThreadLocal目标，这儿挑选Boolean种类的，以下所显示：

private ThreadLocal<Boolean>mBooleanThreadLocal = new ThreadLocal<Boolean>();

       随后各自在主线任务程、子进程1和子进程2中设定和浏览它的值，编码以下所显示：

[java] view plain copy

 
  1. mBooleanThreadLocal.set(true);  
  2. Log.d(TAG, “[Thread#main]mBooleanThreadLocal=”   mBooleanThreadLocal.get());  
  3.   
  4. new Thread(“Thread#1”) {  
  5.     @Override  
  6.     public void run() {  
  7.         mBooleanThreadLocal.set(false);  
  8.         Log.d(TAG, “[Thread#1]mBooleanThreadLocal=”   mBooleanThreadLocal.get());  
  9.     };  
  10. }.start();  
  11.   
  12. new Thread(“Thread#2”) {  
  13.     @Override  
  14.     public void run() {  
  15.         Log.d(TAG, “[Thread#2]mBooleanThreadLocal=”   mBooleanThreadLocal.get());  
  16.     };  
  17. }.start();  

       在上面的编码中，在主线任务程中设定mBooleanThreadLocal的数值true，在子进程1中设定mBooleanThreadLocal的数值false，在子进程2中不设定mBooleanThreadLocal的值，随后各自在3个进程中根据get方式去mBooleanThreadLocal的值，依据前边对ThreadLocal的叙述，这个时候，主线任务程中应该是true，子进程1中应该是false，而子进程2中因为沒有设定值，因此 应该是null，安裝并运作程序流程，日志以下所显示：

D/TestActivity(8676):[Thread#main]mBooleanThreadLocal=true

D/TestActivity(8676):[Thread#1]mBooleanThreadLocal=false

D/TestActivity(8676):[Thread#2]mBooleanThreadLocal=null

       从上边日志能够看得出，尽管在不一样进程中浏览的是同一个ThreadLocal目标，可是他们根据ThreadLocal来获得到的值确是不一样的，这就是ThreadLocal的奇特之处。融合这这一事例随后再看一遍前边对ThreadLocal的2个应用情景的基础理论剖析，大伙儿应当就能比较好地了解ThreadLocal的操作方法了。ThreadLocal往往有那么奇特的实际效果，是由于不一样进程浏览同一个ThreadLocal的get方式，ThreadLocal內部会从分别的进程中取下一个二维数组，随后再从二维数组中依据当今ThreadLocal的数据库索引去搜索出相匹配的value值，很显而易见，不一样进程中的二维数组是不一样的，这就是为何根据ThreadLocal能够在不一样的进程中维护保养一套数据信息的团本而且彼此之间互相影响。

       对ThreadLocal的操作方法和工作中全过程干了一个详细介绍后，下边剖析下ThreadLocal的內部完成， ThreadLocal是一个泛型类，它的界定为public class ThreadLocal<T>，只需搞清楚ThreadLocal的get和set方式就可以搞清楚它的原理。

       最先看ThreadLocal的set方式，以下所显示：

[java] view plain copy

 
  1. public void set(T value) {  
  2.     Thread currentThread = Thread.currentThread();  
  3.     Values values = values(currentThread);  
  4.     if (values == null) {  
  5.         values = initializeValues(currentThread);  
  6.     }  
  7.     values.put(this, value);  
  8. }  

       在上面的set方式中，最先会根据values方式来获得当今进程中的ThreadLocal数据信息，假如获得呢？实际上获得的方法也是非常简单的，在Thread类的內容有一个组员专业用以储存进程的ThreadLocal的数据信息，以下所显示：ThreadLocal.Values localValues，因而获得当今进程的ThreadLocal数据信息就越来越出现异常简易了。假如localValues的数值null，那麼就必须对其开展复位，复位后再将ThreadLocal的值开展储存。下边看看ThreadLocal的值到底是如何localValues中开展储存的。在localValues內部有一个二维数组：private Object[] table，ThreadLocal的值便是存有在这个table二维数组中，下边看下localValues是怎么使用put方式将ThreadLocal的值储存到table二维数组中的，以下所显示：

[java] view plain copy

 
  1. void put(ThreadLocal<?> key, Object value) {  
  2.     cleanUp();  
  3.   
  4.     // Keep track of first tombstone. That’s where we want to go back  
  5.     // and add an entry if necessary.  
  6.     int firstTombstone = –1;  
  7.   
  8.     for (int index = key.hash & mask;; index = next(index)) {  
  9.         Object k = table[index];  
  10.   
  11.         if (k == key.reference) {  
  12.             // Replace existing entry.  
  13.             table[index   1] = value;  
  14.             return;  
  15.         }  
  16.   
  17.         if (k == null) {  
  18.             if (firstTombstone == –1) {  
  19.                 // Fill in null slot.  
  20.                 table[index] = key.reference;  
  21.                 table[index   1] = value;  
  22.                 size ;  
  23.                 return;  
  24.             }  
  25.   
  26.             // Go back and replace first tombstone.  
  27.             table[firstTombstone] = key.reference;  
  28.             table[firstTombstone   1] = value;  
  29.             tombstones–;  
  30.             size ;  
  31.             return;  
  32.         }  
  33.   
  34.         // Remember first tombstone.  
  35.         if (firstTombstone == –1 && k == TOMBSTONE) {  
  36.             firstTombstone = index;  
  37.         }  
  38.     }  
  39. }  

       上边的编码完成数据信息的sql语句，这儿没去剖析它的实际优化算法，可是我们可以得到一个储存标准，那便是ThreadLocal的值在table二维数组中的储存部位一直为ThreadLocal的reference字段名所标志的目标的下一个部位，例如ThreadLocal的reference目标在table二维数组的数据库索引为index，那麼ThreadLocal的值在table二维数组中的数据库索引便是index 1。最后ThreadLocal的值可能被储存在table二维数组中：table[index 1] = value。

       上边剖析了ThreadLocal的set方式，这儿剖析下它的get方式，以下所显示：

[java] view plain copy

 
  1. public T get() {  
  2.     // Optimized for the fast path.  
  3.     Thread currentThread = Thread.currentThread();  
  4.     Values values = values(currentThread);  
  5.     if (values != null) {  
  6.         Object[] table = values.table;  
  7.         int index = hash & values.mask;  
  8.         if (this.reference == table[index]) {  
  9.             return (T) table[index   1];  
  10.         }  
  11.     } else {  
  12.         values = initializeValues(currentThread);  
  13.     }  
  14.   
  15.     return (T) values.getAfterMiss(this);  
  16. }  

       能够发觉，ThreadLocal的get方式的逻辑性也较为清楚，它一样是取下当今进程的localValues目标，假如这一目标为null那麼就回到初值，初值由ThreadLocal的initialValue方式来叙述，默认设置状况下为null，自然还可以重写这一方式，它的默认设置完成以下所显示：

[java] view plain copy

 
  1. /** 
  2.  * Provides the initial value of this variable for the current thread. 
  3.  * The default implementation returns {@code null}. 
  4.  * 
  5.  * @return the initial value of the variable. 
  6.  */  
  7. protected T initialValue() {  
  8.     return null;  
  9. }  

       假如localValues目标不以null，那么就取下它的table二维数组并找到ThreadLocal的reference目标在table二维数组中的部位，随后table二维数组中的下一个部位所储存的数据信息便是ThreadLocal的值。

       从ThreadLocal的set和get方式能够看得出，他们所实际操作的目标全是当今进程的localValues目标的table二维数组，因而在不一样进程中浏览同一个ThreadLocal的set和get方式，他们对ThreadLocal所做的存取数据仅限分别进程的內部，这就是为何ThreadLocal能够在好几个进程中互相影响地储存和改动数据信息，了解ThreadLocal的完成方法有利于了解Looper的原理。

 
 
 

    关键字：

天才代写-代写联系方式