Chromium on Android: Chromium线程局部存储系统

线程局部存储(Thread Local Storage), 简称TLS，提供了一种存储线程私有数据的方式，每个线程的私有数据对其他线程均不可见。Chromium是一个多进程多线程架构的浏览器，运行时会创建多达30几个线程，其中很多线程需要拥有自己私有数据，在TLS数量有限的系统上，例如Android 4.3或更早的系统，可能会因为无法分配足够的TLS而导致Chromium崩溃。本文将介绍最近在Chromium提交代码中是如何解决这个问题的。

TLS在Chromium中的使用

Chromium代码中，有些类提供了一个current()方法用来返回调用线程的私有数据，最典型的两个例子是MessageLoop和RenderThread。以MessageLoop为例，因为每个线程可能运行着一个主消息循环，如何能够获取与线程相关的主消息循环呢？为此，MessageLoop提供了current()方法，当线程在创建MessageLoop实例时，会将这个实例设置为线程的私有数据，当调用current()方法时，再将这个私有数据返回给调用者。

每个TLS槽都由一个唯一的键值（key）标识，这个键值由进程负责向OS申请分配，如果当前进程申请的键值数量超过系统规定的上限，申请将失败，即无法获取一个新的TLS槽。线程可以将TLS槽绑定到一个私有数据上，这个私有数据实际上是一个指针，指向一块由调用线程动态分配的内存块。

Chromium代码中，对TLS的使用都抽象在ThreadLocalPointer模板类中（参见base/threading/thread_local.h文件）：

template <typename Type>
class ThreadLocalPointer {
 public:
  ThreadLocalPointer() : slot_() {
    internal::ThreadLocalPlatform::AllocateSlot(slot_);
  }

  ~ThreadLocalPointer() {
    internal::ThreadLocalPlatform::FreeSlot(slot_);
  }

  Type* Get() {
    return static_cast<Type*>(
        internal::ThreadLocalPlatform::GetValueFromSlot(slot_));
  }

  void Set(Type* ptr) {
    internal::ThreadLocalPlatform::SetValueInSlot(
        slot_, const_cast<void*>(static_cast<const void*>(ptr)));
  }

 private:
  typedef internal::ThreadLocalPlatform::SlotType SlotType;

  SlotType slot_;

  DISALLOW_COPY_AND_ASSIGN(ThreadLocalPointer<Type>);
};

其中SlotType是对TLS槽（键值）类型的抽象，internal::ThreadLocalPlatform是对特定平台的TLS实现的抽象。例如，在POSIX系统上，ThreadLocalPlatform::AllocateSlot的实现为：

void ThreadLocalPlatform::AllocateSlot(SlotType& slot) {
  int error = pthread_key_create(&slot, NULL);
  CHECK_EQ(error, 0);
}

一般地，会结合LazyInstance使用ThreadLocalPointer，例如：

staticbase::LazyInstance<base::ThreadLocalPointer<RenderThread> >lazy_tls =
   LAZY_INSTANCE_INITIALIZER;
 
RenderThread* RenderThread::current() {
 return lazy_tls.Pointer()->Get();
}
 
RenderThread::RenderThread() {
 lazy_tls.Pointer()->Set(this);
}
 
RenderThread::~RenderThread() {
 lazy_tls.Pointer()->Set(NULL);
}

当创建RenderThread实例时，当前线程会通过访问lazy_tls设置线程的私有数据，此后每次调用current()方法时，都会返回线程私有的RenderThread实例。

由于LazyInstance是延迟初始化的，上述代码中，当首次访问Pointer()时，会创建一个新的ThreadLocalPointer实例，也就是向OS申请分配一个新的TLS槽。

潜在的问题

在三大桌面操作系统上（Windows/Linux/Mac）,上述对ThreadLocalPointer的封装和实现都能工作的很好，但自从Chromium支持Android之后，潜伏在上述实现中的问题就浮出水面了。

如果一个线程中需要存储多个私有数据，比如除了RenderThread实例，还有MessageLoop实例等等，每个都要系统分配给进程的TLS键值，那么一旦键值的数据达到上限，申请失败导致程序崩溃。这个问题已经在Chromium WebView中暴露了，原因是Android 4.3或更老的系统，最大可用的TLS槽数量只有64个，除去Android系统库（opengl，jvm）需要占用一部分之外，留给Chromium使用的数量已经不多了，一旦发现分配不成功，Chromium会触发CHECK，程序立即异常退出。Android 4.4系统上，最大可用的TLS槽数量多达128个，这个问题得到一定的缓解，但仍没有从根本上杜绝这个问题。

解决方法

Chromium提供了一种新的方式解决上述问题，主要思路是Chromium自己管理TLS。

以POSIX系统为例，通过pthread_key_create创建的key对进程内所有的线程都可见，但每个线程可以绑定不同的私有数据到一个相同的key上，这就意味着整个Chromium可以共享同一个TLS槽，创建一个应用层的TLS表来彻底解决系统级别TLS槽的数量限制。

具体来说，Chromium TLS系统会首先向OS申请一个key，每个线程都将为这个key绑定一张线程私有的TLS表，Chromium设置了这张表可以容纳64个表项。当线程需要一个新的TLS槽时，首先会检查这个线程是否为key已经绑定了TLS表，如果没有，则需要创建这样一个TLS表并将其设置为线程私有，然后从表中按顺序取一个可用项，并设置新的私有数据。不难看出，新的TLS槽并不是向OS申请的，而是向Chromium TLS申请的。

ThreadLocalStorage模板类是新的ChromiumTLS系统中对TLS的抽象，StaticSlot和Slot封装了初始化Chromium TLS系统，创建TLS表以及设置和获取线程私有数据的操作。因此，上述ThreadLocalPointer模板类将从直接使用ThreadLocalPlatform操作TLS，应改为使用ThreadLocalStorage::Slot, 如下：

template <typename Type>
class ThreadLocalPointer {
 public:
  ThreadLocalPointer() {}
  ~ThreadLocalPointer() { slot_.Free(); }
  Type* Get() {
    return static_cast<Type*>(slot_.Get());
  }
  void Set(Type* ptr) {
    slot_.Set(const_cast<void*>(static_cast<const void*>(ptr)));
  }
 private:
  ThreadLocalStorage::Slot slot_;

  DISALLOW_COPY_AND_ASSIGN(ThreadLocalPointer<Type>);
};

再次强调，ThreadLocalStorage::Slot只是向Chromium TLS系统申请可用的TLS槽，而不是向系统直接申请。

更多信息

• Chromium项目的bug列表里已经报告了这个问题，参见这里。

• Chromium TLS实现是最近才提交到Chromium代码库中的，参见这里。

• Android源代码中对TLS槽数量的定义在BIONIC_TLS_SLOTS宏常量中，见Android 4.3和Android 4.4。

• 关于Chromium TLS系统实现细节，感兴趣的读者可读读base/threading/thread_local_storage.h/cc等源文件。

• 关于pthread_key_create，参见Linux Man Page。