之前测试mysqldump的导入，需要另外一台数据库，自己有一台CentOS 7系统的服务器。
于是需要在CentOS 7安装mysql，之前并没有怎么使用CentOS 7。而且CentOS 7下mysql下替换成MariaDB了（MariaDB是从MySQL fork过来的，和MySQL有很好的兼容性 ）。所以这里记录下。

CentOS 7下yum安装MariaDB

由于作为测试服务器使用，所以使用yum快速安装。如下：

yum install mariadb mariadb-server systemctl start mariadb   #启动mariadb systemctl enable mariadb  #设置开机自启动 mysql_secure_installation #设置root密码等相关 mysql -uroot -p           #测试登录

1. 零拷贝是网络编程的关键, 很多性能优化都需要零拷贝。
2. 在 Java程序中, 常用的零拷贝方式有m(memory)map[内存映射] 和 sendFile。它们在OS中又是怎样的设计?
3. NIO中如何使用零拷贝?

NIO 与 传统IO对比

• 传统IO流程示意图

  

  • user context: 用户态
  • kernel context: 内核态
  • User space: 用户空间
  • Kernel space: 内核空间
  • Syscall read: 系统调用读取
  • Syscall write: 系统调用写入
  • Hard drive: 硬件驱动
  • kernel buffer: 内核态缓冲区
  • user buffer: 用户态缓冲区
  • socket buffer: 套接字缓存
  • protocol engine: 协议引擎
  • DMA: Direct Memory Access: 直接内存拷贝(不使用CPU)
  • 总结: 4次拷贝, 3次状态切换, 效率不高

• mmap优化流程示意图

  

  • mmap 通过内存映射, 将文件映射到内核缓冲区, 同时, 用户空间可以共享内核空间的数据。
  • 这样, 在进行网络传输时, 就可以减少内核空间到用户空间的拷贝次数。
  • 总结: 3次拷贝, 3次状态切换, 不是真正意义上的零拷贝。

• sendFile Linux2.1版本优化流程示意图

  

  • 数据根本不经过用户态, 直接从内核缓冲区进入到Socket Buffer, 同时, 由于和用户台完全无关, 就减少了一次上下文切换。
  • 但是仍然有一次CPU拷贝, 不是真正的零拷贝(没有CPU拷贝)。
  • 总结: 3次拷贝, 2次切换

• sendFile Linux

  

  • 避免了从内核缓冲区拷贝到Socket buffer的操作, 直接拷贝到协议栈, 从而再一次减少了数据拷贝。
  • 其实是有一次cpu拷贝的, kernel buffer -> socket buffer, 但是拷贝的信息很少, length, offset, 消耗低, 基本可以忽略。
  • 总结: 2次拷贝(如果忽略消耗低的cpu拷贝的话), 2次切换, 基本可以认为是零拷贝了。

零拷贝理解

• 零拷贝是从操作系统的角度来看的。内核缓冲区之间, 没有数据是重复的(只有kernel buffer有一份数据)。
• 零拷贝不仅仅带来更少的数据复制, 还能带来其他的性能优势: 如更少的上下文切换, 更少的 CPU 缓存伪共享以及无CPU校验和计算。

mmap 与 sendFile 总结

• mmap适合小数据两读写, sendFile适合大文件传输
• mmap 需要3次上下文切换, 3次数据拷贝; sendFile 需要3次上下文切换, 最少2次数据拷贝。
• sendFile 可以利用 DMA 方式, 减少 CPU 拷贝, 而 mmap则不能(必须从内核拷贝到Socket缓冲区)。

1、 time_wait的作用：

TIME_WAIT状态存在的理由： 1）可靠地实现TCP全双工连接的终止    在进行关闭连接四次挥手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN， 因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。 因而，要实现TCP全双工连接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。   2）允许老的重复分节在网络中消逝  TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个原来的迷途分节就称为lost duplicate。 在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身（incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。 为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复分组已经在网络中消逝。

2、大量TIME_WAIT造成的影响：

      在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。

为什么我们要关注这个高并发短连接呢？有两个方面需要注意：
1. 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
2. 在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。

      这里有个相对长短的概念，比如取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的(占着茅坑不拉翔)。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高。
     综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，无法用SO_REUSEADDR选项解决这个问题。

