这样有一个严重的问题，就是垃圾回收器进行 STW 时，如果有一个 Goroutine 一直都在阻塞调用，垃圾回收器就会一直等待他，不知道等到什么时候…但万一代码是在运行了好一段时间后又能够运行了（业务上也允许长等待），也就是该 Goroutine 从阻塞状态中恢复了，期望继续运行，没了 P 怎么办？这个例子在老版本（1.14版本之前）的 Go 语言中，就会一直阻塞，没法重见天日，是一个需要做抢占的

如果在同一个协程内边遍历边删除，并不会检测到同时读写，理论上是可以这样做的。但是，遍历的结果就可能不会是相同的了，有可能结果遍历结果集中包含了删除的 key，也有可能不包含，这取决于删除 key 的时间：是在遍历到 key 所在的 bucket 时刻前或者后。读之前调用 RLock() 函数，读完之后调用 RUnlock() 函数解锁。写之前调用 Lock() 函数，写完之后，调用 Unlock(

golang程序变量会携带有一组校验数据，用来证明它的整个生命周期是否在运行时完全可知。如果变量通过了这些校验，它就可以在栈上分配。否则就说它逃逸了，必须在堆上分配。在方法内把局部变量指针返回 局部变量原本应该在栈中分配，在栈中回收。但是由于返回时被外部引用，因此其生命周期大于栈，则溢出。发送指针或带有指针的值到 channel 中。在编译时，是没有办法知道哪个 goroutine 会在 chan

执行go tidy，发现执行不了，得升级一下版本了。

与栈一样，队列也是最基本的数据结构之一。队列也是值的一种容器，其中值的插入和删除遵循“先进先出”（First-In-First-Out, FIFO）的原则⎯⎯也就是说，每次删除的只能是最先插入的值。

DaemonSet 将 pod 部署到集群中的所有节点上，也可以通过 pod 模板中的 nodeSelector 属性指定的部署到特定节点上。DaemonSet 是k8s节点上的守护进程。

执行滚动升级操作来逐步替代原有的 pod，而不是同时创建所有新的 pod 并一并删除所有旧的 pod。在这个过程中，服务的 pod 选择器同时包含新旧两个版本的 pod, 因此它将请求切换到这两组 pod。假设 pod 一开始使用v1版本的镜像运行第一个版本的应用。然后开发了一个新版本的应用打包成镜像，并将其推送到镜像仓库，标记为v2，接下来想用这个新版本替换所有的 pod。由于 pod 在创建之

ReplicaSet 是替代 ReplicationController 的，ReplicaSet 的行为与 ReplicationController 完全相同， 但pod 选择器的表达能力更强。ReplicationController 的标签选择器只允许包含某个标签的匹配 pod，但 ReplicaSet 的选择器还允许匹配缺少某个标签的 pod, 或包含特定标签名的 pod。Replica

一个 Statefulset 创建的每个pod都有一个从零开始的顺序索引，这个会体现在 pod 的名称和主机名上，同样还会体现在 pod 对应的固定存储上。这些 pod 的名称是可预知的，它是由 Statefulset 的名称加该实例的顺序索引值组成的。比如在一个属于 default 命名空间，名为 foo 的控制服务，它的一个 pod 名称为 A-0，那么可以通过下面的完整域名来访问它：a-0.

在这几秒时间里，“死掉”的消费者不会读取分区里的消息。对于分区数固定的情况，如果消费者过多，出现了消费者的个数大于分区个数的情况，就会有消费者分配不到任何分区。在进行主动再均衡期间，所有消费者都会停止读取消息，放弃分区所有权，重新加入消费组，并获得重新分配到的分区。协作再均衡（也称为增量再均衡）是指将一个消费者的部分分区重新分配给另一个消费者，其他消费者则继续读取没有被重新分配的分区。这种再均衡包