"\u003cp\u003eGolang中的编译参数\u003c/p\u003e\n\u003cp\u003e开发中经常使用 \u003ccode\u003ego build\u003c/code\u003e 命令来编译我们的程序源码，然后将生成二进制文件直接部署，极其方便。\u003c/p\u003e\n\u003cp\u003e对于 \u003ccode\u003ego build\u003c/code\u003e 有一些参数，对于针对程序源码进行一些编译优化，下面我们对经常使用的一些参数来介绍一下。\u003c/p\u003e\n\u003ch1 id=\"环境变量\"\u003e环境变量\u003c/h1\u003e\n\u003cp\u003e环境变量需要在go命令前面设置，如果多个变量的话，中间需要用“空格”分隔。下面我们介绍一个非常常见到的一些环境变量\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e$ CGO_ENABLED=1 GOARCH=amd64 GOOS=linux go build -o myserver main.go\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e除了这里给出的这几个变量外，还有一些其它变量，如 GODEBUG、GOFLAGS、GOPROXY 等，所有支持环境变量都可以在  里找到，有兴趣的话可以看看他们的作用。\u003c/p\u003e\n\u003cp\u003e这里重点介绍一下 \u003ccode\u003eCGO_ENABLED\u003c/code\u003e 环境变量对我们程序的影响。 \u003ccode\u003eCGO_ENABLED\u003c/code\u003e是用来控制golang 编译期间是否支持调用 cgo 命令的开关，其值为1或0，默认情况下值为1，可以用 \u003ccode\u003ego env\u003c/code\u003e 查看默认值。\u003c/p\u003e\n\u003cp\u003e如果你的程序里调用了cgo 命令，此参数必须设置为1,否则将编译时出错。这里直接用文档  中的一个例 …\u003c/p\u003e"

"\u003cp\u003eiptables 作为 Linux/Unix 下一款优秀的防火墙软件，在安全方面发挥着极其重要的作用，作为系统管理员来讲一点也不陌生。不过对于一些新手来说，复杂性是一个门槛，Linux厂商为了解决这个问题，于是推出了新的管理工具,如 Centos 下的 Firewalld 和 Ubuntu 下的ufw, 他们对新手十分友好，只需要几个很简单的命令即可实现想要的功能，再不也必为记不住iptables中的四表五键而烦恼了。\n那么，是不是有了 firewalld 和 ufw就不需要iptables了呢？并不是的。\u003c/p\u003e\n\u003cp\u003e首先我们要清楚firewalld、ufw 与iptables的关系，可以理解为两者只是对iptables其进行了一层封装，它们在用户交互方面做了非常多的改进，使其对用户更加友好，不需要再记住原来那么多命令了。\u003c/p\u003e\n\u003cp\u003e而目前对于一些系统管理员来讲，大概率还是会直接使用 iptables，主要原因是灵活性，当然也有一定的历史原因。对比前面两个管理工具，他们也存在一定的问题，如只能对单条规则进行管理，详细参考相关文档。\u003c/p\u003e\n\u003cp\u003e另外对于 firewalld 还有图形界面。 …\u003c/p\u003e"

"\u003cp\u003e在日常开发中经常会遇到有些镜像在 gcr.io 仓库，其仓库是google提供的，由于国内网络环境的复杂性是无法拉取到这些镜像的，这时候就需要我们想一些办法来实现拉取了。\u003c/p\u003e\n\u003cp\u003e这里给出了两种解决方法，一种是直接使用代理，这种可以直接拉取远程镜像到本地。另一种是通过中转的方法，先找一个可以直接拉取到镜像的网络，先将存储到本地，然后再转镜像上传到三方国内可以访问的镜像，如我们最常用镜像 \u003ca href=\"https://hub.docker.com\"\u003ehttps://hub.docker.com\u003c/a\u003e。\u003c/p\u003e\n\u003ch1 id=\"代理方式\"\u003e代理方式\u003c/h1\u003e\n\u003cp\u003e使用代理方法的时候，如果通过直接设置 http_proxy 和 https_proxy 这两个环境变量是不可行的。如果是k8s环境的话，可能会使用到 \u003ccode\u003econtainerd\u003c/code\u003e 运行时，这时可能还需要设置 \u003ccode\u003ecrictl\u003c/code\u003e 配置，因此下面将分别介绍这个软件的配置方式。\u003c/p\u003e\n\u003cp\u003e如果k8s运行时，使用的是 Docker Engine ，则可以通过 docker 命令管理镜像；如果使用的是 \u003ccode\u003econtainerd\u003c/code\u003e运行时，则需要通过 \u003ccode\u003ecrictl\u003c/code\u003e 命令管理镜像。\u003c/p\u003e\n\u003cp\u003e不同运行时需要不同的管理客户端，因此下面我们将一下针对这两个软件配置的不同代理配置。 …\u003c/p\u003e"

"\u003cp\u003e在k8s中的时间会提示证书过期问题，如\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e# kubectl get nodes\nUnable to connect to the server: x509: certificate has expired or is not yet valid\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e这里我们介绍一下续期方法。\u003c/p\u003e\n\u003cp\u003e注意：当前集群通过 kubeadm 命令创建。\u003c/p\u003e\n\u003cp\u003ekubeadm 安装得证书默认为 1 年，\u003cstrong\u003e注意原证书文件必须保留在服务器上才能做延期操作，否则就会重新生成，集群可能无法恢复\u003c/strong\u003e。\u003c/p\u003e\n\u003ch1 id=\"准备\"\u003e准备\u003c/h1\u003e\n\u003cp\u003e这里先查看一下测试集群的证书过期时间\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e# kubeadm certs check-expiration\n[check-expiration] Reading configuration from the cluster...\n[check-expiration] FYI: You can look at this config file with \u0026#39;kubectl -n kube-system get cm kubeadm-config -o yaml\u0026#39;\n\nCERTIFICATE …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e建议参考官方文档 https://istio.io/latest/zh/docs/setup/install/virtual-machine/  ，这里提醒大家对于命令中文版部分命令与英文版不一致，请以 \u003cstrong\u003e英文版\u003c/strong\u003e 为准。\u003c/p\u003e\n\u003cp\u003e对于istio在vm上的安装教程主要分为三部分。首先是在k8s的master节点生成vm连接主节点的一些配置信息，其实是在vm上应用这些配置信息，最后也就是验证连接是否成功。\u003c/p\u003e\n\u003cp\u003e本篇主要介绍“单网络”的情况， 对于”多网络“请自行参考官方文档。\u003c/p\u003e\n\u003ch1 id=\"vm环境准备\"\u003evm环境准备\u003c/h1\u003e\n\u003ch2 id=\"生成vm通讯配置信息\"\u003e生成vm通讯配置信息\u003c/h2\u003e\n\u003cp\u003e这里主要介绍一些新手迷惑的部分。如环境变量设置及vm注册的方式\u003c/p\u003e\n\u003ch3 id=\"设置环境变量\"\u003e设置环境变量\u003c/h3\u003e\n\u003cp\u003e在设置变量时，对于”单网络“来讲 CLUSTER_NETWORK 和 VM_NETWORK 保留空值即可。如我这里设置如下\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\"\u003e\u003ccode class=\"language-shell\" data-lang=\"shell\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e$ VM_APP\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;myapp\u0026#34;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e$ VM_NAMESPACE\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;vm\u0026#34;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e$ WORK_DIR\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;/root/myapp\u0026#34;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e$ SERVICE_ACCOUNT\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;vm-sa\u0026#34;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e$ CLUSTER_NETWORK\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;\u0026#34; …\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e"