关于time_wait的反思：

存在即是合理的，既然TCP协议能盛行四十多年，就证明他的设计合理性。所以我们尽可能的使用其原本功能。 依靠TIME_WAIT状态来保证我的服务器程序健壮，服务功能正常。 那是不是就不要性能了呢？并不是。如果服务器上跑的短连接业务量到了我真的必须处理这个TIMEWAIT状态过多的问题的时候，我的原则是尽量处理，而不是跟TIMEWAIT干上，非先除之而后快。 如果尽量处理了，还是解决不了问题，仍然拒绝服务部分请求，那我会采取负载均衡来抗这些高并发的短请求。持续十万并发的短连接请求，两台机器，每台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题，一句话，达不到时才需要关注这个问题的访问量。

小知识点：

TCP协议发表：1974年12月，卡恩、瑟夫的第一份TCP协议详细说明正式发表。当时美国国防部与三个科学家小组签定了完成TCP/IP的协议，结果由瑟夫领衔的小组捷足先登，首先制定出了通过详细定义的TCP/IP协议标准。当时作了一个试验，将信息包通过点对点的卫星网络，再通过陆地电缆
，再通过卫星网络，再由地面传输，贯串欧洲和美国，经过各种电脑系统，全程9.4万公里竟然没有丢失一个数据位，远距离的可靠数据传输证明了TCP/IP协议的成功。

3、案列分析：

    首先，根据一个查询TCP连接数，来说明这个问题。

netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}' LAST_ACK 14 SYN_RECV 348 ESTABLISHED 70 FIN_WAIT1 229 FIN_WAIT2 30 CLOSING 33 TIME_WAIT 18122

状态描述：

CLOSED：无连接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另一边已同意释放 ITMED_WAIT：等待所有分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另一边已初始化一个释放 LAST_ACK：等待所有分组死掉

命令解释：

先来看看netstat： netstat -n Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 123.123.123.123:80 234.234.234.234:12345 TIME_WAIT 你实际执行这条命令的时候，可能会得到成千上万条类似上面的记录，不过我们就拿其中的一条就足够了。  再来看看awk： /^tcp/ 滤出tcp开头的记录，屏蔽udp, socket等无关记录。 state[]相当于定义了一个名叫state的数组 NF 表示记录的字段数，如上所示的记录，NF等于6 $NF 表示某个字段的值，如上所示的记录，$NF也就是$6，表示第6个字段的值，也就是TIME_WAIT state[$NF]表示数组元素的值，如上所示的记录，就是state[TIME_WAIT]状态的连接数 ++state[$NF]表示把某个数加一，如上所示的记录，就是把state[TIME_WAIT]状态的连接数加一 END 表示在最后阶段要执行的命令 for(key in state) 遍历数组

如何尽量处理TIMEWAIT过多?

编辑内核文件/etc/sysctl.conf，加入以下内容：

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭； net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭； net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。 net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间

然后执行 /sbin/sysctl -p 让参数生效.

/etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口，它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，修改内核参数永久生效。

简单来说，就是打开系统的TIMEWAIT重用和快速回收。

如果以上配置调优后性能还不理想，可继续修改一下配置：

vi /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 1200  #表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。 net.ipv4.ip_local_port_range = 1024 65000  #表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。 net.ipv4.tcp_max_syn_backlog = 8192  #表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。 net.ipv4.tcp_max_tw_buckets = 5000  #表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。 默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于 Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。

http://wizmann.tk/linux-lockless-llist.html

typeof和sizeof类似，sizeof求的是变量/类型的大小，而typeof是求变量/类型的数据类型。

typeof在#define中的应用很多，例如：

#define max(a,b) \    ({ typeof (a) _a = (a); \        typeof (b) _b = (b); \      _a > _b ? _a : _b; }) 

typeof(a)获得了a的类型，声明了一个同类型的_a变量。

p.s. 上面是一个安全的用#define实现的max函数。

ACCESS_ONCE

#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))； 

ACCESS_ONCE使用了一个类型转换，使用volatile修饰 x。避免编译器优化带来的潜在岐义。

参考文献列表：
http://en.wikipedia.org/wiki/Memory_barrier
http://en.wikipedia.org/wiki/Out-of-order_execution
https://www.kernel.org/doc/Documentation/memory-barriers.txt

