Golang中的编译参数

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

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

环境变量

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

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

除了这里给出的这几个变量外，还有一些其它变量，如 GODEBUG、GOFLAGS、GOPROXY 等，所有支持环境变量都可以在  里找到，有兴趣的话可以看看他们的作用。

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

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

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 的情况

iptables 作为 Linux/Unix 下一款优秀的防火墙软件，在安全方面发挥着极其重要的作用，作为系统管理员来讲一点也不陌生。不过对于一些新手来说，复杂性是一个门槛，Linux厂商为了解决这个问题，于是推出了新的管理工具,如 Centos 下的 Firewalld 和 Ubuntu 下的ufw, 他们对新手十分友好，只需要几个很简单的命令即可实现想要的功能，再不也必为记不住iptables中的四表五键而烦恼了。 那么，是不是有了 firewalld 和 ufw就不需要iptables了呢？并不是的。

首先我们要清楚firewalld、ufw 与iptables的关系，可以理解为两者只是对iptables其进行了一层封装，它们在用户交互方面做了非常多的改进，使其对用户更加友好，不需要再记住原来那么多命令了。

而目前对于一些系统管理员来讲，大概率还是会直接使用 iptables，主要原因是灵活性，当然也有一定的历史原因。对比前面两个管理工具，他们也存在一定的问题，如只能对单条规则进行管理，详细参考相关文档。

另外对于 firewalld 还有图形界面。

除了这三个还有一个 netfilter 的东西，它又是什么呢？

firewalld/ufw 自身并不具备防火墙的功能，而是和 iptables 一样需要通过内核的 netfilter 来实现，也就是说 firewalld 和 iptables 一样，他们的作用都是用于维护规则，而真正使用规则干活的是内核的netfilter。所以iptables服务和firewalld服务都不是真正的防火墙，只是用来定义防火墙规则功能的管理工具，通过iptables将定义好的规则交给内核中的netfilter(网络过滤器来读取)从而实现真正的防火墙功能。不过由于用户一般操作的都是iptables，所以称其为

防火墙也并没有什么不妥的。

总结一下，Netfilter/Iptables 是Linux系统自带的防火墙，Iptables管理规则，Netfilter则是规则的执行者，它们一起实现Linux下安全防护。

以上就是他们四者的关系。

参考资料 https://www.cnblogs.com/kevingrace/p/6265113.html

在日常开发中经常会遇到有些镜像在 gcr.io 仓库，其仓库是google提供的，由于国内网络环境的复杂性是无法拉取到这些镜像的，这时候就需要我们想一些办法来实现拉取了。

这里给出了两种解决方法，一种是直接使用代理，这种可以直接拉取远程镜像到本地。另一种是通过中转的方法，先找一个可以直接拉取到镜像的网络，先将存储到本地，然后再转镜像上传到三方国内可以访问的镜像，如我们最常用镜像 https://hub.docker.com。

代理方式

使用代理方法的时候，如果通过直接设置 http_proxy 和 https_proxy 这两个环境变量是不可行的。如果是k8s环境的话，可能会使用到 containerd 运行时，这时可能还需要设置 crictl 配置，因此下面将分别介绍这个软件的配置方式。

如果k8s运行时，使用的是 Docker Engine ，则可以通过 docker 命令管理镜像；如果使用的是 containerd运行时，则需要通过 crictl 命令管理镜像。

不同运行时需要不同的管理客户端，因此下面我们将一下针对这两个软件配置的不同代理配置。

如果使用的是 containerd运行时，crictl 命令无法下载镜像的话，可能还需要配置一下 Docker 代理。

Docker 代理

主要原因是 docker 并不会使用它们，需要为 docker daemon 服务的设置代理才可以。

1. 设置docker服务代理

sudo mkdir -p /etc/systemd/system/docker.service.d/
sudo vim /etc/systemd/system/docker.service.d/http-proxy.conf

将以下内容写入 http-proxy.conf 文件

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
Environment="ALL_PROXY=socks5://127.0.0.1:7890"
Environment="NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp,.docker.io,.docker.com"

上面代理地址是本机开启的代理服务监听端口，如果代理服务在局域网内的其它机器上的话，需要更换为其 ip 地址和端口号。环境变量 NO_PROXY 表示不使用代理的域名或IP。

2. 重启 docker 服务

