sync.Pool 是 Golang 内置的对象池技术，可用于缓存临时对象，以缓解因频繁建立临时对象带来的性能损耗以及对 GC 带来的压力。
在许多知名的开源库中都可以看到 sync.Pool 的大量使用。例如，HTTP 框架 Gin 用 sync.Pool 来复用每个请求都会创建的 gin.Context 对象。 在 grpc-Go、kubernetes 等也都可以看到对 sync.Pool 的身影。
但需要注意的是，sync.Pool 缓存的对象随时可能被无通知的清除，因此不能将 sync.Pool 用于存储持久对象的场景。
sync.Pool 作为 goroutine 内置的官方库，其设计非常精妙。sync.Pool 不仅是并发安全的，而且实现了 lock free，里面有许多值得学习的知识点。
本文将基于 go-1.16 的源码 对 sync.Pool 的底层实现一探究竟。
问题是这样的：我在代码里面调用了 os.Chmod("test.txt", 777)，希望把该文件的读写及执行权限对所有用户开放。
执行完代码，顺手 ls 看了下。如下：
1 | ls -l test.txt |
结果出乎意料，不仅文件权限没有按预期的变成 rwxrwxrwx。反而执行完后，当前用户就只剩可读权限了，其他用户就只有可执行权限同时无读写权限。
因为这实在是一个简单又愚蠢的错误，所以先直接给出结论:
rwxrwxrwx，需要写成 0777，而非 777。chmod 命令的表示形式，用八进制表示更方便和准确点。0777 和 777 都可以。这个问题虽然非常简单，但尴尬的是我还踩了坑，所以把这个问题及原因分享出来。
我们在开发 HTTP Server 的时候，经常有对接口内容做缓存的需求。例如，对于某些热点内容，我们希望做 1 分钟内的缓存。短期内缓存相同内容不会对业务造成实质影响，同时也会降低系统的整体负载。
有时我们需要把缓存逻辑放在 Server 内部，而非网关侧如 Nginx 等，是因为这样我们可以根据需要便捷地清除缓存，或者可以使用 Redis 等其他存储介质作为缓存后端。
这样的缓存场景无非是有缓存时从缓存取，无缓存时从下游服务取，并将数据放入缓存中。这其实是个非常通用的逻辑，应该可以将其抽象出来。从而缓存逻辑无需侵入进业务代码。
我常用的 HTTP 框架是 golang 的 gin。gin 官方就有一个 cache 组件：github.com/gin-contrib/cache，但这个 cache 组件无论在性能还是接口设计上，都有一些不足之处。
因此，我重新设计了一套 cache 中间件： gin-cache。 从压测结果来看，其性能相比于 gin-contrib/cache 明显提升。
「优雅终止」指的是当服务需要下线或者重启时，通过一些措施和手段，一方面能够让其他服务尽快的感知到当前服务的下线，另一方面也尽量减小对当前正在处理请求的影响。优雅终止可提升服务的高可用，减少下线造成的服务抖动，提升服务稳定性和用户体验。
下线服务不仅仅是运维层面的工作，需要整个 RPC 实现、服务架构以及运维体系的配合，才能完美的实现服务的优雅下线。本文将基于服务下线的整个流程，分析如何实现微服务的优雅终止。主要包含以下方面：
一致性 Hash 常用于缓解分布式缓存系统扩缩容节点时造成的缓存大量失效的问题。一致性 Hash 与其说是一种 Hash 算法，其实更像是一种负载均衡策略。
GroupCache 是 golang 官方提供的一个分布式缓存库，其中包含了一个简单的一致性 Hash 的实现。其代码在 github.com/golang/groupcache/consistenthash。本文将会基于 GroupCache 的一致性 Hash 实现，深入剖析一致性 Hash 的原理。
本文会着重探讨以下几点内容：
sync.Cond 条件变量是 Golang 标准库 sync 包中的一个常用类。sync.Cond 往往被用在一个或一组 goroutine 等待某个条件成立后唤醒这样的场景，例如常见的生产者消费者场景。
本文将基于 go-1.13 的源码 分析 sync.Cond 源码，将会涉及以下知识点: