背景

随着 Docker 技术的发展和广泛流行，云原生应用和容器调度管理系统也成为 IT 领域大热的词汇，Kuberentes可以说是乘着Docker和微服务的东风，一经推出便迅速蹿红，所以当下很多开始进行kubernetes的学习。于是很多人将Kubernetes源码拉下来，但在本地进行make quick-release时，经常会遇到镜像拉取失败的错误

1
2
3
4

make quick-release                                
....
error: failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to do request: Head https://k8s.gcr.io/v2/build-image/kube-cross/manifests/v1.23.0-go1.17.2-bullseye.0: net/http: TLS handshake timeout
...

1
2
3
4
5
6
7

# touch /etc/systemd/system/docker.service.d/proxy.conf
# vi /etc/systemd/system/docker.service.d/proxy.conf

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080/"
Environment="HTTPS_PROXY=http://proxy.example.com:8080/"
Environment="NO_PROXY=localhost,127.0.0.1,.example.com"

1
2
3
4
5

# docker build . \
    --build-arg "HTTP_PROXY=http://proxy.example.com:8080/" \
    --build-arg "HTTPS_PROXY=http://proxy.example.com:8080/" \
    --build-arg "NO_PROXY=localhost,127.0.0.1,.example.com" \
    -t your/image:tag

它就和servicemesh一样，将springcloud那一堆微服务要做的事情，下沉到基础设施层，这样我们的程序员就可以专注到业务开发上去了

网络拓扑

笔者的开发模式是windows+linux虚拟机的方式，linux是以虚拟机的方式跑在windows上面，虚拟机通过NAT模式连接至windows。

这里windows（192.168.88.1）其实是vm的网关，vm的数据包发往windows后，再由windows转发至外网。这里有两种思路，一种是主路由代理，一种是旁臂路由代理。

​

• 主路由：改造windows，在windows实现路由代理。

  

• 旁臂路由：添加一台VM，该VM实现路由代理，我们将其称作路由VM，其它VM的网关指向该路由VM。

由于笔记的宿主机是windows，如何将windows打造成代理路由是笔者的知识盲区，所以这里我们主要介绍旁臂路由模式。

原理

首先，要解释一下目前主流的你懂的上网方式原理，首先我们要在你懂的地方搭建一个服务端（这个不是本文的教学内容），然后在我们内网搭启动相应的客户端，客户端和服务端以某种加密方式通信，伪装成普通的请求（如https），这样逃过你懂的拦截。

这里服务端可以自己搭建也可以购买，一般自己搭建大家称作自建VPS，就是自己购买海外VPS，然后在上面安装Server，别人搭好的Server一般称作机场，机场名称的由来是因为最早ShadowSocket的客户端图标是一架飞机，然后客户端要寻找服务端连接，就好像是找飞机停靠的机场一样

代理模式

代理模式就是我们的手机或pc直接连接到这个客户端：

当我们手机连接wifi的时候有一个代理选项，讲的就是这种模式：

网关模式

网关模式就是将网关指向代理路由，然后路由内部再将数据包转发至该客户端：
​

我们手机连接wifi时，可以选择手动设置IP：

网关模式也是本文要讲的方式，这里我们主要讲解在代理路由内部，我们要如何将数据包转发至该客户端,现在主流的方式还是利用linux的netfilter的能力来进行转发的，这里又分成两种模式

REDIRECT

1

# iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port 1041

该命令将所有外部进来的tcp流量都转发至本地的1041端口，这种方式要确保内核的ip_forward参数是1

1
2

# sysctl net.ipv4.ip_forward    
net.ipv4.ip_forward = 1

既然修改了数据包的目标IP地址，那么我们程序中不是就拿不到原始的目标IP了吗？linux的conntrack模块会记录链接的原始IP，并且为我们提供了一个系统调用来获取原始IP
getdestaddr(int fd, struct sockaddr_storage *destaddr)

TPROXY

对于TPROXY模式，实现的原理要相对复杂不少，需要借助iptables和路由

1
2
3

# iptables -t mangle -A PREROUTING -p tcp -j TPROXY --tproxy-mark 0x1/0x1 --on-port 8888
# ip rule add fwmark 0x1/0x1 pref 100 table 100
# ip route add local default dev lo table 100

由于tproxy并没有改变数据包，所以怎么让用户空间接收目标IP不属于本机的包呢？linux为socket提供了一个IP_TRANSPARENT选项，让进程可以bind一个不属于本机的地址，这也正是透明代理神奇的地方。

Openwrt安装（macvlan+docker）

原理搞明白之后，我们接下来进入动手阶段，openwrt是linux的一个发行版，它可以用来作为软路由的操作系统，我们只要装好它就可以得到一个网关代理。

环境准备

1. 安装docker

这里我们使用docker进行openwrt的安装，这样不影响我linux开发机的正常使用。关于docker的安装请大家自行搜索，或者参考centos7上安装docker环境

2. 拉取镜像

镜像列表可以查看这里
笔者是x86_64机器，运行以下命令拉取镜像

1

# docker pull registry.cn-shanghai.aliyuncs.com/suling/openwrt:x86_64

网络设置

1. 打开网卡的混杂模式

1

# ip link set eth0 promisc on

这里eth0是笔者linux虚拟机的网卡名称，你必须改成你机器的实际网卡名称

这里开混杂模式是因为虚拟机的eth0网卡必须接收不同ip的数据包

2. 创建macvlan网络

这里我们要为docker先创建一个macvlan类型的网络

1
2
3
4
5
6
7
8

# docker network create -d macvlan --subnet=192.168.88.0/24 --gateway=192.168.88.1 -o parent=eth0 macvlan0
# docker network ls
NETWORK ID     NAME       DRIVER    SCOPE
3f480a69e394   bridge     bridge    local
cc721823c8ca   host       host      local
8ec9c9727726   kind       bridge    local
1b330a41a687   macvlan0   macvlan   local
a8f4badfc912   none       null      local

• -d 指定网络类型为macvlan
• –subnet 指定该网络的cidr，它必须和linux开发机同处于一个网段
• –gateway 指定网关，同linux开发机同一个网关即可
• -o parent 指定要从哪个网卡创建macvlan
• macvlan0是网络名称，这个后面创建容器的时候使用

最后docker network ls检查网络是否创建成功

安装配置

1. 创建容器

1

# docker run --restart always --name openwrt -d --network macvlan0 --ip 192.168.88.254 --privileged registry.cn-shanghai.aliyuncs.com/suling/openwrt:x86_64 /sbin/init

其中–ip指定容器的ip地址，这里选择254相对靠后的ip，不容易和其它VM冲突。

2. 配置容器网络

先进入容器

1

# docker exec -it openwrt bash

1
2
3
4
5
6
7
8
9
10
11
12

# vi /etc/config/network
...
config interface 'lan'
        option type 'bridge'
        option ifname 'eth0'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.88.254'
        option gateway '192.168.88.2'
        option dns '192.168.88.2'
...

• ipaddr: 必须和上一步–ip参数一致
• gateway: 必须和虚拟机的网关一致
• dns: 最好和虚拟机的一致

编辑完成后，保存并重启network服务

1

# /etc/init.d/network restart

1

# ip link set br-lan promisc on

3. 配置虚拟机

macvlan为了安全起见，默认情况下各个子网口和宿主机是不通的，为了让宿主机能访问容器，这里我们要给宿主机单独创建一个子网口，并配置相应的路由

1

# ip link add link eth0 dev macv1 type macvlan mode bridge

1

# ip route add 192.168.88.254/32 dev macv1

1
2
3
4
5

ping 192.168.88.254                                     
PING 192.168.88.254 (192.168.88.254) 56(84) bytes of data.
64 bytes from 192.168.88.254: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from 192.168.88.254: icmp_seq=2 ttl=64 time=0.060 ms
...

4. 配置openwrt

1. 添加节点

这里通过浏览器打开http://192.168.88.254 这里你可以替换成你自己的容器ip，默认的用户名和密码：root/password
登录完成后，首先要添加节点

这里上文提到的自建vps或者购买的机场，你一般都会有一串字符串，将它贴到这个地方，点击添加。
完成后可以在节点列表里面看到

2. 基本设置

点击基本设置，打开主开关，TCP节点选择上一步添加的节点，UDP节点选择和TCP节点相同即可，然后点击“保存&应用”按钮。

3. 设置DNS

切换至DNS项，关闭缓存解析结果和ChinaDNS-NG，最后点击清空IPSET，最后记得保存变更。

4. 检测

最后，如果你的梯子线路正常，那么就可以通过检测

配置网关代理

最后一步，我们可以将虚拟机的默认网关指向该容器

1
2

# ip route del default
# ip route add default via 192.168.88.254 dev macv1

结束语

最后，大家可能觉得这样的配置过于复杂，其实你完成可以将上述步骤固化成脚本，将openwrt配置好后导出镜像，然后在开机的时候自动执行这些脚本就可以了,例如这样的脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

 1 #!/bin/bash
 2 
 3 # start openwrt
 4 docker rm -f openwrt
 5 docker run --restart no --name openwrt -d --network macvlan0 --ip 192.168.88.254 --privileged openwrt:hkv2r
   ay /sbin/init
 6 
 7 # set route to openwrt
 8 ip link add link eth0 dev macv1 type macvlan mode bridge
 9 ip link set macv1 up
10 ip route add 192.168.88.254/32 dev macv1
11 ip route del default
12 ip route add default via 192.168.88.254 dev macv1
13 
14 # set interface promisc
15 ip link set eth0 promisc on
16 sleep 30
17 docker exec openwrt ip link set br-lan promisc on

