c语言多个线程对同一变量执行memcpy_你可曾听过网络编程中应用线程本地存储？...

壹：你可曾听过线程本地存储？

1. 什么是线程本地存储？

线程本地存储：thread local storage（简称TLS）。也叫线程特有存储：thread specific storage（简称TSS）或线程私有存储：thread private storage。

顾名思义，就是在多线程编程的环境中给全局或静态的变量每个线程分配不同的存储空间互不干扰。

注意区分TLS不是SSL网络协议的那个TLS，切莫混淆。

2. 什么时候需要线程本地存储？

不管是pthread还是C++的std::thread。多线程编程下，每个线程的执行逻辑都使用回调函数的方式赋给线程。如果一个变量仅仅是回调函数内使用，则不需要使用TLS，函数栈会保证多个线程执行同一个函数的时候，函数内的变量是不同的存储。如果是多线程需要共享变量，比如全局的资源计数器，这种是进程级别的变量也不需要TLS。

通常我们的多线程的回调函数内，不可能写一镜到底，还会调用多个函数，如果想让多个函数内共享一个变量。即一个变量要跨越多个函数的生命周期，并且不同线程需要不同的存储空间，那么需要TLS。

也就是回调函数中使用了『全局存储区』的某个变量（全局变量或函数内外静态变量）。简而言之，TLS就是要达到线程内的全局变量或静态变量的效果。

贰：你可见过C/C++线程本地存储API？

1. pthread线程特有存储

Unix编程接口的POSIX标准中定义的pthread_key_t为代表的『线程特有存储』是最传统的线程本地存储，适用于所有Unix（含Mac）与Linux系统。

static

phtread_key_t作为一个线程特有存储的标记key；phtread_key_create()对key进行初始化，注意，一定要先初始化才能进行后续的存取操作；pthread_setspecific()把key和一段堆存储区锚定；pthread_getspecific()通过key来取出数据，不同的线程会得到不同的结果。

值得一提的是，phtread_key_create()并非幂等的函数，多次调用key会变化。要保证线程内key唯一（即幂等）的话，需要配合pthread_once()来实现。

这套API的缺点显而易见，就是太过复杂了，使用起来着实不变，另外就是容易造成内存泄露。

2. __thread

__thread是GCC的关键字，非Unix编程标准，属于编译器自己实现。__thread只能修饰基础数据类型或者POD类型。所谓POD就是C语言中传统的struct类型。即无拷贝、析构函数的结构体。__thread也是只能用于全局存储区的变量，比如普通的全局变量或者函数内的静态变量。声明时的初始化并非必须的，但是最好如此！

#include

gcc编译需要加额外参数-pthread 即gcc xxx.cpp -pthread

输出：

140158795429632:1 1
140158787036928:2 2

显而易见的是__thread比pthread线程特有存储的用法更简洁，并且从资料来看性能更优！

但上面这两种API都是针对C语言的，所以__thread对C++的类并不支持（非POD），而自从C++11开始，C++也增加了自己的关键字thread_local用以支持线程本地存储，从而规避了__thread 不支持非POD类型的问题！

3. thread_local

C++11给标准库补充了std::thread库。同时新增关键字thread_local作为线程本地存储的修饰符！

在函数内使用的时候，是自动静态化的，示例：

#include

注意，Linux下编译上述代码要加额外参数-pthread（g++ -std=c++11 -pthread xxx.cpp），否则编译时虽过，但是运行时报错：Enable multithreading to use std::thread: Operation not permitted. Mac无此问题。

除标准数据类型之外，thread_local也可以修饰C++的对象。

thread_local

另外thread_local还可以修饰类中的成员变量，但只能是静态的成员变量，这个限制不难理解。

普通的static修饰的成员变量在实例化为多个对象的时候，存储区是共享的。而static thread_local修饰的时候又是另外一种情况：每个线程内共享，多个线程不共享的。