root@ubuntu:~# systemctl daemon-reload
root@ubuntu:~# systemctl restart docker

3. 验证设置

root@ubuntu:~# systemctl show --property=Environment docker
Environment=HTTP_PROXY=http://127.0.0.1:7890 HTTPS_PROXY=http://127.0.0.1:7890 ALL_PROXY=socks5://127.0.0.1:7890 NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp,.docker.io,.docker.com

也可以使用命令 docker info 验证

在k8s中的时间会提示证书过期问题，如

# kubectl get nodes
Unable to connect to the server: x509: certificate has expired or is not yet valid

这里我们介绍一下续期方法。

注意：当前集群通过 kubeadm 命令创建。

kubeadm 安装得证书默认为 1 年，注意原证书文件必须保留在服务器上才能做延期操作，否则就会重新生成，集群可能无法恢复。

准备

这里先查看一下测试集群的证书过期时间

# kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Aug 30, 2022 03:18 UTC   324d                                    no
apiserver                  Aug 30, 2022 03:18 UTC   324d            ca                      no
apiserver-etcd-client      Aug 30, 2022 03:18 UTC   324d            etcd-ca                 no
apiserver-kubelet-client   Aug 30, 2022 03:18 UTC   324d            ca                      no
controller-manager.conf    Aug 30, 2022 03:18 UTC   324d                                    no
etcd-healthcheck-client    Aug 30, 2022 03:18 UTC   324d            etcd-ca                 no
etcd-peer                  Aug 30, 2022 03:18 UTC   324d            etcd-ca                 no
etcd-server                Aug 30, 2022 03:18 UTC   324d            etcd-ca                 no
front-proxy-client         Aug 30, 2022 03:18 UTC   324d            front-proxy-ca          no
scheduler.conf             Aug 30, 2022 03:18 UTC   324d                                    no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Aug 28, 2031 03:18 UTC   9y              no
etcd-ca                 Aug 28, 2031 03:18 UTC   9y              no
front-proxy-ca          Aug 28, 2031 03:18 UTC   9y              no

可以看到过期时间为 2022-08-30。

建议参考官方文档 https://istio.io/latest/zh/docs/setup/install/virtual-machine/  ，这里提醒大家对于命令中文版部分命令与英文版不一致，请以 英文版 为准。

对于istio在vm上的安装教程主要分为三部分。首先是在k8s的master节点生成vm连接主节点的一些配置信息，其实是在vm上应用这些配置信息，最后也就是验证连接是否成功。

本篇主要介绍“单网络”的情况， 对于”多网络“请自行参考官方文档。

vm环境准备

生成vm通讯配置信息

这里主要介绍一些新手迷惑的部分。如环境变量设置及vm注册的方式

设置环境变量

在设置变量时，对于”单网络“来讲 CLUSTER_NETWORK 和 VM_NETWORK 保留空值即可。如我这里设置如下

$ VM_APP="myapp"
$ VM_NAMESPACE="vm"
$ WORK_DIR="/root/myapp"
$ SERVICE_ACCOUNT="vm-sa"
$ CLUSTER_NETWORK=""
$ VM_NETWORK=""
$ CLUSTER="Kubernetes"

每个环境变量的解释： VM_APP 表示vm上应用的名称 VM_NAMESPACE 表示应用所在的namespace WORK_DIR 生成vm配置信息保留的目录，任何位置即可 SERVICE_ACCOUNT 服务运行的账号 ，即yaml文件中的 ServiceAccount 字段 CLUSTER 集群名称，默认为 Kubernetes 即可。

安装 Istio 控制平面

1 为安装创建 IstioOperator 空间

cat <<EOF > ./vm-cluster.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    enableEnvoyAccessLogService: true
    defaultConfig.envoyAccessLogService.address: skywalking-oap.istio-system:11800
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: "${CLUSTER}"
      network: "${CLUSTER_NETWORK}"
EOF

spec.meshConfig.accessLogFile 表示启用日志功能，这样流量经过envoy 时将在日志 /var/log/istio/istio.log 中输出；其余三个是启用skywaling链路追踪服务所需要的配置，如果不启用将其删除即可；第四个是链路追踪服务的地址。如果仅仅是想输出日志没有启用流量追踪服务的话，则只配置前两项即可。

什么是 docker buildx

