在日常开发中经常会遇到有些镜像在 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))
}

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

Linux 内核仓库 https://github.com/torvalds/linux

Linux 内核文档： https://www.kernel.org/doc/html/latest/index.html（ 中文）

开发工具参考： https://www.kernel.org/doc/html/latest/dev-tools/index.html

也可以使用 VSCode + 插件C/C++ GNU Global

通过前面三个博客可以得知 select，** poll， eventpoll** 的详细实现，现在来总结对比下它们之间的不同:

1. select 流程图
2. poll 流程图
3. eventpoll 流程图
4. 优缺点总结 <1> 监控文件最大数不同：select和poll都是以数组形式传入药监控的文件句柄，而这个数组是有大小限制的1024个左右(不是很清楚).而epoll则是每add一个文件句柄会new一个新epi出来，挂载在ep的红黑树中，监控的文件个数没有明确限制(可能会受限于系统最大打开文件句柄数)从这点上看，epoll是优于select和poll. <2> copy参数次数不同：无论是select/poll/epoll都是有对应的系统调用，其参数都会从userspace拷贝到kernelspace,如果监控的文件句柄数很大，select/poll在这方面的耗时会明显多于epoll,因为每次调用select/poll都要重新拷贝一次所有的监控句柄，而epoll则在sys_epoll_ctrl的时候添加一次存储在内核数据结构中，后续的sys_epoll_wait会通过内核数据找到监控的文件句柄对应的file和监控得到的event. <3> 轮询方式的差异：select 会传入监控句柄的最大句柄，从而监控查询0 ~~ max_fd之间的所有file的驱动状态来获取想要的文件句柄中想要的event，而poll则只会轮询用户传入的文件句柄集，相比select会少轮询很多file的状态，这点上poll明显优于select.而epoll则是完全异步的方式，哪个有更新会添加到ep->rdlist中,epoll_wait来取走.当连接数不是很多且每个client都非常活跃的情况下,poll > select > epoll,而当连接数巨大且大多数client都是潜水状态的情况下，epoll > poll > select。

本文摘自： https://blog.csdn.net/weixin_38537730/article/details/104100468

上一节 《Runtime: Golang 之 sync.Pool 源码分析》 我们介绍了sync.Pool 的源码分析，本节介绍一个 fasthttp 中引用的一缓存池库 [bytebufferpool](https://github.com/valyala/bytebufferpool)，这两个库是同一个开发者。对于这个缓存池库与同类型的几个库的对比，可以参考 https://omgnull.github.io/go-benchmark/buffer/。

建议大家了解一下[fasthttp](https://github.com/valyala/fasthttp) 这个库，性能要比直接使用内置的 net/http 高出很多，其主要原因是大量的用到了缓存池 sync.Pool 进行性能提升。

用法

// https://github.com/valyala/bytebufferpool/blob/18533face0/bytebuffer_example_test.go
package bytebufferpool_test

import (
	"fmt"

	"github.com/valyala/bytebufferpool"
)

func ExampleByteBuffer() {
	// 从缓存池取 Get()
	bb := bytebufferpool.Get()

	// 用法
	bb.WriteString("first linen")
	bb.Write([]byte("second linen"))
	bb.B = append(bb.B, "third linen"...)

	fmt.Printf("bytebuffer contents=%q", bb.B)

	// 使用完毕，放回缓存池 Put()
	// It is safe to release byte buffer now, since it is no longer used.
	bytebufferpool.Put(bb)
}

全局变量

我们先看一下与其相关的一些常量