每个线程除了共享进程的资源外还拥有各自的私有资源：
一个寄存器组（或者说是线程上下文）；一个专属的堆栈；一个专属的消息队列；一个专属的Thread Local Storage（TLS）；一个专属的结构化异常处理串链。

TLS 是一个良好的Win32 特质，让多线程程序设计更容易一些。TLS 是一个机制，经由它，程序可以拥有全域变量，但处于「每一线程各不相同」的状态。也就是说，进程中的所有线程都可以拥有全域变量，但这些变量其实是特定对某个线程才有意义。例如，你可能有一个多线程程序，每一个线程都对不同的文件写文件（也因此它们使用不同的文件handle）。这种情况下，把每一个线程所使用的文件handle 储存在TLS 中，将会十分方便。当线程需要知道所使用的handle，它可以从TLS 获得。重点在于：线程用来取得文件handle 的那一段码在任何情况下都是相同的，而从TLS中取出的文件handle 却各不相同。

四个函数就是对TLS进行操作的：

（1）TlsAlloc

上面我们说过了KERNEL32 使用两个DWORDs（总共64 个位）来记录哪一个slot 是可用的、哪一个slot 已经被用。当你需要使用一个TLS slot 的时候，你就可以用这个函数将相应的TLS slot位置１。

（2）TlsSetValue

TlsSetValue 可以把数据放入先前配置到的TLS slot 中。两个参数分别是TLS slot 索引值以及欲写入的数据内容。TlsSetValue 就把你指定的数据放入64 DWORDs 所组成的数组（位于目前的thread database）的适当位置中。

（3）TlsGetValue

这个函数几乎是TlsSetValue 的一面镜子，最大的差异是它取出数据而非设定数据。和TlsSetValue 一样，这个函数也是先检查TLS 索引值合法与否。如果是，TlsGetValue 就使用这个索引值找到64 DWORDs 数组（位于thread database 中）的对应数据项，并将其内容传回。

（4）TlsFree

这个函数将TlsAlloc 和TlsSetValue 的努力全部抹消掉。TlsFree 先检验你交给它的索引值是否的确被配置过。如果是，它将对应的64 位TLS slots 位关闭。然后，为了避免那个已经不再合法的内容被使用，TlsFree 巡访进程中的每一个线程，把0 放到刚刚被释放的那个TLS slot 上头。于是呢，如果有某个TLS 索引后来又被重新配置，所有用到该索引的线程就保证会取回一个0 值，除非它们再调用TlsSetValue。

实现TLS有两种方法：静态TLS和动态TLS。以下我们将分别说明这两类TLS。

二、静态TLS

1、使用静态TLS

之所以先讲静态TLS，是因为他在代码中使用时非常简单，我们只需写类似如下这一句：

__declspec(thread) DWORD myTLSData=0;

我们就为本程序中的每一个线程创建了一个独立的DWORD数据。

__declspec(thread)的前缀是Microsoft添加给Visual C++编译器的一个修改符。它告诉编译器，对应的变量应该放入可执行文件或DLL文件中它的自己的节中。__declspec(thread)后面的变量必须声明为函数中（或函数外）的一个全局变量或静态变量。不能声明一个类型为__declspec(thread)的局部变量，你想，因为局部变量总是与特定的线程相联系的，如果再加上这个声明是代表什么意思？

2、静态TLS原理

静态TLS的使用是如此简单，那么当我们写了如上代码以后，操作系统和编译器是怎么处理的呢？

首先，在编译器对程序进行编译时，它会将所有声明的TLS变量放入它们自己的节，这个节的名字是.tls。而后链接程序将来自所有对象模块的所有.tls节组合起来，形成结果的可执行文件或DLL文件中的一个大的完整的.tls节。
然后，为了使含有静态TLS的程序能够运行，操作系统必须参与其操作。当TLS应用程序加载到内存中时，系统要寻找可执行文件中的.tls节，并且动态地分配一个足够大的内存块，以便存放所有的静态TLS变量。应用程序中的代码每次引用其中的一个变量时，就要转换为已分配内存块中包含的一个内存位置。因此，编译器必须生成一些辅助代码来引用该静态TLS变量，这将使你的应用程序变得比较大而且运行的速度比较慢。在x86 CPU上，将为每次引用的静态TLS变量生成3个辅助机器指令。如果在进程中创建了另一个线程，那么系统就要将它捕获并且自动分配另一个内存块，以便存放新线程的静态TLS变量。新线程只拥有对它自己的静态TLS变量的访问权，不能访问属于其他线程的TLS变量。

以上是包含静态TLS变量的可执行文件如何运行的情况。我们再来看看DLL的情况：

a、隐式链接包含静态TLS变量的DLL

如果应用程序使用了静态TLS变量，并且隐式链接包含静态TLS变量的DLL时，当系统加载该应用程序时，它首先要确定应用程序的.tls节的大小，并将这个值与应用程序链接的DLL中的所有.tls节的大小相加。当在你的进程中创建线程时，系统自动分配足够大的内存块来存放所有应用程序声明的和所有隐含链接的DLL包含的TLS变量。

