線程局部存儲(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。