参考文章：

https://gsoc-blog.ecklm.com/iptables-redirect-vs.-dnat-vs.-tproxy/
https://www.cfmem.com/2021/08/docker-openwrt.html
https://www.ichenfu.com/2019/04/09/istio-inbond-interception-and-linux-transparent-proxy/

首先准备以下go程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package main

import (
    "math/rand"
    "time"
    "fmt"
)

func add(a, b int32)int32{
    return a + b
}

func main() {
    for{
        a := rand.Int31n(100)
        b := rand.Int31n(100)
        r := add(a, b)
        fmt.Printf("%d + %d = %d\n", a, b, r)
        time.Sleep(time.Second)
    }
}

1

$ go build -gcflags='-N -l' main.go && ./main

开启另一个shell，我们要来获取add函数在代码段中的地址：

1
2
3
4

$ objdump --syms main | grep add
...
0000000000480220 g     F .text  0000000000000034 main.add
...

1
2

$ cat /proc/`pgrep main`/maps | grep /root/study/main | grep r-xp
00400000-00481000 r-xp 00000000 fd:00 102732081                          /root/study/main

我们如何写入uprobe调式信息呢，uprobe的事件格式如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

p[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a uprobe
r[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a return uprobe (uretprobe)
-:[GRP/]EVENT                           : Clear uprobe or uretprobe event

GRP           : Group name. If omitted, "uprobes" is the default value.
EVENT         : Event name. If omitted, the event name is generated based
                on PATH+OFFSET.
PATH          : Path to an executable or a library.
OFFSET        : Offset where the probe is inserted.

FETCHARGS     : Arguments. Each probe can have up to 128 args.
 %REG         : Fetch register REG
 @ADDR        : Fetch memory at ADDR (ADDR should be in userspace)
 @+OFFSET     : Fetch memory at OFFSET (OFFSET from same file as PATH)
 $stackN      : Fetch Nth entry of stack (N >= 0)
 $stack       : Fetch stack address.
 $retval      : Fetch return value.(*)
 +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)
 NAME=FETCHARG     : Set NAME as the argument name of FETCHARG.
 FETCHARG:TYPE     : Set TYPE as the type of FETCHARG. Currently, basic types
                     (u8/u16/u32/u64/s8/s16/s32/s64), "string" and bitfield
                     are supported.

1
2

$ echo 'p:entry_add /root/study/main:0x80220 %ax:u32 %bx:u32' > /sys/kernel/debug/tracing/uprobe_events
$ echo 'r:exit_add /root/study/main:0x80220 %ax:u32' >> /sys/kernel/debug/tracing/uprobe_events

1

$ echo > /sys/kernel/debug/tracing/trace

1

$ echo 1 >  /sys/kernel/debug/tracing/events/uprobes/enable

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

$ cat /sys/kernel/debug/tracing/trace    
# tracer: nop
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
            main-25197 [001] d... 853041.215718: entry_add: (0x480220) arg1=81 arg2=87
                  |                                  |           |         |      |
                进程ID                             事件名    函数入口地址  参数a  参数b  
            main-25197 [001] d... 853041.215746: exit_add: (0x4802b6 <- 0x480220)    arg1=168
                  |                                  |         |           |             |
                进程ID                             事件名    函数入口地址  函数返回地址  函数返回值                                              
            main-25197 [001] d... 853042.216402: entry_add: (0x480220) arg1=47 arg2=59
            main-25197 [001] d... 853042.216415: exit_add: (0x4802b6 <- 0x480220) arg1=106
            main-25197 [000] d... 853043.219246: entry_add: (0x480220) arg1=81 arg2=18
            main-25197 [000] d... 853043.219254: exit_add: (0x4802b6 <- 0x480220) arg1=99
            main-25197 [000] d... 853044.221530: entry_add: (0x480220) arg1=25 arg2=40
            main-25197 [000] d... 853044.221539: exit_add: (0x4802b6 <- 0x480220) arg1=65
            main-25197 [000] d... 853045.221832: entry_add: (0x480220) arg1=56 arg2=0
            main-25197 [000] d... 853045.221842: exit_add: (0x4802b6 <- 0x480220) arg1=56
            main-25197 [000] d... 853050.230817: entry_add: (0x480220) arg1=37 arg2=6
            main-25197 [000] d... 853050.230827: exit_add: (0x4802b6 <- 0x480220) arg1=43
            main-25197 [000] d... 853052.234467: entry_add: (0x480220) arg1=28 arg2=58
            main-25197 [000] d... 853052.234476: exit_add: (0x4802b6 <- 0x480220) arg1=86
            main-25197 [000] d... 853053.234655: entry_add: (0x480220) arg1=47 arg2=47
            main-25197 [000] d... 853053.234664: exit_add: (0x4802b6 <- 0x480220) arg1=94
            main-25197 [000] d... 853054.237878: entry_add: (0x480220) arg1=87 arg2=88
            main-25197 [000] d... 853054.237887: exit_add: (0x4802b6 <- 0x480220) arg1=175

1
2
3
4
5
6
7
8
9
10
11
12
13
14

81 + 87 = 168
47 + 59 = 106
81 + 18 = 99
25 + 40 = 65
56 + 0 = 56
94 + 11 = 105
62 + 89 = 151
28 + 74 = 102
11 + 45 = 56
37 + 6 = 43
95 + 66 = 161
28 + 58 = 86
47 + 47 = 94
87 + 88 = 175

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

gdb -p `pgrep main`
(gdb) info line main.add
....
(gdb) disas main.add
...
Dump of assembler code for function main.add:
   0x0000000000480220 <+0>:     int3   
   0x0000000000480221 <+1>:     sub    $0x10,%esp
   0x0000000000480224 <+4>:     mov    %rbp,0x8(%rsp)
   0x0000000000480229 <+9>:     lea    0x8(%rsp),%rbp
   0x000000000048022e <+14>:    mov    %eax,0x18(%rsp)
   0x0000000000480232 <+18>:    mov    %ebx,0x1c(%rsp)
   0x0000000000480236 <+22>:    movl   $0x0,0x4(%rsp)
   0x000000000048023e <+30>:    mov    0x18(%rsp),%eax
   0x0000000000480242 <+34>:    add    0x1c(%rsp),%eax
   0x0000000000480246 <+38>:    mov    %eax,0x4(%rsp)
   0x000000000048024a <+42>:    mov    0x8(%rsp),%rbp
   0x000000000048024f <+47>:    add    $0x10,%rsp
   0x0000000000480253 <+51>:    ret    
End of assembler dump.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

(gdb) disas main.main
Dump of assembler code for function main.main:
   .....
   0x000000000048028f <+47>:    call   0x460860 <math/rand.Int31n>
   0x0000000000480294 <+52>:    mov    %eax,0x34(%rsp)
   0x0000000000480298 <+56>:    mov    $0x64,%eax
   0x000000000048029d <+61>:    nopl   (%rax)
   0x00000000004802a0 <+64>:    call   0x460860 <math/rand.Int31n>
   0x00000000004802a5 <+69>:    mov    %eax,0x30(%rsp)
   0x00000000004802a9 <+73>:    mov    0x34(%rsp),%ecx
   0x00000000004802ad <+77>:    mov    %eax,%ebx
   0x00000000004802af <+79>:    mov    %ecx,%eax
   0x00000000004802b1 <+81>:    call   0x480220 <main.add>
   0x00000000004802b6 <+86>:    mov    %eax,0x2c(%rsp)
   ....
End of assembler dump.

1

$ echo 0 >  /sys/kernel/debug/tracing/events/uprobes/enable

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

(gdb) disas main.add
Dump of assembler code for function main.add:
   0x0000000000480220 <+0>:     sub    $0x10,%rsp
   0x0000000000480224 <+4>:     mov    %rbp,0x8(%rsp)
   0x0000000000480229 <+9>:     lea    0x8(%rsp),%rbp
   0x000000000048022e <+14>:    mov    %eax,0x18(%rsp)
   0x0000000000480232 <+18>:    mov    %ebx,0x1c(%rsp)
   0x0000000000480236 <+22>:    movl   $0x0,0x4(%rsp)
   0x000000000048023e <+30>:    mov    0x18(%rsp),%eax
   0x0000000000480242 <+34>:    add    0x1c(%rsp),%eax
   0x0000000000480246 <+38>:    mov    %eax,0x4(%rsp)
   0x000000000048024a <+42>:    mov    0x8(%rsp),%rbp
   0x000000000048024f <+47>:    add    $0x10,%rsp
   0x0000000000480253 <+51>:    ret    
End of assembler dump.

引子

在Go 1.13的时候，每当遇到defer语句，运行时就会生成一个_defer结构体对象（结构体保存着延迟函数的地址，参数及参数大小等信息），并将其插入 一个 defer链表的头部（该链表位于当前g上），如下图所示：

_defer结构体的完整定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// A _defer holds an entry on the list of deferred calls.
// If you add a field here, add code to clear it in freedefer and deferProcStack
// This struct must match the code in cmd/compile/internal/reflectdata/reflect.go:deferstruct
// and cmd/compile/internal/gc/ssa.go:(*state).call.
// Some defers will be allocated on the stack and some on the heap.
// All defers are logically part of the stack, so write barriers to
// initialize them are not required. All defers must be manually scanned,
// and for heap defers, marked.
type _defer struct {
	siz     int32 // includes both arguments and results
	started bool
	heap    bool
	// openDefer indicates that this _defer is for a frame with open-coded
	// defers. We have only one defer record for the entire frame (which may
	// currently have 0, 1, or more defers active).
	openDefer bool
	sp        uintptr  // sp at time of defer
	pc        uintptr  // pc at time of defer
	fn        *funcval // can be nil for open-coded defers
	_panic    *_panic  // panic that is running defer
	link      *_defer

	// If openDefer is true, the fields below record values about the stack
	// frame and associated function that has the open-coded defer(s). sp
	// above will be the sp for the frame, and pc will be address of the
	// deferreturn call in the function.
	fd   unsafe.Pointer // funcdata for the function associated with the frame
	varp uintptr        // value of varp for the stack frame
	// framepc is the current pc associated with the stack frame. Together,
	// with sp above (which is the sp associated with the stack frame),
	// framepc/sp can be used as pc/sp pair to continue a stack trace via
	// gentraceback().
	framepc uintptr
}

opencoded优化方案

根据 defer 开放代码优化提案 这描述的，我们这里主要看下编译器是如何优化defer性能的。

• 如果一个defer语句处于循环中的话，则无法进行优化。
• 如果defer语句处于条件判断中（如果在编译阶段能计算出条件值的话，则if语句会被直接优化掉）的话，则需要一个defer bit来对其进行标识

条件标志位的逻辑如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

defer f1(a)
if cond {
 defer f2(b)
}
body...
==========================================================================================================
deferBits |= 1<<0
tmpF1 = f1
tmpA = a
if cond {
 deferBits |= 1<<1
 tmpF2 = f2
 tmpB = b
}
body...
exit:
if deferBits & 1<<1 != 0 {
 deferBits &^= 1<<1
 tmpF2(tmpB)
}
if deferBits & 1<<0 != 0 {
 deferBits &^= 1<<0
 tmpF1(tmpA)
}

验证

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package main

import "math/rand"

func main() {
    if 500 > rand.Int(){
        defer named()
    }
    if 600 > rand.Int(){
        defer named()
    }
    if 700 > rand.Int(){
        defer named()
    }
}

func named()(result int){
  result = 1
  return
}

准备实验代码，将三个延迟函数放入三个条件语句中。
首先看一下不优化是什么情况
go build -gcflags=”-N -l” main.go，-N表示禁止优化 -l表示禁止内联，然后通过gdb查看汇编代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

Dump of assembler code for function main.main:
   0x00000000004633e0 <+0>:     lea    -0x88(%rsp),%r12
   0x00000000004633e8 <+8>:     cmp    0x10(%r14),%r12
   0x00000000004633ec <+12>:    jbe    0x46351f <main.main+319>
   0x00000000004633f2 <+18>:    sub    $0x108,%rsp
   0x00000000004633f9 <+25>:    mov    %rbp,0x100(%rsp)
   0x0000000000463401 <+33>:    lea    0x100(%rsp),%rbp
   0x0000000000463409 <+41>:    call   0x462e60 <math/rand.Int>
   0x000000000046340e <+46>:    mov    %rax,0x8(%rsp)
   0x0000000000463413 <+51>:    cmp    $0x1f4,%rax
   0x0000000000463419 <+57>:    jl     0x46341d <main.main+61>
   0x000000000046341b <+59>:    jmp    0x463463 <main.main+131>
   0x000000000046341d <+61>:    movl   $0x0,0xb0(%rsp)
   0x0000000000463428 <+72>:    lea    0x19c39(%rip),%rcx        # 0x47d068
   0x000000000046342f <+79>:    mov    %rcx,0xc8(%rsp)
   0x0000000000463437 <+87>:    lea    0xb0(%rsp),%rax
   0x000000000046343f <+95>:    nop
   0x0000000000463440 <+96>:    call   0x42b380 <runtime.deferprocStack>
   0x0000000000463445 <+101>:   test   %eax,%eax
   0x0000000000463447 <+103>:   jne    0x46344d <main.main+109>
   0x0000000000463449 <+105>:   jmp    0x46344b <main.main+107>
   0x000000000046344b <+107>:   jmp    0x463465 <main.main+133>
   0x000000000046344d <+109>:   nop
   0x000000000046344e <+110>:   call   0x42bfe0 <runtime.deferreturn>
   0x0000000000463453 <+115>:   mov    0x100(%rsp),%rbp
   0x000000000046345b <+123>:   add    $0x108,%rsp
   0x0000000000463462 <+130>:   ret    
   0x0000000000463463 <+131>:   jmp    0x463465 <main.main+133>
   0x0000000000463465 <+133>:   call   0x462e60 <math/rand.Int>
   0x000000000046346a <+138>:   mov    %rax,0x8(%rsp)
   0x000000000046346f <+143>:   cmp    $0x258,%rax
   0x0000000000463475 <+149>:   jl     0x463479 <main.main+153>
   0x0000000000463477 <+151>:   jmp    0x4634b5 <main.main+213>
   0x0000000000463479 <+153>:   movl   $0x0,0x60(%rsp)
   0x0000000000463481 <+161>:   lea    0x19be8(%rip),%rcx        # 0x47d070
   0x0000000000463488 <+168>:   mov    %rcx,0x78(%rsp)
   0x000000000046348d <+173>:   lea    0x60(%rsp),%rax
   0x0000000000463492 <+178>:   call   0x42b380 <runtime.deferprocStack>
   0x0000000000463497 <+183>:   test   %eax,%eax
   0x0000000000463499 <+185>:   jne    0x46349f <main.main+191>
   0x000000000046349b <+187>:   jmp    0x46349d <main.main+189>
   0x000000000046349d <+189>:   jmp    0x4634b7 <main.main+215>
   0x000000000046349f <+191>:   nop
   0x00000000004634a0 <+192>:   call   0x42bfe0 <runtime.deferreturn>
   0x00000000004634a5 <+197>:   mov    0x100(%rsp),%rbp
   0x00000000004634ad <+205>:   add    $0x108,%rsp
   0x00000000004634b4 <+212>:   ret    
   0x00000000004634b5 <+213>:   jmp    0x4634b7 <main.main+215>
   0x00000000004634b7 <+215>:   call   0x462e60 <math/rand.Int>
   0x00000000004634bc <+220>:   mov    %rax,0x8(%rsp)
   0x00000000004634c1 <+225>:   cmp    $0x2bc,%rax
   0x00000000004634c7 <+231>:   jl     0x4634cb <main.main+235>
   0x00000000004634c9 <+233>:   jmp    0x463507 <main.main+295>
   0x00000000004634cb <+235>:   movl   $0x0,0x10(%rsp)
   0x00000000004634d3 <+243>:   lea    0x19b9e(%rip),%rcx        # 0x47d078
   0x00000000004634da <+250>:   mov    %rcx,0x28(%rsp)
   0x00000000004634df <+255>:   lea    0x10(%rsp),%rax
   0x00000000004634e4 <+260>:   call   0x42b380 <runtime.deferprocStack>
   0x00000000004634e9 <+265>:   test   %eax,%eax
   0x00000000004634eb <+267>:   jne    0x4634f1 <main.main+273>
   0x00000000004634ed <+269>:   jmp    0x4634ef <main.main+271>
   0x00000000004634ef <+271>:   jmp    0x463509 <main.main+297>
   0x00000000004634f1 <+273>:   nop
   0x00000000004634f2 <+274>:   call   0x42bfe0 <runtime.deferreturn>
   0x00000000004634f7 <+279>:   mov    0x100(%rsp),%rbp
   0x00000000004634ff <+287>:   add    $0x108,%rsp
   0x0000000000463506 <+294>:   ret    
   0x0000000000463507 <+295>:   jmp    0x463509 <main.main+297>
   0x0000000000463509 <+297>:   nop
   0x000000000046350a <+298>:   call   0x42bfe0 <runtime.deferreturn>
   0x000000000046350f <+303>:   mov    0x100(%rsp),%rbp
   0x0000000000463517 <+311>:   add    $0x108,%rsp
   0x000000000046351e <+318>:   ret    
   0x000000000046351f <+319>:   nop
   0x0000000000463520 <+320>:   call   0x4554c0 <runtime.morestack_noctxt>
   0x0000000000463525 <+325>:   jmp    0x4633e0 <main.main>
End of assembler dump.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130

Dump of assembler code for function main.main:
   # 栈检查，不够则跳转至动态扩容处
   ==============================================================================================
   0x0000000000463300 <+0>:     cmp    0x10(%r14),%rsp
   0x0000000000463304 <+4>:     jbe    0x46340f <main.main+271>
   
   # main函数栈帧40字节
   ==============================================================================================
   0x000000000046330a <+10>:    sub    $0x30,%rsp                # 栈顶调整
   0x000000000046330e <+14>:    mov    %rbp,0x28(%rsp)           # 保存栈底旧值
   0x0000000000463313 <+19>:    lea    0x28(%rsp),%rbp           # 栈底调整
   
   ==============================================================================================
   0x0000000000463318 <+24>:    movups %xmm15,0x10(%rsp)
   0x000000000046331e <+30>:    movups %xmm15,0x18(%rsp)
   
   ==============================================================================================
   0x0000000000463324 <+36>:    movb   $0x0,0x7(%rsp)            # 0x7（第8个字节）处，置0，该字节为 defer bit
   
   # 第一个if， if 500 > rand.Int(), 如果随机数大于等于500，则直接跳转至76行
   ==============================================================================================
   0x0000000000463329 <+41>:    call   0x462d80 <math/rand.Int>
   0x000000000046332e <+46>:    mov    %rax,0x8(%rsp)
   0x0000000000463333 <+51>:    cmp    $0x1f4,%rax
   0x0000000000463339 <+57>:    jge    0x46334c <main.main+76>
   
   ==============================================================================================
   0x000000000046333b <+59>:    lea    0x19d16(%rip),%rcx        # 0x47d058
   0x0000000000463342 <+66>:    mov    %rcx,0x20(%rsp)
   
   # 将defer bit 第一位置1
   ==============================================================================================
   0x0000000000463347 <+71>:    movb   $0x1,0x7(%rsp)            # 0x7处的值为  00000001
   
   第二个if, if 600 > rand.Int()
   ==============================================================================================
   0x000000000046334c <+76>:    call   0x462d80 <math/rand.Int>
   0x0000000000463351 <+81>:    mov    0x8(%rsp),%rcx            # 注意0x8留存的是第一个rand的结果（46行）
   0x0000000000463356 <+86>:    cmp    $0x1f4,%rcx               # 这里又进行一次和（500）的比较，是不是还有优化的空间？
   0x000000000046335d <+93>:    setl   %cl                       # 如果rcx小于500，则cl置为1
   0x0000000000463360 <+96>:    cmp    $0x258,%rax               # 第二个rand的值和600比较
   0x0000000000463366 <+102>:   jge    0x46337b <main.main+123>  # 如果大于等于600则直接跳至123行
   
   ==============================================================================================
   0x0000000000463368 <+104>:   lea    0x19cf1(%rip),%rax        # 0x47d060
   0x000000000046336f <+111>:   mov    %rax,0x18(%rsp)
   
   # 将第二个bit位置1
   ==============================================================================================
   0x0000000000463374 <+116>:   or     $0x2,%ecx                 # exc = 00000010 | ecx
   0x0000000000463377 <+119>:   mov    %cl,0x7(%rsp)             # 0x7 存储defer bit
   0x000000000046337b <+123>:   mov    %cl,0x6(%rsp)             # 0x6 存储defer bit
   
   # 第三个if,  if 700 > rand.Int()
   ==============================================================================================
   0x000000000046337f <+127>:   nop
   0x0000000000463380 <+128>:   call   0x462d80 <math/rand.Int>
   0x0000000000463385 <+133>:   cmp    $0x2bc,%rax
   0x000000000046338b <+139>:   jge    0x4633a7 <main.main+167>
   
   ==============================================================================================
   0x000000000046338d <+141>:   lea    0x19cd4(%rip),%rax        # 0x47d068
   0x0000000000463394 <+148>:   mov    %rax,0x10(%rsp)
   
   # 将第三个bit位置1
   ==============================================================================================
   0x0000000000463399 <+153>:   movzbl 0x6(%rsp),%ecx            # 移动8(b)位至32(l)位，高24位用0(z:zero)补齐
   0x000000000046339e <+158>:   or     $0x4,%ecx                 # ecx = 00000100 | ecx
   0x00000000004633a1 <+161>:   mov    %cl,0x7(%rsp)             # 此时 0x7保存着defer bit标识着三个if都进行了处理了
   0x00000000004633a5 <+165>:   jmp    0x4633ac <main.main+172>
   ==============================================================================================
   0x00000000004633a7 <+167>:   movzbl 0x6(%rsp),%ecx            # 移动8(b)位至32(l)位，高24位用0(z:zero)补齐
   
   # 如果第3个bit为0，则跳过dwrap·3的调用
   ==============================================================================================
   0x00000000004633ac <+172>:   test   $0x4,%cl                  
   0x00000000004633af <+175>:   je     0x4633ca <main.main+202>  
   
   # 调用main.main·dwrap·3
   ==============================================================================================
   0x00000000004633b1 <+177>:   and    $0xfffffffb,%ecx          # ecx = 1011 & ecx  执行之前先将第3位置0
   0x00000000004633b4 <+180>:   mov    %cl,0x6(%rsp)             # 0x6 保存 defer bit
   0x00000000004633b8 <+184>:   mov    %cl,0x7(%rsp)             # 0x7 保存 defer bit  
   0x00000000004633bc <+188>:   nopl   0x0(%rax)        
   0x00000000004633c0 <+192>:   call   0x463500 <main.main·dwrap·3>
   0x00000000004633c5 <+197>:   movzbl 0x6(%rsp),%ecx
   
   # 如果第2个bit为0，则跳过dwrap·2的调用
   ==============================================================================================
   0x00000000004633ca <+202>:   test   $0x2,%cl
   0x00000000004633cd <+205>:   je     0x4633e4 <main.main+228>
   
   # 调用main.main·dwrap·2
   ==============================================================================================
   0x00000000004633cf <+207>:   and    $0xfffffffd,%ecx          # ecx = 1101 & ecx  执行之前先将第2位置0
   0x00000000004633d2 <+210>:   mov    %cl,0x6(%rsp)             # 0x6 保存 defer bit 
   0x00000000004633d6 <+214>:   mov    %cl,0x7(%rsp)             # 0x7 保存 defer bit
   0x00000000004633da <+218>:   call   0x4634a0 <main.main·dwrap·2>
   0x00000000004633df <+223>:   movzbl 0x6(%rsp),%ecx
   
   # 如果第1个bit为0，则跳过dwrap·1的调用
   ==============================================================================================
   0x00000000004633e4 <+228>:   test   $0x1,%cl
   0x00000000004633e7 <+231>:   je     0x4633f5 <main.main+245>
   
   # 调用main.main·dwrap·1
   ==============================================================================================
   0x00000000004633e9 <+233>:   and    $0xfffffffe,%ecx           # ecx = 1110 & ecx  执行之前先将第1位置0
   0x00000000004633ec <+236>:   mov    %cl,0x7(%rsp)              # 0x7 保存 defer bit
   0x00000000004633f0 <+240>:   call   0x463440 <main.main·dwrap·1>
   
   # main函数返回
   ==============================================================================================
   0x00000000004633f5 <+245>:   mov    0x28(%rsp),%rbp            # 栈底调整     
   0x00000000004633fa <+250>:   add    $0x30,%rsp                 # 栈顶调整
   0x00000000004633fe <+254>:   ret    
   
   ==============================================================================================
   0x00000000004633ff <+255>:   nop
   0x0000000000463400 <+256>:   call   0x42bf20 <runtime.deferreturn>
   
   ==============================================================================================
   0x0000000000463405 <+261>:   mov    0x28(%rsp),%rbp
   0x000000000046340a <+266>:   add    $0x30,%rsp
   0x000000000046340e <+270>:   ret
   
   ==============================================================================================
   0x000000000046340f <+271>:   call   0x455400 <runtime.morestack_noctxt>
   0x0000000000463414 <+276>:   jmp    0x463300 <main.main>
End of assembler dump.

1
2

0x0000000000463360 <+96>:    cmp    $0x258,%rax               # 第二个rand的值和600比较
0x0000000000463366 <+102>:   jge    0x46337b <main.main+123>  # 如果大于等于600则直接跳至123行

1
2
3

0x0000000000463374 <+116>:   or     $0x2,%ecx                 # exc = 00000010 | ecx
0x0000000000463377 <+119>:   mov    %cl,0x7(%rsp)             # 0x7 存储defer bit
0x000000000046337b <+123>:   mov    %cl,0x6(%rsp)             # 0x6 存储defer bit

疑问：为啥这里还要有一个0x6来保存一下defer bit？

而接下来，在函数ret前，被插入的代码则是以倒序的方式检测每个标志位 0x4->0x2->0x1, 看下0x2标志位是如何检测的：

1
2

0x00000000004633ca <+202>:   test   $0x2,%cl
0x00000000004633cd <+205>:   je     0x4633e4 <main.main+228>

1
2
3
4
5

0x00000000004633cf <+207>:   and    $0xfffffffd,%ecx          # ecx = 1101 & ecx  执行之前先将第2位置0
0x00000000004633d2 <+210>:   mov    %cl,0x6(%rsp)             # 0x6 保存 defer bit 
0x00000000004633d6 <+214>:   mov    %cl,0x7(%rsp)             # 0x7 保存 defer bit
0x00000000004633da <+218>:   call   0x4634a0 <main.main·dwrap·2>
0x00000000004633df <+223>:   movzbl 0x6(%rsp),%ecx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

Dump of assembler code for function main.main·dwrap·2:
   # 栈检查，不够则跳转至动态扩容处
   ==============================================================================================
   0x0000000000463440 <+0>:     cmp    0x10(%r14),%rsp
   0x0000000000463444 <+4>:     jbe    0x46346e <main.main·dwrap·2+46>
   
   # main.main·dwrap·2 栈帧 0字节
   ==============================================================================================
   0x0000000000463446 <+6>:     sub    $0x8,%rsp                   # 调整栈顶
   0x000000000046344a <+10>:    mov    %rbp,(%rsp)                 # 保留栈底旧值 
   0x000000000046344e <+14>:    lea    (%rsp),%rbp                 # 栈底调整  
   
   ==============================================================================================
   0x0000000000463452 <+18>:    mov    0x20(%r14),%r12
   0x0000000000463456 <+22>:    test   %r12,%r12                         
   0x0000000000463459 <+25>:    jne    0x463475 <main.main·dwrap·2+53>  # r12 > 0
   
   ==============================================================================================
   0x000000000046345b <+27>:    nopl   0x0(%rax,%rax,1)
   0x0000000000463460 <+32>:    call   0x463420 <main.named>
   
   # 回收  main.main·dwrap·2 栈帧
   ==============================================================================================
   0x0000000000463465 <+37>:    mov    (%rsp),%rbp
   0x0000000000463469 <+41>:    add    $0x8,%rsp
   0x000000000046346d <+45>:    ret    
   
   ==============================================================================================
   0x000000000046346e <+46>:    call   0x455400 <runtime.morestack_noctxt>
   0x0000000000463473 <+51>:    jmp    0x463440 <main.main·dwrap·2>
   
   ==============================================================================================
   0x0000000000463475 <+53>:    lea    0x10(%rsp),%r13
   0x000000000046347a <+58>:    nopw   0x0(%rax,%rax,1)
   0x0000000000463480 <+64>:    cmp    %r13,(%r12)    
   0x0000000000463484 <+68>:    jne    0x46345b <main.main·dwrap·2+27>
   0x0000000000463486 <+70>:    mov    %rsp,(%r12)
   0x000000000046348a <+74>:    jmp    0x46345b <main.main·dwrap·2+27>
End of assembler dump.

• 25 -> 53 -> 68 -> 27 -> 32(main.named)
• 25 -> 53 -> 74 -> 27 -> 32(main.named)
• 25 -> 27 -> 32(main.named)

最后展开main.named，看到确实是 return 1(通过eax寄存器返回)

1
2
3
4

Dump of assembler code for function main.named:
   0x0000000000463420 <+0>:     mov    $0x1,%eax
   0x0000000000463425 <+5>:     ret    
End of assembler dump.

总结

标志位的变化

最后我们来看一下defer bit标志位数据变化的情况，我们假设三个if条件全部成立：
0000 -> rand.Int() -> 0001 -> rand.Int() -> 0011 -> rand.Int() -> 0111 -> named() -> 0011 -> named() -> 0001 -> named() -> 0000

免去defer链表递归调用

从实验代码可以看出，优化后的代码并没有出现runtime.deferproc或runtime.deferprocStack调用，最后函数返回时，也跳过了runtime.deferreturn的调用，我们知道一旦进入defer链表的递归调用（runtime.jmpdefer 尾递归）后，因为维护延迟函数的上下文环境需要花费非常多的指令，（defer结构体的创建和销毁等操作）这也是早期Go版本的defer特性被人诟病性能低下的重要原因。
​

经过开放代码优化后，我们可以看到这和直接调用函数的性能相差无几（多了标志位的维护），当然这里我们还可以看到deferbit只有一个字节也就是8位，因此我们最多支持8个defer语句，超过8将会回到defer链表模式（循环中的defer无法优化）。


（实验环境go1.17.2 linux/amd64）

Go的诞生

go语言自诞生（2007年设计、2009年发布Go1）以来，凭借其高并发的特性开始逐渐进入大家的视野，接着在云原生领域大行其道，其中最著名的代表作便是大名鼎鼎的k8s和docker。伴随着其在开源社区的巨大成功，Go成为了时下编程界最耀眼的明星。当然Go的成功绝非偶然，曾经听过这么一个笑话，Go是在C++的编译过程中诞生的，其意思是吐槽C++繁琐而漫长的编译过程。Overall Simplicity 全面的简单。这是Go自诞生以来一贯秉承的价值观。Go语言价值观形成是与Go的初期设计者不无关系的，可以说Go最初设计者主导了Go语言价值观的形成！这就好比一个企业的最初创始人缔造企业价值观和文化一样

图中是Go的三位最初设计者，从左到右分别是罗伯特·格瑞史莫、罗伯·派克和肯·汤普逊。Go初期的所有features adoption是需要三巨头达成一致才行。三位设计者有一个共同特征，那就是深受Unix文化熏陶。罗伯特·格瑞史莫参与设计了Java的HotSpot虚拟机和Chrome浏览器的JavaScript V8引擎，罗博·派克在大名鼎鼎的bell lab侵淫多年，参与了Plan9操作系统、C编译器以及多种语言编译器的设计和实现，肯·汤普逊更是图灵奖得主、Unix之父。关于Unix设计哲学阐述最好的一本书莫过于埃瑞克.理曼德(Eric S. Raymond)的《UNIX编程艺术》了，该书中列举了很多unix的哲学条目，比如：简单、模块化、正交、组合、pipe、功能短小且聚焦等。三位设计者将Unix设计哲学应用到了Go语言的设计当中，因此你或多或少都能在Go的设计和应用中找到这些哲学的影子。

进程

我们都知道计算机CPU的处理速度远高于其它的IO设备（磁盘，网卡等），假设我们一台计算机上面只有一个程序在执行，如果这个程序是计算密集型的程序（假设一个算法要执行一个月后才能得出结果），那么这台计算机没有操作系统也能很好地利用CPU资源，但现实是这种类型的应用很少，大部分的应用只需要少量的计算资源和大量的IO操作，那么这种情况下我们再让计算机只跑一个程序，就会造成计算资源的严重浪费。为了解决这种浪费，人们就引入进程，为了管理进程，人们又设计了操作系统。

要认识进程我们要先从大家写的程序开始，我们编写代码，然后进行编译链接打包，成为一个程序，程序是存在计算机的磁盘中的一个文件而已。当程序被执行起来，它就会从磁盘上被加载进内存中，计算机为了运行这段程序，就会在CPU设置各种寄存器的值，申请堆栈等，像这样一个程序运行起来后执行环境的总和，就是一个进程。为了提高CPU的利用率，我们会启动很多的进程，操作系统就是用来管理这些进程的。前面说到很多进程都要等待IO设备，那么这样的进程就会被操作系统挂起，进程从运行状态到被挂起，然后换成另一个进程获得CPU的执行权，这样的一个过程就叫作进程的上下文切换，这里的进程上下文实际上就是指运行进程所需的CPU寄存器状态和内存状态。进行上下文切换本身也是要消耗一定的CPU资源的。

用户空间和内核空间

一般来说，操作系统的内存会被划分为两块：内核空间和用户空间。为了安全，它们是隔离的，即使用户的程序崩溃了，内核也不受影响。当进程运行在内核空间时就处于内核态，当进程运行在用户空间时就处于用户态。

进程用户态和内核态的切换也是要消耗一定资源的，但相对进程上下文切换来说，这部分资源的消耗要小得多。进程一般通过系统调用，或者中断来进入内核空间。

分时系统

前面提到为了提高CPU资源的利用率，我们需要进行进程切换。linux是一个基于时间片的分时操作系统，所谓时间片就是操作系统给每个进程分配一定的时间配额，只要进程获得的cpu资源超过了该时间配额的值，该进程就会被换出去，让其它进程有执行的机会，这样做的好处是让系统中的每个进程都有机会执行而不至于被“饿死”。但是本身“判断某个进程时间片是否用完”这个过程也是一段代码，它也是要消耗CPU资源的，换一种说法它也是要被执行起来才能起到调度的作用，而且这个过程还要每隔一段时间就被执行一下，我们将这个过程称作“检查-调度”。一般要实现这个功能有两种做法，一种是主动式的，一种是被动式的。

主动式

主动式就是将你的进程代码和“检查-调度”写到一块去，比如我们可以每运行n个指令后去检查一下时间片，如果还没到时间，我们再运行n个指令，然后再去检查一下。

被动式

被动式的就是我们将“检查-调度”单独放到一个地方，然后通过某种机制通知CPU去运行这部分代码。这种方式也是linux操作系统使用的方式（时钟中断）。时钟中断打断CPU，中断处理程序调用“检查-调度”代码。

抢占

了解上面的时间片概念以后，抢占就是当一个进程的时间片还没运行完，这时候有一个更高优先级的进程需要立即被执行，我们强行进行进程切换，使得高优先级的进程得以运行，这个过程就叫作抢占。抢占还分为内核抢占和用户抢占，当进程在内核态被抢占就称为内核抢占。

线程模型

线程的实现模型主要有3种：内核级线程模型、用户级线程模型和混合型线程模型。它们之间最大的区别在于线程与内核调度实体KSE(Kernel Scheduling Entity)之间的对应关系上。所谓的内核调度实体KSE 就是指可以被操作系统内核调度器调度的对象实体，有些地方也称其为内核级线程，是操作系统内核的最小调度单元。在linux中，这样一个KSE就是一个轻量级的进程（通过clone系统调用创建出来的）。

内核级线程模型

用户线程与KSE是1对1关系(1:1)。大部分编程语言的线程库(如linux的pthread，Java的java.lang.Thread，C++11的std::thread等等)都是对操作系统的线程（内核级线程）的一层封装，创建出来的每个线程与一个不同的KSE静态关联，因此其调度完全由OS调度器来做。这种方式实现简单，直接借助OS提供的线程能力，并且不同用户线程之间一般也不会相互影响。但其创建，销毁以及多个线程之间的上下文切换等操作都是直接由OS层面亲自来做，在需要使用大量线程的场景下对OS的性能影响会很大。

用户级线程模型

用户线程与KSE是多对1关系(M:1)，这种线程的创建，销毁以及多个线程之间的协调等操作都是由用户自己实现的线程库来负责，对OS内核透明，一个进程中所有创建的线程都与同一个KSE在运行时动态关联。现在有许多语言实现的 协程 基本上都属于这种方式。这种实现方式相比内核级线程可以做的很轻量级，对系统资源的消耗会小很多，因此可以创建的数量与上下文切换所花费的代价也会小得多。但该模型有个致命的缺点，如果我们在某个用户线程上调用阻塞式系统调用(如用阻塞方式read网络IO)，那么一旦KSE因阻塞被内核调度出CPU的话，剩下的所有对应的用户线程全都会变为阻塞状态（整个进程挂起）。
所以这些语言的协程库会把自己一些阻塞的操作重新封装为完全的非阻塞形式，然后在以前要阻塞的点上，主动让出自己，并通过某种方式通知或唤醒其他待执行的用户线程在该KSE上运行，从而避免了内核调度器由于KSE阻塞而做上下文切换，这样整个进程也不会被阻塞了。

混合型线程模型

用户线程与KSE是多对多关系(M:N), 这种实现综合了前两种模型的优点，为一个进程中创建多个KSE，并且线程可以与不同的KSE在运行时进行动态关联，当某个KSE由于其上工作的线程的阻塞操作被内核调度出CPU时，当前与其关联的其余用户线程可以重新与其他KSE建立关联关系。当然这种动态关联机制的实现很复杂，也需要用户自己去实现，这算是它的一个缺点吧。Go语言中的并发就是使用的这种实现方式，Go为了实现该模型自己实现了一个运行时调度器来负责Go中的”线程”与KSE的动态关联。此模型有时也被称为 两级线程模型，即用户调度器实现用户线程到KSE的“调度”，内核调度器实现KSE到CPU上的调度。

GO Routine模型

• G：Goroutine的简称，上面用go关键字加函数调用的代码就是创建了一个G对象，是对一个要并发执行的任务的封装，也可以称作用户态线程。属于用户级资源，对OS透明，具备轻量级，可以大量创建，上下文切换成本低等特点。
• M：Machine的简称，在linux平台上是用clone系统调用创建的，其与用linux pthread库创建出来的线程本质上是一样的，都是利用系统调用创建出来的OS线程实体。M的作用就是执行G中包装的并发任务。Go运行时系统中的调度器的主要职责就是将G公平合理的安排到多个M上去执行。其属于OS资源，可创建的数量上也受限了OS，通常情况下G的数量都多于活跃的M的。
• P：Processor的简称，逻辑处理器，主要作用是管理G对象（每个P都有一个G队列），并为G在M上的运行提供本地化资源。

用户态调度

1
2
3
4
5
6
7
8
9
10
11
12
13

func main() {
	runtime.GOMAXPROCS(1)
	var a [10]int
	for i := 0; i < 10; i++ {
		go func(i int) {
			for {
				a[i]++
			}
		}(i)
	}
	time.Sleep(time.Millisecond)
	fmt.Println(a)
}

以上代码将P设置为1个，然后启动10个goroutine，每个goroutine对数组里相应的索引位置进行递增操作。没写过go的同学一般会认为这段程序运行不会有什么问题，但实际上这段程序的main函数运行到time.Sleep之后，就再也没机会运行了。这也是goroutine在用户态调度所存在的问题：用户态调度器只能“主动式”的运行“检查-调度”代码，这是因为用户态没有类似中断这种可以打断CPU的能力，因而它没办法采用“被动式的”方法。Go运行时，将“检查-调度”代码放在了每次函数调用之前，我们观察这段代码，每个goroutine里面都是一个无限循环的内存操作而已，不存在函数调用，因而，“检查-调度”代码永远都没有机会被执行，所以其它的goroutine都被活活“饿死了”。要解开这个问题，我们需要“主动的”调用“检查-调度”代码，在go里面也就是runtime.Gosched()，在for循环里面加上这行代码就可以解决这个问题。

总结

虽然goroutine很强大，但凡事都是有利有弊，我们只有深入了解其背后的机理，才能趋利避害，既能充分利用其高效的特性，又能避开其埋下的一些坑。

安装Helm

Helm的安装分为两部分：客户端（helm）和服务端（Tiller）

客户端安装

1. 在此选择你需要的版本进行下载
2. 解压：tar -zxvf helm-v2.0.0-linux-amd64.tgz
3. 将二进制文件移至目标路径： mv linux-amd64/helm /usr/local/bin/helm

服务端安装

1	$ helm init --upgrade

由于默认情况下，helm会拉取gcr.io/kubernetes-helm/tiller镜像，并且会以https://kubernetes-charts.storage.googleapis.com 作为stable的repository，国内无法直接访问，可用阿里云代替

1	$ helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.10.0 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

给Tiller授权

因为 Helm 的服务端 Tiller 是一个部署在 Kubernetes 中 Kube-System Namespace 下 的 Deployment，它会去连接 Kube-Api 在 Kubernetes 里创建和删除应用。
而从 Kubernetes 1.6 版本开始，API Server 启用了 RBAC 授权。目前的 Tiller 部署时默认没有定义授权的 ServiceAccount，这会导致访问 API Server 时被拒绝。所以我们需要明确为 Tiller 部署添加授权。

1 2 3

$ kubectl create serviceaccount --namespace kube-system tiller $ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller $ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

什么是PID 1

在Linux操作系统中，当内核初始化完毕之后，会启动一个init进程，这个进程是整个操作系统的第一个用户进程，所以它的进程ID为1，也就是我们常说的PID1进程。在这之后，所有的用户态进程都是该进程的后代进程，由此我们可以看出，整个系统的用户进程，是一棵由init进程作为根的进程树。

init进程有一个非常厉害的地方，就是SIGKILL信号对它无效。很显然，如果我们将一棵树的树根砍了，那么这棵树就会分解成很多棵子树，这样的最终结果是导致整个操作系统进程杂乱无章，无法管理。

PID 1进程的发展也是一段非常有趣的过程，从最早的sysvinit,到upstart,再到systemd。其中systemd还在linux社区引起了不小的争议，systemd作者Lennart还在 Google Plus 上发了贴子，喜欢八卦的同学可以前往一读。

那么这个PID 1进程在操作系统的整个生命周期中，到底起了什么重要的作用呢？首先我们先来了解以下几个概念：

进程表项

linux内核程序通过进程表对进程进行管理, 每个进程在进程表中占有一项，称为进程表项，它记录了进程的状态，打开的文件描述符等等一系统信息。当一个进程结束了运行或在半途中终止了运行，那么内核就需要释放该进程所占用的系统资源。这包括进程运行时打开的文件，申请的内存等。但是，这里要注意的是，进程表项并没有随着进程的退出而被清除，它会一直占用内核的内存。为什么会有这么奇怪的行为呢？这是因为在某些程序中，我们必须明确地知道进程的退出状态等信息，而这些信息的获取是由父进程调用wait/waitpid而获取的。设想这样一种场景，如果子进程在退出的时候直接清除文件表项的话，那么父进程就很可能没有地方获取进程的退出状态了，因此操作系统就会将文件表项一直保留至wait/waitpid系统调用结束。

僵尸进程

僵尸进程指的是：进程退出后，到其父进程还未对其调用wait/waitpid之间的这段时间所处的状态。一般来说，这种状态持续的时间很短，所以我们一般很难在系统中捕捉到。但是，一些粗心的程序员可能会忘记调用wait/waitpid，或者由于某种原因未执行该调用等等，那么这个时候就会出现长期驻留的僵尸进程了。如果大量的产生僵尸进程，其进程号就会一直被占用，可能导致系统不能产生新的进程。

聪明的读者可能立马会想到一种情况，就是如果父进程先于子进结束，那么是不是就没有人负责这个子进程的资源清理工作了，那我们的系统岂不是到处都是僵尸进程?事实上操作系统设计人员早就想到了这个问题，这也是我们的PID 1进程最重要的职责。

孤儿进程

父进程先于子进程退出，那么子进程将成为孤儿进程。孤儿进程将被init进程(进程号为1)接管，并由init进程对它完成状态收集(wait/waitpid)工作。

从这里我们可以看出，PID 1负责清理那些被抛弃的进程所留下来的痕迹，有效的回收的系统资源，保证系统长时间稳定的运行，可谓是功不可没。在理解了它的重要性之后，我们今天主要探讨一下在容器中的PID 1是怎么回事。

容器中的孤儿进程

容器中的PID 1

熟悉Docker同学可能知道，容器并不是一个完整的操作系统，它也没有什么内核初始化过程，更没有像init(1)这样的初始化过程。在容器中被标志为PID 1的进程实际上就是一个普普通通的用户进程，也就是我们制作镜像时在Dockerfile中指定的ENTRYPOINT的那个进程。而这个进程在宿主机上有一个普普通通的进程ID，而在容器中之所以变成PID 1，是因为linux内核提供的PID namespaces功能，如果宿主机的所有用户进程构成了一个完整的树型结构，那么PID namespaces实际上就是将这个ENTRYPOINT进程（包括它的后代进程）从这棵大树剪下来，很显然，剪下来的这部分东西本身也是一个树型结构，它完全可以自己长成一棵苍天大树（不断地fork）,当然，子树里面是看不到整棵树的原貌的，但是在子树外面确可以看到完整的子树。
比如我们在宿主机查看某个tomcat容器：

1 2 3 4 5

$ docker top 7bb975e9a7cb UID PID PPID C STIME TTY TIME CMD 8080 56128 56100 0 15:52 ? 00:00:00 /bin/bash /home/tomcat/start.sh 8080 56178 56128 2 15:52 ? 00:02:26 /usr/bin/java ......

1 2	$ cat /proc/56128/status | grep NSpid NSpid: 56128 1

1 2	$ cat /proc/56178/status | grep NSpid NSpid: 56178 17

可以看到同一个进程在容器内外的进程号是不同的。我们如果在容器外部kiss -9 56128,那整个容器便会处于退出状态。
我们现在进入容器：

1 2 3 4 5 6 7

$ docker exec -it 7bb975e9a7cb bash $ ps -ef UID PID PPID C STIME TTY TIME CMD tomcat 1 0 0 15:52 ? 00:00:00 /bin/bash /home/tomcat/start.sh tomcat 17 1 2 15:52 ? 00:02:30 /usr/bin/java .... tomcat 119 0 0 17:24 pts/0 00:00:00 bash tomcat 126 119 0 17:25 pts/0 00:00:00 ps -ef

可以看到bash进程的父进程号是0，和PID 1进程处于同一层级上。接下来我们打算在容器当中造个孤儿进程出来。

1 2	#parent.sh bash ./child.sh

1 2 3 4 5

#child.sh while true do sleep 10 done

1	bash ./parent.sh

在另一个终端中运行

1 2 3 4 5 6 7 8 9

$ ddocker exec -it 7bb975e9a7cb ps xf -o pid,ppid,stat,args PID PPID STAT COMMAND 201 0 Rs+ ps xf -o pid,ppid,stat,args 119 0 Ss bash 198 119 S+ \_ bash ./parent.sh 199 198 S+ \_ bash ./child.sh 200 199 S+ \_ sleep 10 1 0 Ss /bin/bash /home/tomcat/start.sh 17 1 Sl /usr/bin/java ......

接下来用kill -9杀死parent进程

1	$ docker exec -it 7bb975e9a7cb kill -9 198

1 2 3 4 5 6 7 8

$ docker exec -it 7bb975e9a7cb ps xf -o pid,ppid,stat,args PID PPID STAT COMMAND 222 0 Rs+ ps xf -o pid,ppid,stat,args 199 0 S bash ./child.sh 214 199 S \_ sleep 10 119 0 Ss+ bash 1 0 Ss /bin/bash /home/tomcat/start.sh 17 1 Sl /usr/bin/java ......

可以看到，child进程的父进程变成了PID 0，那么这个PID 0又是何方神圣，为什么它可以接管孤儿进程，又为何ENTRYPOINT进程的父进程也是它。

容器中的PID 0

我们在前面提到过，容器中的进程树实际上是宿主机进程树的一棵子树，那么我们在宿主机上是否就可以找到这棵子树的父进程呢？我们在宿主机上执行以下命令

1 2 3 4 5

$ ps -axf | grep -C 5 56128 ...... 56100 ? Sl 0:00 \_ docker-containerd-shim -namespace moby -workdir /data/var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/7bb975e9a7cbf84a17b584c0594c854283e47116cb4fd7eaecec8e4c706e363f -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc -systemd-cgroup 56128 ? Ss 0:00 \_ /bin/bash /home/tomcat/start.sh 56178 ? Sl 2:47 | \_ /usr/bin/java ......

至此，我们可以大胆的猜想，这个PID 0应该就是这个docker-containerd-shim

Docker 1.11版本后的架构

从架构图中我们可以看到shim进程下还有一个runC进程，但我们在进程树中并没有发现runC这个进程。

runC

runC是OCI标准的一个参考实现，而OCI Open Container Initiative，是由多家公司共同成立的项目，并由linux基金会进行管理，致力于container runtime的标准的制定和runc的开发等工作。runc，是对于OCI标准的一个参考实现，是一个可以用于创建和运行容器的CLI(command-line interface)工具。runc直接与容器所依赖的cgroup/linux kernel等进行交互，负责为容器配置cgroup/namespace等启动容器所需的环境，创建启动容器的相关进程。

事实上，Docker容器的创建过程是这样子的 docker-containerd-shim –> runC –> entrypoint，而我们看到的最终状态是 docker-containerd-shim –> entrypoint，聪明的你可能已经猜到，runc进程创建完容器之后，自己就先退出去了。但是这里面其实暗藏了一个问题，按照前面提到的孤儿进程理论，entrypint进程应该由操作系统的PID 1进程接管，但为什么会被shim接管呢？

PR_SET_CHILD_SUBREAPER

linux在内核3.14以后版本支持该系统调用，它可以将调用进程标记“child subreaper”属性，而拥有该属性的进程则可以充当init(1)进程的功能，收养其后代进程中所产生的孤儿进程。我们可以从shim的源码中找到答案

1 2 3 4 5 6 7 8 9 10 11

func start(log *os.File) error { // start handling signals as soon as possible so that things are properly reaped // or if runtime exits before we hit the handler signals := make(chan os.Signal, 2048) signal.Notify(signals) // set the shim as the subreaper for all orphaned processes created by the container if err := osutils.SetSubreaper(1); err != nil { return err } ... }

既然充当了reaper的角色，那么就应该尽到回收资源的责任：

1 2 3 4 5 6 7 8 9

func start(log *os.File) error { ... switch s { case syscall.SIGCHLD: exits, _ := osutils.Reap(false) ... } ... }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

func Reap(wait bool) (exits []Exit, err error) { ... for { pid, err := syscall.Wait4(-1, &ws, flag, &rus) if err != nil { if err == syscall.ECHILD { return exits, nil } return exits, err } ... } }

从这里我们可以看到shim的wait/waitpid系统调用。

1.11以前的Docker

实际上在早期的Docker中，并没有reaper的设置，那么内核此时会如何处理孤儿进程呢？

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

/* * When we die, we re-parent all our children, and try to: * 1. give them to another thread in our thread group, if such a member exists * 2. give it to the first ancestor process which prctl'd itself as a * child_subreaper for its children (like a service manager) * 3. give it to the init process (PID 1) in our pid namespace */ static struct task_struct *find_new_reaper(struct task_struct *father, struct task_struct *child_reaper) { struct task_struct *thread, *reaper; thread = find_alive_thread(father); if (thread) return thread; if (father->signal->has_child_subreaper) { /* * Find the first ->is_child_subreaper ancestor in our pid_ns. * We start from father to ensure we can not look into another * namespace, this is safe because all its threads are dead. */ for (reaper = father; !same_thread_group(reaper, child_reaper); reaper = reaper->real_parent) { /* call_usermodehelper() descendants need this check */ if (reaper == &init_task) break; if (!reaper->signal->is_child_subreaper) continue; thread = find_alive_thread(reaper); if (thread) return thread; } } return child_reaper; }

1. 找到相同线程组里其它可用线程
2. 沿着它的进程树向祖先进程找一个最近的child_subreaper并且运行着的进程
3. 该namespace下进程号为1的进程

很显然，旧版本的Docker在容器内所产生的孤儿进程，会被进程号为1（也就是entrypoint进程）所接管，而我们知道，该进程一般是一个普通的应用程序，一般不会特意去实现对孤儿进程的处理，所以，在使用早期版本的Docker时，我们会发现操作系统会经常出现僵尸进程。所以，为了你的系统稳定，早点升级你的内核和Docker的版本吧。

准备:删除旧版本

1
2
3
4
5
6
7
8
9
10

$ sudo yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-selinux \
                  docker-engine-selinux \
                  docker-engine

1. 安装仓库

1

$ sudo yum install -y yum-utils

1
2
3

$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

2. 安装指定版本的Docker CE

1. 列出版本

1

$ yum list docker-ce --showduplicates | sort -r

2.安装指定版本

1

$ sudo yum install docker-ce-<VERSION STRING>

3. 启动docker

1

$ sudo systemctl start docker

续：

###（1）修改cgroup driver:
在 /usr/lib/systemd/system/docker.service 中添加以下启动项

1
2

ExecStart=/usr/bin/dockerd \
          --exec-opt native.cgroupdriver=systemd

###（2）修改storage-driver:
在/etc/docker/daemon.json 添加以下配置

1
2
3
4
5
6

{
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]
}

重启docker

1
2

$ systemctl daemon-reload
$ systemctl restart docker

1. 查看当前内核版本

1
2

$ uname -r
3.10.0-229.el7.x86_64

2. 导入public key

1

$ rpm --import http://www.elrepo.org/RPM-GPG-KEY-elrepo.org

3. 安装ELRepo到CentOS-6.5中

1

$ rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

4. 安装kernel-lt（lt=long-term）

1

$ yum --enablerepo=elrepo-kernel install kernel-lt -y

5. 修改Grub引导顺序

1

$ grub2-set-default 0

6. 重启，查看内核版本号

1
2

$ uname -r
4.4.156-1.el7.elrepo.x86_64

引子

最近将java应用迁移至docker容器时，发现了一个有趣的现象：在容器内运行一段时间以后，总是被内核OOM Killed.顾名思义，这是java进程内存使用超过了一定的限制。
我们在启动容器的时候，限制其可用物理内存为1G，通过以下命令可查看内存限制

1

docker inspect --format='{{.HostConfig.Memory}}' ${ContainerId}

容器启动之后，我们能过grafana观察其内存变量，其内存使用在一小时之内就涨到了1G，再经过差不多一小时，容器就被OOM Killed了。
有趣的是，我们将该程序放到一以1G内存的虚拟机上去执行，其内存使用量一直保存在300M左右，自然也不会触发OOM Killed。
同样是1G内存的限制，为什么在容器内就挂了而在物理机或虚拟机上就正常了呢？看来这值得我们深挖一下。

CGroup

首先，可以确定的是，容器之所以被杀死，是因为其内存超过了限制，那么这个限制，就是由Linux内核提供的CGroup来行限制的。
CGroup全名Control Group,其作用就是限制某一个或一组进程对系统资源的使用，在这里我们不对CGroup进行深入的探讨，有兴趣的同学可以点击这里进行深入学习。
在这里要提到的是，为什么上述容器在内存满了之后还要再过1小时才被Kill？这是因为我们的系统开启了交换内存的功能，而如果我们不对容器进行交换内存进行限制而只是限制物理内存，那么交换内存将会被设置为物理内存的2倍。（注意，这里交换内存包含了物理内存的容量）
所以当物理内存满了以后，容器还能继续跑是因为其还在涨的内存被交换出去了，还没到达交换内存的限制而已。

JVM –Xmx

除非我们显示的设置JVM的最大堆大小，否则，JVM将会根据宿主机的RAM来推断这个值 – 默认情况下，这个值会被设置成宿主机内存的1/4。
我们可以能过-XX:+PrintFlagsFinal来查看这个值的大小

笔者在一台64G内存的物理器上执行得到如下结果：

1
2
3
4
5
6

$ java -XX:+PrintFlagsFinal -version|grep -i heapsize|egrep 'Initial|Max'
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
    uintx InitialHeapSize                          := 1057991744      {product}           
    uintx MaxHeapSize                              := 16928210944     {product}

1
2
3
4
5
6

$ docker run --rm java java  -XX:+PrintFlagsFinal -version |grep -i heapsize | egrep 'Initial|Max'
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
    uintx InitialHeapSize                          := 1057991744      {product}           
    uintx MaxHeapSize                              := 16928210944     {product}

1
2
3
4
5
6

$ docker run -m 1024m --rm java java  -XX:+PrintFlagsFinal -version |grep -i heapsize | egrep 'Initial|Max'
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
    uintx InitialHeapSize                          := 1057991744      {product}           
    uintx MaxHeapSize                              := 16928210944     {product}

Memory Inside Linux Containers

我们用free来看一下内存的情况
在宿主机上:

1
2
3
4
5

$ free -m
             total       used       free     shared    buffers     cached
Mem:         64574      62979       1594          0        864      49236
-/+ buffers/cache:      12878      51695
Swap:         4095        448       3647

1
2
3
4
5

$ docker run -1024 --rm busybox free -m
             total       used       free     shared    buffers     cached
Mem:         64574      62979       1594          0        864      49236
-/+ buffers/cache:      12878      51695
Swap:         4095        448       3647

解决

1. 一些人认为可以提供一个用户态的库供大家调用，这种方案只适合新的程序，那些旧的程序如top,free甚至jvm都无法使用这个方案了
2. 另一种方案是在用户态重写/proc/meminfo，例如FUSE就可以实现这种功能。但这种方案的问题是要在宿主机上运行这个用户态的服务，如果这个服务挂了该如何处理？总之，这种方案可以解决问题，但并不是十分完美
3. 直接内核支持，但是这种又会影响到那些没有容器化的系统，所以除非你自定义内核，否则不可能被合并到主流内核版本中。

JVM的解决

知道了问题产生的原因，那么我们解决JVM在容器中的问题其实就很简单了：
我们结合容器的限制内存，给JVM设置一下最大堆参数就可以了

1
2
3
4
5
6

$ docker run -m 1024m --rm java java -Xmx256m -Xms16m  -XX:+PrintFlagsFinal -version|grep -i heapsize|egrep 'Initial|Max'     
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
    uintx InitialHeapSize                          := 16777216        {product}           
    uintx MaxHeapSize                              := 268435456       {product}

笔者最后给最开始被OOM Killed的Java程序加上最大堆限制之后，就再也没有出现被Kill的情况，附上内存图：

（全文完）

问题

首先我们来看一下需求：

有四个整型数（初始化为0）存在我们计算机的内存之中，现在要求对每个数分别进行++操作，重复这个动作1000000000次。

这很显然是一个计算密集型的过程，其间并不会涉及任何的io操作，因此，我们可以考虑用四个线程来同时对这四个数进行操作（用四个线程是因为笔者的电脑CPU物理核数为4）,这样可以最大程度地利用我们的cpu资源。

实现

接下来，我们用程序来实现这个需求，笔者用的语言是C#，这个实验和使用的语言关系不是很大，各个语言之间的差异很小。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

class Program
{
    private static int m_numOfProcessor = 4;
    private static int m_step = 1;
    private volatile static int[] m_array = new int[m_numOfProcessor * m_step];
    private static readonly int m_ticks = 1000000000;
    static void Main(string[] args)
    {
        var events = InitEvents(m_numOfProcessor);
        Stopwatch watch = new Stopwatch();
        watch.Start();
        for (int i = 0; i < m_numOfProcessor; i++)
        {
            new Thread(new ParameterizedThreadStart((o) =>
            {
                UpdateCounter(Convert.ToInt32(o) * m_step);
                events[Convert.ToInt32(o)].Set();
            })).Start(i);
        }
        WaitHandle.WaitAll(events);
        watch.Stop();
        Console.WriteLine(String.Format("step {0} elapsed:" + watch.ElapsedMilliseconds, m_step));
        Print(m_array, m_step);
        Console.Read();
    }
    private static void Print(int[] array,int step)
    {
        for (int i = 0; i < array.Length; i = i + step)
        {
            Console.WriteLine(array[i]);
        }
    }
    private static ManualResetEvent[] InitEvents(int num)
    {
        ManualResetEvent[] events = new ManualResetEvent[4];
        for (int i = 0; i < num; i++)
        {
            events[i] = new ManualResetEvent(false);
        }
        return events;
    }
    private static void UpdateCounter(int position)
    {
        for (int i = 0; i < m_ticks; i++)
        {
            m_array[position] = m_array[position] + 1;
        }
    }
}

1
2
3
4
5

step 1 elapsed:15495
1000000000
1000000000
1000000000
1000000000

我们一开始的想法是通过多线程来充分利用CPU的计算资源，那么，我们现在来验证多线程是否确实比单线程速度快：

1
2
3
4
5
6
7
8
9
10

for (int i = 0; i < m_numOfProcessor; i++)
{
    //new Thread(new ParameterizedThreadStart((o) =>
    //{
    //    UpdateCounter(Convert.ToInt32(o) * m_step);
    //    events[Convert.ToInt32(o)].Set();
    //})).Start(i);
    UpdateCounter(i * m_step);
}
//WaitHandle.WaitAll(events);

1
2
3
4
5

step 1 elapsed:7741
1000000000
1000000000
1000000000
1000000000

结果竟然是单线程比多线程的速度快！

接下来，我们调整一下m_step的值分别为2、4、8、16，来看一下不同的步长在多线程和单线程模式下的各自的性能表现：

这里，我们发现当步长为8和16的时候，多线程性能突然提升，并且在16的时候超过了单线程的性能，而这一切又是为什么呢？

分析

要解释这个结果，我们要先理解CPU的工作原理。
1) cpu从来都不直接访问主存, 都是通过cpu cache间接访问主存。
2) 每次需要访问主存时, 遍历一遍全部cache line, 查找主存的地址是否在某个cache line中。
3) 如果cache中没有找到, 则分配一个新的cache entry, 把主存的内存copy到cache line中, 再从cache line中读取。