本文例子均在 Linux（g++）下验证通过，CPU 为 X86-64 处理器架构。所有罗列的 Linux 内核代码也均在（或只在）X86-64 下有效。

本文首先通过范例（以及内核代码）来解释 Memory barrier，然后介绍一个利用 Memory barrier 实现的无锁环形缓冲区。

Memory barrier 简介

程序在运行时内存实际的访问顺序和程序代码编写的访问顺序不一定一致，这就是内存乱序访问。内存乱序访问行为出现的理由是为了提升程序运行时的性能。内存乱序访问主要发生在两个阶段：

1. 编译时，编译器优化导致内存乱序访问（指令重排）
2. 运行时，多 CPU 间交互引起内存乱序访问

Memory barrier 能够让 CPU 或编译器在内存访问上有序。一个 Memory barrier 之前的内存访问操作必定先于其之后的完成。Memory barrier 包括两类：

1. 编译器 barrier
2. CPU Memory barrier

很多时候，编译器和 CPU 引起内存乱序访问不会带来什么问题，但一些特殊情况下，程序逻辑的正确性依赖于内存访问顺序，这时候内存乱序访问会带来逻辑上的错误，例如：

1. // thread 1
2. while (!ok);
3. do(x);
4.  
5. // thread 2
6. x = 42;
7. ok = 1;

此段代码中，ok 初始化为 0，线程 1 等待 ok 被设置为 1 后执行 do 函数。假如说，线程 2 对内存的写操作乱序执行，也就是 x 赋值后于 ok 赋值完成，那么 do 函数接受的实参就很可能出乎程序员的意料，不为 42。

编译时内存乱序访问

在编译时，编译器对代码做出优化时可能改变实际执行指令的顺序（例如 gcc 下 O2 或 O3 都会改变实际执行指令的顺序）：

1. // test.cpp
2. int x, y, r;
3. void f()
4. {
5. x = r;
6. y = 1;
7. }

编译器优化的结果可能导致 y = 1 在 x = r 之前执行完成。首先直接编译此源文件：

1. g++ -S test.cpp

得到相关的汇编代码如下：

1. movl r(%rip), %eax
2. movl %eax, x(%rip)
3. movl $1, y(%rip)

这里我们看到，x = r 和 y = 1 并没有乱序。现使用优化选项 O2（或 O3）编译上面的代码（g++ -O2 -S test.cpp），生成汇编代码如下：

1. movl r(%rip), %eax
2. movl $1, y(%rip)
3. movl %eax, x(%rip)

我们可以清楚的看到经过编译器优化之后 movl $1, y(%rip) 先于 movl %eax, x(%rip) 执行。避免编译时内存乱序访问的办法就是使用编译器 barrier（又叫优化 barrier）。Linux 内核提供函数 barrier() 用于让编译器保证其之前的内存访问先于其之后的完成。内核实现 barrier() 如下（X86-64 架构）：

1. #define barrier() __asm__ __volatile__("" ::: "memory")

现在把此编译器 barrier 加入代码中：

1. int x, y, r;
2. void f()
3. {
4. x = r;
5. __asm__ __volatile__("" ::: "memory");
6. y = 1;
7. }

这样就避免了编译器优化带来的内存乱序访问的问题了（如果有兴趣可以再看看编译之后的汇编代码）。本例中，我们还可以使用 volatile 这个关键字来避免编译时内存乱序访问（而无法避免后面要说的运行时内存乱序访问）。volatile 关键字能够让相关的变量之间在内存访问上避免乱序，这里可以修改 x 和 y 的定义来解决问题：

1. volatile int x, y;
2. int r;
3. void f()
4. {
5. x = r;
6. y = 1;
7. }

现加上了 volatile 关键字，这使得 x 相对于 y、y 相对于 x 在内存访问上有序。在 Linux 内核中，提供了一个宏 ACCESS_ONCE 来避免编译器对于连续的 ACCESS_ONCE 实例进行指令重排。其实 ACCESS_ONCE 实现源码如下：

1. #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

此代码只是将变量 x 转换为 volatile 的而已。现在我们就有了第三个修改方案：