Docker Buildx是一个CLI插件，它扩展了Docker命令，完全支持Moby BuildKit builder toolkit提供的功能。它提供了与docker build相同的用户体验，并提供了许多新功能，如创建作用域生成器实例和针对多个节点并发构建。

Docker Buildx包含在Docker 19.03中，并与以下Docker Desktop版本捆绑在一起。请注意，必须启用“实验特性”选项才能使用Docker Buildx。

Docker Desktop Enterprise version 2.1.0 Docker Desktop Edge version 2.0.4.0 or higher

用法

Usage:  docker buildx [OPTIONS] COMMAND

Extended build capabilities with BuildKit

Options:
      --builder string   Override the configured builder instance

Management Commands:
  imagetools  Commands to work on images in registry

Commands:
  bake        Build from a file
  build       Start a build
  create      Create a new builder instance
  du          Disk usage
  inspect     Inspect current builder instance
  ls          List builder instances
  prune       Remove build cache
  rm          Remove a builder instance
  stop        Stop builder instance
  use         Set the current builder instance
  version     Show buildx version information

Run 'docker buildx COMMAND --help' for more information on a command

一般用到 create、ls 和 rm 就可以了

在使用kubenetes的过程中，如何将服务开放到集群外部访问是一个重要的问题。当使用云平台（阿里云、腾讯云、AWS等）的容器服务时，我们可以通过配置 service 为 LoadBalancer 模式来绑定云平台的负载均衡器，从而实现外网的访问。但是，如果对于自建的 kubernetes裸机集群，这个问题则要麻烦的多。

祼机集群不支持负载均衡的方式，可用的不外乎NodePort、HostNetwork、ExternalIPs等方式来实现外部访问。但这些方式并不完美，他们或多或少都存在的一些缺点，这使得裸机集群成为Kubernetes生态系统中的二等公民。

MetalLB 旨在通过提供与标准网络设备集成的Network LB实施来解决这个痛点，从而使裸机群集上的外部服务也尽可能“正常运行”，减少运维上的管理成本。它是一种纯软件的解决方案，参考 https://kubernetes.github.io/ingress-nginx/deploy/baremetal/。

从 v0.13.0 版本开始，官方对解决方案进行了部分调整，操作步骤简洁一些，建议使用最新版本，参考官方教程 https://metallb.universe.tf/installation/

部署

1. 创建namespace

$ kubectl create namespace metallb-system

2. 新建 secret

$ kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

参数 from 前面是两个-

3. 部署

root@sxf-virtual-machine:~# kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
podsecuritypolicy.policy/controller created
podsecuritypolicy.policy/speaker created
serviceaccount/controller created
serviceaccount/speaker created
clusterrole.rbac.authorization.k8s.io/metallb-system:controller created
clusterrole.rbac.authorization.k8s.io/metallb-system:speaker created
role.rbac.authorization.k8s.io/config-watcher created
role.rbac.authorization.k8s.io/pod-lister created
role.rbac.authorization.k8s.io/controller created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:controller created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:speaker created
rolebinding.rbac.authorization.k8s.io/config-watcher created
rolebinding.rbac.authorization.k8s.io/pod-lister created
rolebinding.rbac.authorization.k8s.io/controller created
daemonset.apps/speaker created
deployment.apps/controller created

查看部署结果

使用服务入口（Service Entry） 来添加一个服务入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样，可参考 https://istio.io/latest/zh/docs/concepts/traffic-management/#service-entries。

简单的理解就是允许内网向外网服务发送流量请求，但你可能会说正常情况下在pod里也是可以访问外网的，这两者有什么区别呢?

确实默认情况下，Istio 配置 Envoy 代理可以将请求传递给外部服务。但是无法使用 Istio 的特性来控制没有在网格中注册的目标流量。这也正是 ServiceEntry 真正发挥的作用，通过配置服务入口允许您管理运行在网格外的服务的流量。

此外，可以配置虚拟服务和目标规则，以更精细的方式控制到服务条目的流量，就像为网格中的其他任何服务配置流量一样。

为了更好的理解这一块的内容，我们先看一下普通POD发送请求的流程图普通 Pod 请求

创建 ServiceEntry 资源

举例来说：

svc-entry.yaml

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - "www.baidu.com"
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

该 ServiceEntry 资源定义了一个外部网站 www.baidu.com 服务，并将它纳入到 Istio 内部维护的服务注册表（服务网格）中。

