理解Android中ThreadLocal的工作原理

一提Android中的消息机制,我们很容易就想到Handler,确实,Android中的异步消息处理机制,主要都依赖于Handler机制(不懂的可以看深入理解Android中的Handler机制 这篇文章),而Handler机制的实现其实和ThreadLocal密不可分。

ThreadLocal

Implements a thread-local storage, that is, a variable for which each thread has its own value. All threads share the same {@code ThreadLocal} object, but each sees a different value when accessing it, and changes made by one thread do not affect the other threads. The implementation supports {@code null} values.

以上是官方文档对ThreadLocal的解释,从这里我们可以看出,ThreadLocal相当于一个容器,存储着每个线程的数据,且所有线程都共享这一个ThreadLocal变量,但每个线程访问该对象时会获得不同的数据,而且就算修改这些数据也不会影响到其他线程,即所有线程互不干扰。因为这个特性,ThreadLocal在Java中也常用于处理多线程,也就是说,ThreadLocal和线程同步机制一样,都是为了解决多线程访问同一变量造成的访问冲突问题,不同的的是,

  • 同步机制是通过锁机制牺牲时间来达到多线程安全访问的目的;
  • ThreadLocal为每个线程提供独立的变量副本,牺牲空间保证每个线程访问相同变量时可以得到自己专属的变量,达到多线程安全访问的目的。

具体如何实现的呢?我们从Android中的Handler机制进行讲解。
在Handler机制中,我们需要新建一个线程,而在每个Thread中,都会包含一个ThreadLocal.Values 类型的localValues变量,表示该线程映射到ThreadLocal中的值。

ThreadLocal.Values

首先来看一下它的一个和消息机制相关的构造函数。

/** Size must always be a power of 2. */
private static final int INITIAL_SIZE = 16;

/** Placeholder for deleted entries. */
private static final Object TOMBSTONE = new Object();

/**
 * Map entries. Contains alternating keys (ThreadLocal) and values.
 * The length is always a power of 2.
 */
private Object[] table;

/** Used to turn hashes into indices. */
private int mask;

/** Number of live entries. */
private int size;

/** Number of tombstones. */
private int tombstones;

/** Maximum number of live entries and tombstones. */
private int maximumLoad;

/** Points to the next cell to clean up. */
private int clean;

Values() {
    initializeTable(INITIAL_SIZE);
    this.size = 0;
    this.tombstones = 0;
}

private void initializeTable(int capacity) {
    this.table = new Object[capacity * 2];
    this.mask = table.length - 1;
    this.clean = 0;
    this.maximumLoad = capacity * 2 / 3; // 2/3
}

这里主要是对几个变量进行初始化初始化。包括用于存储线程本身一些数据的Object数组table,该数组也存储了线程间共享的ThreadLocal对象和自身相关的Looper 对象,还有用于将哈希值转为指数的掩码。

记住该Values类后我们来看ThreadLocal是如何在消息机制中发挥作用的。

在Handler机制中,

  • Handler用于处理子线程耗时操作结束后的反馈,一般用于从子线程切换回主线程并更新UI。
  • MessageQueue用于存储消息。
  • Looper用于处理消息,以无限循环的形式查找MessageQueue中是否有消息。
    所以每个线程的运行都需要Looper的存在,不然无法处理消息(不懂的先完看深入理解Android中的Handler机制 这篇文章)。
    所以先讲下调用Looper的构建。通常我们都是通过Looper.prepare()来构建looper实例的,但是该方法除了实例一个looper并创建一个MessageQueue、指定其mThread为当前线程外,就是将该Looper对象存到ThreadLocal中。
public static void prepare() {
    prepare(true);
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}    

所以我们来看一下ThreadLocal的set方法,如下:

public void set(T value) {
    Thread currentThread = Thread.currentThread();
    Values values = values(currentThread);
    if (values == null) {
        values = initializeValues(currentThread);
    }
    values.put(this, value);
}

Values values(Thread current) {
    return current.localValues;
}

Values initializeValues(Thread current) {
    return current.localValues = new Values();
}

这里 values(currentThread) 方法返回的就是我们前面提到的ThreadLocal.Values对象,也就是Thread类中的localValue值,如果是null就进行初始化,初始化执行的就是我们前面提到的构造方法。初始化成功后便将该ThreadLocal对象和该looper对象(即参数value)存储到该values对象中,具体实现如下:

void put(ThreadLocal<?> key, Object value) {
    // Cleans up after garbage-collected thread locals.
    cleanUp();

    // Keep track of first tombstone. That's where we want to go back
    // and add an entry if necessary.
    int firstTombstone = -1;

    for (int index = key.hash & mask;; index = next(index)) {
        Object k = table[index];

        if (k == key.reference) {
            // Replace existing entry.
            table[index + 1] = value;
            return;
        }

        if (k == null) {
            if (firstTombstone == -1) {
                // Fill in null slot.
                table[index] = key.reference;
                table[index + 1] = value;
                size++;
                return;
            }

            // Go back and replace first tombstone.
            table[firstTombstone] = key.reference;
            table[firstTombstone + 1] = value;
            tombstones--;
            size++;
            return;
        }

        // Remember first tombstone.
        if (firstTombstone == -1 && k == TOMBSTONE) {
            firstTombstone = index;
        }
    }
}

private int next(int index) {
    return (index + 2) & mask;
}

从上面代码可以看到,该方法其实就是把传进来的ThreadLocal对象和looper对象存到它的table数组中,可以看到,这里通过计算该threadLocal的哈希值key.hash与掩码值mask 的与运算结果来判断table中是否存在该threadLocal对象的引用reference ,若存在则将该looper对象放在该引用在table数组中的位置的后一个位置,即table[index + 1];若不存在则将该threadLocal对象的引用存到table数组的[index]位置上,而looper对象同样存在其后一个位置。也就是说,looper的值都会存在threadLocal引用的后一个位置。
到这里Looper构造并准备完毕。
然后就应该构造Handler获取looper了。在创建handler时,若参数中没有指定looper,会通过mLooper = Looper.myLooper(); 为自身指定一个looper对象。而myLooper实际上就是返回threadLocal.get()而已。

public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}

那么具体是如何获得当前线程相关的looper的呢?

public T get() {
    // Optimized for the fast path.
    Thread currentThread = Thread.currentThread();
    Values values = values(currentThread);
    if (values != null) {
        Object[] table = values.table;
        int index = hash & values.mask;
        if (this.reference == table[index]) {
            return (T) table[index + 1];
        }
    } else {
        values = initializeValues(currentThread);
    }

    return (T) values.getAfterMiss(this);
}

Values values(Thread current) {
    return current.localValues;
}

Values initializeValues(Thread current) {
    return current.localValues = new Values();
}

可以看到,这里依然是通过当前线程自身的localValues这个值内部的table数组来获得相关联的looper对象,如果是null,则重新初始化该Values对象,如果不为null则返回table数组中该ThreadLocal对象的引用所在位置的下一个值,也就是我们前面set进去looper啦。

综上,我们可以知道,在handler机制中,之所以每个线程能够获得自身的looper,而不影响其他线程,是因为通过操作每个线程自身的localValues对象内部的table数组实现的,从而达到不同线程访问同一个threadLocal的get()和set()不会访问或修改到其他线程的数据。

发布了15 篇原创文章 · 获赞 15 · 访问量 6万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览