1. int x, y, r;
2. void f()
3. {
4. ACCESS_ONCE(x) = r;
5. ACCESS_ONCE(y) = 1;
6. }

到此基本上就阐述完了我们的编译时内存乱序访问的问题。下面开始介绍运行时内存乱序访问。

运行时内存乱序访问

在运行时，CPU 虽然会乱序执行指令，但是在单个 CPU 的上，硬件能够保证程序执行时所有的内存访问操作看起来像是按程序代码编写的顺序执行的，这时候 Memory barrier 没有必要使用（不考虑编译器优化的情况下）。这里我们了解一下 CPU 乱序执行的行为。在乱序执行时，一个处理器真正执行指令的顺序由可用的输入数据决定，而非程序员编写的顺序。
早期的处理器为有序处理器（In-order processors），有序处理器处理指令通常有以下几步：

1. 指令获取
2. 如果指令的输入操作对象（input operands）可用（例如已经在寄存器中了），则将此指令分发到适当的功能单元中。如果一个或者多个操作对象不可用（通常是由于需要从内存中获取），则处理器会等待直到它们可用
3. 指令被适当的功能单元执行
4. 功能单元将结果写回寄存器堆（Register file，一个 CPU 中的一组寄存器）

相比之下，乱序处理器（Out-of-order processors）处理指令通常有以下几步：

1. 指令获取
2. 指令被分发到指令队列
3. 指令在指令队列中等待，直到输入操作对象可用（一旦输入操作对象可用，指令就可以离开队列，即便更早的指令未被执行）
4. 指令被分配到适当的功能单元并执行
5. 执行结果被放入队列（而不立即写入寄存器堆）
6. 只有所有更早请求执行的指令的执行结果被写入寄存器堆后，指令执行的结果才被写入寄存器堆（执行结果重排序，让执行看起来是有序的）

从上面的执行过程可以看出，乱序执行相比有序执行能够避免等待不可用的操作对象（有序执行的第二步）从而提高了效率。现代的机器上，处理器运行的速度比内存快很多，有序处理器花在等待可用数据的时间里已经可以处理大量指令了。
现在思考一下乱序处理器处理指令的过程，我们能得到几个结论：

1. 对于单个 CPU 指令获取是有序的（通过队列实现）
2. 对于单个 CPU 指令执行结果也是有序返回寄存器堆的（通过队列实现）

由此可知，在单 CPU 上，不考虑编译器优化导致乱序的前提下，多线程执行不存在内存乱序访问的问题。我们从内核源码也可以得到类似的结论（代码不完全的摘录）：

1. #ifdef CONFIG_SMP
2. #define smp_mb() mb()
3. #else
4. #define smp_mb() barrier()
5. #endif

这里可以看到，如果是 SMP 则使用 mb，mb 被定义为 CPU Memory barrier（后面会讲到），而非 SMP 时，直接使用编译器 barrier。

在多 CPU 的机器上，问题又不一样了。每个 CPU 都存在 cache（cache 主要是为了弥补 CPU 和内存之间较慢的访问速度），当一个特定数据第一次被特定一个 CPU 获取时，此数据显然不在 CPU 的 cache 中（这就是 cache miss）。此 cache miss 意味着 CPU 需要从内存中获取数据（这个过程需要 CPU 等待数百个周期），此数据将被加载到 CPU 的 cache 中，这样后续就能直接从 cache 上快速访问。当某个 CPU 进行写操作时，它必须确保其他的 CPU 已经将此数据从它们的 cache 中移除（以便保证一致性），只有在移除操作完成后此 CPU 才能安全的修改数据。显然，存在多个 cache 时，我们必须通过一个 cache 一致性协议来避免数据不一致的问题，而这个通讯的过程就可能导致乱序访问的出现，也就是这里说的运行时内存乱序访问。这里不再深入讨论整个细节，这是一个比较复杂的问题，有兴趣可以研究 http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf 一文，其详细的分析了整个过程。

现在通过一个例子来说明多 CPU 下内存乱序访问：