创建资源

$ kubectl apply -f svc-entry.yaml
serviceentry.networking.istio.io/svc-entry created

现在我们已经创建了一个 ServiceEntry, 默认在 default 命名空间。

root@vm:/home/sxf/service-entry# kubectl get se
NAMESPACE   NAME        HOSTS               LOCATION        RESOLUTION   AGE
default     svc-entry   ["www.baidu.com"]   MESH_EXTERNAL   DNS          13s

为了测试这个效果，我们再创建一个pod，然后在pod里访问上面创建的 ServiceEntry。

环境 ubuntu18.04 64位

Kubernetes v1.21.3

这里需要注意，本教程安装的k8s版本号 <- v1.24.0，主要是因为从v1.24.0以后移除了 Dockershim，无法继续使用 Docker Engine，后续将默认采用 containerd ，它是一个从 CNCF 毕业的项目。如果仍想使用原来 Docker Engine 的方式可以安装  cri-dockerd ，它是 Dockershim 的替代品。

如果你想将现在 Docker Engine 的容器更换为 containerd，可以参考官方迁移教程 将节点上的容器运行时从 Docker Engine 改为 containerd

为了解决国内访问一些国外网站慢的问题，本文使用了国内阿里云的镜像。

更换apt包源

这里使用aliyun镜像 , 为了安全起见，建议备份原来系统默认的 /etc/apt/sources.list 文件

编辑文件 /etc/apt/sources.list，将默认网址  或  替换为

更新缓存

$ sudo apt-get clean all
$ sudo apt-get update

安装Docker

参考官方文档  或 aliyun 文档

安装 docker

1. 安装基础工具

$ sudo apt update
$ sudo apt-get install
    apt-transport-https
    ca-certificates
    curl
    gnupg
    lsb-release

2. 安装GPG证书

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

3: 写入软件源信息

• The SPIFFE Workload API

• Envoy spiffe spire

• 简而言之SPIFFE

• SPIFFE信任域

• 使用SPIRE（自动）提供TLS证书给Envoy以进行更强大的身份验证

• 谁使用SPIFFE？

• Securing the Service Mesh with SPIRE 0.3

在runtime中有 [runtime.LockOSThread](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L4248-L4278) 和 [runtime.UnlockOSThread](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L4302-L4323) 两个函数，这两个函数有什么作用呢？我们看一下标准库中对它们的解释。

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 独占 一个系统线程）；

无锁队列是 lock-free 中最基本的数据结构，一般应用在需要一款高性能队列的场景下。

对于多线程用户来说，无锁队列的入队和出队操作是线程安全的，不用再加锁控制

什么是无锁队列

队列每个开发者都知道，那么什么又是无锁队列呢？字面理解起来就是一个无锁状态的队列，多个线程（消费者）同时操作数据的时候不需要加锁，因为加/解锁都是一个很消耗资源的动作。

实现原理

我们先看一下无锁队列的底层实现数据结构。

数据结构

无锁队列底层的数据结构实现方式主要有两种：数组 和 链接。

数组

在首次初始化时，需要申请一块连接的大的内存。读写数据直接从数据的指定位置操作即可，时间复杂度为O(1)。

缺点：数组长度有限，一旦数组索引位置写满，则无法继续写入，即队列有上限。

链表

不用像数组一样，刚开始就申请一块连接的大的内存空间。只有在每次写时数据的时候，申请这个数据节点大小的内存即可，这样就可以实现无限的写入，没有长度限制问题。

缺点：每次写数据都要申请内存，在写的场景，最差的情况是多少个数据就申请多少次内存，而每次申请都是一个消耗资源的动作。

可以看到无锁底层的实现的不同各有优势。多数据情况下，我们都采用链表来实现无锁队列，主要原因就是写入可以没有长度的限制。相比每次申请都要费时来说，满足前面的条件是我们最基本的要求。当然主要还是真正的使用场景。

CAS

CAS 是 Compare And Swap 的简称, 属于 乐观锁，这是一个并发同步原语. 伪代码如下:

bool compare_and_swap(int *reg, int oldval, int newval)
{
    int reg_val = *reg;
    if(reg_val == oldval)
    {
        *reg = newval;
        return true;
    }
    return false;
}

CAS操作有三个参数，分别表示 内存值V、旧的预期值A 和 修改后的更新值B。

