线程局部存储(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。