“幸福的家庭都是相似的，不幸的家庭却各有各的不幸”，托尔斯泰的名言。在 BUG 定位这件事情上，其实也有类似的现象：”菜鸟们的紧张无措都是相似的，老鸟们的方法却各有各的不同”。

此话题历史久远。在早期，map 和 channel 都是语法指针，不能声明和使用非指针实例。此外，我们在竭尽全力探索数组如何工作。最终，我们认为指针和值的严格分离使语言更难使用。将这些类型更改为对关联的共享数据结构的引用，就解决了这些问题。改变给语言增加了一些令人遗憾的复杂性，但却对可用性产生了很大的影响：Go...

面向对象编程强调数据和操作绑定，方法是有状态的，本身可能会修改数据。因此编程时确定方法是否会修改原始数据尤其关键。多数从其他语言转到 Go 语言的开发者，都会首先了解 Go 语言传递参数的时候到底是 “传值” 还是 “传引用”。如果第一门开发语言是 C 语言或者 C++ 的开发者，还会区分下什么时候 “传指针”。

“接受接口、返回结构” 的一般原则，我在前一篇文章中写到，也多次在代码评审时向同事介绍，但经常遇到“为什么”的疑问。特别是因为这不是一条硬性规定。该想法的关键在于保持灵活性的同时避免预先抽象，并理解何时改变它。

interface 是 Go 语言最精髓的特性之一，一直以来想写一篇关于 interface 的文章，但是一直没敢写。持续几年之久，还是斗胆总结下。

Golang 的各种组件很灵活也很强大，但对于初级入门的使用者来说，要用好着实不易。最近，在开发一个可以拿来即用的 golang 库。第一个组件选择了缓存，主要是因为这个组件非常的关键，但也非常不容易实现好。

在请求处理过程中，应用程序会接受和处理请求，然后返回响应结果。在该过程中，还存在一些通用的功能，例如：鉴权、监控、链路追踪。众多 RPC 框架会提供称之为 Middleware 或者 Interceptor 等概念，以可插拔的方式来支持上述谈到的众多功能。以 gRPC 为例，工作原理如图：

一年前，我写过一致性模型的文章的第一个版本。因为当时写的很匆忙，而且这个主题非常重要，值得更缜密的对待，所以我并不是很满意。ACM Queue 为将其发布到自己觉得杂志上，所以请我仔细推敲。我得以借此机会改进这篇文章。本文就是最新的版本。

本篇从我自己的角度来写对物理内存管理的理解。由于 Linux 引入了虚拟内存的概念，应用程序对物理内存的访问都是由内核模块来接管的，因此带着以下问题，逐步揭开相关的细节：

想象一下自己是一名伐木工人，手里有林场里最好的斧子，因此你是工作效率最高的。突然有一天场里来了个推销的，他把一种新的砍树工具——链锯——给夸到了天上去。你也买了一把，不过你不懂得怎么用。你估摸着按照自己原来擅长的砍树方法，把链锯大力地挥向树干……