判断变量内存某个位置的值是否为预期值，如果是则更改为新的值，并返回true，这个过程是原子性操作。如果修改失败，可能需要重试再次执行CAS操作，直到修改成功，一般称此过程为自旋。可以看到每次调用 CAS 命令前需要先读取旧值 oldval。

现在几乎所有的CPU指令都支持CAS的原子操作，X86下对应的是 CMPXCHG 汇编指令。有了这个操作，我们就可以用其来实现各种无锁的数据结构。

使用场景

无锁队列也属于队列的一种，所以大部分队列的使用场景都可以使用它来代替其它有锁队列,无锁队列通过不加锁的方式提高队列性能。

参考资料

• https://zhuanlan.zhihu.com/p/336912752
• 无锁队列是否不适用于大容量应用场景？
• https://www.dazhuanlan.com/2019/12/16/5df6622b4f46b/
• https://blog.codingnow.com/2014/12/skynet_spinlock.html
• https://blog.csdn.net/yishizuofei/article/details/78353722
• 一文彻底搞懂CAS实现原理 & 深入到CPU指令
• 无锁队列的分析与设计
• Golang中的CAS原子操作 和 锁

上一节《 GC 对根对象扫描实现的源码分析》中，我们提到过在GC的时候，在对一些goroutine 栈进行扫描时，会在其扫描前触发 G 的暂停([suspendG](https://github.com/golang/go/blob/go1.16.2/src/runtime/preempt.go#L76-L254))和恢复([resumeG](https://github.com/golang/go/blob/go1.16.2/src/runtime/preempt.go#L256-L280))。

// markroot scans the i'th root.
//
// Preemption must be disabled (because this uses a gcWork).
//
// nowritebarrier is only advisory here.
//
//go:nowritebarrier
func markroot(gcw *gcWork, i uint32) {
	baseFlushCache := uint32(fixedRootCount)
	baseData := baseFlushCache + uint32(work.nFlushCacheRoots)
	baseBSS := baseData + uint32(work.nDataRoots)
	baseSpans := baseBSS + uint32(work.nBSSRoots)
	baseStacks := baseSpans + uint32(work.nSpanRoots)
	end := baseStacks + uint32(work.nStackRoots)

	// Note: if you add a case here, please also update heapdump.go:dumproots.
	switch {
		......

	default:
		var gp *g
		if baseStacks <= i && i < end {
			gp = allgs[i-baseStacks]
		} else {
			throw("markroot: bad index")
		}

		status := readgstatus(gp) // We are not in a scan state
		if (status == _Gwaiting || status == _Gsyscall) && gp.waitsince == 0 {
			gp.waitsince = work.tstart
		}

		// scanstack must be done on the system stack in case
		// we're trying to scan our own stack.
		systemstack(func() {
			userG := getg().m.curg
			selfScan := gp == userG && readgstatus(userG) == _Grunning
			if selfScan {
				casgstatus(userG, _Grunning, _Gwaiting)
				userG.waitreason = waitReasonGarbageCollectionScan
			}

			// TODO: suspendG blocks (and spins) until gp
			// stops, which may take a while for
			// running goroutines. Consider doing this in
			// two phases where the first is non-blocking:
			// we scan the stacks we can and ask running
			// goroutines to scan themselves; and the
			// second blocks.
			stopped := suspendG(gp)
			if stopped.dead {
				gp.gcscandone = true
				return
			}
			if gp.gcscandone {
				throw("g already scanned")
			}
			scanstack(gp, gcw)
			gp.gcscandone = true
			resumeG(stopped)

			if selfScan {
				casgstatus(userG, _Gwaiting, _Grunning)
			}
		})
	}
}

那么它在暂停和恢复一个goroutine时都做了些什么工作呢，今天我们通过源码来详细看一下。 go version 1.16.2

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

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

stackLarge：对应 > 32K 的 stack

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

当我们执行一个 go func() 语句的时候，runtime 会通过调用 newproc() 函数来创建G。而内部真正创建G的函数为 [newproc1()](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L3990-L4098)，在没有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()](https://github.com/golang/go/blob/go1.16.3/src/runtime/stack.go#L321-L419) 函数为其分配 stacksize 大小stack，那么分配操作它又是如何工作的呢？

现状

目前在网络编程中，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))
}

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