"\u003ch1 id=\"什么是-docker-buildx\"\u003e什么是 docker buildx\u003c/h1\u003e\n\u003cp\u003eDocker Buildx是一个CLI插件，它扩展了Docker命令，完全支持Moby BuildKit builder toolkit提供的功能。它提供了与docker build相同的用户体验，并提供了许多新功能，如创建作用域生成器实例和针对多个节点并发构建。\u003c/p\u003e\n\u003cp\u003eDocker Buildx包含在Docker 19.03中，并与以下Docker Desktop版本捆绑在一起。请注意，必须启用“实验特性”选项才能使用Docker Buildx。\u003c/p\u003e\n\u003cp\u003eDocker Desktop Enterprise version 2.1.0\nDocker Desktop Edge version 2.0.4.0 or higher\u003c/p\u003e\n\u003ch1 id=\"用法\"\u003e用法\u003c/h1\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eUsage: docker buildx [OPTIONS] COMMAND\n\nExtended build capabilities with BuildKit\n\nOptions:\n --builder string Override the configured builder instance …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e在使用kubenetes的过程中，如何将服务开放到集群外部访问是一个重要的问题。当使用云平台（阿里云、腾讯云、AWS等）的容器服务时，我们可以通过配置 service 为 \u003cstrong\u003eLoadBalancer\u003c/strong\u003e 模式来绑定云平台的负载均衡器，从而实现外网的访问。但是，如果对于自建的 kubernetes裸机集群，这个问题则要麻烦的多。\u003c/p\u003e\n\u003cp\u003e祼机集群不支持负载均衡的方式，可用的不外乎NodePort、HostNetwork、ExternalIPs等方式来实现外部访问。但这些方式并不完美，他们或多或少都存在的一些缺点，这使得裸机集群成为Kubernetes生态系统中的二等公民。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/metallb/metallb\"\u003eMetalLB\u003c/a\u003e 旨在通过提供与标准网络设备集成的Network LB实施来解决这个痛点，从而使裸机群集上的外部服务也尽可能“正常运行”，减少运维上的管理成本。它是一种纯软件的解决方案，参考 \u003ca href=\"https://kubernetes.github.io/ingress-nginx/deploy/baremetal/\"\u003ehttps://kubernetes.github.io/ingress-nginx/deploy/baremetal/\u003c/a\u003e。\u003c/p\u003e\n\u003cp\u003e从 v0.13.0 版本开始，官方对解决方案进行了部分调整，操作步骤简洁一些，建议使用最新版本， …\u003c/p\u003e"

"\u003cp\u003e使用服务入口（Service Entry） 来添加一个服务入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样，可参考 \u003ca href=\"https://istio.io/latest/zh/docs/concepts/traffic-management/#service-entries\"\u003ehttps://istio.io/latest/zh/docs/concepts/traffic-management/#service-entries\u003c/a\u003e。\u003c/p\u003e\n\u003cp\u003e简单的理解就是允许内网向外网服务发送流量请求，但你可能会说正常情况下在pod里也是可以访问外网的，这两者有什么区别呢?\u003c/p\u003e\n\u003cp\u003e确实默认情况下，Istio 配置 Envoy 代理可以将请求传递给外部服务。但是无法使用 Istio 的特性来控制没有在网格中注册的目标流量。这也正是 ServiceEntry 真正发挥的作用，通过配置服务入口允许您管理运行在网格外的服务的流量。\u003c/p\u003e\n\u003cp\u003e此外，可以配置虚拟服务和目标规则，以更精细的方式控制到服务条目的流量，就像为网格中的其他任何服务配置流量一样。\u003c/p\u003e\n\u003cp\u003e为了更好的理解这一块的内容，我们先看一下普通POD发送请求的流程图\u003cimg src=\"https://blogstatic.haohtml.com/uploads/2021/08/d2b5ca33bd970f64a6301fa75ae2eb22.png\" alt=\"\"\u003e普通 Pod 请求\u003c/p\u003e\n\u003ch1 id=\"创建-serviceentry-资源\"\u003e创建 ServiceEntry 资源\u003c/h1\u003e\n\u003cp\u003e举例来说：\u003c/p\u003e\n\u003cp\u003esvc-entry.yaml …\u003c/p\u003e"

"\u003cp\u003e环境 ubuntu18.04 64位\u003c/p\u003e\n\u003cp\u003eKubernetes v1.21.3\u003c/p\u003e\n\u003cp\u003e这里需要注意，本教程安装的k8s版本号 \u003ccode\u003e\u0026lt;- v1.24.0\u003c/code\u003e，主要是因为从v1.24.0以后移除了 \u003ccode\u003eDockershim\u003c/code\u003e，无法继续使用 \u003ccode\u003eDocker Engine\u003c/code\u003e，后续将默认采用 \u003ca href=\"https://containerd.io/\"\u003econtainerd\u003c/a\u003e ，它是一个从 CNCF 毕业的项目。如果仍想使用原来 \u003ccode\u003eDocker Engine\u003c/code\u003e 的方式可以安装  \u003ca href=\"https://github.com/Mirantis/cri-dockerd\"\u003ecri-dockerd\u003c/a\u003e ，它是 Dockershim 的替代品。\u003c/p\u003e\n\u003cp\u003e如果你想将现在 Docker Engine 的容器更换为 \u003ccode\u003econtainerd\u003c/code\u003e，可以参考官方迁移教程 \u003ca href=\"https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/\"\u003e将节点上的容器运行时从 Docker Engine 改为 containerd\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e为了解决国内访问一些国外网站慢的问题，本文使用了国内阿里云的镜像。\u003c/p\u003e\n\u003ch1 id=\"更换apt包源\"\u003e更换apt包源\u003c/h1\u003e\n\u003cp\u003e这里使用aliyun镜像 , 为了安全起见，建议备份原来系统默认的 /etc/apt/sources.list 文件\u003c/p\u003e\n\u003cp\u003e编辑文件 /etc/apt/sources.list，将默认网址  或  替换为\u003c/p\u003e\n\u003cp\u003e更新缓存\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e$ sudo apt-get clean all\n$ sudo …\u003c/code\u003e\u003c/pre\u003e"

