sync.Once

在多数情况下，sync.Once 被用于控制变量的初始化，这个变量的读写通常遵循单例模式，满足这三个条件：

当且仅当第一次读某个变量时，进行初始化（写操作）
变量被初始化过程中，所有读都被阻塞（读操作；当变量初始化完成后，读操作继续进行）
变量仅初始化一次，初始化完成后驻留在内存里

Once 的实现非常的灵活、简洁、高效，排除注释部分 Once 仅用 17 行实现，且单次执行时间在 0.3ns 左右。这让我十分敬佩，对它可谓喜爱至极，但因为它的通用性，在使用 Once 时给我带来了一些小小的负担，这也成了我极少的使用它的原因。

Once 只保证调用安全性（即线程安全以及只执行一次动作函数），但是细心的朋友一定发现了我们往往需要配对定义 Once 和业务实例变量，极少使用的情况下（如上述两个例子）看起来并没有什么负担，但是如果我们项目中有大量实例进行管理时（一般是集中管理，便于解决依赖问题），这时就会变得有点丑陋。

一个实际的业务场景，我有一个 http 服务，它有数百个组件实例，我们创建了一个 APP 用来管理所有实例的初始化、依赖关系，从而保证各个组件依赖其接口，相互之间进行解耦，也使得每个组件的配置（初始化参数）、依赖易于管理，不过我们常常对单例实例在 http 服务启动时进行初始化，这样避免使用 Once，且可以在 http 服务启动时暴露外部依赖问题（数据库、其它服务等）。

这个 http 服务需要很多辅助命令，每个命令负责极少的工作，如果我在命令启动时使用 APP 初始化所有组件，这造成了大量的资源浪费。我单独实现一个 Command 依赖管理组件，它大量使用 Once 保证各个组件只在第一次使用时进行初始化，这给我带来了一些困扰，我大量定义 Once 的实例，且它和具体的组件实例没有关联，我在使用时需要非常的小心。

buff64One 到 buff8192One 7个 Once 的实例，且对应的存在 buff64 到 buff8192 的业务实例，我在 GetBuff64 中必须小心使用 Once 实例，避免错误使用导致对应的实例未被初始化，而且上诉的代码看起来还有一些丑陋。

https://segmentfault.com/a/1190000038773386

https://github.com/thinkeridea/go-extend/tree/v1.1.2/pool