1. // test2.cpp
2. #include <pthread.h>
3. #include <assert.h>
4.  
5. // -------------------
6. int cpu_thread1 = 0;
7. int cpu_thread2 = 1;
8.  
9. volatile int x, y, r1, r2;
10.  
11. void start()
12. {
13. x = y = r1 = r2 = 0;
14. }
15.  
16. void end()
17. {
18. assert(!(r1 == 0 && r2 == 0));
19. }
20.  
21. void run1()
22. {
23. x = 1;
24. r1 = y;
25. }
26.  
27. void run2()
28. {
29. y = 1;
30. r2 = x;
31. }
32.  
33. // -------------------
34. static pthread_barrier_t barrier_start;
35. static pthread_barrier_t barrier_end;
36.  
37. static void* thread1(void*)
38. {
39. while (1) {
40. pthread_barrier_wait(&barrier_start);
41. run1();
42. pthread_barrier_wait(&barrier_end);
43. }
44.  
45. return NULL;
46. }
47.  
48. static void* thread2(void*)
49. {
50. while (1) {
51. pthread_barrier_wait(&barrier_start);
52. run2();
53. pthread_barrier_wait(&barrier_end);
54. }
55.  
56. return NULL;
57. }
58.  
59. int main()
60. {
61. assert(pthread_barrier_init(&barrier_start, NULL, 3) == 0);
62. assert(pthread_barrier_init(&barrier_end, NULL, 3) == 0);
63.  
64. pthread_t t1;
65. pthread_t t2;
66. assert(pthread_create(&t1, NULL, thread1, NULL) == 0);
67. assert(pthread_create(&t2, NULL, thread2, NULL) == 0);
68.  
69. cpu_set_t cs;
70. CPU_ZERO(&cs);
71. CPU_SET(cpu_thread1, &cs);
72. assert(pthread_setaffinity_np(t1, sizeof(cs), &cs) == 0);
73. CPU_ZERO(&cs);
74. CPU_SET(cpu_thread2, &cs);
75. assert(pthread_setaffinity_np(t2, sizeof(cs), &cs) == 0);
76.  
77. while (1) {
78. start();
79. pthread_barrier_wait(&barrier_start);
80. pthread_barrier_wait(&barrier_end);
81. end();
82. }
83.  
84. return 0;
85. }

这里创建了两个线程来运行测试代码（需要测试的代码将放置在 run 函数中）。我使用了 pthread barrier（区别于本文讨论的 Memory barrier）主要为了让两个子线程能够同时运行它们的 run 函数。此段代码不停的尝试同时运行两个线程的 run 函数，以便得出我们期望的结果。在每次运行 run 函数前会调用一次 start 函数（进行数据初始化），run 运行后会调用一次 end 函数（进行结果检查）。run1 和 run2 两个函数运行在哪个 CPU 上则通过 cpu_thread1 和 cpu_thread2 两个变量控制。
先编译此程序：g++ -lpthread -o test2 test2.cpp（这里未优化，目的是为了避免编译器优化的干扰）。需要注意的是，两个线程运行在两个不同的 CPU 上（CPU 0 和 CPU 1）。只要内存不出现乱序访问，那么 r1 和 r2 不可能同时为 0，因此断言失败表示存在内存乱序访问。编译之后运行此程序，会发现存在一定概率导致断言失败。为了进一步说明问题，我们把 cpu_thread2 的值改为 0，换而言之就是让两个线程跑在同一个 CPU 下，再运行程序发现断言不再失败。

最后，我们使用 CPU Memory barrier 来解决内存乱序访问的问题（X86-64 架构下）：

1. int cpu_thread1 = 0;
2. int cpu_thread2 = 1;
3.  
4. void run1()
5. {
6. x = 1;
7. __asm__ __volatile__("mfence" ::: "memory");
8. r1 = y;
9. }
10.  
11. void run2()
12. {
13. y = 1;
14. __asm__ __volatile__("mfence" ::: "memory");
15. r2 = x;
16. }

准备使用 Memory barrier

Memory barrier 常用场合包括：

1. 实现同步原语（synchronization primitives）
2. 实现无锁数据结构（lock-free data structures）
3. 驱动程序

实际的应用程序开发中，开发者可能完全不知道 Memory barrier 就可以开发正确的多线程程序，这主要是因为各种同步机制中已经隐含了 Memory barrier（但和实际的 Memory barrier 有细微差别），这就使得不直接使用 Memory barrier 不会存在任何问题。但是如果你希望编写诸如无锁数据结构，那么 Memory barrier 还是很有用的。