"\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md\"\u003eThe SPIFFE Workload API\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.scriptjc.com/article/1097\"\u003eEnvoy spiffe spire\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://blog.csdn.net/dnc8371/article/details/106701159\"\u003e简而言之SPIFFE\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://cloud.tencent.com/developer/article/1549231\"\u003eSPIFFE信任域\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://segmentfault.com/a/1190000018432444\"\u003e使用SPIRE（自动）提供TLS证书给Envoy以进行更强大的身份验证\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://segmentfault.com/a/1190000017881797\"\u003e谁使用SPIFFE？\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://blog.envoyproxy.io/securing-the-service-mesh-with-spire-0-3-abb45cd79810\"\u003eSecuring the Service Mesh with SPIRE 0.3\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"

"\u003cp\u003e在runtime中有 \u003ccode\u003e[runtime.LockOSThread](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L4248-L4278)\u003c/code\u003e 和 \u003ccode\u003e[runtime.UnlockOSThread](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L4302-L4323)\u003c/code\u003e 两个函数，这两个函数有什么作用呢？我们看一下标准库中对它们的解释。\u003c/p\u003e\n\u003ch2 id=\"runtimelockosthread\"\u003eruntime.LockOSThread\u003c/h2\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e// LockOSThread wires the calling goroutine to its current operating system thread.\n// The calling goroutine will always execute in that thread,\n// and no other goroutine will execute in it,\n// until the calling goroutine has made …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003ccode\u003e无锁队列\u003c/code\u003e是 \u003ccode\u003elock-free\u003c/code\u003e 中最基本的数据结构，一般应用在需要一款高性能队列的场景下。\u003c/p\u003e\n\u003cp\u003e对于多线程用户来说，无锁队列的入队和出队操作是线程安全的，不用再加锁控制\u003c/p\u003e\n\u003ch1 id=\"什么是无锁队列\"\u003e什么是无锁队列\u003c/h1\u003e\n\u003cp\u003e队列每个开发者都知道，那么什么又是无锁队列呢？字面理解起来就是一个无锁状态的队列，\u003ccode\u003e多个线程（消费者）\u003c/code\u003e同时操作数据的时候不需要加锁，因为加/解锁都是一个很消耗资源的动作。\u003c/p\u003e\n\u003ch1 id=\"实现原理\"\u003e实现原理\u003c/h1\u003e\n\u003cp\u003e我们先看一下无锁队列的底层实现数据结构。\u003c/p\u003e\n\u003ch2 id=\"数据结构\"\u003e数据结构\u003c/h2\u003e\n\u003cp\u003e无锁队列底层的数据结构实现方式主要有两种：\u003ccode\u003e数组\u003c/code\u003e 和 \u003ccode\u003e链接\u003c/code\u003e。\u003c/p\u003e\n\u003ch3 id=\"数组\"\u003e数组\u003c/h3\u003e\n\u003cp\u003e在首次初始化时，需要申请\u003ccode\u003e一块连接\u003c/code\u003e的\u003ccode\u003e大\u003c/code\u003e的内存。读写数据直接从数据的指定位置操作即可，时间复杂度为O(1)。\u003c/p\u003e\n\u003cp\u003e缺点：数组长度有限，一旦数组索引位置写满，则无法继续写入，即队列有上限。\u003c/p\u003e\n\u003ch3 id=\"链表\"\u003e链表\u003c/h3\u003e\n\u003cp\u003e不用像数组一样，刚开始就申请一块连接的大的内存空间。只有在每次写时数据的时候，申请这个数据节点大小的内存即可，这样就可以实现无限的写入，没有长度限制问题。\u003c/p\u003e\n\u003cp\u003e缺点：每次写数据都要申请内存，在写的场景，最差的情况是多少个数据就申请多少次内存，而每次申请都是一个消耗资源的动作。\u003c/p\u003e\n\u003cp\u003e可以看到无锁底层的实现的不同各有优势。多数据情况下，我们都采 …\u003c/p\u003e"

"\u003cp\u003e上一节《 \u003ca href=\"https://blog.haohtml.com/archives/27003\"\u003eGC 对根对象扫描实现的源码分析\u003c/a\u003e》中，我们提到过在GC的时候，在对一些goroutine 栈进行扫描时，会在其扫描前触发 G 的暂停(\u003ccode\u003e[suspendG](https://github.com/golang/go/blob/go1.16.2/src/runtime/preempt.go#L76-L254)\u003c/code\u003e)和恢复(\u003ccode\u003e[resumeG](https://github.com/golang/go/blob/go1.16.2/src/runtime/preempt.go#L256-L280)\u003c/code\u003e)。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e// markroot scans the i\u0026#39;th root.\n//\n// Preemption must be disabled (because this uses a gcWork).\n//\n// nowritebarrier is only advisory here.\n//\n//go:nowritebarrier\nfunc markroot(gcw *gcWork, i uint32) {\n\tbaseFlushCache := uint32(fixedRootCount) …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e对于提高对 stack 的使用效率，避免重复从heap中分配与释放，对其使用了 \u003ccode\u003epool\u003c/code\u003e 的概念，\u003ccode\u003eruntime\u003c/code\u003e 里为共提供了两个pool, 分别为 \u003ccode\u003estackpool\u003c/code\u003e ，另一个为 \u003ccode\u003estackLarge\u003c/code\u003e。\u003cimg src=\"https://blogstatic.haohtml.com/uploads/2022/05/b33bde90901d27dd591e65c12e007fa2.png\" alt=\"\"\u003estack pool\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003estackpool\u003c/code\u003e: 16b~32k 对应通用的大小的stack。获取时通过调用 \u003ccode\u003estackpoolalloc()\u003c/code\u003e, 释放时调用 \u003ccode\u003estackpoolfree()\u003c/code\u003e。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003estackLarge\u003c/code\u003e：对应 \u0026gt; 32K 的 stack\u003c/p\u003e\n\u003cp\u003e在程序全局调度器 \u003ca href=\"https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L634\"\u003e初始化\u003c/a\u003e 时会通过调用 \u003ccode\u003estackinit()\u003c/code\u003e 实现对 \u003ccode\u003estack\u003c/code\u003e 初始化。\u003c/p\u003e\n\u003cp\u003e当我们执行一个 \u003ccode\u003ego func()\u003c/code\u003e 语句的时候，\u003ccode\u003eruntime\u003c/code\u003e 会通过调用 \u003ccode\u003enewproc()\u003c/code\u003e 函数来创建G。而内部真正创建G的函数为 \u003ccode\u003e[newproc1()](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L3990-L4098)\u003c/code\u003e，在没有G可以复用的情况下，会通过 \u003ccode\u003enewg = malg(_StackMin)\u003c/code\u003e 语句创建一个\u003cstrong\u003e包含stack\u003c/strong\u003e的G。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e// Allocate a …\u003c/code\u003e\u003c/pre\u003e"

"\u003ch2 id=\"现状\"\u003e现状\u003c/h2\u003e\n\u003cp\u003e目前在网络编程中，golang采用的是一种 \u003ccode\u003egoroutine-per-connection\u003c/code\u003e 的模式，即为每一个连接都分配一个goroutine，一个连接就是一个goroutine，多个连接之间没有关系。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003epackage main\n\nimport (\n\t\u0026#34;fmt\u0026#34;\n\t\u0026#34;io/ioutil\u0026#34;\n\t\u0026#34;net\u0026#34;\n\t\u0026#34;time\u0026#34;\n)\n\n//模拟server端\nfunc main() {\n\ttcpServer, _ := net.ResolveTCPAddr(\u0026#34;tcp4\u0026#34;, \u0026#34;:8080\u0026#34;)\n\tlistener, _ := net.ListenTCP(\u0026#34;tcp\u0026#34;, tcpServer)\n\n\tfor {\n\t\t//当有新客户端请求时拿到与客户端的连接\n\t\tconn, err := listener.Accept()\n\t\tif err != nil {\n\t\t\tfmt.Println(err)\n\t\t\tcontinue\n\t\t}\n\n\t\t// …\u003c/code\u003e\u003c/pre\u003e"