当用户发起一个网络请求时，流量会通过默认的网卡接口流出与流入，但有时需要将流量通过指定的网卡进行流出流入，这时我们可能需要进行一些额外的开发工作，对其实现主要用到了 Dialer.Control 配置项。

type Dialer struct {
​
    // If Control is not nil, it is called after creating the network
    // connection but before actually dialing.
    //
    // Network and address parameters passed to Control method are not
    // necessarily the ones passed to Dial. For example, passing "tcp" to Dial
    // will cause the Control function to be called with "tcp4" or "tcp6".
    Control func(network, address string, c syscall.RawConn) error
}

可以看到这是一个函数类型的参数。

环境

当前系统一共两个网卡 ens33和 ens160 ，ip地址分别为 192.168.3.80 和 192.168.3.48

➜  ~ ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.80  netmask 255.255.255.0  broadcast 192.168.3.255
        inet6 fe80::8091:2406:c51e:ecb9  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:4f:05:90  txqueuelen 1000  (Ethernet)
        RX packets 4805008  bytes 826619853 (826.6 MB)
        RX errors 0  dropped 104152  overruns 0  frame 0
        TX packets 732513  bytes 284605386 (284.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
​
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.48  netmask 255.255.255.0  broadcast 192.168.3.255
        inet6 fe80::259a:d8d4:80a9:7fa4  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:4f:05:9a  txqueuelen 1000  (Ethernet)
        RX packets 4158530  bytes 746167179 (746.1 MB)
        RX errors 1  dropped 106875  overruns 0  frame 0
        TX packets 351616  bytes 149235606 (149.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
​
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 426742  bytes 80978543 (80.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 426742  bytes 80978543 (80.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
​

路由表记录

➜  ~ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.1     0.0.0.0         UG    100    0        0 ens33
0.0.0.0         192.168.3.1     0.0.0.0         UG    101    0        0 ens160
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 ens33
192.168.3.0     0.0.0.0         255.255.255.0   U     100    0        0 ens33
192.168.3.0     0.0.0.0         255.255.255.0   U     101    0        0 ens160
​

从最后两条路由记录可以看到对于 192.168.3.0/24 这个段的流量会匹配的两个物理网卡，但由于配置的 Metric 的优先级比较的高，因此最终流量只会走网卡 ens33。

计时器分 Timer 和 Ticker 两种，它们底层基本是一样的，两差的区别请参考 https://blog.haohtml.com/archives/19859, 这里我们的介绍对象是 Timer 。

计时器结构体

https://github.com/golang/go/blob/go1.17.6/src/time/sleep.go#L84-L98

 // NewTimer creates a new Timer that will send
 // the current time on its channel after at least duration d.
 func NewTimer(d Duration) *Timer {
     c := make(chan Time, 1)
     t := &Timer{
         C: c,
         r: runtimeTimer{
             when: when(d),
             f:    sendTime,
             arg:  c,
         },
     }
     startTimer(&t.r)
     return t
 }

通过调用 NewTimer() 函数创建一个 Timer，首先创建一个长度为1的有缓冲channel，再创建一个Timer的结构体，并将 channel 置于 Timer 结构体内。

注意这里的 runtimeTimer.f 字段是一个函数 sendTime ，其实现如下

func sendTime(c interface{}, seq uintptr) {
	// Non-blocking send of time on c.
	// Used in NewTimer, it cannot block anyway (buffer).
	// Used in NewTicker, dropping sends on the floor is
	// the desired behavior when the reader gets behind,
	// because the sends are periodic.
	select {
	case c.(chan Time) <- Now():
	default:
	}
}

当 sendTime 函数主要用在 newTimer() 时，它以无阻塞的方式将当前时间 Now() 发送到 c 通道里。如果用在 newTicker() 时，如果读取落后，会将发送丢弃，它是周期性的。

我们给出 Timer 的结构体声明。

 type Timer struct {
     C <-chan Time
     r runtimeTimer
 }

一共两个字段，为了理解方面我们称 runtimeTimer 为 timer 值。

我们再看一下其中的 runtimeTimer 结构体的声明

 // Interface to timers implemented in package runtime.
 // Must be in sync with ../runtime/time.go:/^type timer
 type runtimeTimer struct {
     pp       uintptr
     when     int64
     period   int64
     f        func(interface{}, uintptr) // NOTE: must not be closure
     arg      interface{}
     seq      uintptr
     nextwhen int64
     status   uint32
 }

对于 runnerTimer结构体要与在 runtime/time.go 文件中的 timer 结构体保持同步。

结构体字段说明

• pp 指针类型，这里指 GPM 中的 P。如果这个计时器 timer 在一个heap 上，它在哪个 P 的堆上
• when 表示唤醒执行的时间，表示什么时间开始执行
• period 周期，一定是大于 0; when+period 表示下次唤醒执行的时间
• f 执行函数，不允许为匿名函数，最好为非阻塞函数
• arg 上面f函数的参数
• seq 同 arg，其在 runOneTimer 函数中的调用方式为 f(arg, seq)
• nextwhen 下次运行的时间，其值只有在 timerModifiedXX status 状态下才设置
• status 状态，其定义的的可用值有10种，定义在 runtime/time.go，我们下面对这些状态进行了介绍。

每次开启一个goroutine 执行 f(arg, now)，基中when表示执行的时间，而 when+period 表示下次执行的时间。(这时有点疑问，对调用的函数参数，f的第二个参数是 now, 但后面介绍的时候第二个参数却是 seq)

通过查看 https://github.com/golang/go/blob/go1.17.6/src/runtime/time.go#L41-L116 可知以下几点：

在执行 go build 命令的时候，经常需要添加一些参数，或许是为了调试，也或许是为了生成最终部署二进制文件。

在编译特定包时需要传递参数，格式应遵守“包名=参数列表”，如

go build -gcflags -gcflags='log=-N -l' main.go

-gcflags

go build 可以用 -gcflags 给go编译器传入参数，也就是传给 go tool compile 的参数，因此可以用 go tool compile –help 查看所有可用的参数。

其中 -m 可以检查代码的编译优化情况，包括逃逸情况和函数是否内联。

-ldflags

go build用 -ldflags 给go链接器传入参数，实际是给go tool link的参数，可以用go tool link –help查看可用的参数。

常用-X来指定版本号等编译时才决定的参数值。例如代码中定义var buildVer string，然后在编译时用go build -ldflags “-X main.buildVer=1.0” … 来赋值。注意-X只能给string类型变量赋值。

Golang中的编译参数

开发中经常使用 go build 命令来编译我们的程序源码，然后将生成二进制文件直接部署，极其方便。

对于 go build 有一些参数，对于针对程序源码进行一些编译优化，下面我们对经常使用的一些参数来介绍一下。

环境变量

环境变量需要在go命令前面设置，如果多个变量的话，中间需要用“空格”分隔。下面我们介绍一个非常常见到的一些环境变量

$ CGO_ENABLED=1 GOARCH=amd64 GOOS=linux go build -o myserver main.go

除了这里给出的这几个变量外，还有一些其它变量，如 GODEBUG、GOFLAGS、GOPROXY 等，所有支持环境变量都可以在 https://github.com/golang/go/blob/a88575d662a7e8e4fbb31bf139bcffc063e2a734/src/cmd/go/internal/help/helpdoc.go#L485 里找到，有兴趣的话可以看看他们的作用。

这里重点介绍一下 CGO_ENABLED 环境变量对我们程序的影响。 CGO_ENABLED是用来控制golang 编译期间是否支持调用 cgo 命令的开关，其值为1或0，默认情况下值为1，可以用 go env 查看默认值。

如果你的程序里调用了cgo 命令，此参数必须设置为1,否则将编译时出错。这里直接用文档 https://go.dev/blog/cgo 中的一个例子验证。

package main

// #include <stdio.h>
// #include <stdlib.h>
//
// static void myprint(char* s) {
//   printf("%sn", s);
// }
import "C"
import "unsafe"

func main() {
	cs := C.CString("Hello from stdio")
	C.myprint(cs)
	C.free(unsafe.Pointer(cs))
}

然后我们执行一下 启用 CGO_ENABLED=1 的情况

root@ubuntu:/home/sxf/gotest# CGO_ENABLED=1 go run main.go
root@ubuntu:/home/sxf/gotest# ./main
Hello from stdio

可以看到输出正常，这里也可以省略不写变量，因为默认情况为启用CGO状态

启用 CGO_ENABLED=0 的情况

root@ubuntu:/home/sxf/gotest# CGO_ENABLED=0 go build main.go
go: no Go source files

可以看到编译失败，验证了我们上面说的情况。

这里提示找不到go源文件，不清楚底层是如何判断这一情况的。

那么，如果我们一个程序里未调用cgo，在编译时指定 CGO_ENABLED 不同值话，又会发生什么呢？编译的二进制有何区别呢？

root@ubuntu:/home/sxf/gotest# CGO_ENABLED=1 go build -o cgo_main main.go
root@ubuntu:/home/sxf/gotest# CGO_ENABLED=0 go build -o no_cgo_main main.go
root@ubuntu:/home/sxf/gotest# ls -al
total 3804
drwxrwxr-x  2 sxf  sxf     4096 Nov 25 10:22 .
drwxr-x--- 47 sxf  sxf     4096 Nov 19 12:48 ..
-rwxr-xr-x  1 root root 1937311 Nov 25 10:22 cgo_main
-rw-rw-r--  1 sxf  sxf      119 Oct 29 09:07 go.mod
-rw-rw-r--  1 sxf  sxf      241 Oct 29 09:07 go.sum
-rw-rw-r--  1 sxf  sxf       72 Nov 25 10:21 main.go
-rwxr-xr-x  1 root root 1937311 Nov 25 10:22 no_cgo_main

可以看到两种情况都可能编译成功，且两者生成的二进制文件是完全一样的。由此总结出可以看出如果程序里未调用 cgo 的话，此变量值并没有影响的。

那么问题来了，为什么这么多项目里编译的时候都明确指定了此环境变量的值呢，主要是编译器在编译时会根据不同的情况使用不同的编译方法。 当CGO_ENABLED=1，进行编译时会将文件中引用libc的库（比如常用的net包），以动态链接的方式生成目标文件。 当CGO_ENABLED=0，进行编译时则会把在目标文件中未定义的符号（外部函数）一起链接到可执行文件中。

不论哪种方式，都可以使用静态连接编译

参考

• https://go.dev/blog/cgo
• https://pkg.go.dev/cmd/cgo
• https://johng.cn/cgo-enabled-affect-go-static-compile/
• https://github.com/golang/go/blob/a040ebeb98/src/cmd/cgo/doc.go
• https://www.jianshu.com/p/bc78c32db030

在runtime中有 runtime.LockOSThread 和 runtime.UnlockOSThread 两个函数，这两个函数有什么作用呢？我们看一下标准库中对它们的解释。

runtime.LockOSThread

// LockOSThread wires the calling goroutine to its current operating system thread.
// The calling goroutine will always execute in that thread,
// and no other goroutine will execute in it,
// until the calling goroutine has made as many calls to
// UnlockOSThread as to LockOSThread.
// If the calling goroutine exits without unlocking the thread,
// the thread will be terminated.
//
// All init functions are run on the startup thread. Calling LockOSThread
// from an init function will cause the main function to be invoked on
// that thread.
//
// A goroutine should call LockOSThread before calling OS services or
// non-Go library functions that depend on per-thread state.

调用 LockOSThread 将 绑定 当前 goroutine 到当前 操作系统线程，此 goroutine 将始终在此线程执行，其它 goroutine 则无法在此线程中得到执行，直到当前调用线程执行了 UnlockOSThread 为止（也就是说 LockOSThread 可以指定一个goroutine 独占 一个系统线程）；

对于提高对 stack 的使用效率，避免重复从heap中分配与释放，对其使用了 pool 的概念，runtime 里为共提供了两个pool, 分别为 stackpool ，另一个为 stackLarge。

stackpool: 16b~32k 对应通用的大小的stack。获取时通过调用 stackpoolalloc(), 释放时调用 stackpoolfree()。

stackLarge：对应 > 32K 的 stack

在程序全局调度器初始化时会通过调用 stackinit() 实现对 stack 初始化。

当我们执行一个 go func() 语句的时候，runtime 会通过调用 newproc() 函数来创建G。而内部真正创建G的函数为 newproc1()，在没有G可以复用的情况下，会通过 newg = malg(_StackMin) 语句创建一个包含stack的G。

// Allocate a new g, with a stack big enough for stacksize bytes.
func malg(stacksize int32) *g {
	newg := new(g)
	if stacksize >= 0 {
		stacksize = round2(_StackSystem + stacksize)
		systemstack(func() {
			newg.stack = stackalloc(uint32(stacksize))
		})
		newg.stackguard0 = newg.stack.lo + _StackGuard
		newg.stackguard1 = ^uintptr(0)
		// Clear the bottom word of the stack. We record g
		// there on gsignal stack during VDSO on ARM and ARM64.
		*(*uintptr)(unsafe.Pointer(newg.stack.lo)) = 0
	}
	return newg
}

对于新创建的g，需要通过调用 stackalloc() 函数为其分配 stacksize 大小stack，那么分配操作它又是如何工作的呢？

stack的申请

根据申请stack的大小分两种情况，一种是 small stack，另一种是 large stack，两者采用不同的申请策略。主要涉及了内存申请策略，如果对golang 的内存管理比较了解的话，这块理解起来就显的太过于简单了。建议先阅读一下这篇文章《Golang 内存组件之mspan、mcache、mcentral 和 mheap 数据结构》。

func stackalloc(n uint32) stack {
	...

	var v unsafe.Pointer
	if n < _FixedStack<<_NumStackOrders && n < _StackCacheSize {
		order := uint8(0)
		n2 := n
		for n2 > _FixedStack {
			order++
			n2 >>= 1
		}
		var x gclinkptr
		if stackNoCache != 0 || thisg.m.p == 0 || thisg.m.preemptoff != "" {
			// thisg.m.p == 0 can happen in the guts of exitsyscall
			// or procresize. Just get a stack from the global pool.
			// Also don't touch stackcache during gc
			// as it's flushed concurrently.
			lock(&stackpool[order].item.mu)
			x = stackpoolalloc(order)
			unlock(&stackpool[order].item.mu)
		} else {
			c := thisg.m.p.ptr().mcache
			x = c.stackcache[order].list
			if x.ptr() == nil {
				stackcacherefill(c, order)
				x = c.stackcache[order].list
			}
			c.stackcache[order].list = x.ptr().next
			c.stackcache[order].size -= uintptr(n)
		}
		v = unsafe.Pointer(x)
	} else {
		...
	}
	return stack{uintptr(v), uintptr(v) + uintptr(n)}
}

对于 small stack 以可以分两种情况：

• 有 P：会直接通过从当前 G 绑定的P中的 mcache 字段申请，这个字段可以理解为内存资源中心，里面包含有多种不同规格大小的内存块，根据申请大小找到一个可以满足其大小的最小规格的内存区域。
• 无 P：调用 stackpoolalloc() 会直接从全局 stack pool 中获取

现状

目前在网络编程中，golang采用的是一种 goroutine-per-connection 的模式，即为每一个连接都分配一个goroutine，一个连接就是一个goroutine，多个连接之间没有关系。

package main

import (
	"fmt"
	"io/ioutil"
	"net"
	"time"
)

//模拟server端
func main() {
	tcpServer, _ := net.ResolveTCPAddr("tcp4", ":8080")
	listener, _ := net.ListenTCP("tcp", tcpServer)

	for {
		//当有新客户端请求时拿到与客户端的连接
		conn, err := listener.Accept()
		if err != nil {
			fmt.Println(err)
			continue
		}

		// 处理逻辑 goroutine-per-connection
		go handle(conn)
	}
}

func handle(conn net.Conn) {
	defer conn.Close()

	//读取客户端传送的消息
	go func() {
		response, _ := ioutil.ReadAll(conn)
		fmt.Println(string(response))
	}()

	//向客户端发送消息
	time.Sleep(1 * time.Second)
	now := time.Now().String()
	conn.Write([]byte(now))
}

这种模式看起来非常的舒服，简单易懂，大大减少了开发者的心智负担，深受开发者的喜爱。

存在的问题

对于 goroutine-per-connection 这种模式，真的就不有一点问题的吗？

假如现在只有两个 P，正常情况下每秒可以处理 10000 个 goroutine 连接。突然有1秒并发量极其的大，此时有 100万 个请求发送过来（极少出现这种极端情况，但并不表示不存在），根据 goroutine-per-connection 模式服务端会为这些连接创建 100万 个 goroutine，每个goroutine表示一个请求连接。