通常来说，在单个 CPU 上，存在依赖的内存访问有序：

1. Q = P;
2. D = *Q;

这里内存操作有序。然而在 Alpha CPU 上，存在依赖的内存读取操作不一定有序，需要使用数据依赖 barrier（由于 Alpha 不常见，这里就不详细解释了）。

在 Linux 内核中，除了前面说到的编译器 barrier — barrier() 和 ACCESS_ONCE()，还有 CPU Memory barrier：

1. 通用 barrier，保证读写操作有序的，mb() 和 smp_mb()
2. 写操作 barrier，仅保证写操作有序的，wmb() 和 smp_wmb()
3. 读操作 barrier，仅保证读操作有序的，rmb() 和 smp_rmb()

注意，所有的 CPU Memory barrier（除了数据依赖 barrier 之外）都隐含了编译器 barrier。这里的 smp 开头的 Memory barrier 会根据配置在单处理器上直接使用编译器 barrier，而在 SMP 上才使用 CPU Memory barrier（也就是 mb()、wmb()、rmb()，回忆上面相关内核代码）。

最后需要注意一点的是，CPU Memory barrier 中某些类型的 Memory barrier 需要成对使用，否则会出错，详细来说就是：一个写操作 barrier 需要和读操作（或数据依赖）barrier 一起使用（当然，通用 barrier 也是可以的），反之依然。

Memory barrier 的范例

读内核代码进一步学习 Memory barrier 的使用。
Linux 内核实现的无锁（只有一个读线程和一个写线程时）环形缓冲区 kfifo 就使用到了 Memory barrier，实现源码如下：

