在`C++11`标准当中，提供了一个新的关键字`thread_local`，用于声明一个线程本地变量，即该变量是线程独有的。

它的效果是，对于一个被声明为`thread_local`的变量`a`，不同的线程都会持有一个单独的`a`实例。

假设目前有两个线程A和B，那么**同时**在线程A当中访问`a`和在线程B当中访问`a`，是不冲突的，不存在竞态条件。

本文不探讨如何使用`thread_local`变量，我们旨在研究其具体是**如何实现**的，它的**底层原理**是什么。





话先说在前头，由于涉及到了底层，那么其实现原理必然是和各种底层设施有关的，例如编译器/操作系统/指令集，以下探究的过程不保证在其他平台上一模一样，仅供参考。

接下来的探究都将基于`x86_64 Ubuntu`，内核版本为`6.8.0-40-generic`，使用的编译器为`gcc version 13.2.0`

首先，我们得先把使用了`thread_local`关键字的代码给写出来，才可以进一步探究。

```cpp
#include <thread>
#include <iostream>

thread_local int num = 0;

void fun() {
	num = 0x1638;
	printf("in fun -> num: %x, addr: %p\n", num, &num);
}

int main() {

	std::thread t(fun);
	
	num = 0x7520;
	printf("in main -> num: %x, addr: %p\n", num, &num);

	t.join();


	return 0;
}
```
这一小段代码的意图是很明显的，程序运行起来之后会在两个线程中访问一个全局变量`num`，改变它的值之后会输出值和所在地址。

注意到，我们并没有添加任何的手段来避免并发带来的竞争，由于`thread_local`的存在，实际上并没有竞争出现(即便这个`num`是一个全局可访问的变量)。

编译也是非常简单的，这份代码是完全符合C++标准的代码(意味着你只需要复制粘贴)，只要你的C++标准支持11或更高，都能过编译。

使用g++进行编译，命令如下所示。

`g++ -std=c++11 thread_local_test.cpp -o thread_local_test`

执行一下看看结果是什么。

```shell
% ./thread_local_test
in main -> num: 7520, addr: 0x78d0ca31273c
in fun -> num: 1638, addr: 0x78d0c9a006bc
```
你的结果应该与我不一样，或者说每次运行的结果应该都不一样，主要体现在`addr`的输出上，稍后我们会看到为什么不一样(in main和in fun的输出顺序也可能不一样，但这是因为操作系统对线程的调度所引发的影响)。

从运行的结果来看，我们有了一个非常直观的认识，main里面的`num`和fun里面的`num`并不存放在同一个内存位置。

那么，即便同时访问它，也不会发生竞争，因为它俩只是长得一样(都叫做`num`)，但实际并不是一个东西。

至此，我们解开了第一个疑惑，即为什么`thread_local`关键字可以让一个全局变量在并发的情况下，不采取任何手段，也不会因为竞态条件出现问题。

好了，该填坑了，为什么`addr`的输出不一样，即`num`的地址为什么会不一样，这应该是直接揭露了`thread_local`背后的秘密。

如果目前你没有什么思路，应该是缺乏一些有关程序底层调试的经验。

我们使用了一个关键字，编译器在拿到我们写的代码后，开始读取并解析，编译器对`thread_local`关键字做了什么神秘的动作，使变量的地址都变得不一样了呢？

既然要探究编译器背后做的小动作，一般是有两个途径，第一就是直接把编译器的源码看明白，源码面前没有秘密；当然还有一个途径，对于C++语言而已，编译器只是一个翻译官，它会把C++代码翻译成汇编代码，这就是第二个途径，可以从汇编代码入手，看看它都翻译了一些什么东西出来。

我们自然是选择后者，因为看编译器源码并不是一件轻松的事情，很容易迷失在里面，不到万不得已当然是不建议选择的；对于解决我们的疑惑，看汇编就足够了。

