Go源码--sync库(3):sync.Pool(2)

回收

回收其实就是将 pool.local 置为空 可以让垃圾回收器回收
我们来看下 源码

func init() {// 将 poolCleanup 注册到 gc开始前的准备工作处理器中在 STW时执行runtime_registerPoolCleanup(poolCleanup)
}

这里注册了清理程序到GC前准备工作 也就是发生GC前需要执行这段代码 具体细节可以自行追踪下

我们来看下 poolCleanup的源代码

// 清理pools 将pools中的数据清理掉
// 具体逻辑 将 主缓存数据 移到 受害者缓存中 然后等GC清理 上次的 受害者缓存数据
// 也就是说 发生GC后 清理的是 上个GC时 放在 pools里的数据 而这次GC只是将pools里的数据放在受害者缓存里
func poolCleanup() {// This function is called with the world stopped, at the beginning of a garbage collection.// It must not allocate and probably should not call any runtime functions.// Because the world is stopped, no pool user can be in a// pinned section (in effect, this has all Ps pinned).// Drop victim caches from all pools.for _, p := range oldPools {p.victim = nilp.victimSize = 0}// Move primary cache to victim cache.for _, p := range allPools {p.victim = p.localp.victimSize = p.localSizep.local = nilp.localSize = 0}// The pools with non-empty primary caches now have non-empty// victim caches and no pools have primary caches.oldPools, allPools = allPools, nil
}

可以看到 我们前面提到的受害者缓存在这里赋值的。

疑问点

**问题一： ** runtime_procUnpin和runtime_procPin有什么作用
答：runtime_procPin 的作用
在 Go 运行时中，runtime_procPin 是一个内部函数，主要用于绑定当前 goroutine 到当前的 P（Processor）。其作用包括以下几点：

1. 防止 goroutine 被调度到其他 P 上：调用 runtime_procPin 后，当前 goroutine 会被固定在当前的 P 上，直到调用 runtime_procUnpin。这对于某些需要固定在同一线程上的操作特别有用，例如与线程相关的外部库交互。
2. 确保本地缓存的一致性：在某些高性能应用中，使用 runtime_procPin 可以确保本地缓存的一致性，从而提高性能。这对于涉及大量并发和线程间通信的程序特别重要。
3. 优化性能：在某些情况下，固定 goroutine 到特定的 P 可以减少上下文切换和调度开销，优化程序性能。

runtime_procUnpin的作用
作用和机制
4. 解除绑定：runtime_procUnpin 解除 runtime_procPin 所做的绑定，使得 goroutine 可以再次在不同的 P 之间迁移。
5. 恢复调度灵活性：解除绑定后，调度器可以将 goroutine 迁移到其他 P，以更好地平衡负载和资源利用。
6. 清理和释放资源：在某些需要固定资源或特定线程的操作完成后，通过 runtime_procUnpin 可以释放这些资源，使系统恢复正常的调度。

问题二： sync.Pool如何保证并发安全
我们首先来看下 Put()调用集 和 Get()调用集 同时发生时 可能存在的情况 如下图：

可以看到 正常情况下 （没有偷数据发生）Put Get操作运行在不同P上 且访问的内存各自独立 所以并发安全，有偷操作加进来后 采用了 for+cas的方式 使得同一时刻 只有一个协程可以取得数据 保证了并发安全

总结

还是有一些细节没想清楚，等有时间再补充，小弟水货，还望各位大神指教，共同进步。
感想：不敢想
csdn老是报错，本来一篇搞定 老是报超时啥的，只能拆分了 抱歉