1. /*
2. * A simple kernel FIFO implementation.
3. *
4. * Copyright (C) 2004 Stelian Pop <stelian@popies.net>
5. *
6. * This program is free software; you can redistribute it and/or modify
7. * it under the terms of the GNU General Public License as published by
8. * the Free Software Foundation; either version 2 of the License, or
9. * (at your option) any later version.
10. *
11. * This program is distributed in the hope that it will be useful,
12. * but WITHOUT ANY WARRANTY; without even the implied warranty of
13. * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
14. * GNU General Public License for more details.
15. *
16. * You should have received a copy of the GNU General Public License
17. * along with this program; if not, write to the Free Software
18. * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
19. *
20. */
21.  
22. #include <linux/kernel.h>
23. #include <linux/module.h>
24. #include <linux/slab.h>
25. #include <linux/err.h>
26. #include <linux/kfifo.h>
27. #include <linux/log2.h>
28.  
29. /**
30. * kfifo_init - allocates a new FIFO using a preallocated buffer
31. * @buffer: the preallocated buffer to be used.
32. * @size: the size of the internal buffer, this have to be a power of 2.
33. * @gfp_mask: get_free_pages mask, passed to kmalloc()
34. * @lock: the lock to be used to protect the fifo buffer
35. *
36. * Do NOT pass the kfifo to kfifo_free() after use! Simply free the
37. * &struct kfifo with kfree().
38. */
39. struct kfifo *kfifo_init(unsigned char *buffer, unsigned int size,
40. gfp_t gfp_mask, spinlock_t *lock)
41. {
42. struct kfifo *fifo;
43.  
44. /* size must be a power of 2 */
45. BUG_ON(!is_power_of_2(size));
46.  
47. fifo = kmalloc(sizeof(struct kfifo), gfp_mask);
48. if (!fifo)
49. return ERR_PTR(-ENOMEM);
50.  
51. fifo->buffer = buffer;
52. fifo->size = size;
53. fifo->in = fifo->out = 0;
54. fifo->lock = lock;
55.  
56. return fifo;
57. }
58. EXPORT_SYMBOL(kfifo_init);
59.  
60. /**
61. * kfifo_alloc - allocates a new FIFO and its internal buffer
62. * @size: the size of the internal buffer to be allocated.
63. * @gfp_mask: get_free_pages mask, passed to kmalloc()
64. * @lock: the lock to be used to protect the fifo buffer
65. *
66. * The size will be rounded-up to a power of 2.
67. */
68. struct kfifo *kfifo_alloc(unsigned int size, gfp_t gfp_mask, spinlock_t *lock)
69. {
70. unsigned char *buffer;
71. struct kfifo *ret;
72.  
73. /*
74. * round up to the next power of 2, since our 'let the indices
75. * wrap' technique works only in this case.
76. */
77. if (!is_power_of_2(size)) {
78. BUG_ON(size > 0x80000000);
79. size = roundup_pow_of_two(size);
80. }
81.  
82. buffer = kmalloc(size, gfp_mask);
83. if (!buffer)
84. return ERR_PTR(-ENOMEM);
85.  
86. ret = kfifo_init(buffer, size, gfp_mask, lock);
87.  
88. if (IS_ERR(ret))
89. kfree(buffer);
90.  
91. return ret;
92. }
93. EXPORT_SYMBOL(kfifo_alloc);
94.  
95. /**
96. * kfifo_free - frees the FIFO
97. * @fifo: the fifo to be freed.
98. */
99. void kfifo_free(struct kfifo *fifo)
100. {
101. kfree(fifo->buffer);
102. kfree(fifo);
103. }
104. EXPORT_SYMBOL(kfifo_free);
105.  
106. /**
107. * __kfifo_put - puts some data into the FIFO, no locking version
108. * @fifo: the fifo to be used.
109. * @buffer: the data to be added.
110. * @len: the length of the data to be added.
111. *
112. * This function copies at most @len bytes from the @buffer into
113. * the FIFO depending on the free space, and returns the number of
114. * bytes copied.
115. *
116. * Note that with only one concurrent reader and one concurrent
117. * writer, you don't need extra locking to use these functions.
118. */
119. unsigned int __kfifo_put(struct kfifo *fifo,
120. const unsigned char *buffer, unsigned int len)
121. {
122. unsigned int l;
123.  
124. len = min(len, fifo->size - fifo->in + fifo->out);
125.  
126. /*
127. * Ensure that we sample the fifo->out index -before- we
128. * start putting bytes into the kfifo.
129. */
130.  
131. smp_mb();
132.  
133. /* first put the data starting from fifo->in to buffer end */
134. l = min(len, fifo->size - (fifo->in & (fifo->size - 1)));
135. memcpy(fifo->buffer + (fifo->in & (fifo->size - 1)), buffer, l);
136.  
137. /* then put the rest (if any) at the beginning of the buffer */
138. memcpy(fifo->buffer, buffer + l, len - l);
139.  
140. /*
141. * Ensure that we add the bytes to the kfifo -before-
142. * we update the fifo->in index.
143. */
144.  
145. smp_wmb();
146.  
147. fifo->in += len;
148.  
149. return len;
150. }
151. EXPORT_SYMBOL(__kfifo_put);
152.  
153. /**
154. * __kfifo_get - gets some data from the FIFO, no locking version
155. * @fifo: the fifo to be used.
156. * @buffer: where the data must be copied.
157. * @len: the size of the destination buffer.
158. *
159. * This function copies at most @len bytes from the FIFO into the
160. * @buffer and returns the number of copied bytes.
161. *
162. * Note that with only one concurrent reader and one concurrent
163. * writer, you don't need extra locking to use these functions.
164. */
165. unsigned int __kfifo_get(struct kfifo *fifo,
166. unsigned char *buffer, unsigned int len)
167. {
168. unsigned int l;
169.  
170. len = min(len, fifo->in - fifo->out);
171.  
172. /*
173. * Ensure that we sample the fifo->in index -before- we
174. * start removing bytes from the kfifo.
175. */
176.  
177. smp_rmb();
178.  
179. /* first get the data from fifo->out until the end of the buffer */
180. l = min(len, fifo->size - (fifo->out & (fifo->size - 1)));
181. memcpy(buffer, fifo->buffer + (fifo->out & (fifo->size - 1)), l);
182.  
183. /* then get the rest (if any) from the beginning of the buffer */
184. memcpy(buffer + l, fifo->buffer, len - l);
185.  
186. /*
187. * Ensure that we remove the bytes from the kfifo -before-
188. * we update the fifo->out index.
189. */
190.  
191. smp_mb();
192.  
193. fifo->out += len;
194.  
195. return len;
196. }
197. EXPORT_SYMBOL(__kfifo_get);

为了更好的理解上面的源码，这里顺带说一下此实现使用到的一些和本文主题无关的技巧：