#include

和普通static成员变量一样，static thread_local的变量也需要在类外进行初始化，并且带着thread_local关键字。

4. boost::thread_specific_ptr

在C++还没有std::thread以及thread_local的年代，boost库用自己的方式实现了适合C++使用的线程本地存储：thread_specific_ptr模板（其实对于Unix/Linux系统而言，也是封装的pthread特有存储啦），可以将各种类型的变量转化为线程本地存储的变量。官方demo：

#include

thread_specific_ptr 的源码定义在线阅读：https://www.boost.org/doc/libs/1_59_0/boost/thread/tss.hpp

叁：你可曾读过半同步/半异步网络并发模型

不知道大家有没有读过这篇博文：

果冻虾仁：高山仰之可极，谈半同步/半异步网络并发模型zhuanlan.zhihu.com

在这篇文章中介绍了『半同步/半异步』以及『半同步/半反应堆』的网络模型。这些模型可以用多进程也可以用多线程来实现。通常来说多线程的实现会更轻量一些。其中会用到一个IO线程、一组工作线程和一个用于中间传导数据的队列。关于IO线程和中间队列的其他细节可以阅读上述文章，这里你只需要知道，一次请求最后会落到一个线程内去处理。

所以在这种情况下，一次请求处理的生命周期中中，变量可以区分出三种类型：

第一种是进程级别的，也就是请求无关的，和线程也无关的变量。比如配置文件的句柄、各类资源句柄（比如数据库、Redis）等
第二种是线程级别的，也就是请求级别的变量。在整个线程的处理过程之中会多次用到、并且是跨越函数的一些变量。换言之：线程级别的全局变量！
其他临时变量。在每个函数中随处可见的临时变量。

对于第二种，就是线程本地存储的使用场景。如果这类性质的变量十分繁多，可以封装进一个结构体中，然后用将整个结构体定义成线程本地存储（比如使用thread_local）。

肆：你可曾记得设计模式

1. 单例模式与有状态的单例

单例模式，应该是大家最最熟悉的设计模式了。在上节讨论各类存储的时候，很多人可能会首先想到用单例模式来封装第一二类变量。对于进程级别的数据可以，但是对于线程级别的数据，仅仅有单例模式不够的，单例模式可以做到变量存储的唯一性。但是唯一这个是进程级别的唯一，不同线程同时取用会出问题，这种实例只有一个，但是其数据在不同线程有不同副本的单例，我称之为有状态的单例。当然也有很多无状态的单例，就比如数据的连接句柄。对于这种有状态的单例，定义成线程本地存储而非普通成员变量才是正确的打开方式。

2. 网络编程设计模式中职责链

这里强调网络编程中的设计模式，是因为这里提到的职责链模式和传统的面向对象的职责链模式并不等价，但是其思想却是和普通的职责链模式相通的，只是网络编程中的职责链模式在更高一层的业务架构逻辑抽象中。

回顾上节，最终一次请求会在一个线程中得到处理。对于一个大型的系统而言，这一次处理可不是几十几百行代码能写完的，有时可能几千甚至几万。此时用类似职责链模式的思想来进行逻辑抽象，就是比较常见的解决方案了。将一次请求中业务逻辑的处理过程划分为多个不同的阶段，让请求在多个阶段的处理类中进行传递。这种事件传递的思想，在Android系统中也有很多应用，比如Android系统的事件分发机制以及有序广播功能。

每个阶段用一个类来封装，可以采用单例模式，初始化时给每个阶段的类生成唯一对象。线程的回调函数依次调用这些对象的处理函数，来处理请求数据，封装返回数据。彼时线程本地存储就有两种了：

全局的线程本地存储：可以跨越职责链多个阶段，一份数据在多个阶段都会进行加工处理
阶段内的线程本地存储：由于每个阶段对应一个单例的类，这些类通常是有状态的单例，因此也可能用到线程本地存储。