要想看到汇编代码，用`objdump`命令就可以了，当然，我们会考虑看两份汇编代码，一份是在链接前，另一份是在链接后，原因会在后文说明。
```shell
g++ -std=c++11 thread_local_test.cpp -c -o thread_local_test_beforeld.o

objdump -d thread_local_test_beforeld.o -M intel > thread_local_test_beforeld.s

g++ -std=c++11 thread_local_test_beforeld.o -o thread_local_test

objdump -d thread_local_test -M intel > thread_local_test.s

```
注意到，`objdump`命令的参数中附加了`-M intel`，它指明了生成的汇编代码是什么形式的，这完全是我个人的习惯，我比较喜欢看`intel`形式的汇编，`objdump`默认输出的是`AT&T`形式的，我并不习惯这种形式的汇编代码。

执行上述的4条命令后，当前目录下应该会出现`thread_local_test_beforeld.s`和`thread_local_test.s`两个文件，这就是我们得到的汇编代码，前者是链接前的汇编代码，后者是链接之后的。

我们先看`thread_local_test_beforeld.s`，汇编并不好看，所以当然不是全看，我们只看我们关心的。

那么我们关心什么呢？当然是关心`num`，这也是为什么我们要赋一个十六进制的特殊值(0x1638和0x7520)，这非常方便在汇编当中定位。

在main函数体当中，可以定位到这:

```asm
  77:	64 c7 04 25 00 00 00 	mov    DWORD PTR fs:0x0,0x7520
  7e:	00 20 75 00 00 
  83:	64 8b 04 25 00 00 00 	mov    eax,DWORD PTR fs:0x0
  8a:	00 
  8b:	64 48 8b 14 25 00 00 	mov    rdx,QWORD PTR fs:0x0
  92:	00 00 
  94:	48 81 c2 00 00 00 00 	add    rdx,0x0
  9b:	89 c6                	mov    esi,eax
  9d:	48 8d 05 00 00 00 00 	lea    rax,[rip+0x0]        # a4 <main+0x5f>
  a4:	48 89 c7             	mov    rdi,rax
  a7:	b8 00 00 00 00       	mov    eax,0x0
  ac:	e8 00 00 00 00       	call   b1 <main+0x6c>
```
多了我们都没必要看，只需要`mov    DWORD PTR fs:0x0,0x7520`就够了，不过在这之后的汇编可以辅助你理解，后面的汇编就是准备printf需要的参数并调用printf。

这句汇编的含义也很明显，就是把`0x7520`放到一个内存中，这时候你可能会问，为什么是放到内存当中，`DWORD PTR`告诉我们的；你还会问，`DWORD PTR`是什么东西，这个问题的答案也许GPT回答地比我好。

那么是放到哪块内存中呢，我的回答是`fs:0x0`，准确来说`fs:0x0`是一个内存地址，也就是指针，`DWORD PTR`已经表明了。

等等，还有疑问，fs又是什么东西呢？不着急，先看看fun的汇编。


```asm
0000000000000000 <_Z3funv>:
   0:	f3 0f 1e fa          	endbr64
   4:	55                   	push   rbp
   5:	48 89 e5             	mov    rbp,rsp
   8:	64 c7 04 25 00 00 00 	mov    DWORD PTR fs:0x0,0x1638
   f:	00 38 16 00 00 
  14:	64 8b 04 25 00 00 00 	mov    eax,DWORD PTR fs:0x0
  1b:	00 
  1c:	64 48 8b 14 25 00 00 	mov    rdx,QWORD PTR fs:0x0
  23:	00 00 
  25:	48 81 c2 00 00 00 00 	add    rdx,0x0
  2c:	89 c6                	mov    esi,eax
  2e:	48 8d 05 00 00 00 00 	lea    rax,[rip+0x0]        # 35 <_Z3funv+0x35>
  35:	48 89 c7             	mov    rdi,rax
  38:	b8 00 00 00 00       	mov    eax,0x0
  3d:	e8 00 00 00 00       	call   42 <_Z3funv+0x42>
  42:	90                   	nop
  43:	5d                   	pop    rbp
  44:	c3                   	ret
```
你可能会问，是不是看错了，这个函数名是`_Z3funv`，这不得不提到C++有趣的**名称修饰**了，有关这点，GPT同样回答地比我好。