1. 使用与操作来求取环形缓冲区的下标，相比取余操作来求取下标的做法效率要高不少。使用与操作求取下标的前提是环形缓冲区的大小必须是 2 的 N 次方，换而言之就是说环形缓冲区的大小为一个仅有一个 1 的二进制数，那么 index & (size – 1) 则为求取的下标（这不难理解）
2. 使用了 in 和 out 两个索引且 in 和 out 是一直递增的（此做法比较巧妙），这样能够避免一些复杂的条件判断（某些实现下，in == out 时还无法区分缓冲区是空还是满）

这里，索引 in 和 out 被两个线程访问。in 和 out 指明了缓冲区中实际数据的边界，也就是 in 和 out 同缓冲区数据存在访问上的顺序关系，由于未使用同步机制，那么保证顺序关系就需要使用到 Memory barrier 了。索引 in 和 out 都分别只被一个线程修改，而被两个线程读取。__kfifo_put 先通过 in 和 out 来确定可以向缓冲区中写入数据量的多少，这时，out 索引应该先被读取后才能真正的将用户 buffer 中的数据写入缓冲区，因此这里使用到了 smp_mb()，对应的，__kfifo_get 也使用 smp_mb() 来确保修改 out 索引之前缓冲区中数据已经被成功读取并写入用户 buffer 中了。对于 in 索引，在 __kfifo_put 中，通过 smp_wmb() 保证先向缓冲区写入数据后才修改 in 索引，由于这里只需要保证写入操作有序，故选用写操作 barrier，在 __kfifo_get 中，通过 smp_rmb() 保证先读取了 in 索引（这时候 in 索引用于确定缓冲区中实际存在多少可读数据）才开始读取缓冲区中数据（并写入用户 buffer 中），由于这里只需要保证读取操作有序，故选用读操作 barrier。

到这里，Memory barrier 就介绍完毕了。

(1)编译器在编译程序的时候，将程序中的所有的元素分成了一些组成部分，各部分构成一个段，所以说段是可执行程序的组成部分。

(2)代码段：代码段就是程序中的可执行部分，直观理解代码段就是函数堆叠组成的。

(3)数据段（也被称为数据区、静态数据区、静态区）：数据段就是程序中的数据，直观理解就是C语言程序中的全局变量。（注意：全局变量才算是程序的数据，局部变量不算程序的数据，只能算是函数的数据）

(4)bss段（又叫ZI(zero initial)段）：bss段的特点就是被初始化为0，bss段本质上也是属于数据段，bss段就是被初始化为0的数据段。 注意区分：数据段（.data）和bss段的区别和联系：二者本来没有本质区别，都是用来存放C程序中的全局变量的。区别在于把显示初始化为非零的全局变量存在.data段中，而把显式初始化为0或者并未显式初始化（C语言规定未显式初始化的全局变量值默认为0）的全局变量存在bss段。

有些特殊数据会被放到代码段

(1)C语言中使用char *p = "linux";定义字符串时，字符串"linux"实际被分配在代码段，也就是说这个"linux"字符串实际上是一个常量字符串而不是变量字符串。

(2)const型常量：C语言中const关键字用来定义常量，常量就是不能被改变的量。

const的实现方法至少有2种：

第一种就是编译将const修饰的变量放在代码段去以实现不能修改（普遍见于各种单片机的编译器）；

第二种就是由编译器来检查以确保const型的常量不会被修改，实际上const型的常量还是和普通变量一样放在数据段的（gcc中就是这样实现的）。

显式初始化为非零的全局变量和静态局部变量放在数据段

(1)放在.data段的变量有2种：第一种是显式初始化为非零的全局变量。第二种是静态局部变量，也就是static修饰的局部变量。（普通局部变量分配在栈上，静态局部变量分配在.data段）

未初始化或显式初始化为0的全局变量放在bss段 (1)bss段和.data段并没有本质区别，几乎可以不用明确去区分这两种。


C++中虚函数表位于只读数据段（.rodata），也就是C++内存模型中的常量区；而虚函数则位于代码段（.text），也就是C++内存模型中的代码区。

# mount -t cifs //10.0.0.1/share /mnt/sharefolder -o username=sensirx,password=sensirx,vers=2.0