b、显式链接包含静态TLS变量的DLL

考虑一下，当我们的应用程序通过调用LoadLibrary，以便显式链接到包含静态TLS变量的DLL时，会发生什么情况呢？系统必须查看该进程中已经存在的所有线程，并扩大它们的TLS内存块，以便适应新DLL对内存的需求。另外，如果调用FreeLibrary来释放包含静态TLS变量的DLL，那么与进程中的每个线程相关的的TLS内存块又都应该被压缩。
对于操作系统来说，这样的管理任务太重了。所以，虽然系统允许包含静态TLS变量的库在运行期进行显式加载，但是其包含TLS数据却没有进行相应的初始化。如果试图访问这些数据，就可能导致访问违规！

所以，请记住：如果某个DLL包含静态TLS数据，请不要对这个DLL采用显式链接的方式，否则可能会出错！

三、动态TLS

1、使用动态TLS

动态TLS在程序实现中比静态TLS要稍微麻烦一些，需要通过一组函数来实现：

DWORD TlsAlloc();//返回TLS数组可用位置的索引

BOOL TlsSetValue(DWORD dwTlsIndex, LPVOID lpTlsValue); //将调用线程的TLS数组索引dwTlsIndex处设为值lpTlsValue

LPVOID TlsGetValue(DWORD dwTlsIndex); //返回调用线程的TLS数组dwTlsIndex索引处的值

BOOL TlsFree(DWORD dwTlsIndex); //释放所有线程的TLS数组位置索引dwTlsIndex，将该位置标记为未使用。

有了以上四个函数，我们可以发现使用动态TLS其实还是很容易很方便的。

2、动态TLS原理

让我们看看windows用来管理TLS的内部数据结构：
线程本地存储器的位标志显示了该进程中所有运行的线程正在使用的一组标志。每个标志均可设置为FREE或者INUSE，表示TLS插槽(slot)是否正在使用。Microsoft保证至少TLS_MINIMUM_AVAILABLE位标志是可供使用的。另外，TLS_MINIMUM_AVAILABLE在WinNT.h中被定义为64。Windows2000将这个标志数组扩展为允许有1000个以上的TLS插槽。

而每一个线程拥有一个自己独立的TLS slot数组，用于存储TLS数据。
为了使用动态TLS，我们首先调用TlsAlloc()来命令系统对进程的位标志进行扫描，找到一个可用的位置，并返回该索引；如果找不到，就返回TLS_OUT_OF_INDEXES。事实上，除此之外，TlsAlloc函数还会自动清空所有线程的TLS数组的对应索引的值。这避免以前遗留的值可能引起的问题。
然后，我们就可以调用TlsSetValue函数将对应的索引位保存一个特定的值，可以调用TlsGetValue()来返回该索引位的值。注意，这两个函数并不执行任何测试和错误检查，我们必须要保证索引是通过TlsAlloc正确分配的。
当所有线程都不需要保留TLS数组某个索引位的时候，应该调用TlsFree。该函数告知系统将进程的位标志数组的index位置为FREE状态。如果运行成功，函数返回TRUE。注意，如果试图释放一个没有分配的索引位，将产生一个错误。
动态TLS的使用相对静态TLS稍微麻烦一点，但是无论是将其用在可执行文件中还是DLL中，都还是很简单的。而且当用在DLL中时，没有由于DLL链接方式而可能产生的问题，所以，如果要在DLL中用TLS，又不能保证客户始终采用隐式链接方式，那么请采用动态TLS的实现。

主要参考文档《windows核心编程》。

Go语言中没有原生的线程（协程）上下文，也不支持TLS（Thread Local Storage），更没有暴露API获取Goroutine的Id（后面简称GoId）。这导致无法像Java一样，把一些信息放在TLS上，用于来简化上层应用的API使用：不需要在调用栈的函数中通过传递参数来传递调用链与日志跟踪的一些上下文信息。
在Go语言中，而Google提供的解决方法是采用golang.org/x/net/context包来传递GoRoutine的上下文。
Context也是能存储Goroutine一些数据达到共享，但它提供的接口是WithValue函数来创建一个新的Context对象。
用户经常使用GoId来实现goroutine local storage，而Go语言不希望用户使用goroutine local storage。
不建议使用goroutine local storage的原因是由于不容易GC，虽然能获当前的GoId，但不能获取其它正在运行的Goroutine。
另一个重要的原因是由于产生一个Goroutine非常地容易（而线程通用会采用线程池），新产生的Goroutine会失去访问goroutine local storage。需要上层应用保证不会产生新的Goroutine，但我们很难确保标准库或第三库不会这样做。

在 Go 语言中，TLS 存储了一个 G 结构体的指针。这个指针所指向的结构体包括 Go 例程的内部细节（后面会详细谈到这些内容）。因此，当在不同的例程中访问该变量时，实际访问的是该例程相应的变量所指向的结构体。链接器知道这个变量所在的位置，前面的指令中移动到 CX 寄存器的就是这个变量。对于 AMD64，TLS 是用 FS 寄存器来实现的， 所在我们前面看到的命令实际上可以翻译为 MOVQ FS, CX。