可以看到，类似地出现了`mov    DWORD PTR fs:0x0,0x1638`，一样的配方，`fs:0x0`。

明显的，这是在告诉我们，`num`的地址就是`fs:0x0`。

上一个疑问还没有解决，新的疑问又产生了，从代码的运行结果来看，明明`num`的地址不同，但这里为什么都是一样的`fs:0x0`呢，难道是之前想错了吗？

当然不是，可以预见的是，秘密都藏在`fs:0x0`当中，你越不了解的东西，秘密就越能藏得住。

这很容易推理出来，我们从运行结果已经确定两个线程中的`num`的地址就是不一样的，运行结果骗不了我们，那说明`fs:0x0`这个东西在某个时候变了，我们现在看的是链接前的代码，这时候还没变，那么只有可能是在链接之后变的了。

我们的思路又得以延续，`thread_local`背后的秘密我们已经揭露一半了，我们顺利的知道了，它是通过`fs:0x0`这个东西来使得全局变量`num`的地址在不同线程变得不同的。

现在是AI大展身手的时候了，在前文我总提到GPT的答案比我的答案好，这肯定是有一定道理的(

> 在x86_64架构中，FS寄存器是一个段寄存器，通常用于存储线程本地存储（Thread Local Storage, TLS）的基地址。TLS用于为每个线程提供独立的存储空间，例如线程局部变量、线程ID等。
> 
> 当线程切换时，操作系统会更新FS寄存器的内容，使其指向新线程的TLS基地址。这样，每个线程都可以通过FS寄存器访问自己的TLS数据。

上面这一段是DeepSeek给我的有关fs是什么的答案，当然我只截了一部分。

好了，至此我们就搞清楚`fs`是什么东西，并且是如何导致`num`变量在不同线程的地址不一样了。

现在我们简单梳理一下。

1. 各个线程都通过统一的`fs:0x0`来访问变量`num`
2. 在切换线程的时候，改变`fs`寄存器当中的值，以此来实现访问不同的`num`

假设线程`main`当中的`fs`是`100`，线程`fun`当中的`fs`是`200`，那么`main`对应的`num`的地址为`100+0x0`，fun对应的`num`地址为`200+0x0`，这也是为什么它们看起来一样，但实际却不一样的核心原理。

假设归假设，`fs`里面的值具体怎么得出来的呢？操作系统可没有对我们程序的任何了解，它怎么知道在切换线程的时候`fs`应该对应地切换到多少？

操作系统一开始当然不知道某个线程对应的`fs`是多少，肯定需要我们主动告诉它，但是我们从来没写过什么和操作系统通信的代码，那又是怎么告诉操作系统的呢？

别忘了，还有编译器这个家伙。准确来说，应该是**语言运行时库**，我通常会把语言运行时库归类到编译器的范畴当中，广义地说这也没问题。

用户态程序和操作系统内核进行通信的手段，一个最典型的就是使用**系统调用**，这为我们提供了一个排查思路。

在Linux系统当中，我们可以用strace这个命令来跟踪一个进程在运行过程中所使用的所有系统调用。


```shell
% strace ./thread_local_test
```
当然，这玩意执行之后，会得到一大堆不明所以的输出信息，会给我们带来很大的挫败感，根本没法下手。

那我们就想，尽可能地简化它的输出信息，那就从改造源码开始。


```cpp
#include <iostream>

thread_local int num = 0;

int main() {

	num = 0x7520;
	printf("in main -> num: %x, addr: %p\n", num, &num);

	return 0;
}
```
我们现在确实也不需要再开一个线程了，因为我们刚刚从汇编中也能看出，就`thread_local`而言，`fun`做的事情和`main`做的事情没有什么本质上的区别，只不过给`num`赋的值不同而已。

编译呢，还是那4条命令，没有变化，同样再用strace跟踪一下。

可以发现，strace的输出当中稍微少了一些信息，比如比之前少了clone3这个系统调用，因为我们确实没再创建线程了。

细心观察一下，注意到有个系统调用`arch_prctl`，这时你可能会问，为什么注意力这么好，可以刚好注意到这个系统调用而不是别的。

```shell
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7a01e74b3000
arch_prctl(ARCH_SET_FS, 0x7a01e74b4500) = 0
```

事实上这并不是我注意到的，这是AI注意到的，在前面我提到了DeepSeek给了我一些有关`fs`寄存器的介绍，但我只截了一部分并没有截全，在前文那个语境下，确实不需要截全。

但是其实DeepSeek也给我介绍了`fs`是如何改变的，就是通过系统调用`arch_prctl`，从strace的输出来看，也可以证明，`arch_prctl`的第一个参数就是`ARCH_SET_FS`，这个意图就比较明显了。

这给了我们一个提示，即我们可以先通过AI对一个未知事物有一个大概的了解和印象，以此充当日后实践当中的理论指导。

这个`arch_prctl`并不是我们去调用的，而是语言运行时库去调用的，只不过这底层的细节被隐藏起来了，对我们来说是透明的；这是一件好事同时也是一件坏事，对于我们写程序来说确实便捷了许多，但是当我们对细节有疑问时，会带来研究上的麻烦。

注意，在`arch_prctl`之前还有一个系统调用`mmap`，这实际上是在向操作系统申请一块内存，范围是\[`0x7a01e74b3000`,`0x7a01e74b3000+8192`)

在`arch_prctl`的第二个参数，使用了`0x7a01e74b4500`，这是在刚刚分配这块内存的范围当中的。这实际上就是将该线程的`fs`寄存器设置为`0x7a01e74b4500`。

那我们有一个很自然的想法，就是这块内存就是专门存放各个线程的`thread_local`变量的。

我们在strace的输出当中还可以观察到如下的信息，这实际就是printf。
```shell
write(1, "in main -> num: 7520, addr: 0x7a"..., 43in main -> num: 7520, addr: 0x7a01e74b44fc
) = 43
```
`num`的地址就是`0x7a01e74b44fc`，不难发现，就是`0x7a01e74b4500-4`，或者说是`fs-4`，那为什么是`-4`呢？当然是是因为`sizeof(int) = 4`

我们最后来看一下刚刚这个C++代码的汇编结果，重点关注链接后的main函数。


```asm
0000000000001149 <main>:
    1149:	f3 0f 1e fa          	endbr64
    114d:	55                   	push   rbp
    114e:	48 89 e5             	mov    rbp,rsp
    1151:	64 c7 04 25 fc ff ff 	mov    DWORD PTR fs:0xfffffffffffffffc,0x7520
    1158:	ff 20 75 00 00 
    115d:	64 8b 04 25 fc ff ff 	mov    eax,DWORD PTR fs:0xfffffffffffffffc
    1164:	ff 
    1165:	64 48 8b 14 25 00 00 	mov    rdx,QWORD PTR fs:0x0
    116c:	00 00 
    116e:	48 81 c2 fc ff ff ff 	add    rdx,0xfffffffffffffffc
    1175:	89 c6                	mov    esi,eax
    1177:	48 8d 05 87 0e 00 00 	lea    rax,[rip+0xe87]        # 2005 <_ZStL19piecewise_construct+0x1>
    117e:	48 89 c7             	mov    rdi,rax
    1181:	b8 00 00 00 00       	mov    eax,0x0
    1186:	e8 c5 fe ff ff       	call   1050 <printf@plt>
    118b:	b8 00 00 00 00       	mov    eax,0x0
    1190:	5d                   	pop    rbp
    1191:	c3                   	ret
```

因为我们简化了main函数，去掉了启动线程的代码，所以main的汇编代码也变得简短许多，更便于我们阅读。

注意到这一行汇编`mov    DWORD PTR fs:0xfffffffffffffffc,0x7520`，这与之前的不太一样，在链接之后`fs:0x0`变成了`fs:0xfffffffffffffffc`。

首先你有一个疑问，为什么链接之后就变了呢，为什么链接前不是`0xfffffffffffffffc`而是`0x0`？其次是还有个疑问，`0xfffffffffffffffc`是什么东西？

后一个问题说简单也简单，说复杂也复杂，`0xfffffffffffffffc`你要以**补码**的视角来看，它实际就代表着`-4`，复杂是因为补码这个知识本身需要一定的学习成本，也就是`0xfffffffffffffffc`在补码当中为什么就是`-4`；编译器现在普遍都采用补码来生成有关代码，有一个核心原因是补码可以把减法当加法来做，从而复用加法器电路，节省了一块本该用于减法器的电路面积，用来实现其他的电路。


那么在汇编`mov    DWORD PTR fs:0xfffffffffffffffc,0x7520`当中，就是将`0x7520`写入内存`fs+0xfffffffffffffffc = fs-0x4 = 0x7a01e74b4500-0x4 = 0x7a01e74b44fc`当中。

好了，至此我们已经把`thread_local`背后的所有秘密都摸清楚了，这篇文章终于可以谢幕了(

？似乎还有一个坑没有填，为什么链接前不是`0xfffffffffffffffc`而是`0x0`？

既然不一致是出现在链接前后，那自然是链接上的问题了，和`thread_local`本身关系不大。

假如我们的项目是一个大项目，那自然会采用多个编译单元的形式进行组织，简单来说就是有多个.cpp源文件，在多个源文件当中，有可能定义多个`thread_local`变量。

这就导致了一个问题，我们不能在所有`thread_local`变量汇总之前，给它们写死一个偏移量，否则会造成冲突。

我们来看看链接前写死地址是怎么样导致冲突的，在a.cpp当中的`thread_local`变量`num1`地址是`fs:0xfffffffffffffffc`，在b.cpp当中的`thread_local`变量`num2`地址也是`fs:0xfffffffffffffffc`，在链接前，看起来很正常没有问题，但是链接后，`num1`和`num2`就属于同一个可执行文件当中，那么由于它们拥有相同的地址，若是两者不在同一个线程倒还说得过去(意味`fs`是不同的)，若是在同一个线程当中(`fs`是相同的)，访问`num1`就相当于访问`num2`(两者地址一模一样)，这就不正常了。

所以在链接前，我们不能确定其它编译单元有多少个`thread_local`变量，只有在链接之后，汇总了所有编译单元，才知道有多少个`thread_local`变量，才能保证不冲突地分配地址。

这是一个有关链接方面的小细节，如果你对此还有疑惑，应该是我讲述地不够完善，因为这不是我们的主题，你应当去系统地学习一下链接方面的知识。

现在，这篇文章终于可以谢幕了，但是谢幕之前，我们来总结一下整个`thread_local`实现的流程。

- 在C++当中使用`thread_local`关键字来修饰一个变量`num`
- 编译器将变量`num`的地址指定为`fs:0x0`
- 链接各个编译单元，得到可执行文件后，分配具体的地址，如`fs:0xfffffffffffffffc`
- 对变量`num`的读写都会是直接操作这个指定内存地址`fs:0xfffffffffffffffc`
- 在语言运行时库创建一个线程时，通过系统调用`arch_prctl`指明这个线程对应的`fs`是多少
- 操作系统在切换线程时，会根据系统调用`arch_prctl`指明的`fs`来进行对应地切换。
- 假设线程A设置的`fs`为`0x7a01e74b4500`，线程B设置的`fs`为`0x7a01f74b4500`
- 在线程A中访问`num`，实际上是`0x7a01e74b4500+0xfffffffffffffffc`，而在线程B中访问`num`，实际上是`0x7a01f74b4500+0xfffffffffffffffc`
- 看起来都是用地址`fs+0xfffffffffffffffc`在访问内存，但实际各个线程的`fs`并不相同，最终访问的内存地址也不一样

一句话总结一下，为每个线程分配一块独享内存，将那些被`thread_local`修饰的变量移到这块内存当中，虽然外在形式是全局共享的，但实际本质是各线程独立的。

这篇文章终于可以谢幕了(事不过三