那什么又是cache line呢？
现代的cpu从主存读取数据并不是一个字节一个字节读取，而是一整块一整块地读取，那么究竟一次会读取多少数据呢，这就取决于CPU的cache line的大小。CPU将它的cache划分成一块一块的，一块这样的存储区域就是一个cache line。
在现代计算机CPU的cache line大小一般为32Byte或64Byte，我们要如何查看cache line的大小呢？可以使用 CoreInfo工具。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Logical Processor to Cache Map:
**------  Data Cache          0, Level 1,   32 KB, Assoc   8, LineSize  64
**------  Instruction Cache   0, Level 1,   32 KB, Assoc   8, LineSize  64
**------  Unified Cache       0, Level 2,  256 KB, Assoc   8, LineSize  64
********  Unified Cache       1, Level 3,    8 MB, Assoc  16, LineSize  64
--**----  Data Cache          1, Level 1,   32 KB, Assoc   8, LineSize  64
--**----  Instruction Cache   1, Level 1,   32 KB, Assoc   8, LineSize  64
--**----  Unified Cache       2, Level 2,  256 KB, Assoc   8, LineSize  64
----**--  Data Cache          2, Level 1,   32 KB, Assoc   8, LineSize  64
----**--  Instruction Cache   2, Level 1,   32 KB, Assoc   8, LineSize  64
----**--  Unified Cache       3, Level 2,  256 KB, Assoc   8, LineSize  64
------**  Data Cache          3, Level 1,   32 KB, Assoc   8, LineSize  64
------**  Instruction Cache   3, Level 1,   32 KB, Assoc   8, LineSize  64
------**  Unified Cache       4, Level 2,  256 KB, Assoc   8, LineSize  64

• 当步长为1时，四个数全部在同一个cache line中
• 当步长为2时，四个数全部在同一个cache line中
• 当步长为4时，四个数全部在同一个cache line中
• 当步长为8时，每两个处于不同的cache line中
• 当步长为16时，每个数都处于不同的cache line中

到这里我们就很好解释上述实验所显示的结果，正是因为多个CPU处理器同时操作了同一个cache line，一旦某一个处理器更新了cache line的数据，会导致其它处理器同一个cache line的数据失效，那么其它处理器就必须从主存再次读取，这正是导致其性能低下的原因。
（全文完）