index.xml

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>断念梦的站点 – 首页</title><link>https://desistdaydream.github.io/</link><description>Recent content in 首页 on 断念梦的站点</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><atom:link href="https://desistdaydream.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Blog: 公众号,码农的荒岛求生-操作系统话题系列文章</title><link>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg4OTYzODM4Mw==&amp;amp;action=getalbum&amp;amp;album_id=1923404049802985480&amp;amp;scene=173&amp;amp;from_msgid=2247485655&amp;amp;from_itemidx=1&amp;amp;count=3&amp;amp;nolastread=1#wechat_redirect">系列文章目录&lt;/a>&lt;/p></description></item><item><title>Blog: ChatGPT 团队是如何使用Kubernetes的</title><link>https://desistdaydream.github.io/blog/copy/%E4%BA%91%E5%8E%9F%E7%94%9F/ChatGPT-%E5%9B%A2%E9%98%9F%E6%98%AF%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8Kubernetes%E7%9A%84/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E4%BA%91%E5%8E%9F%E7%94%9F/ChatGPT-%E5%9B%A2%E9%98%9F%E6%98%AF%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8Kubernetes%E7%9A%84/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/u7zibC7UmMSAYotWZ81eYg">原文链接&lt;/a>&lt;/p>
&lt;p>&lt;a href="https://openai.com/research/scaling-kubernetes-to-7500-nodes">https://openai.com/research/scaling-kubernetes-to-7500-nodes&lt;/a>&lt;/p>
&lt;p>在本文中，OpenAI 的工程师团队分享了他们在 Kubernetes 集群扩展过程中遇到的各种挑战和解决方案，以及他们取得的性能和效果。&lt;/p>
&lt;p>我们已经将 Kubernetes 集群扩展到 7500 个节点，为大型模型（如 GPT-3、 CLIP 和 DALL·E）创建了可扩展的基础设施，同时也为快速小规模迭代研究（如 神经语言模型的缩放定律）创建了可扩展的基础设施。&lt;/p>
&lt;p>将单个 Kubernetes 集群扩展到这种规模很少见，但好处是能够提供一个简单的基础架构，使我们的机器学习研究团队能够更快地推进并扩展，而无需更改代码。&lt;/p>
&lt;p>自上次发布关于扩展到 2500 个节点的帖子以来，我们继续扩大基础设施以满足研究人员的需求，在此过程中学到了许多的经验教训。本文总结了这些经验教训，以便 Kubernetes 社区里的其他人也能从中受益，并最后会介绍下我们仍然面临的问题，我们也将继续解决这些问题。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VOiciaV2ibeVb4gXQtYocv76XKdUh15yLPEl9eIzUgtNqcpB4tp85WFRKYQGYlv5dlPjib6OTbqCqeUdg/640?wx_fmt=png&amp;amp;wxfrom=13&amp;amp;tp=wxpic" alt="">&lt;/p>
&lt;p>我们的工作负载&lt;/p>
&lt;p>在深入探讨之前，我们着重描述一下我们的工作负载。我们在 Kubernetes 上运行的应用程序和硬件与大家在普通公司遇到的可能相当不同。因此，我们的问题及解决方案可能与你自己的设置匹配，也可能不匹配！&lt;/p>
&lt;p>一个大型的机器学习作业跨越许多节点，当它可以访问每个节点上的所有硬件资源时，运行效率最高。这允许 GPU 直接使用 NVLink 进行交叉通信，或者 GPU 使用 GPUDirect 直接与 NIC 进行通信。因此，对于我们的许多工作负载，单个 Pod 占用整个节点。任何 NUMA、CPU 或 PCIE 资源争用都不是调度的因素。装箱或碎片化不是常见的问题。我们目前的集群具有完全的二分带宽，因此我们也不考虑机架或网络拓扑。所有这些都意味着，虽然我们有许多节点，但调度程序的负载相对较低。&lt;/p>
&lt;p>话虽如此，kube-scheduler 的负载是有波动的。一个新的作业可能由许多数百个 Pod 同时创建组成，然后返回到相对较低的流失率。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VOiciaV2ibeVb4gXQtYocv76XKLpfylgOVT7BzEulB0dicicTPY64JIp4CzqozxGqiaibbxiawSQliaFeicVhWA/640?wx_fmt=png&amp;amp;wxfrom=5&amp;amp;wx_lazy=1&amp;amp;wx_co=1&amp;amp;tp=wxpic" alt="">&lt;/p>
&lt;p>我们最大的作业运行 MPI，作业中的所有 Pod 都参与一个单一的 MPI 通信器。如果任何一个参与的 Pod 挂掉，整个作业就会停止，需要重新启动。作业会定期进行检查点，当重新启动时，它会从上一个检查点恢复。因此，我们认为 Pod 是半有状态的——被删掉的 Pod 可以被替换并且工作可以继续，但这样做会造成干扰，应该尽量减少发生。&lt;/p>
&lt;p>我们并不太依赖 Kubernetes 的负载均衡。我们的 HTTPS 流量非常少，不需要进行 A/B 测试、蓝 / 绿或金丝雀部署。Pod 使用 SSH 直接通过 Pod IP 地址与 MPI 进行通信，而不是通过服务端点。服务“发现”是有限的；我们只在作业启动时进行一次查找，查找哪些 Pod 参与 MPI。&lt;/p>
&lt;p>大多数作业与某种形式的 Blob 存储进行交互。它们通常会直接从 Blob 存储流式传输一些数据集的分片或检查点，或将其缓存到快速的本地临时磁盘中。我们有一些 PersistentVolumes，用于那些需要 POSIX 语义的情况，但 Blob 存储更具可扩展性，而且不需要缓慢的分离 / 附加操作。&lt;/p>
&lt;p>最后，我们的工作性质本质上是研究，这意味着工作负载本身是不断变化的。虽然超级计算团队努力提供我们认为达到“生产”质量水平的计算基础架构，但在该集群上运行的应用程序寿命很短，它们的开发人员会快速迭代。因此，随时可能出现新的使用模式，这些模式会挑战我们对趋势和适当权衡的设定。我们需要一个可持续的系统，同时也能让我们在事情发生变化时快速做出响应。&lt;/p>
&lt;p>网   络&lt;/p>
&lt;p>随着集群内节点和 Pod 数量的增加，我们发现 Flannel 难以满足所需的吞吐量。因此，我们转而使用 Azure VMSS 的本地 Pod 网络技术和相关 CNI 插件来配置 IP。这使我们的 Pod 能够获得主机级别的网络吞吐量。&lt;/p>
&lt;p>我们转而使用别名 IP 地址的另一个原因是，在我们最大的集群中，可能会同时使用约 20 万个 IP 地址。在测试了基于路由的 Pod 网络后，我们发现能够使用的路由数明显存在限制。&lt;/p>
&lt;p>避免封装会增加底层 SDN 或路由引擎的需求，虽然这使我们的网络设置变得简单。添加 VPN 或隧道可以在不需要任何其他适配器的情况下完成。我们不需要担心由于某部分网络具有较低的 MTU 而导致的分组分段。网络策略和流量监控很简单；没有关于数据包源和目的地的歧义。&lt;/p>
&lt;p>我们使用主机上的 iptables 标记来跟踪每个 Namespace 和 Pod 的网络资源使用情况，这使研究人员可以可视化他们的网络使用模式。特别是，由于我们的许多实验具有不同的 Internet 和 Pod 内通信模式，因此能够调查任何瓶颈发生的位置通常是非常有意义的。&lt;/p>
&lt;p>可以使用 iptables &lt;code>mangle&lt;/code> 规则任意标记符合特定条件的数据包。以下是我们用来检测流量是内部流量还是 Internet 流量的规则。&lt;code>FORWARD&lt;/code> 规则涵盖了来自 Pod 的流量，而 &lt;code>INPUT&lt;/code> 和 &lt;code>OUTPUT&lt;/code> 规则涵盖了主机上的流量：&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-nginx" data-lang="nginx">&lt;span style="display:flex;">&lt;span>&lt;span style="color:#204a87;font-weight:bold">iptables&lt;/span> &lt;span style="color:#4e9a06">-t&lt;/span> &lt;span style="color:#4e9a06">mangle&lt;/span> &lt;span style="color:#4e9a06">-A&lt;/span> &lt;span style="color:#4e9a06">INPUT&lt;/span> &lt;span style="color:#4e9a06">!&lt;/span> &lt;span style="color:#4e9a06">-s&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">10&lt;/span>&lt;span style="color:#4e9a06">.0.0.0/8&lt;/span> &lt;span style="color:#4e9a06">-m&lt;/span> &lt;span style="color:#4e9a06">comment&lt;/span> &lt;span style="color:#4e9a06">--comment&lt;/span> &lt;span style="color:#4e9a06">&amp;#34;iptables-exporter&lt;/span> &lt;span style="color:#4e9a06">openai&lt;/span> &lt;span style="color:#4e9a06">traffic=internet-in&amp;#34;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#4e9a06">iptables&lt;/span> &lt;span style="color:#4e9a06">-t&lt;/span> &lt;span style="color:#4e9a06">mangle&lt;/span> &lt;span style="color:#4e9a06">-A&lt;/span> &lt;span style="color:#4e9a06">FORWARD&lt;/span> &lt;span style="color:#4e9a06">!&lt;/span> &lt;span style="color:#4e9a06">-s&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">10&lt;/span>&lt;span style="color:#4e9a06">.0.0.0/8&lt;/span> &lt;span style="color:#4e9a06">-m&lt;/span> &lt;span style="color:#4e9a06">comment&lt;/span> &lt;span style="color:#4e9a06">--comment&lt;/span> &lt;span style="color:#4e9a06">&amp;#34;iptables-exporter&lt;/span> &lt;span style="color:#4e9a06">openai&lt;/span> &lt;span style="color:#4e9a06">traffic=internet-in&amp;#34;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#4e9a06">iptables&lt;/span> &lt;span style="color:#4e9a06">-t&lt;/span> &lt;span style="color:#4e9a06">mangle&lt;/span> &lt;span style="color:#4e9a06">-A&lt;/span> &lt;span style="color:#4e9a06">OUTPUT&lt;/span> &lt;span style="color:#4e9a06">!&lt;/span> &lt;span style="color:#4e9a06">-d&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">10&lt;/span>&lt;span style="color:#4e9a06">.0.0.0/8&lt;/span> &lt;span style="color:#4e9a06">-m&lt;/span> &lt;span style="color:#4e9a06">comment&lt;/span> &lt;span style="color:#4e9a06">--comment&lt;/span> &lt;span style="color:#4e9a06">&amp;#34;iptables-exporter&lt;/span> &lt;span style="color:#4e9a06">openai&lt;/span> &lt;span style="color:#4e9a06">traffic=internet-out&amp;#34;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#4e9a06">iptables&lt;/span> &lt;span style="color:#4e9a06">-t&lt;/span> &lt;span style="color:#4e9a06">mangle&lt;/span> &lt;span style="color:#4e9a06">-A&lt;/span> &lt;span style="color:#4e9a06">FORWARD&lt;/span> &lt;span style="color:#4e9a06">!&lt;/span> &lt;span style="color:#4e9a06">-d&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">10&lt;/span>&lt;span style="color:#4e9a06">.0.0.0/8&lt;/span> &lt;span style="color:#4e9a06">-m&lt;/span> &lt;span style="color:#4e9a06">comment&lt;/span> &lt;span style="color:#4e9a06">--comment&lt;/span> &lt;span style="color:#4e9a06">&amp;#34;iptables-exporter&lt;/span> &lt;span style="color:#4e9a06">openai&lt;/span> &lt;span style="color:#4e9a06">traffic=internet-out&amp;#34;&lt;/span>
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>一旦标记，iptables 将开始计数以跟踪匹配该规则的字节数和数据包数。你可以使用 &lt;code>iptables&lt;/code> 本身来查看这些计数器：&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-bash" data-lang="bash">&lt;span style="display:flex;">&lt;span>% iptables -t mangle -L -v
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Chain FORWARD &lt;span style="color:#ce5c00;font-weight:bold">(&lt;/span>policy ACCEPT 50M packets, 334G bytes&lt;span style="color:#ce5c00;font-weight:bold">)&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> pkts bytes target prot opt in out &lt;span style="color:#204a87">source&lt;/span> destination
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>....
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>1253K 555M all -- any any anywhere !10.0.0.0/8 /* iptables-exporter openai &lt;span style="color:#000">traffic&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span>internet-out */
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>1161K 7937M all -- any any !10.0.0.0/8 anywhere /* iptables-exporter openai &lt;span style="color:#000">traffic&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span>internet-in */
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>我们使用名为 iptables-exporter 的开源 Prometheus 导出器将这些数据追踪到我们的监控系统中。这是一种简单的方法，可以跟踪与各种不同类型的条件匹配的数据包。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VOiciaV2ibeVb4gXQtYocv76XKd8NicaEsHsoGOvcBJMt435PARbypib0ENCBwpeXTibnrp9mkYENFG0Hfg/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VOiciaV2ibeVb4gXQtYocv76XKQOOXeibMYDia4Eoic4E7iaNI2uPCa1HOVeY75vj4D2SfSnGVm5wVmDx9Ug/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>我们网络模型中比较独特的一点是，我们完全向研究人员公开节点、Pod 和 Service 网络 CIDR 范围。我们采用集线器和分支的网络模型，并使用本机节点和 Pod CIDR 范围路由该流量。研究人员连接到中心枢纽，然后可以访问任何一个单独的集群（分支）。但是这些集群本身无法相互通信。这确保了集群保持隔离、没有跨集群依赖，可以防止故障隔离中的故障传播。&lt;/p>
&lt;p>我们使用一个“NAT”主机来翻译从集群外部传入的服务网络 CIDR 范围的流量。这种设置为我们的研究人员提供了很大的灵活性，他们可以选择各种不同类型的网络配置进行实验。&lt;/p>
&lt;p>API 服务器&lt;/p>
&lt;p>Kubernetes 的 API Server 和 etcd 是保持集群健康运行的关键组件，因此我们特别关注这些系统的压力。我们使用 kube-prometheus 提供的 Grafana 仪表板以及额外的内部仪表板。我们发现，将 HTTP 状态码 429（请求太多）和 5xx（服务器错误）的速率作为高级信号警报是有用的。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VOiciaV2ibeVb4gXQtYocv76XKDtNcvSjnOqmZ6iccOSmwmricspB55500xvHpBMAI6HiaGfcCtSjqq3ljA/640?wx_fmt=png&amp;amp;wxfrom=5&amp;amp;wx_lazy=1&amp;amp;wx_co=1&amp;amp;tp=wxpic" alt="">&lt;/p>
&lt;p>虽然有些人在 kube 内部运行 API 服务器，但我们一直在集群外运行它们。etcd 和 API 服务器都在它们自己的专用节点上运行。我们的最大集群运行 5 个 API 服务器和 5 个 etcd 节点，以分散负载并尽可能减少发生故障后带来的影响。自从我们在 上一篇博文 中提到的将 Kubernetes 事件拆分到它们自己的 etcd 集群中以来，我们没有遇到 etcd 的任何值得注意的问题。API 服务器是无状态的，通常很容易在自我修复的实例组或扩展集中运行。我们尚未尝试构建任何自我修复 etcd 集群的自动化，因为发生事故非常罕见。&lt;/p>
&lt;p>API 服务器可能会占用相当多的内存，并且往往会与集群中的节点数量成线性比例。对于我们有 7500 个节点的集群，我们观察到每个 API 服务器使用高达 70GB 的堆内存，因此幸运地是，未来这应该仍然在硬件能力范围之内。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VOiciaV2ibeVb4gXQtYocv76XKh2rebxQzCsojXTUN9nDTDZbYWPMpq9ORPlVQfzHwh4sbM4VCztKibWQ/640?wx_fmt=png&amp;amp;tp=wxpic&amp;amp;wxfrom=5&amp;amp;wx_lazy=1&amp;amp;wx_co=1" alt="">&lt;/p>
&lt;p>API Servers 受到压力的主要来源之一就是对 Endpoints 的 WATCH。在整个集群中有一些服务，如“kubelet”和“node-exporter”，其中每个节点都是成员。当一个节点被添加或从集群中删除时，这个 WATCH 将被触发。通常，由于每个节点本身都通过 kube-proxy 监视 &lt;code>kubelet&lt;/code> 服务，因此这些响应中所需的数量和带宽将是 N2 非常大，有时会达到 1GB/s 或更高。Kubernetes 1.17 中推出的 EndpointSlices 大大降低了这种负载，减少达 1000 倍。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VOiciaV2ibeVb4gXQtYocv76XKwwo1NJytItYTcNF6oeOvs5TeLaBNqZuJa7LKFysickwuoBcHEiacZltQ/640?wx_fmt=png&amp;amp;wxfrom=5&amp;amp;wx_lazy=1&amp;amp;wx_co=1&amp;amp;tp=wxpic" alt="">&lt;/p>
&lt;p>总的来说，我们会非常注意随着集群规模增大而增加的 API Server 请求。我们尽量避免任何 DaemonSets 与 API Server 交互。在需要每个节点监视更改的情况下，引入缓存服务（例如 Datadog Cluster Agent）作为中介，似乎是避免集群范围瓶颈的良好模式。&lt;/p>
&lt;p>随着集群的增长，我们对集群的实际自动伸缩越来越少。但当一次性自动扩展太多时，我们偶尔会遇到问题。当新节点加入集群时会生成大量请求，一次性添加数百个节点可能会超过 API 服务器容量的负荷。稍微平滑一下这个过程，即使只有几秒钟也有助于避免宕机。&lt;/p>
&lt;p>时间序列度量与 Prometheus 和 Grafana&lt;/p>
&lt;p>我们使用 Prometheus 收集时间序列度量数据，并使用 Grafana 进行图形、仪表板和警报。我们从 kube-prometheus 部署开始收集了各种各样的度量数据，并使用了一些良好的仪表板进行可视化。随着节点数量的不断增加，我们开始遇到 Prometheus 收集的度量数据数量过多的问题。尽管 kube-prometheus 公开了许多有用的数据，但我们实际上并没有查看所有的度量数据，一些数据也过于细化，无法有效地进行收集、存储和查询。因此，我们使用 Prometheus 规则从被摄入的度量数据中“删掉”一些数据。&lt;/p>
&lt;p>有一段时间，我们遇到了 Prometheus 消耗越来越多的内存问题，最终导致容器崩溃并出现 Out-Of-Memory 错误（OOM）。即使为应用程序分配了大量的内存容量，这种情况似乎仍然会发生。更糟糕的是，它在崩溃时会花费很多时间在启动时回放预写日志文件，直到它再次可用。最终，我们发现了这些 OOM 的来源是 Grafana 和 Prometheus 之间的交互，其中 Grafana 使用 &lt;code>/api/v1/series&lt;/code> API 查询 &lt;code>{le!=&amp;quot;&amp;quot;}&lt;/code>（基本上是“给我所有的直方图度量”）。&lt;code>/api/v1/series&lt;/code> 的实现在时间和空间上没有限制，对于具有大量结果的查询，这将不断消耗更多的内存和时间。即使请求者已经放弃并关闭了连接，它也会继续增长。对于我们来说，内存永远不够，而 Prometheus 最终会崩溃。因此，我们修补了 Prometheus，将此 API 包含在上下文中以强制执行超时，从而完全解决了问题。&lt;/p>
&lt;p>虽然 Prometheus 崩溃的次数大大减少，但在我们需要重新启动它的时候，WAL 回放仍然是一个问题。通常需要多个小时来回放所有 WAL 日志，直到 Prometheus 开始收集新的度量数据并提供服务。在 Robust Perception 的帮助下，我们发现将 &lt;code>GOMAXPROCS=24&lt;/code> 应用于服务器可以显著提高性能。在 WAL 回放期间，Prometheus 尝试使用所有核心，并且对于具有大量核心的服务器，争用会降低所有性能。&lt;/p>
&lt;p>我们正在探索新的选项来增加我们的监控能力，下面“未解决的问题”部分将对此进行描述。&lt;/p>
&lt;p>健康检查&lt;/p>
&lt;p>对于如此庞大的集群，我们当然依赖自动化来检测并从集群中移除行为不当的节点。随着时间的推移，我们建立了许多健康检查系统。&lt;/p>
&lt;p>被动健康检查&lt;/p>
&lt;p>某些健康检查是被动的，总是在所有节点上运行。这些检查监视基本的系统资源，例如网络可达性、坏盘或满盘，或者 GPU 错误。GPU 以许多不同的方式出现问题，但一个容易出现的常见问题是“不可纠正的 ECC 错误”。Nvidia 的数据中心 GPU 管理器（DCGM）工具使查询这个问题和许多其他“Xid”错误变得容易。我们跟踪这些错误的一种方式是通过 dcgm-exporter 将指标收集到我们的监控系统 Prometheus 中。这将出现为 &lt;code>DCGM_FI_DEV_XID_ERRORS&lt;/code> 指标，并设置为最近发生的错误代码。此外，NVML 设备查询 API 公开了有关 GPU 的健康和操作的更详细信息。&lt;/p>
&lt;p>一旦检测到错误，它们通常可以通过重置 GPU 或系统来修复，但在某些情况下确实需要更换基础 GPU。&lt;/p>
&lt;p>另一种健康检查是跟踪来自上游云提供商的维护事件。每个主要的云提供商都公开了一种方式来了解当前 VM 是否需要进行会最终导致中断的、即将发生的维护事件。VM 可能需要重新启动以应用底层的超级管理程序补丁，或者将物理节点替换为其他硬件。&lt;/p>
&lt;p>这些被动健康检查在所有节点上不断运行。如果健康检查开始失败，节点将自动划分，因此不会在节点上安排新的 Pod。对于更严重的健康检查失败，我们还将尝试 Pod 驱逐，以要求当前运行的所有 Pod 立即退出。这仍然取决于 Pod 本身，可通过 Pod 故障预算进行配置来决定是否允许此驱逐发生。最终，无论是在所有 Pod 终止之后，还是在 7 天过去之后（我们的服务级别协议的一部分），我们都将强制终止 VM。&lt;/p>
&lt;p>活动 GPU 测试&lt;/p>
&lt;p>不幸的是，并非所有 GPU 问题都会通过 DCGM 可见的错误代码表现出来。我们建立了自己的测试库，通过对 GPU 进行测试来捕捉其他问题，并确保硬件和驱动程序的行为符合预期。这些测试无法在后台运行 - 它们需要独占 GPU 运行数秒钟或数分钟。&lt;/p>
&lt;p>我们首先在节点启动时运行这些测试，使用我们称之为“预检（preflight）”的系统。所有节点都会附带一个“预检”污点和标签加入集群。这个污点会阻止普通 Pod 被调度到节点上。我们配置了一个 DaemonSet，在所有带有此标签的节点上运行预检测试 Pod。测试成功完成后，测试本身将删除污点和标签，然后该节点就可供一般使用。&lt;/p>
&lt;p>我们还定期在节点的生命周期中运行这些测试。我们将其作为 CronJob 运行，允许它着陆在集群中的任何可用节点上。哪些节点会被测试到可能有些随机和不受控制，但我们发现随着时间的推移，它提供了足够的覆盖率，并且最小化了协调或干扰。&lt;/p>
&lt;p>配额和资源使用&lt;/p>
&lt;p>随着集群规模的扩大，研究人员开始发现他们难以获取分配给他们的全部容量。传统的作业调度系统有许多不同的功能，可以公平地在竞争团队之间运行工作，而 Kubernetes 没有这些功能。随着时间的推移，我们从这些作业调度系统中汲取灵感，并以 Kubernetes 原生的方式构建了几个功能。&lt;/p>
&lt;p>团队污点&lt;/p>
&lt;p>我们在每个集群中都有一个服务，称为“team-resource-manager”，具有多个功能。它的数据源是一个 ConfigMap，为在给定集群中具有容量的所有研究团队指定了 （节点选择器、应用的团队标签、分配数量） 元组。它会将当前节点与这些元组进行对比，并使用 &lt;code>openai.com/team=teamname:NoSchedule&lt;/code> 的污点对适当数量的节点进行标记。&lt;/p>
&lt;p>“team-resource-manager”还有一个入站的 webhook 服务，因此在提交每个作业时会根据提交者的团队成员身份应用相应的容忍度。使用污点使我们能够灵活地限制 Kubernetes Pod 调度程序，例如允许较低优先级的 Pod 具有 &amp;ldquo;any&amp;rdquo; 容忍度，这样团队可以借用彼此的容量，而无需进行大量协调。&lt;/p>
&lt;p>CPU 和 GPU  balloons&lt;/p>
&lt;p>除了使用集群自动缩放器动态扩展我们基于虚拟机的集群之外，我们还使用它来纠正（删除和重新添加）集群中的不健康成员。我们通过将集群的 &amp;ldquo;最小值&amp;rdquo; 设置为零、&amp;ldquo;最大值&amp;rdquo; 设置为可用容量来实现这一点。然而，如果 cluster-autoscaler 发现有空闲节点，它将尝试缩小到只需要的容量。由于多种原因（VM 启动延迟、预分配成本、上面提到的 API 服务器影响），这种空闲缩放并不理想。&lt;/p>
&lt;p>因此，我们为 CPU 和 GPU 主机都引入了“球形”部署。这个部署包含一个具有 &amp;ldquo;最大值&amp;rdquo; 数量的低优先级 Pod 副本集。这些 Pod 占用节点内的资源，因此自动缩放器不会将它们视为空闲。但由于它们是低优先级的，调度程序可以立即将它们驱逐出去，以腾出空间进行实际工作。（我们选择使用 Deployment 而不是 DaemonSet，以避免将 DaemonSet 视为节点上的空闲工作负载。）&lt;/p>
&lt;p>需要注意的是，我们使用 pod 反亲和性（anti-affinity）来确保 pod 在节点之间均匀分布。Kubernetes 调度器的早期版本存在一个 O(N^2) 的性能问题，与 pod 反亲和性有关。自 Kubernetes 1.18 版本以后，这个问题已经得到了纠正。&lt;/p>
&lt;p>Gang 调度&lt;/p>
&lt;p>我们的实验通常涉及一个或多个 StatefulSets，每个 StatefulSet 操作不同部分的训练任务。对于优化器，研究人员需要在进行任何训练之前调度 StatefulSet 的所有成员（因为我们通常使用 MPI 在优化器成员之间协调，而 MPI 对组成员变化很敏感）。&lt;/p>
&lt;p>然而再默认情况下，Kubernetes 不一定会优先满足某个 StatefulSet 的所有请求。例如，如果两个实验都请求 100％的集群容量，那么 Kubernetes 可能只会调度给每个实验需要的一半 Pod，这会导致死锁，使两个实验都无法进行。&lt;/p>
&lt;p>我们尝试了一些需要自定义调度程序的方法，但遇到了一些与正常 Pod 调度方式冲突的边缘情况。Kubernetes 1.18 引入了核心 Kubernetes 调度程序的插件体系结构，使本地添加此类功能变得更加容易。我们最近选择了 Coscheduling 插件作为解决此问题的方法。&lt;/p>
&lt;p>未解决的问题&lt;/p>
&lt;p>随着 Kubernetes 集群规模的扩大，我们仍有许多问题需要解决。其中一些问题包括：&lt;/p>
&lt;p>指标&lt;/p>
&lt;p>在如今的规模下，Prometheus 内置的 TSDB 存储引擎很难压缩，并且每次重新启动时需要长时间回放 WAL（预写式日志）。查询还往往会导致“查询处理会加载过多样本”的错误。我们正在迁移到不同的、与 Prometheus 兼容的存储和查询引擎。大家可以期待下我们未来的博客文章，看看它的表现如何！&lt;/p>
&lt;p>Pod 网络流量整形&lt;/p>
&lt;p>随着集群规模的扩大，每个 Pod 的互联网带宽量被计算了出来。每个人的聚合互联网带宽需求变得非常大，我们的研究人员现在有能力会意外地对互联网上的其他位置施加重大资源压力，例如要下载的数据集和要安装的软件包。&lt;/p>
&lt;p>结   论&lt;/p>
&lt;p>Kubernetes 是一个非常灵活的平台，可以满足我们的研究需求。它具有满足我们所面临的最苛刻工作负载的能力。尽管它仍有许多需要改进的地方，但 OpenAI 的超级计算团队将继续探索 Kubernetes 的可扩展性。&lt;/p></description></item><item><title>Blog: 反思</title><link>https://desistdaydream.github.io/blog/%E5%8F%8D%E6%80%9D/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/%E5%8F%8D%E6%80%9D/</guid><description>
&lt;h1 id="概述">概述&lt;a class="td-heading-self-link" href="#%e6%a6%82%e8%bf%b0" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;blockquote>
&lt;p>参考：&lt;/p>
&lt;ul>
&lt;li>&lt;/li>
&lt;/ul>
&lt;/blockquote>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/VQUEXNJCgj-ydH44QTpeBA">https://mp.weixin.qq.com/s/VQUEXNJCgj-ydH44QTpeBA&lt;/a>&lt;/p>
&lt;p>伟大的开发者，你们过得开心吗？&lt;/p>
&lt;p>互联网做得太出色了，以至于很多人把它看作某种像太平洋一样的自然资源，而非人造的。—— Alan Kay.&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/sz_mmbiz_jpg/dkwuWwLoRK8nrric2k6n7z179ev9Na9MamauNIbjribicfzQVter39E6ZqgmFuiaKgZhKfDlsCfiaV5M9Ws7PJIoOsw/640?wxfrom=12&amp;amp;tp=wxpic&amp;amp;usePicPrefetch=1&amp;amp;wx_fmt=jpeg" alt="800">&lt;/p></description></item><item><title>Blog: 灵魂拷问，上 Kubernetes 有什么业务价值？</title><link>https://desistdaydream.github.io/blog/copy/%E4%BA%91%E5%8E%9F%E7%94%9F/%E7%81%B5%E9%AD%82%E6%8B%B7%E9%97%AE%E4%B8%8A-Kubernetes-%E6%9C%89%E4%BB%80%E4%B9%88%E4%B8%9A%E5%8A%A1%E4%BB%B7%E5%80%BC/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E4%BA%91%E5%8E%9F%E7%94%9F/%E7%81%B5%E9%AD%82%E6%8B%B7%E9%97%AE%E4%B8%8A-Kubernetes-%E6%9C%89%E4%BB%80%E4%B9%88%E4%B8%9A%E5%8A%A1%E4%BB%B7%E5%80%BC/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/a3NE5fSpZIM9qlOofGTMWQ">原文链接&lt;/a>&lt;/p>
&lt;p>本文整理自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建统一、标准化的应用管理平台》主题线上网络研讨会。文章共分为上下两篇，本文为上篇，主要和大家介绍上Kubernetes有什么业务价值，以及什么是“以应用为中心”的 Kubernetes。下篇将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。&lt;/p>
&lt;p>&lt;strong>&lt;strong>关注公众号，回复&lt;/strong>&lt;/strong>“0722”&lt;strong>&lt;strong>即可下载 PPT&lt;/strong>&lt;/strong>&lt;/p>
&lt;p>非常感谢大家来到 CNCF 的直播，我是张磊，阿里云的高级技术专家，Kubernetes 项目资深维护者。同时也是 CNCF 应用交付领域 co-chair。我今天给大家带来的分享主题是《基于 Kubernetes 与 OAM 构建统一、标准化的应用管理平台》。在封面上有个钉钉群组二维码。大家可以通过这个二维码进入线上交流群。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8QooolHAJELazlEgJaCtxTJSXlz0ze2ryrlyNs08awKug6GMpxVDqYDg/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>上 Kubernetes 有什么业务价值？&lt;/strong>&lt;/p>
&lt;p>今天要演讲的主题是跟应用管理或者说是云原生应用交付是相关的。首先我们想要先回答这么一个问题：为什么我们要基于 Kubernetes 去构建一个应用管理平台？&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8QjhcMMlwCRicqK1hhjiaYqVdUD9gSEhsLSDZvdlich8ZFgOWpzic3fomQsg/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>上图是一个本质的问题，我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题，我们上 Kubernetes 有什么业务价值？这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢？实际上这跟 K8s 的定位是相关的。K8s 这个项目呢，如果去做一个分析的话，我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢？大家可以看一下下图。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8Qibw7FRA1G9hpUenLEOUI0PKbdfr1OReJhtM36pjzQAswxYvM9ib5PdsA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API，这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象，而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口，实际上是对集群基础设施：网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD（也就是 Custom Resource）的自定义对象。让你自己能够自定义底层基础设施的一个抽象。&lt;/p>
&lt;p>而这些抽象本身或者是 API 本身，是通过另外一个模式叫做控制器(Controller)去实现的。通过控制器去驱动我们的底层基础设施向我的抽象逼近，或者是满足我抽象定义的一个终态。&lt;/p>
&lt;p>所以本质来讲，Kubernetes 他的专注点是“如何标准化的接入来自于底层，无论是容器、虚机、负载均衡各种各样的一个能力，然后通过声明式 API 的方式去暴露给用户”。这就意味着 Kubernetes 实际用户不是业务研发，也不是业务运维。那是谁呢？是我们的平台开发者。希望平台开发者能够基于 Kubernetes 再去做上层的框架或者是平台。那就导致了今天我们的业务研发和业务运维对 Kubernetes 直接暴露出来的这一层抽象，感觉并不是很友好。&lt;/p>
&lt;p>这里的关键点在于，Kubernetes 对这些基础设施的抽象，跟业务研发和业务运维看待系统的角度是完全不同的。这个抽象程度跟业务研发和业务运维希望的抽象程度也是不一样的。语义完全对不上，使用习惯也是有很大的鸿沟。所以说为了解决这样一个问题，都在思考一些解决方法。怎么能让我 Kubernetes 提供的基础设施的抽象能够满足我业务研发和业务运维的一个诉求呢？怎么能让 Kubernetes 能够成为业务研发和业务运维喜欢的一个平台呢？&lt;/p>
&lt;h3 id="方法一把所有人都变成-kubernetes-专家">&lt;strong>方法一：把所有人都变成 Kubernetes 专家&lt;/strong>&lt;a class="td-heading-self-link" href="#%e6%96%b9%e6%b3%95%e4%b8%80%e6%8a%8a%e6%89%80%e6%9c%89%e4%ba%ba%e9%83%bd%e5%8f%98%e6%88%90-kubernetes-%e4%b8%93%e5%ae%b6" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8QicqQTtcXytBOyTdQQe7zLsWCVoicvvVMlZYVzm6Pz1XQ0mc9LD0siavcA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>假如我们所有人都是 Kubernetes 专家，那当然会喜欢 Kubernetes 对我提供的服务，这里给他发个 Kubernetes 的 PhD 博士。这里我强烈推荐阿里云和 CNCF 主办的云原生技术公开课。大家试试学完这门课程后，能不能变成 Kubernetes 专家。&lt;/p>
&lt;p>这个方法门槛比较高，因为每个人对于这个系统本身感兴趣程度不太一样，学习能力也不太一样。&lt;/p>
&lt;h3 id="方法二构建一个面向用户的应用管理平台">&lt;strong>方法二：构建一个面向用户的应用管理平台&lt;/strong>&lt;a class="td-heading-self-link" href="#%e6%96%b9%e6%b3%95%e4%ba%8c%e6%9e%84%e5%bb%ba%e4%b8%80%e4%b8%aa%e9%9d%a2%e5%90%91%e7%94%a8%e6%88%b7%e7%9a%84%e5%ba%94%e7%94%a8%e7%ae%a1%e7%90%86%e5%b9%b3%e5%8f%b0" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>业界常见的方法，大家会基于 Kubernetes 构建一个面向用户的应用管理平台，或者说是一个 PaaS，有人直接做成一个 Serverless。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8QYKexjNJtDyz9V5AMQ1xAh470gONwXHlgQ60WRyt6N5TIWPibNXWdRuQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>那这个具体是怎么做呢？还是在 Kubernetes 之上，会搭建一个东西叫做上层应用管理平台，这个上层应用平台对业务研发和业务运维暴露出来一个上层的 API。比如说业务研发这一侧，他不太会暴露 Pod，Deployment 这样的抽象。只会暴露出来 CI/CD 流水线。或者说一个应用，WordPress，一个外部网站，暴露出这样一个上层的概念，这是第一个部分。&lt;/p>
&lt;p>第二部分，它也会给业务运维暴露出一组运维的 API。比如说：水平扩容，发布策略，分批策略，访问控制，流量配置。这样的话有一个好处，业务研发和业务运维面对的 API 不是 Kubernetes 底层的 API，不是 Node，不是 Service，不是 Deployment，不是我们的 CRD。是这样一组经过抽象经过封装后的 API。这样的业务研发和业务运维用起来会跟他所期望的 Ops 流水线，它所熟悉的使用体检有个天然的结合点。&lt;/p>
&lt;p>所以说只有这么做了之后，我们才能够跟我们的业务老大说，Kubernetes 的业务价值来了。实际上业务价值不是在 Kubernetes 这一层，而是在 Kubernetes 往上的这一层&amp;ndash;&amp;quot;&lt;strong>你的解决方案&lt;/strong>&amp;quot;。所以说这样的一个系统构建出来之后呢，实际上是对 Kubernetes 又做了一层封装。变成了很多公司都有的，比如说 Kubernetes 应用平台。这是一个非常常见的做法。相比于我们让研发运维变成 Kubernetes 专家来说会更加实际一点。&lt;/p>
&lt;p>但是我们在阿里也好，在很多社区的实际场景也好，它往往会伴随着这么一个问题。这个问题是：今天 Kubernetes 的生态是非常非常繁荣的，下图是我在 CNCF 截的图，好几百个项目，几千个可以让我们 Kubernetes 即插即用的能力。比如 istio，KEDA，Promethues 等等都是 Kubernetes 的插件。正是基于这么一个扩展性非常高的声明式 API 体系才会有了这么繁荣的 Kubernetes 生态。所以可以认为 Kubernetes 能力是无限的，非常强大。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8QLHL0ibjiauseNYYibibyBwA6lazv8vlz5k9X1Fx9MWCG8FBz3aj2NqpsXQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>可是这么一个无限能力，如果对接到一个非常传统的，非常经典的一个应用管理平台。比如说我们的 PaaS 上，如 Cloud Foundry。立刻就会发现一个问题，PaaS 虽然对用户提供的是很友好的 API，但是这个 API 本身是有限的，是难以扩展的。比如说 Cloud Foundry 要给用户使用，就有 Buildpack 这么一个概念，而不是 Kubernetes 所有的能力都能给用户去使用。其实几乎所有的 PaaS 都会存在这么一个问题。它往上暴露的是一个用户的API，是不可扩展的，是个有限集。&lt;/p>
&lt;p>下面一个非常庞大繁荣的 Kubernetes 生态，没办法直接给用户暴露出去。可能每使用一个插件就要重新迭代开发你的 PaaS，重新交付你的 PaaS。这个是很难接受的。&lt;/p>
&lt;h3 id="传统-paas-的能力困境">&lt;strong>传统 PaaS 的“能力困境”&lt;/strong>&lt;a class="td-heading-self-link" href="#%e4%bc%a0%e7%bb%9f-paas-%e7%9a%84%e8%83%bd%e5%8a%9b%e5%9b%b0%e5%a2%83" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>这问题是一个普遍存在的问题，我们叫做传统 PaaS 的“能力困境”。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8QoDERgH8CalNEQRVsZ3UdnxkcLXerLqIUdB52bzKpxSVzPEXvaxDFaQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>本质上来说这个困境是什么意思呢？K8s 生态繁荣多样的应用基础设施能力，与业务开发人员日益增长的应用管理诉求，中间存在一个传统的 PaaS，他就会变成一个瓶颈。K8s 无限的能力无法让你的研发与运维立刻用到。所以传统 PaaS 就会成为一个显而易见的瓶颈。&lt;/p>
&lt;p>这样给我带来一个思考：我们能不能抛弃传统 PaaS 的一个做法，基于 K8s 打造高可扩展的应用管理平台。我们想办法能把 K8s 能力无缝的透给用户，同时又能提供传统 PaaS 比较友好的面向研发运维的使用体验呢？&lt;/p>
&lt;p>其实可以从另外一个角度思考这个问题：如何基于 K8s 打造高可扩展的应用管理平台，实际上等同于 如何打造一个“以应用为中心的”的 Kubernetes。或者说能不能基于 Kubernetes 去封装下，让它能够像 PaaS 一样，去面向我的实际用户去使用呢？这个就是我们要聊的关键点。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_gif/US10Gcd0tQGY9ddd5GpbmVRuaRfuaESAUBGE7uHX5G0nxxLSub2QTKZdu538V7GaHXS5jsTCebYCUibaHsjg0ow/640?wx_fmt=gif" alt="">&lt;/p>
&lt;p>&lt;strong>什么是“以应用为中心”的 Kubernetes&lt;/strong>&lt;/p>
&lt;h3 id="特征一通过原生的声明式-api-和插件体系暴露面向最终用户的上层语义和抽象">&lt;strong>特征一：通过原生的声明式 API 和插件体系，暴露面向最终用户的上层语义和抽象&lt;/strong>&lt;a class="td-heading-self-link" href="#%e7%89%b9%e5%be%81%e4%b8%80%e9%80%9a%e8%bf%87%e5%8e%9f%e7%94%9f%e7%9a%84%e5%a3%b0%e6%98%8e%e5%bc%8f-api-%e5%92%8c%e6%8f%92%e4%bb%b6%e4%bd%93%e7%b3%bb%e6%9a%b4%e9%9c%b2%e9%9d%a2%e5%90%91%e6%9c%80%e7%bb%88%e7%94%a8%e6%88%b7%e7%9a%84%e4%b8%8a%e5%b1%82%e8%af%ad%e4%b9%89%e5%92%8c%e6%8a%bd%e8%b1%a1" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8QhBSxNlRvpGWfJDkyx8ftxpO0rswAky1rVmVWho2Ey6RWqE7Dia6LBIw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>我们不是说要在 Kubernetes 上盖一个 PaaS，或者说是盖一个大帽子，不干这件事情。因为 K8s 本身可以扩展，可以写一组 CRD，把我们要的 API 给装上去。比如 CI/CD 流水线，就可以像 Tektong 系统直接使用 pipeline。应用也可以通过某些项目直接暴露出来。运维这一侧的发布扩容等，都可以通过安装一个 Operator 去解决问题。当然也需要一些技术将这些运维策略绑定到应用或者流水线中。&lt;/p>
&lt;p>这就是我们第一个点，以应用为中心的 K8s 首先是暴露给用户的语义和 API，而不是非常底层的，比如 Service、Node 或者是 Ingress。可能用户都不知道什么意思，也不知道怎么写的。&lt;/p>
&lt;h3 id="特征二上层语义和抽象可插拔可扩展没有抽象程度锁定和任何能力限制">&lt;strong>特征二：上层语义和抽象可插拔，可扩展，没有抽象程度锁定和任何能力限制&lt;/strong>&lt;a class="td-heading-self-link" href="#%e7%89%b9%e5%be%81%e4%ba%8c%e4%b8%8a%e5%b1%82%e8%af%ad%e4%b9%89%e5%92%8c%e6%8a%bd%e8%b1%a1%e5%8f%af%e6%8f%92%e6%8b%94%e5%8f%af%e6%89%a9%e5%b1%95%e6%b2%a1%e6%9c%89%e6%8a%bd%e8%b1%a1%e7%a8%8b%e5%ba%a6%e9%94%81%e5%ae%9a%e5%92%8c%e4%bb%bb%e4%bd%95%e8%83%bd%e5%8a%9b%e9%99%90%e5%88%b6" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvk7Pu7LACjibshibapmweer8Q0Z4N3HbqpJnstTLAEicg9IR7QVTMWGzN6toXCticVeGHtCxLXUI2kBpQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>第二个点很重要，上层语义和抽象必须是可插拔的，必须是可扩展的，是无缝兼容利用 K8s 的可扩展能力的。并且也不应该有对抽象程度的锁定。&lt;/p>
&lt;p>举个例子：比如一个应用本身既可以是 Deployment，这是一个比较低程度的抽象。也可以是 Knative Service，这是一个相对来说高程度的抽象，相对于 deployment 来说比较简单，只有一个 PodTemplate。甚至可以更简单，可以是一个 Service，或者是个 Function。这个时候抽象程度就很高。如果基于 K8s 做一个以应用为中心的框架的话，它应该是能够暴露工作负载的多种抽象程度的。而不是说单独去使用 Knative，只能暴露出 Knative Service。假如我想使用 Knative 部署一个 Statefulset，这当然是不可以的。抽象程度是完全不一致的。所以我希望这个以应用为中心的 K8s 是没有抽象程度的锁定的。&lt;/p>
&lt;p>同时也不应该有能力的限制，什么叫没有能力的限制呢？比如从运维侧举个例子，运维侧有很多很多扩容策略、发布策略等等。如果我想新加一个策略能力，它应该是非常简单的，就像在 K8s 安装一个 Operator 一样非常简单，能 helm insatll 就能搞定，答案是必须的。假如需要添加一个水平扩容，直接 helm install vpa 就能解决。通过这种方式才能做一个以应用为中心的 Kubernetes。&lt;/p>
&lt;p>可以看到它跟我们的传统 PaaS 还是有很大区别的，它的可扩展能力非常非常强。它本质上就是一个 K8s，但是它跟专有的 Service，Knative，OpenFaaS 也不一样。它不会把抽象程度锁定到某一种 Workload 上，你的 Workload 是可以随意去定义。运维侧的能力也可以随意可插拔的去定义。这才是我们叫做一个以应用为中心的 Kubernetes。那么这么一个 Kubernetes 怎么做呢？&lt;/p>
&lt;p>后续我们将会在下篇文章中详细为大家解读如何构建“以应用为中心”的 Kubernetes？以及构建这么一个以用户为中心的 Kubernetes，需要做几个层级的事情。&lt;/p></description></item><item><title>Blog: 如何构建以应用为中心的Kubernetes</title><link>https://desistdaydream.github.io/blog/copy/%E4%BA%91%E5%8E%9F%E7%94%9F/%E5%A6%82%E4%BD%95%E6%9E%84%E5%BB%BA%E4%BB%A5%E5%BA%94%E7%94%A8%E4%B8%BA%E4%B8%AD%E5%BF%83%E7%9A%84Kubernetes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E4%BA%91%E5%8E%9F%E7%94%9F/%E5%A6%82%E4%BD%95%E6%9E%84%E5%BB%BA%E4%BB%A5%E5%BA%94%E7%94%A8%E4%B8%BA%E4%B8%AD%E5%BF%83%E7%9A%84Kubernetes/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/ql_AIFc0s5HwZgsML63zQA">原文链接&lt;/a>&lt;/p>
&lt;p>本文整理自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建统一、标准化的应用管理平台》主题线上网络研讨会。&lt;/p>
&lt;p>&lt;strong>&lt;strong>关注公众号，回复&lt;/strong>&lt;/strong>“0722”&lt;strong>&lt;strong>即可下载 PPT&lt;/strong>&lt;/strong>&lt;/p>
&lt;p>文章共分为上下两篇。上篇文章《&lt;a href="http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&amp;amp;mid=2247492713&amp;amp;idx=1&amp;amp;sn=63d26542a935a6b3d1cfd7a72f71425b&amp;amp;chksm=fae6efa6cd9166b0c66e73ad47be04d029d40066b7697f2f4c7cd7a53d08ba6e019419166bb8&amp;amp;scene=21#wechat_redirect">&lt;strong>灵魂拷问，上 Kubernetes 有什么业务价值？&lt;/strong>&lt;/a>》，主要和大家介绍了上 Kubernetes 有什么业务价值，以及什么是“以应用为中心”的 Kubernetes。本文为下篇，将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。&lt;/p>
&lt;p>&lt;strong>如何构建“以应用为中心”的 Kubernetes？&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZwcdrrveib3FgS5lfWSW255sBic8ichpP7AYUlokiaq0vwibQ6tx6xBFiayjQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>构建这么一个以用户为中心的 Kubernetes，需要做几个层级的事情。&lt;/p>
&lt;h3 id="1-应用层驱动">&lt;strong>1. 应用层驱动&lt;/strong>&lt;a class="td-heading-self-link" href="#1-%e5%ba%94%e7%94%a8%e5%b1%82%e9%a9%b1%e5%8a%a8" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>首先来看最核心的部分，上图中蓝色部分，也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API，比如说 pipeline 就是一个 API，应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。&lt;/p>
&lt;h3 id="2-应用层抽象">&lt;strong>2. 应用层抽象&lt;/strong>&lt;a class="td-heading-self-link" href="#2-%e5%ba%94%e7%94%a8%e5%b1%82%e6%8a%bd%e8%b1%a1" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象，就等同于定义 CRD 和 Controller，所以 Controller 可以叫做应用层的抽象。本身可以是社区里的，比如 Tekton，istio 这些，可以作为你的应用驱动层。这是第一个问题，解决的是抽象的问题。不是特别难。&lt;/p>
&lt;h3 id="3-插件能力管理">&lt;strong>3. 插件能力管理&lt;/strong>&lt;a class="td-heading-self-link" href="#3-%e6%8f%92%e4%bb%b6%e8%83%bd%e5%8a%9b%e7%ae%a1%e7%90%86" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>很多功能不是 K8s 提供的，内置的 Controller 还是有限的，大部分能力来自于社区或者是自己开发的 Controller。这时我的集群里面就会安装好多好多插件。如果要构建以应用为中心的 Kubernetes，那我必须能够管理起来这些能力，否则整个集群就会脱管了。用户想要这么一个能力，我需要告诉他有或者是没有。需要暴露出一个 API 来告诉他，集群是否有他需要的能力。假设需要 istio 的流量切分，需要有个接口告诉用户这个能力存不存在。不能指望用户去 get 一下 crd 合不合适，检查 Controller 是否运行。这不叫以应用为中心的 K8s，这叫裸 K8s。&lt;/p>
&lt;p>所以必须有个能力，叫做插件能力管理。如果我装了 Tekton，kEDA，istio 这些组件，我必须将这些组件注册到能力注册中心，让用户能够发现这些能力，查询这些能力。这叫做：插件能力管理。&lt;/p>
&lt;h3 id="4-用户体验层">&lt;strong>4. 用户体验层&lt;/strong>&lt;a class="td-heading-self-link" href="#4-%e7%94%a8%e6%88%b7%e4%bd%93%e9%aa%8c%e5%b1%82" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>有了应用层驱动，应用层抽象，插件能力管理，我们才能更好地去考虑，如何给用户暴露一个友好的 API 或者是界面出来。有这么几种方式，比如 CLI 客户端命令行工具，或者是一个 Dashboard，又或者是研发侧的 Docker Compose。或者可以让用户写代码，用 python 或者 go 等实现 DSL，这都是可以的。&lt;/p>
&lt;p>用户体验层怎么做，完全取决于用户接受什么样的方式。关键点在于以应用为中心的 Kubernetes，UI 层就可以非常方便的基于应用层抽象去做。比如 CLI 就可以直接创建一个流水线和应用，而不是兜兜转转去创建 Deployment 和 Pod，这两个的衔接方式是完全不一样的。pipeline 只需要生成一下就结束了。然后去把 Pod 和 Deployment 组成一个 Pipeline，那这个工作就非常繁琐了。这是非常重要的一点，当你有了应用层驱动，应用层抽象，插件能力管理，再去构建用户体验层就会非常非常简单。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_gif/US10Gcd0tQGY9ddd5GpbmVRuaRfuaESAUBGE7uHX5G0nxxLSub2QTKZdu538V7GaHXS5jsTCebYCUibaHsjg0ow/640?wx_fmt=gif" alt="">&lt;/p>
&lt;p>&lt;strong>Open Application Model(OAM)&lt;/strong>&lt;/p>
&lt;p>如果想构建一个应用为中心的 Kubernetes，有没有一个标准化的、简单的方案呢？&lt;/p>
&lt;p>&lt;strong>下面就要为大家介绍：&lt;/strong> &lt;strong>Open Application Model(OAM)。&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZ6yAC7L8wPYdL8WnH4Tr8wlvibeicaQDALk3FpYb6jPIJdgicmmaxkK1yw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>OAM 的本质是帮助你构建一个“以应用为中心“的 Kubernetes 标准规范和框架，相比较前面的方案，OAM 专注于做这三个层次。&lt;/p>
&lt;h3 id="1-应用组件-components">&lt;strong>1. 应用组件 Components&lt;/strong>&lt;a class="td-heading-self-link" href="#1-%e5%ba%94%e7%94%a8%e7%bb%84%e4%bb%b6-components" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>第一个叫做应用层抽象，OAM 对用户暴露出自己定义的应用层抽象，第一个抽象叫做 Components。Components 实际上是帮助我们定义 Deployment、StatefulSet 这样的 Workload 的。暴露给用户，让他去定义这些应用的语义。&lt;/p>
&lt;h3 id="2-应用特征-traits">&lt;strong>2. 应用特征 Traits&lt;/strong>&lt;a class="td-heading-self-link" href="#2-%e5%ba%94%e7%94%a8%e7%89%b9%e5%be%81-traits" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>第二个叫做应用特征，叫做 Traits。运维侧的概念，比如扩容策略，发布策略，这些策略通过一个叫做 Traits 的 API 暴露给用户。首先 OAM 给你做了一个应用层定义抽象的方式，分别叫做 Components 和 Traits。由于你需要将 Traits 应用特征关联给应用组件 Components，例如 Deployment 需要某种扩容策略或者是发布策略，怎么把他们关联在一起呢？&lt;/p>
&lt;h3 id="3-应用配置-application-configuration">&lt;strong>3. 应用配置 Application Configuration&lt;/strong>&lt;a class="td-heading-self-link" href="#3-%e5%ba%94%e7%94%a8%e9%85%8d%e7%bd%ae-application-configuration" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>这个就需要第三种配置叫做 Application Configuration 应用配置。最终这些概念和配置都会变成 CRD，如果你的 K8s 里面安装了 OAM 的 Kubernetes Runtime 组件，那么那就能解析你 CRD 定义的策略和 Workload，最终去交给 K8s 去执行运行起来。就这么一个组件帮助你更好地去定义抽象应用层，提供了几个标准化的方法。&lt;/p>
&lt;h3 id="4-能力定义对象-definitions">&lt;strong>4. 能力定义对象 Definitions&lt;/strong>&lt;a class="td-heading-self-link" href="#4-%e8%83%bd%e5%8a%9b%e5%ae%9a%e4%b9%89%e5%af%b9%e8%b1%a1-definitions" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>这些抽象和能力交给 K8s 去处理之后，我这些能力需要的 Controller 插件在哪？有没有 Ready？这些版本是不是已经有了，能不能自动去安装。这是第四个能力了：能力定义对象。这是 OAM 提供的最后一个 API，通过这个 API 可以自己去注册 K8s 所有插件，比如 Tekton、KEDA、istio 等。&lt;/p>
&lt;p>把它注册为组件的一个能力，或者是某一个特征。比如说 Flager，可以把它注册为金丝雀发布的能力，用户只要发现这个发布策略存在，说明这个集群支持 Flager，那么他就可以去使用。这就是一个以应用为中心的一个玩法。以用户侧为出发点，而不是以集群侧为出发点，用户侧通过一个上层的 api，特征和组件来去了解他的系统，去操作他的系统。以上就是 OAM 提供的策略和方法。&lt;/p>
&lt;p>总结下来就是 OAM 可以通过标准化的方式帮助平台构建者或者开发者去定义用户侧，应用侧的抽象。第二点是提供了插件化能力注册于管理机制。并且有了这些抽象和机制之后，可以非常方便的构建可扩展的 UI 层。这就是 OAM 最核心的功能和价值。&lt;/p>
&lt;h3 id="5-oam-会怎样给用户提供一个-api-呢">&lt;strong>5. OAM 会怎样给用户提供一个 API 呢？&lt;/strong>&lt;a class="td-heading-self-link" href="#5-oam-%e4%bc%9a%e6%80%8e%e6%a0%b7%e7%bb%99%e7%94%a8%e6%88%b7%e6%8f%90%e4%be%9b%e4%b8%80%e4%b8%aa-api-%e5%91%a2" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;h3 id="1components">&lt;strong>1）Components&lt;/strong>&lt;a class="td-heading-self-link" href="#1components" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZicrjzfqhULmjvxiciaXF9tyibpvKn9priauiaUEiaEvJRLtNia1Saib4TLsggjA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>Component 是工作负载的版本化定义，例如上图中创建一个 Component，实际上就是创建一个 Deployment。这样一个 Component 交给 K8s 之后，首先会创建一个 Component 来管理这个 Workload，当你修改 Component 之后就会生成一个对应版本的 deployment。这个 Component 实际上是 Deployment 的一个模板。比如我把 image 的版本修改一下，这个操作就会触发 OAM 插件，生成一个新的版本的 Deployment，这是第一个点。其实就版本化管理机制去管理 Component。&lt;/p>
&lt;p>第二点是 Workload 部分完全是自定义的，或者是是可插拔的。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZQDmYSgw2tyF9jpq4ibd0tPkpLG6V18L6VSOFpwPOYXK5NOosH3icCCYQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>今天可以定义为 Deployment，明天可以定义为一个非常简单的版本。也就是说我 Components 的抽象程度完全取决于用户自己决定的。后期也可以改成 Knative Service，甚至改成一个 Open PaaS。所以说在 Components 的 Workload 部分你可以自由的去定义自己的抽象。只要你提前安装了对应 CRD 即可，这是一个非常高级的玩法。&lt;/p>
&lt;p>此外在 OAM 中，”云服务“也是一种 Workload， 只要你能用 CRD 定义你的云服务，就可以直接在 OAM 中定义为一个应用所依赖的组件。比如上图中的redis实际上是阿里云的 Redis 服务，大概是这么一个玩法。&lt;/p>
&lt;h3 id="2trait-和-application-configuration">&lt;strong>2）Trait 和 Application Configuration&lt;/strong>&lt;a class="td-heading-self-link" href="#2trait-%e5%92%8c-application-configuration" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZV3ozMFKxZb0rx5OjNF4JK3iacnBZavqticlsEhib8ETcvlUIw6doE5dibw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>首先 Trait 是声明式运维能力的描述，其实就是 Kubernetes API 对象。任何管理和运维 Workload 的组件和能力，都可以以这种 CER 的方式定义为一个 Trait。所以像 HPA，API gateway，istio 里面的 Virtual Services 都是 Trait。&lt;/p>
&lt;p>Application Configuration 就像是一个信封，将 Traits 绑定给 Component，这个是显式绑定的。OAM 里面不建议去使用 Label 这样的松耦合的方式去关联你的工作负载。建议通过这种结构化的方式，通过 CRD 去显式的绑定你的特征和工作负载。这样的好处是我的绑定关系是可管理的。可以通过 kubectl get 看到这个绑定关系。作为管理员或者用户，就非常容易的看到某一个组件绑定的所有运维能力有哪些，这是可以直接展示出来的，如果通过 label 是很难做到的。同时 Label 本身有个问题是，本身不是版本化的，不是结构体，很难去升级，很难去扩展。通过这么结构化定义，后面的升级扩展将会变得非常简单。 &lt;/p>
&lt;p>在一个用户配置里面，可以关联多个 Components。它认为一个应用运行所需要的所有组件和所依赖的运维能力，都应该定义为一个文件叫做 ApplicationConfiguration。所以在任何环境，只要拥有这个文件，提交之后，这个应用就会生效了。OAM 是希望能够提供一个自包含的应用声明方式。&lt;/p>
&lt;h3 id="3definition-object">&lt;strong>3）Definition Object&lt;/strong>&lt;a class="td-heading-self-link" href="#3definition-object" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZhAQ2EeRQcL8DztTJdZLrSbV4AuicsTFnmpXYokfia6jA2Fjjj7usHpAw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>除此之外，还提到了对应管理员提供了 Definition Object，这是用来注册和发现插件化能力的 API 对象。&lt;/p>
&lt;p>比如我想讲 Knative Service 定义为平台支持的一种工作负载，如上图只需要简单的写一个文件即可。其中在 definitionRef 中引用 service.serving.knative.dev 即可。这样的好处就是可以直接用 kubectl get Workload 查看 Knative Service 的 Workload。所以这是一个用来注册和发现插件化能力的机制，使得用户非常简单的看到系统中当前有没有一个工作负载叫做 Knative Service。而不是让用户去看 CRD，看插件是否安装，看 Controller 是否 running，这是非常麻烦的一件事情。所以必须有这么一个插件注册和发现机制。&lt;/p>
&lt;p>这一部分还有其他额外的能力，可以注册 Trait，并且允许注册的 Trait-A 和 Trait-B 是冲突的。这个信息也能带进去，这样部署的时候检查到 A 和 B 是冲突的，会产生报错信息。否则部署下去结果什么都不知道，两个能力是冲突的，赶紧删了回滚重新创建。OAM 在注册的时候就会暴露出来运维能力的冲突，这也是靠 Definition 去做的。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZcuSZtGhUKRMs2jjmLD5PiaO72IKtaxbfibNcWGsliawhtqUKWXSrS3Vpg/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>除此之外，OAM 的 model 这层其他的一些附加能力，能够让你定义更为复杂的应用。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_gif/US10Gcd0tQGY9ddd5GpbmVRuaRfuaESAUBGE7uHX5G0nxxLSub2QTKZdu538V7GaHXS5jsTCebYCUibaHsjg0ow/640?wx_fmt=gif" alt="">&lt;/p>
&lt;p>&lt;strong>总结&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZQ4fuTxibpUFIWWVFhEoPu3GhZJT3JCk3PICeTxuk7m0xlgFOnMnJ3Lw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>前面我们提到很多企业等等都在基于 Kubernetes 去构建一个上层应用管理平台。Kubernetes 实际上是面向平台开发者，而不是面向研发和应用运维的这么一个项目。它天生就是这么设计的，所以说需要基于 Kubernetes 去构建应用管理平台。去更好的服务研发和运维，这也是一个非常自然的选择。不是说必须使用 K8s 去服务你的用户。如果你的用户都是 K8s 专家，这是没问题的。如果不是的话，你去做这样一个应用平台是非常自然的事情。&lt;/p>
&lt;p>但是我们不想在 K8s 之前架一个像 Cloud Foundry 传统的 PaaS。因为它会把 K8s 的能力完全遮住。它有自己的一套 API，自己的理念，自己的模型，自己的使用方式。跟 Kubernetes 都是不太一样的，很难把 Kubernetes 的能力给暴露出去。这是经典 PaaS 的一个用法，但是我们不想要这么一个理念。我们的目标是既能给用户提供一个使用体验，同时又能把 Kubernetes 的能力全部发挥出来。并且使用体验跟 Kubernetes 是完全一致的。OAM 本质上要做的是面向开发和运维的，或者说是面向以应用为中心的Kubernetes。&lt;/p>
&lt;p>所以今天所介绍的 OAM 是一个统一、标准、高可扩展的应用管理平台，能够以应用为中心的全新的 Kubernetes，这是今天讨论的一个重点。OAM 这个项目就是支撑这种理念的核心依赖和机制。简单地来说 OAM 能够让你以统一的，标准化的方式去做这件事情。比如标准化定义应用层抽象，标准化编写底层应用驱动，标准化管理 K8s 插件能力。&lt;/p>
&lt;p>对于平台工程师来说，日常的工作能不能以一个标准化的框架或者依赖让平台工程师更简单更快的做这件事情。这就是 OAM 给平台工程师带来的价值。当然它也有些额外的好处，基于 OAM 暴露出来的新的 API 之后，你上层的UI构建起来会非常简单。&lt;/p>
&lt;p>你的 OAM 天然分为两类，一类叫做工作负载，一类叫做运维特征。所以你的 UI 这层可以直接去对接了，会减少很多前端的工作。如果基于 CI/CD 做 GitOps / 持续集成发现也会变得非常简单。因为它把一个应用通过自包含的方式给定义出来了，而不是说写很多个 yaml 文件。并且这个文件不仅自包含了工作负载，也包括了运维特征。所以创建好了这个文件往 Kubernetes 中提交，这个应用要做金丝雀发布或者是蓝绿发布，流量控制，全部是清清楚楚的定义在这个应用配置文件里面的。因为 GitOps 也好，持续集成也好，是不想管你的 pod 或者是 Deployment 怎么生成的，这个应用怎么运维，怎么 run 起来，还是要靠 Kubernetes 插件或者内置能力去做的。这些能力都被定义到一个自包含的文件，适用于所有集群。所以这就会使得你的 GitOps 和持续集成变得简单。&lt;/p>
&lt;p>以上就是 OAM 给平台工程师带来的一些特有的价值。简单来说是统一、标准的 API，区分研发和运维策略，让你的 UI 和 GitOps 特别容易去构建。另一点是向下提供了高可扩展的管理 K8s 插件能力。这样的系统真正做到了标准，自运维，一个以应用为中心和用户为中心的 Kubernetes 平台。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_gif/US10Gcd0tQGY9ddd5GpbmVRuaRfuaESAUBGE7uHX5G0nxxLSub2QTKZdu538V7GaHXS5jsTCebYCUibaHsjg0ow/640?wx_fmt=gif" alt="">&lt;/p>
&lt;p>&lt;strong>OAM 社区&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/yvBJb5Iiafvlb7BGwRI3ap7CLbL5GOIyZJ2k4MkCDLm5ggusQFO3JsudicVZT9OUe43OHSsLD8TRQYEVSDh4blBg/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>上面最后希望大家踊跃加入 OAM 社区，参与讨论。上图中有钉钉群二维码，目前人数有几千人，讨论非常激烈，我们会在里面讨论 GitOps，CI/CD，构建 OAM 平台等等。OAM 也有亚太地区的周会，大家可以去参加。上面的链接是开源项目地址，将这个安装到 Kubernetes 中就可以使用上面我们说的这些能力了。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_gif/US10Gcd0tQGY9ddd5GpbmVRuaRfuaESAUBGE7uHX5G0nxxLSub2QTKZdu538V7GaHXS5jsTCebYCUibaHsjg0ow/640?wx_fmt=gif" alt="">&lt;/p>
&lt;p>&lt;strong>QA 环节&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Q1：&lt;/strong> 例子中提问到了 Function 的例子，是否可以理解为 Serverless 或者是 PaaS？&lt;/p>
&lt;p>&lt;strong>A1&lt;/strong>**：** 这样理解是没错的，可以理解为阿里云的一个 Function，或者是 Knative Service。&lt;/p>
&lt;p>&lt;strong>Q2：&lt;/strong> 有没有可以让我自由定义出相应的规则这种规范？&lt;/p>
&lt;p>&lt;strong>A2：&lt;/strong> 有的，在 OAM 里面有个规范，叫做 spec。spec 里面有提交容器化的规范。后面会增加更多抽象的规范。当然也分类别，有一些是非常标准化的，需要严格遵守。有一些是比较松的，可以不用严格遵守。&lt;/p>
&lt;p>&lt;strong>Q3：&lt;/strong> docker-compose 的例子可否再谈谈？&lt;/p>
&lt;p>&lt;strong>A3：&lt;/strong> 本次 ppt 中没有 docker-compose 的例子，但是这个其实很容易去理解，因为 OAM 将 Kubernetes API 分为两类，一个叫做 Components，一个叫T raits。有这么一个 Componets 文件，就可以直接映射 OAM 的概念，docker-compose 中有个概念叫做 Service，其实就是对应了 OAM 中的 Component。这完全是一对一对应关系。Service 下面有个 Deployment，有个部署策略，其实对应的就是 OAM 的 Trait。&lt;/p>
&lt;p>&lt;strong>Q4：&lt;/strong> 定义阿里云的 redis 是否已经实现了？&lt;/p>
&lt;p>&lt;strong>A4：&lt;/strong> 已经实现了，但是功能有限。内部已经实现了一个更强大的功能，通过 OAM 将阿里云的所有资源给创建起来。目前这个是在 Crossplane 去做的。但是内部更完整的实现还没有完全的放出去。我们还在规划中，希望通过一个叫做 Alibaba Opreator 的方式暴露出去。&lt;/p>
&lt;p>&lt;strong>Q5：&lt;/strong> 是否可以理解 OAM 通过管理元数据通过编写 CRD 来打包 Components 和 Traits。&lt;/p>
&lt;p>&lt;strong>A5：&lt;/strong> 可以说是对的。你把自己的 CRD 也好，社区里面的 CRD 也好，稍微做个分类或者封装，暴露给用户。所以对于用户来说只要理解两个概念——Components 和 Traits。Components 里面的内容是靠你的 CRD 来决定的，所以说这是一个比较轻量级的抽象。&lt;/p>
&lt;p>&lt;strong>Q6：&lt;/strong> 假设 Components 有四个，Traits 有五个，是否可以理解为可封装能力有 20 项。&lt;/p>
&lt;p>&lt;strong>A6：&lt;/strong> 这个不是这么算的，不管有多少 Components 和 Trait，最终有几个能力取决于你注册的实际 CRD。Components 和 Traits 与背后的能力是解耦开的。&lt;/p>
&lt;p>&lt;strong>Q7：&lt;/strong> OAM 能使用 Kustomize 生成么？&lt;/p>
&lt;p>&lt;strong>A7：&lt;/strong> 当然可以了，Kustomize 使一个 yaml 文件操作工具。你可以用这个工具生成任何你想要的 yaml 文件，你也可以用其他的，比如 google 的另一个项目叫 kpt，比如你用 DSL，json。所有可以操作 yaml 文件的工具都可以操作 OAM 文件，OAM 的 yaml 文件跟正常的 K8s 中的 yaml 没有任何区别。在 K8s 看来 OAM 无非就是一个 CRD。&lt;/p>
&lt;p>&lt;strong>Q8：&lt;/strong> OAM 是否可以生产可用？&lt;/p>
&lt;p>&lt;strong>A8：&lt;/strong> 这里面分几个点，OAM 本身分两个部分。第一部分是规范，是处于 alpha 版本，计划在 2020 年内发布 beta 版本。beta 就是一个稳定版本，这是一个比较明确的计划。现在的 spec 是有可能会变的，但是有另外一个版本叫做 oam-kubernetes-runtime 插件，这是作为独立项目去运营的，计划在 Q3 发布稳定版本。即使我的 spec 发生的改变，但是插件会做向下兼容，保证 spec 变化不会影响你的系统，我们的 runtime 会提前发布稳定版本，应该是比较快的。如果构建平台化建议优先使用 runtime。&lt;/p>
&lt;p>&lt;strong>Q9：&lt;/strong> OAM 有没有稳定性考虑？比如说高可用。&lt;/p>
&lt;p>&lt;strong>A9：&lt;/strong> 这个是有的，目前 runtime 这个项目就在做很多稳定性的东西，这是阿里内部和微软内部的一个诉求。这块都是在做，肯定是有这方面考虑的，包括边界条件的一个覆盖。&lt;/p>
&lt;p>&lt;strong>Q10：&lt;/strong> 可不可介绍下双十一的状态下，有多少个 Pod 在支持？&lt;/p>
&lt;p>&lt;strong>A10：&lt;/strong> 这个数量会比较大，大概在十几万这样一个规模，应用容器数也是很多的。这个对大家的参考价值不是很大，因为阿里的架构和应用跟大多数同学看到的是不太一样的，大多数是个单元化的框架，每个应用拆分的微服务非常非常细。pod 数和容器数都是非常多的。&lt;/p>
&lt;p>&lt;strong>Q11：&lt;/strong> 目前 OAM 只有阿里和微软，以后像 google 这些大厂会加入么？&lt;/p>
&lt;p>&lt;strong>A11：&lt;/strong> 一定会的，接下来的计划会引入新的合作方。目前 google 和 aws 都对 OAM 有一些社区的支持。本身作为云原生的一个规范，也是有一些想法的。在初期的时候，大厂加入的速度会比较慢，更希望的是用户使用起来。大厂并不一定是 OAM 的主要用户，他们更多的是商业考虑。&lt;/p>
&lt;p>&lt;strong>Q12：&lt;/strong> OAM 是否会关联 Mesh？&lt;/p>
&lt;p>&lt;strong>A12：&lt;/strong> 一定会的，但是并不是说直接 Mesh 一个核心能力，更多的说作为 OAM trait 使用,比如描述一个流量的拓扑关系。&lt;/p>
&lt;p>&lt;strong>Q13：&lt;/strong> OAM 的高可用方案？&lt;/p>
&lt;p>&lt;strong>A13：&lt;/strong> OAM 本身就是个无状态服务，本身的高可用方案不是很复杂。&lt;/p>
&lt;p>&lt;strong>Q14：&lt;/strong> OAM 考虑是单集群还是多集群？&lt;/p>
&lt;p>&lt;strong>A14：&lt;/strong> 目前是单集群，但是我们马上也会发布多集群的模型，在阿里内部已经是多集群模型。简单来说多集群是两层模型。多集群的概念是定义在 Scope 里面的，通过 Scope 来决定 Workload 或者是 Components 放到哪个集群里面。我们会在社区尽快放出来。&lt;/p></description></item><item><title>Blog: 硬核致敬Linux ！30岁生日快乐！</title><link>https://desistdaydream.github.io/blog/copy/cE4x63tYxoqrDinifeWqeg/</link><pubDate>Thu, 26 Aug 2021 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/cE4x63tYxoqrDinifeWqeg/</guid><description>
&lt;p>原文链接：&lt;a href="https://mp.weixin.qq.com/s/cE4x63tYxoqrDinifeWqeg">https://mp.weixin.qq.com/s/cE4x63tYxoqrDinifeWqeg&lt;/a>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/Pn4Sm0RsAuhH4SOtTAkhF5RQnT4PAWdG2NT9Smu9eqEV5PAwKq3PbC6iagpqsfWz47RFLIZibibcIDAn3IyVS0ahw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>1991年8月25日，21岁的Linus Torvalds（以下简称Linus）做了一个免费的操作系统“Linux”，并在这一天向外界公布这个由“业余爱好”主导的个人项目；如今，全球超级计算机500强和超过70%的智能手机都在运行Linux，因此，8月25日也被许多Linux的爱好者视为Linux真正的诞生日期。&lt;/p>
&lt;h1 id="你好">你好&lt;a class="td-heading-self-link" href="#%e4%bd%a0%e5%a5%bd" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgH5rcBjAWV0lF8QBtlXSJgRrJqBP90P2rfTd8WpVRAtyzqxhbXd6QnNg/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>30 年前，Linus Torvalds 首次发布 Linux 内核时还是赫尔辛基大学的一名 21 岁学生。他的声明是这样开始的，“我正在做一个（免费的）操作系统（只是一个爱好，不会很大和专业&amp;hellip;&amp;hellip;）”。三十年后，排名前 500 的超级计算机都在运行 Linux，所有智能手机的 70% 以上都是如此。Linux 显然既庞大又专业。&lt;/p>
&lt;p>三十年来，Linus Torvalds 领导了 Linux 内核开发，激励了无数其他开发人员和开源项目。2005 年，Linus 还创建了 Git来帮助管理内核开发过程，此后它成为最受欢迎的版本控制系统，受到无数开源和专有项目的信赖。&lt;/p>
&lt;h3 id="linux历史">Linux历史&lt;a class="td-heading-self-link" href="#linux%e5%8e%86%e5%8f%b2" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;strong>OS史前历史&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHE70XibBtS3DT8Nf3r5k48PGFo8ON6CPEsuyBOxIia8eLIQOuuz6JV1aA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>Linux的历史&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHRicpx9aScqDmIdIib1M2UdibnVGVHJoTR5j94qiaCosHsT4G1XlPL1vYzA/640?wx_fmt=png" alt="">&lt;/p>
&lt;h3 id="linux系统">Linux系统&lt;a class="td-heading-self-link" href="#linux%e7%b3%bb%e7%bb%9f" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;strong>Linux系统软件架构&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgH1QmL07tiarw5K00x2LuwJEaRFCR4eev2O1DI1uEd6rZPOKnNZHzv5Eg/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>Linux系统由硬件、kernel、系统调用、shell、c库、应用程序组成，架构层次分明，Linux内的各种层功能独立，程序在用户空间和内核空间之间的分离，能支持更多应用。&lt;/p>
&lt;p>| 用户模态 | &lt;strong>用户应用&lt;/strong> | 例如：Bash，LibreOffice，GIMP，Blender，0 A.D.，Mozilla Firefox等 |
| 低层系统构件 | &lt;strong>系统守护进程&lt;/strong>：&lt;br>
systemd，runit，logind，networkd，PulseAudio等 | &lt;strong>窗口系统&lt;/strong>：&lt;br>
X11，Wayland，SurfaceFlinger(Android) | &lt;strong>其他库&lt;/strong>：&lt;br>
GTK+, Qt, EFL, SDL, SFML, FLTK, GNUstep等 | &lt;strong>图形&lt;/strong>：&lt;br>
Mesa，AMD Catalyst等 |
| &lt;strong>C标准库&lt;/strong> | open()，exec()，sbrk()，socket()，fopen()，calloc()，&amp;hellip; (直到2000个子例程)&lt;br>
glibc目标为POSIX/SUS兼容，musl和uClibc目标为嵌入式系统，bionic为Android而写等 |
| 内核模态 | &lt;strong>Linux内核&lt;/strong> | stat, splice, dup, read, open, ioctl, write, mmap, close, exit等（大约380个系统调用）&lt;br>
Linux内核系统调用接口（SCI，目标为POSIX/SUS兼容） |
| 进程调度子系统 | IPC子系统 | 内存管理子系统 | 虚拟文件子系统 | 网络子系统 |
| 其他构件：ALSA，DRI，evdev，LVM，device mapper，Linux Network Scheduler，Netfilter&lt;br>
Linux安全模块：SELinux，TOMOYO，AppArmor, Smack |
| 硬件（CPU，内存，数据存储设备等。） |&lt;/p>
&lt;p>&lt;strong>Linux内核代码架构&lt;/strong>&lt;/p>
&lt;p>&lt;strong>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHSXWCabp9jDHopYuOGHSSq3HgXcQKLkWedlzYiaNOBStEEod9YkB8JAw/640?wx_fmt=jpeg" alt="">&lt;/strong>&lt;/p>
&lt;p>Linux代码包含核心几个子系统，比如&lt;strong>内存子系统&lt;/strong>，&lt;strong>I/O子系统&lt;/strong>，&lt;strong>CPU(调度）子系统&lt;/strong>，&lt;strong>设备驱动子系统&lt;/strong>，&lt;strong>网络子系统&lt;/strong>，&lt;strong>虚拟文件子系统&lt;/strong>等。这里简单介绍一些比较重要的子系统。&lt;/p>
&lt;h3 id="调度子系统">调度子系统&lt;a class="td-heading-self-link" href="#%e8%b0%83%e5%ba%a6%e5%ad%90%e7%b3%bb%e7%bb%9f" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;strong>进程调度&lt;/strong>是Linux内核中最重要的子系统，它主要提供对CPU的访问控制。因为在计算机中，CPU资源是有限的，而众多的应用程序都要使用CPU资源，所以需要“进程调度子系统”对CPU进行调度管理。&lt;/p>
&lt;p>&lt;strong>进程调度子系统&lt;/strong>包括4个子模块（见下图），它们的功能如下：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHzhTgCrceib1hkg2RZuwSgf86iaN2JfyHMptZFZGdw0fhQW1hNLgMBlHA/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;ol>
&lt;li>
&lt;p>Scheduling Policy，实现进程调度的策略，它决定哪个（或哪几个）进程将拥有CPU。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Architecture-specific Schedulers，体系结构相关的部分，用于将对不同CPU的控制，抽象为统一的接口。这些控制主要在suspend和resume进程时使用，牵涉到CPU的寄存器访问、汇编指令操作等。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Architecture-independent Scheduler，体系结构无关的部分。它会和“Scheduling Policy模块”沟通，决定接下来要执行哪个进程，然后通过“Architecture-specific Schedulers模块”resume指定的进程。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>System Call Interface，系统调用接口。进程调度子系统通过系统调用接口，将需要提供给用户空间的接口开放出去，同时屏蔽掉不需要用户空间程序关心的细节。&lt;/p>
&lt;/li>
&lt;/ol>
&lt;h3 id="内存子系统">内存子系统&lt;a class="td-heading-self-link" href="#%e5%86%85%e5%ad%98%e5%ad%90%e7%b3%bb%e7%bb%9f" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;strong>内存管理&lt;/strong>同样是Linux内核中最重要的子系统，它主要提供对内存资源的访问控制。Linux系统会在硬件物理内存和进程所使用的内存（称作虚拟内存）之间建立一种映射关系，这种映射是以进程为单位，因而不同的进程可以使用相同的虚拟内存，而这些相同的虚拟内存，可以映射到不同的物理内存上。&lt;/p>
&lt;p>&lt;strong>内存管理子系统&lt;/strong>包括3个子模块（见下图），它们的功能如下：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHNY1OZLaKPcddjClNYLNRmEPuUt7fQf7iafZ7eJtrP46fWqws0wD5yww/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;ol>
&lt;li>
&lt;p>Architecture Specific Managers，体系结构相关部分。提供用于访问硬件Memory的虚拟接口。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Architecture Independent Manager，体系结构无关部分。提供所有的内存管理机制，包括：以进程为单位的memory mapping；虚拟内存的Swapping。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>System Call Interface，系统调用接口。通过该接口，向用户空间程序应用程序提供内存的分配、释放，文件的map等功能。&lt;/p>
&lt;/li>
&lt;/ol>
&lt;h3 id="虚拟文件子系统virtual-filesystem-vfs">虚拟文件子系统（Virtual Filesystem, VFS）&lt;a class="td-heading-self-link" href="#%e8%99%9a%e6%8b%9f%e6%96%87%e4%bb%b6%e5%ad%90%e7%b3%bb%e7%bb%9fvirtual-filesystem-vfs" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>传统意义上的文件系统，是一种存储和组织计算机数据的方法。它用易懂、人性化的方法（文件和目录结构），抽象计算机磁盘、硬盘等设备上冰冷的数据块，从而使对它们的查找和访问变得容易。因而文件系统的实质，就是“存储和组织数据的方法”，文件系统的表现形式，就是“从某个设备中读取数据和向某个设备写入数据”。&lt;/p>
&lt;p>随着计算机技术的进步，存储和组织数据的方法也是在不断进步的，从而导致有多种类型的文件系统，例如FAT、FAT32、NTFS、EXT2、EXT3等等。而为了兼容，操作系统或者内核，要以相同的表现形式，同时支持多种类型的文件系统，这就延伸出了**虚拟文件系统（VFS）**的概念。VFS的功能就是管理各种各样的文件系统，屏蔽它们的差异，以统一的方式，为用户程序提供访问文件的接口。&lt;/p>
&lt;p>我们可以从磁盘、硬盘、NAND Flash等设备中读取或写入数据，因而最初的文件系统都是构建在这些设备之上的。这个概念也可以推广到其它的硬件设备，例如内存、显示器（LCD）、键盘、串口等等。我们对硬件设备的访问控制，也可以归纳为读取或者写入数据，因而可以用统一的文件操作接口访问。Linux内核就是这样做的，除了传统的磁盘文件系统之外，它还抽象出了设备文件系统、内存文件系统等等。这些逻辑，都是由VFS子系统实现。&lt;/p>
&lt;p>&lt;strong>VFS子系统&lt;/strong>包括6个子模块（见下图），它们的功能如下：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHxGOz2c8yZ6yxrrHeibxu3ac8nibP9KGUkVkrXPmgIH9iasFgLjaofdWqA/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;ol>
&lt;li>
&lt;p>Device Drivers，设备驱动，用于控制所有的外部设备及控制器。由于存在大量不能相互兼容的硬件设备（特别是嵌入式产品），所以也有非常多的设备驱动。因此，Linux内核中将近一半的Source Code都是设备驱动，大多数的Linux底层工程师（特别是国内的企业）都是在编写或者维护设备驱动，而无暇估计其它内容（它们恰恰是Linux内核的精髓所在）。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Device Independent Interface， 该模块定义了描述硬件设备的统一方式（统一设备模型），所有的设备驱动都遵守这个定义，可以降低开发的难度。同时可以用一致的形势向上提供接口。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Logical Systems，每一种文件系统，都会对应一个Logical System（逻辑文件系统），它会实现具体的文件系统逻辑。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>System Independent Interface，该模块负责以统一的接口（快设备和字符设备）表示硬件设备和逻辑文件系统，这样上层软件就不再关心具体的硬件形态了。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>System Call Interface，系统调用接口，向用户空间提供访问文件系统和硬件设备的统一的接口。&lt;/p>
&lt;/li>
&lt;/ol>
&lt;h3 id="网络子系统net">网络子系统（Net）&lt;a class="td-heading-self-link" href="#%e7%bd%91%e7%bb%9c%e5%ad%90%e7%b3%bb%e7%bb%9fnet" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;strong>网络子系统&lt;/strong>在Linux内核中主要负责管理各种网络设备，并实现各种网络协议栈，最终实现通过网络连接其它系统的功能。在Linux内核中，网络子系统几乎是自成体系，它包括5个子模块（见下图），它们的功能如下：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHy9IqgNnoDPLwVHDKqVBzD6iaJtzNk7wm3h9aSn1Nf6xOsNM870ScwEA/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;ol>
&lt;li>
&lt;p>Network Device Drivers，网络设备的驱动，和VFS子系统中的设备驱动是一样的。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Device Independent Interface，和VFS子系统中的是一样的。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Network Protocols，实现各种网络传输协议，例如IP, TCP, UDP等等。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>Protocol Independent Interface，屏蔽不同的硬件设备和网络协议，以相同的格式提供接口（socket)。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>System Call interface，系统调用接口，向用户空间提供访问网络设备的统一的接口。&lt;/p>
&lt;/li>
&lt;/ol>
&lt;p>Linux内核版本时间线：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHRqUJPPCSOutrOnet4ICAkEbUHf9LLgGX4rorHj7nXDOcyTvLEJ29Bg/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>Linux内核支持各种硬件架构&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linux内核&lt;/strong>最成功的地方之一就是支持各种硬件架构，为软件提供了公共的平台：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHlp75WAFV1ibBJ0IAN2BVxzKia8ET9rFicziaQxtA0sEl0icYnHula6HzsIQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>基于Linux的系统是一个模块化的类Unix操作系统。&lt;strong>Linux操作系统&lt;/strong>的大部分设计思想来源于20世纪70年代到80年代的Unix操作系统所建立的基本设计思想。Linux系统使用宏内核，由Linux内核负责处理进程控制、网络，以及外围设备和文件系统的访问。在系统运行的时候，设备驱动程序要么与内核直接整合，要么以加载模块形式添加。&lt;/p>
&lt;p>&lt;strong>Linux具有设备独立性&lt;/strong>，它内核具有高度适应能力，从而给系统提供了更高级的功能。GNU用户界面组件是大多数Linux操作系统的重要组成部分，提供常用的C函数库，Shell，还有许多常见的Unix实用工具，可以完成许多基本的操作系统任务。大多数Linux系统使用的图形用户界面建立在X窗口系统之上，由X窗口(XWindow)系统通过软件工具及架构协议来建立操作系统所用的图形用户界面.&lt;/p>
&lt;p>&lt;strong>基于Linux内核各种衍生OS系统&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHiaA5ia2r6z3iarNHHZN7gHOISWONZ0vfBibAz5wm0tJfxaBao2KOF4fM8Q/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>各种发行版本&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHJQp1UUv39Vx04CB4W3DSdh2twrDS7kZV01ygjFXbyeUCfg92kJpiaqA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>当前比较流行发行版是：&lt;strong>Debian&lt;/strong>、&lt;strong>Ubuntu&lt;/strong>、&lt;strong>Fedora&lt;/strong>、&lt;strong>CentOS&lt;/strong>、&lt;strong>Arch Linux&lt;/strong>和&lt;strong>openSUSE&lt;/strong>等，每个发行版都有自己优势地方，都有一批忠实用户。&lt;/p>
&lt;p>&lt;strong>基于Linux内核著名OS&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Android&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHwsGP7L9tNBESaK6GlTHaZWjXcial9ia9bWDQoXqPDUSh4rxfYtCOG1XA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>Android&lt;/strong>（读音：英：[&amp;lsquo;ændrɔɪd]，美：[ˈænˌdrɔɪd]），中文用户多以非官方名称“安卓”称之，是一个基于Linux内核与其他开源软件的开放源代码的移动操作系统，Android的内核是根据Linux内核的长期支持的分支，具有典型的Linux调度和功能。截至2018年，Android的目标是Linux内核的4.4、4.9或是4.14版本。&lt;/p>
&lt;p>&lt;strong>ChromeOS&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHGtbgyZUUeFSicfcZCeRpTGicmJI5vzDibiaCibBfoA06demaPcn1iaVficviag/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>Chrome OS&lt;/strong> 是由Google设计基于Linux内核的操作系统，并使用Google Chrome浏览器作为其主要用户界面。因此，Chrome OS主要支持Web应用程序[6]，2016年起开始陆续兼容Android应用程序（可通过Google Play商店下载）和Linux应用程序。&lt;/p>
&lt;p>&lt;strong>鸿蒙OS&lt;/strong>&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHdmDMzZHEZR94PaMFm9CYibMfvicxDs2ULz9jQJVZKUQNOtAUduCqRJUA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>鸿蒙&lt;/strong>（&lt;strong>HarmonyOS&lt;/strong>，开发代号Ark[1]）是华为自2012年开发的一款可兼容Android应用程序的跨平台分布式操作系统[2]。系统性能包括利用“分布式”技术将各款设备融合成一个“超级终端”，便于操作和共享各设备资源。[3][4][5]系统架构支持多内核，包括Linux内核、LiteOS和鸿蒙微内核，可按各种智能设备选择所需内核，例如在低功耗设备上使用LiteOS内核。[6][7]2019年8月华为发布首款搭载鸿蒙操作系统的产品“荣耀智能屏”，之后于2021年6月发布搭载鸿蒙操作系统的智能手机、平板电脑和智能手表。&lt;/p>
&lt;p>Linux 内核是最大且变动最快的开源项目之一，它由大约 53,600 个文件和近 2,000 万行代码组成。在全世界范围内超过 15,600 位程序员为它贡献代码，Linux 内核项目的维护者使用了如下的协作模型。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHHIWib5fYsnBg0ziccyM2IEj3VRhGUQlkzPSyDpQ5cicLo148yoJ8z33LQ/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>如果你有&lt;strong>深入linux内核的激情&lt;/strong>和&lt;strong>极客精神&lt;/strong>，可以为Linux项目贡献源码，具体如何提交第一个补丁，可以详细阅读下面文章，这里篇幅有限不展开：&lt;/p>
&lt;p>&lt;a href="https://opensource.com/article/18/8/first-linux-kernel-patch">https://opensource.com/article/18/8/first-linux-kernel-patch&lt;/a>&lt;/p>
&lt;p>Linux 开源代码仓库：&lt;/p>
&lt;p>&lt;a href="https://github.com/torvalds/linux">https://github.com/torvalds/linux&lt;/a>&lt;/p>
&lt;p>提交给kernel的补丁，刚开始可能不需要高深的技术，比如这个补丁，可以 是简单的对于已有内容的格式或拼写错误的修正，比如这个来自4岁小朋友的补丁：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHv1787MroX0hXfDbFQCZhqCW68Otw5fpggEib5QicCewZGj0ZRWDVBduQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHhCiab6dlIM2ibMY4KPSrup1iaHNp6ciayzJ0oBRcvyIibRLltBDSw1zyxMA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>Linux内核学习资源&lt;/strong>&lt;/p>
&lt;p>&lt;strong>源码：&lt;/strong>&lt;/p>
&lt;p>&lt;a href="https://elixir.bootlin.com/linux/latest/source">https://elixir.bootlin.com/linux/latest/source&lt;/a>&lt;/p>
&lt;p>在线交叉索引看源码，包括Linux几乎所有版本；&lt;/p>
&lt;p>&lt;a href="https://github.com/torvalds/linux">https://github.com/torvalds/linux&lt;/a>&lt;/p>
&lt;p>内核github仓库，可以下载本地，编译，修改和开发。&lt;/p>
&lt;p>&lt;strong>网站&lt;/strong>&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://www.kernel.org">http://www.kernel.org&lt;/a>&lt;/strong>&lt;/p>
&lt;p>可以通过这个网站上下载内核的源代码和补丁、跟踪内核bug等&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://lwn.net">http://lwn.net&lt;/a>&lt;/strong>&lt;/p>
&lt;p>Linux 内核最新消息，提供给了定期的与内核开发相关的报道&lt;/p>
&lt;p>&lt;strong>&lt;a href="https://www.wiki.kernel.org/">https://www.wiki.kernel.org/&lt;/a>&lt;/strong>&lt;/p>
&lt;p>各种子模块wiki列表&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://www.linuxdoc.org">http://www.linuxdoc.org&lt;/a>&lt;/strong>&lt;/p>
&lt;p>Linux Documentation Project(Linux文档项目)，拥有大量称为“HowTo”&lt;br>
的文档，其中一些是技术性的，并涉及到一些内核相关的主题。&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://www.kerneltravel.net/">http://www.kerneltravel.net/&lt;/a>&lt;/strong>&lt;/p>
&lt;p>国内Linux内核之旅开源社区&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://www.linux-mm.org">http://www.linux-mm.org&lt;/a>&lt;/strong>&lt;br>
该页面面向Linux内存管理开发，其中包含大量有用的信息，并且还包含大量与内核相关的Web站点链接。&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://www.wowotech.net">http://www.wowotech.net&lt;/a>&lt;/strong>&lt;/p>
&lt;p>博客专注分享linux内核知识（偏嵌入式方向）, 很多文章都非常精华和透彻，值得内核学习者学习；&lt;/p>
&lt;p>&lt;strong>&lt;a href="https://blog.csdn.net/gatieme">https://blog.csdn.net/gatieme&lt;/a>&lt;/strong>&lt;/p>
&lt;p>操作系统优质博客，可以学习linux 调度相关内核知识；&lt;/p>
&lt;p>&lt;strong>&lt;a href="https://blog.csdn.net/dog250">https://blog.csdn.net/dog250&lt;/a>&lt;/strong>&lt;/p>
&lt;p>dog250的文章都比较深刻，属于Linux内核进阶，可能不太适合入门，建议入门后，再看这里文章，会让你醍醐灌顶。&lt;/p>
&lt;p>&lt;strong>&lt;a href="https://www.kernel.org/doc">https://www.kernel.org/doc&lt;/a>&lt;/strong>&lt;/p>
&lt;p>内核文档&lt;/p>
&lt;p>&lt;strong>书籍&lt;/strong>&lt;/p>
&lt;p>《深入理解Linux内核》&lt;/p>
&lt;p>《深入Linux内核架构》&lt;/p>
&lt;p>《Linux内核设计与实现》&lt;/p>
&lt;p>《Linux内核源代码情景分析》&lt;/p>
&lt;p>《深入理解LINUX网络内幕》&lt;/p>
&lt;p>《深入理解Linux虚拟内存管理》&lt;/p>
&lt;p>《Linux设备驱动程序》&lt;/p>
&lt;h3 id="git分布式版本控制系统">Git分布式版本控制系统&lt;a class="td-heading-self-link" href="#git%e5%88%86%e5%b8%83%e5%bc%8f%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6%e7%b3%bb%e7%bb%9f" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHplRZhR4pd07qoWDXz6icgRfqLyyC9SbZnxx2PIVCOyYHuWQjYDC3IDw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>2005 年，Linus还创建了 &lt;strong>Git&lt;/strong>，这是非常流行的分布式源代码控制系统。迅速将 Linux 内核源代码树从专有 Bitkeeper 迁移到新创建的开源 Git。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHK6ewlMwmzxJxkuJ2Wb4dUxdUmOuUcVybz2NpicpKYHpbW3Kf8Rg9iabA/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>git 架构&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Git&lt;/strong> 是出于需要而创建的，不是因为发现源代码控制很有趣，而是因为其他多数源代码控制系统不好用，不能满足当时开发需求，并且 git 在 Linux 开发模型中确实运行得相当好，BitKeeper变得站不住脚。&lt;/p>
&lt;p>完美适应现代开源软件的开发模式，分布式版本管理：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHq1UTS3ZCgoIbcKBtU67SJcsLUS7osnicsG9LzkJM75hkjT1O9wVat9g/640?wx_fmt=png" alt="">&lt;/p>
&lt;h3 id="linux内核名人堂">Linux内核名人堂&lt;a class="td-heading-self-link" href="#linux%e5%86%85%e6%a0%b8%e5%90%8d%e4%ba%ba%e5%a0%82" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>让我们膜拜一下对Linux内核做出核心贡献的大神们：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHtEVHKmWufP3VMY68yCQnh3fgdg40AFwfHhLmz2PaqLqXZJHCKQSn9Q/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>林纳斯·班奈狄克·托瓦兹&lt;/strong>（1969年12月28日－），生于芬兰赫尔辛基市，拥有美国国籍，Linux内核的最早作者，随后发起了这个开源项目，担任Linux内核的首要架构师与项目协调者，是当今世界最著名的电脑程序员、黑客之一。他还发起了开源项目Git，并为主要的开发者。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHxticTE1khTNhUIXzRscgET2fazkOk0ISAzIrORD6X51wTUPSlfzCUxg/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>大卫·史提芬·米勒&lt;/strong>（英语：David Stephen Miller，1974年11月26日－），网络昵称为 DaveM，生于美国新泽西州新布朗斯维克，著名程式员与骇客，负责Linux核心网络功能以及SPARC平台的实作。他也参与其他开源软件的开发，是GCC督导委员会的成员之一。根据2013年8月的统计，米勒是Linux核心源代码第二大的贡献者，自2005年开始，已经提交过4989个patch。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHC4qCA4jxF7rIrqwJpzFhzESIQx7ibZ5dIXkicz0XsBcwAibveORZ4NA5g/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>葛雷格·克罗-哈曼&lt;/strong>（英语：Greg Kroah-Hartman，姓名缩写为GKH）， Linux核心开发者，目前为 Linux 核心中稳定分支（&lt;code>-stable&lt;/code>）的维护者[2]，他也是staging 子系统[2]、USB[2]driver core、debugfs、kref、kobject、sysfs kernel 子系统[2]、 TTY layer [2]、linux-hotplug、Userspace I/O（与 Hans J. Koch 共同维护）等专案的维护者[2]，也创立了udev专案。除此之外，他亦协助维护Gentoo Linux中上述程式及 kernel 的套件。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHiaR4nLoIu5MJ2cAFdjykndwROoicmZXR7rpqqXyReD4RCiaPwOrsc2urQ/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>艾伦·考克斯&lt;/strong>（英语：Alan Cox，1968年7月22日－）是一名英国程序员，生于英格兰索利赫尔。他自1991年开始投入Linux内核的开发工作，在开发者社群中有很高的地位，是Linux开发工作中的关键人物之一。他负责维护Linux内核 2.2版这个分支，在2.4版中也提供许多程式码，拥有自己的分支版本。他住在威尔斯斯旺西，他的妻子于2015年逝世[1][2][3]。2020年他再婚[4][5]。他于1991年在斯旺西大学获得计算机科学理学学士学位，2005年在那里获得工商管理硕士学位[6]。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHuOQOEoMQhVfJibrcPjBxIy3Y61qGos8lFbz70cSf8Tycwy8OQsX5Nhg/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>英格·蒙内&lt;/strong>（匈牙利语：Ingo Molnár），匈牙利软件程序员与骇客，在linux内核上有许多贡献，也拥有自己的linux分支版本。对于操作系统的安全性与效能提升方面，他的声名卓著，在linux内核中，他于Linux-2.6.0版加入O(1)排程器，在 Linux-2.6.23版中加入&lt;strong>完全公平调度器CFS&lt;/strong>（Completely Fair Scheduler）。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHBWhcnGvYiaDtbmsqnbjoRFnyXSTs5ibMAZ7Tm0vJuU573vKyrpzvvIjw/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;strong>米格尔·德伊卡萨&lt;/strong>（西班牙语：Miguel de Icaza ，1972年11月23日－），生于墨西哥市，著名墨西哥籍自由软件开发者，为GNOME项目与Mono项目的发起人。但后来[何时？]退出了GNOME项目。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHdkfW1X7mmFsq1ShM2iaHl6XJD5RPK1xaOJ60hAxiczdEDzGWrw2HorhA/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>罗伯特·马修·拉姆&lt;/strong>（英语：Robert Matthew Love，1981年9月25日－），生于美国佛罗里达州，为著名自由软件程式开发者、作家，现职为google软件工程师。现居于波士顿。他是linux核心的主要开发者之一，主要负责程式排程、先占式核心、虚拟内存子系统、核心事件层。他也加入了GNOME计划。目前他在google，主要负责Android系统的开发。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHn9h6QWB8CfkNDIeoLLNgW4p3VkHveT61gVHiccEtjfkF708FfXUW3Aw/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>安德鲁·基斯·保罗·莫顿&lt;/strong>（英语：Andrew Keith Paul Morton，1959年－），生于英国英格兰，澳洲软件工程师与著名骇客。他是Linux核心开发社群的领导者之一，现为ext3的共同维护者，负责区块装置的日志层（Journaling layer for block devices，JBD）。他也是mm tree的负责人。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgH2O1Ze7oATYXWrxfiaHkZqB5ggRna9RRft2huTliaQWyNrV061Z0q3icKQ/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>埃里克·斯蒂芬·雷蒙&lt;/strong>（英语：Eric Steven Raymond，1957年12月4日－），是一名程序员，《大教堂与市集》的作者、《新黑客词典》（&amp;ldquo;Jargon File&amp;rdquo;）的维护人、著名黑客。作为《新黑客词典》的主要编撰人以及维护者，雷蒙很早就被认为是黑客文化的历史学家以及人类学家。但是在1997年以后，雷蒙被广泛公认为是开放源代码运动的主要领导者之一，并且是最为大众所知道（并最具争议性）的黑客。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHutx5g8HmjnzMFaeXZ7kc8TOttGwG1GUg5FswuJtelvTo0GWbZTOjPQ/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>&lt;strong>西奥多·曹&lt;/strong>（英语：Theodore Y. Ts&amp;rsquo;o，1968年1月23日－），小名&lt;strong>泰德·曹&lt;/strong>（Ted Tso），汉名&lt;strong>曹子德&lt;/strong>[1]，生于美国加利福尼亚州帕罗奥图，著名的自由软件工程师，专长于文件系统设计。他是Linux内核在北美最早的开发者，负责ext2、ext3与ext4文件系统的开发与维护工作。他也是e2fsprogs的开发者。为自由标准组织的创始者之一，也曾担任Linux基金会首席技术官。&lt;/p>
&lt;p>由于互联网发达，当前不管是从个人爱好，还是工作原因，对内核贡献的国人越来越多：&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHQ2BEn5hagVPEelr1qE2EHlGWclItckm0saPvuB5zACbZWzIB6kbNeQ/640?wx_fmt=png" alt="">&lt;/p>
&lt;p>&lt;a href="http://www.remword.com/kps">http://www.remword.com/kps&lt;/a>_result/all_whole_line_country.html&lt;/p>
&lt;h3 id="最后">最后&lt;a class="td-heading-self-link" href="#%e6%9c%80%e5%90%8e" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>30年的时间，Linux从一个个人玩具变成现在庞然大物，估值超过100亿美元，Linux还带来一股开源潮流，让开源软件百花齐放，对计算机发展和开源文化起到极大促进作用。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHibFAnWeJmNESo5lWBCcEYdI2MpVkiabQ6n4B3FRpv1FwfDpYaTDWXG4w/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>Linux 庞大的生态与发展过程，Linus伟大而富有创造力并不足以在一篇文章中尽述。&lt;/p>
&lt;p>匆匆30 年，Linux 已经不仅仅是改变了世界，而且已经成为了这个世界不可或缺的一部分感谢 Linus Torvalds，感谢为之致力的一切贡献者！&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_jpg/cYSwmJQric6nhH4RQfgaJfjrfmLsALibgHxfSUWjnl9ia6I5GPetib9tqehO96tNWdaPEQzicHIjk2QQ1eNq5WyQTDw/640?wx_fmt=jpeg" alt="">&lt;/p>
&lt;p>最后，为了致敬Linux，希望大家三连支持，让更多人可以看到！&lt;/p>
&lt;h3 id="参考和扩展">参考和扩展&lt;a class="td-heading-self-link" href="#%e5%8f%82%e8%80%83%e5%92%8c%e6%89%a9%e5%b1%95" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>&lt;a href="http://www.atguigu.com/jsfx/5694.html">http://www.atguigu.com/jsfx/5694.html&lt;/a>&lt;/p>
&lt;p>&lt;a href="https://opensource.com/article/16/12/yearbook-9-lessons-25-years-linux-kernel-development">https://opensource.com/article/16/12/yearbook-9-lessons-25-years-linux-kernel-development&lt;/a>&lt;/p>
&lt;p>&lt;a href="https://www.reddit.com/r/linux/comments/2pqqla/kernel">https://www.reddit.com/r/linux/comments/2pqqla/kernel&lt;/a>_commit_4_year_old_girl_fixes_formatting_to/utm_source=amp&amp;amp;utm_medium=&amp;amp;utm_content=post_title&lt;/p>
&lt;p>&lt;a href="http://oss.org.cn/ossdocs/linux/kernel/a1/index.html">http://oss.org.cn/ossdocs/linux/kernel/a1/index.html&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://www.wowotech.net/linux_kenrel/11.html">http://www.wowotech.net/linux_kenrel/11.html&lt;/a>&lt;/p>
&lt;p>&lt;a href="https://www.wikiwand.com/zh/Linux">https://www.wikiwand.com/zh/Linux&lt;/a>&lt;/p>
&lt;p>&lt;a href="https://zh.wikipedia.org/wiki/Category:Linux%E6%A0%B8%E5%BF%83%E9%A7%AD%E5%AE%A2">https://zh.wikipedia.org/wiki/Category:Linux%E6%A0%B8%E5%BF%83%E9%A7%AD%E5%AE%A2&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/software-architecture">http://www.chromium.org/chromium-os/chromiumos-design-docs/software-architecture&lt;/a>&lt;/p>
&lt;p>- END -&lt;/p></description></item><item><title>Blog: ext 文件系统机制原理剖析</title><link>https://desistdaydream.github.io/blog/copy/ext_filesystem/</link><pubDate>Sun, 25 Oct 2020 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/ext_filesystem/</guid><description>
&lt;p>原文链接：&lt;a href="https://www.junmajinlong.com/linux/ext_filesystem/">https://www.junmajinlong.com/linux/ext_filesystem/&lt;/a>&lt;/p>
&lt;hr>
&lt;p>&lt;strong>&lt;a href="https://www.junmajinlong.com/linux/index">回到 Linux 基础系列文章大纲&lt;/a>&lt;/strong>&lt;br>
&lt;strong>&lt;a href="https://www.junmajinlong.com/shell/index">回到 Shell 系列文章大纲&lt;/a>&lt;/strong>&lt;/p>
&lt;hr>
&lt;p>将磁盘进行分区，分区是将磁盘按柱面进行物理上的划分。划分好分区后还要进行格式化，然后再挂载才能使用 (不考虑其他方法)。格式化分区的过程其实就是创建文件系统。&lt;/p>
&lt;p>文件系统的类型有很多种，如 CentOS 5 和 CentOS 6 上默认使用的 ext2/ext3/ext4，CentOS 7 上默认使用的 xfs，windows 上的 NTFS，光盘类的文件系统 ISO9660，MAC 上的混合文件系统 HFS，网络文件系统 NFS，Oracle 研发的 btrfs，还有老式的 FAT/FAT32 等。&lt;/p>
&lt;p>本文将非常全面且详细地介绍 ext 家族的文件系统，中间还非常详细地介绍了 inode、软链接、硬链接、数据存储方式以及操作文件的理论，基本上看完本文，对文件系统的宏观理解将再无疑惑。ext 家族的文件系统有 ext2/ext3/ext4，ext3 是有日志的 ext2 改进版，ext4 对相比 ext3 做了非常多的改进。虽然 xfs/btrfs 等文件系统有所不同，但它们只是在实现方式上不太同，再加上属于自己的特性而已。&lt;/p>
&lt;h2 id="block的出现-block的出现block-的出现">&lt;a href="#block%E7%9A%84%E5%87%BA%E7%8E%B0" title="block的出现">&lt;/a>block 的出现&lt;a class="td-heading-self-link" href="#block%e7%9a%84%e5%87%ba%e7%8e%b0-block%e7%9a%84%e5%87%ba%e7%8e%b0block-%e7%9a%84%e5%87%ba%e7%8e%b0" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>硬盘最底层的读写 IO 一次是一个扇区 512 字节，如果要读写大量文件，以扇区为单位肯定很慢很消耗性能，所以硬盘使用了一个称作逻辑块的概念。逻辑块是逻辑的，由磁盘驱动器负责维护和操作，它并非是像扇区一样物理划分的。一个逻辑块的大小可能包含一个或多个扇区，每个逻辑块都有唯一的地址，称为 LBA。有了逻辑块之后，磁盘控制器对数据的操作就以逻辑块为单位，一次读写一个逻辑块，磁盘控制器知道如何将逻辑块翻译成对应的扇区并读写数据。&lt;/p>
&lt;p>到了 Linux 操作系统层次，通过文件系统提供了一个也称为块的读写单元，文件系统数据块的大小一般为 1024bytes (1K) 或 2048bytes (2K) 或 4096bytes (4K)。文件系统数据块也是逻辑概念，是文件系统层次维护的，而磁盘上的逻辑数据块是由磁盘控制器维护的，文件系统的 IO 管理器知道如何将它的数据块翻译成磁盘维护的数据块地址 LBA。对于使用文件系统的 IO 操作来说，比如读写文件，这些 IO 的基本单元是文件系统上的数据块，一次读写一个文件系统数据块。比如需要读一个或多个块时，文件系统的 IO 管理器首先计算这些文件系统块对应在哪些磁盘数据块，也就是计算出 LBA，然后通知磁盘控制器要读取哪些块的数据，硬盘控制器将这些块翻译成扇区地址，然后从扇区中读取数据，再通过硬盘控制器将这些扇区数据重组写入到内存中去。&lt;/p>
&lt;p>本文既然是讨论文件系统的，那么重点自然是在文件系统上而不是在磁盘上，所以后文出现的 block 均表示的是文件系统的数据块而不是磁盘维护的逻辑块。&lt;/p>
&lt;p>文件系统 block 的出现使得在文件系统层面上读写性能大大提高，也大量减少了碎片。但是它的副作用是可能造成空间浪费。由于文件系统以 block 为读写单元，即使存储的文件只有 1K 大小也将占用一个 block，剩余的空间完全是浪费的。在某些业务需求下可能大量存储小文件，这会浪费大量的空间。&lt;/p>
&lt;p>尽管有缺点，但是其优点足够明显，在当下硬盘容量廉价且追求性能的时代，使用 block 是一定的。&lt;/p>
&lt;h2 id="inode的出现-inode的出现inode-的出现">&lt;a href="#inode%E7%9A%84%E5%87%BA%E7%8E%B0" title="inode的出现">&lt;/a>inode 的出现&lt;a class="td-heading-self-link" href="#inode%e7%9a%84%e5%87%ba%e7%8e%b0-inode%e7%9a%84%e5%87%ba%e7%8e%b0inode-%e7%9a%84%e5%87%ba%e7%8e%b0" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>如果存储的 1 个文件占用了大量的 block 读取时会如何？假如 block 大小为 1KB，仅仅存储一个 10M 的文件就需要 10240 个 block，而且这些 blocks 很可能在位置上是不连续在一起的 (不相邻)，读取该文件时难道要从前向后扫描整个文件系统的块，然后找出属于该文件的块吗？显然是不应该这么做的，因为太慢太傻瓜式了。再考虑一下，读取一个只占用 1 个 block 的文件，难道只读取一个 block 就结束了吗？并不是，仍然是扫描整个文件系统的所有 block，因为它不知道什么时候扫描到，扫描到了它也不知道这个文件是不是已经完整而不需要再扫描其他的 block。&lt;/p>
&lt;p>另外，每个文件都有属性 (如权限、大小、时间戳等)，这些属性类的元数据存储在哪里呢？难道也和文件的数据部分存储在块中吗？如果一个文件占用多个 block 那是不是每个属于该文件的 block 都要存储一份文件元数据？但是如果不在每个 block 中存储元数据文件系统又怎么知道某一个 block 是不是属于该文件呢？但是显然，每个数据 block 中都存储一份元数据太浪费空间。&lt;/p>
&lt;p>文件系统设计者当然知道这样的存储方式很不理想，所以需要优化存储方式。如何优化？对于这种类似的问题的解决方法是使用索引，通过扫描索引找到对应的数据，而且索引可以存储部分数据。&lt;/p>
&lt;p>在文件系统上索引技术具体化为索引节点 (index node)，在索引节点上存储的部分数据即为文件的属性元数据及其他少量信息。一般来说索引占用的空间相比其索引的文件数据而言占用的空间就小得多，扫描它比扫描整个数据要快得多，否则索引就没有存在的意义。这样一来就解决了前面所有的问题。&lt;/p>
&lt;p>在文件系统上的术语中，索引节点称为 inode。在 inode 中存储了 inode 号（注，inode 中并未存储 inode num，但为了方便理解，这里暂时认为它存储了 inode 号）、文件类型、权限、文件所有者、大小、时间戳等元数据信息，最重要的是还存储了指向属于该文件 block 的指针，这样读取 inode 就可以找到属于该文件的 block，进而读取这些 block 并获得该文件的数据。由于后面还会介绍一种指针，为了方便称呼和区分，暂且将这个 inode 记录中指向文件 data block 的指针称之为 block 指针。以下是 ext2 文件系统中 inode 包含的信息示例：&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>Inode: 12 Type: regular Mode: 0644 Flags: 0x0
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Generation: 1454951771 Version: 0x00000000:00000001
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>User: 0 Group: 0 Size: 5
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>File ACL: 0 Directory ACL: 0
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Links: 1 Blockcount: 8
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Fragment: Address: 0 Number: 0 Size: 0
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> ctime: 0x5b628db2:15e0aff4 -- Thu Aug 2 12:50:58 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> atime: 0x5b628db2:15e0aff4 -- Thu Aug 2 12:50:58 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> mtime: 0x5b628db2:15e0aff4 -- Thu Aug 2 12:50:58 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crtime: 0x5b628db2:15e0aff4 -- Thu Aug 2 12:50:58 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Size of extra inode fields: 28
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>BLOCKS:
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>(0):1024
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>TOTAL: 1
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>一般 inode 大小为 128 字节或 256 字节，相比那些 MB 或 GB 计算的文件数据而言小得多的多，但也要知道可能一个文件大小小于 inode 大小，例如只占用 1 个字节的文件。&lt;/p>
&lt;h2 id="bmap出现-bmap出现bmap-出现">&lt;a href="#bmap%E5%87%BA%E7%8E%B0" title="bmap出现">&lt;/a>bmap 出现&lt;a class="td-heading-self-link" href="#bmap%e5%87%ba%e7%8e%b0-bmap%e5%87%ba%e7%8e%b0bmap-%e5%87%ba%e7%8e%b0" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>在向硬盘存储数据时，文件系统需要知道哪些块是空闲的，哪些块是已经占用了的。最笨的方法当然是从前向后扫描，遇到空闲块就存储一部分，继续扫描直到存储完所有数据。&lt;/p>
&lt;p>优化的方法当然也可以考虑使用索引，但是仅仅 1G 的文件系统就有 1KB 的 block 共 1024*1024=1048576 个，这仅仅只是 1G，如果是 100G、500G 甚至更大呢，仅仅使用索引索引的数量和空间占用也将极大，这时就出现更高一级的优化方法：使用块位图 (bitmap 简称 bmap)。&lt;/p>
&lt;p>位图只使用 0 和 1 标识对应 block 是空闲还是被占用，0 和 1 在位图中的位置和 block 的位置一一对应，第一位标识第一个块，第二个位标识第二个块，依次下去直到标记完所有的 block。&lt;/p>
&lt;p>考虑下为什么块位图更优化。在位图中 1 个字节 8 个位，可以标识 8 个 block。对于一个 block 大小为 1KB、容量为 1G 的文件系统而言，block 数量有 1024*1024 个，所以在位图中使用 1024*1024 个位共 1024*1024/8=131072 字节 = 128K，即 1G 的文件只需要 128 个 block 做位图就能完成一一对应。通过扫描这 100 多个 block 就能知道哪些 block 是空闲的，速度提高了非常多。&lt;/p>
&lt;p>但是要注意，&lt;strong>bmap 的优化针对的是写优化，因为只有写才需要找到空闲 block 并分配空闲 block&lt;/strong>。对于读而言，只要通过 inode 找到了 block 的位置，cpu 就能迅速计算出 block 在物理磁盘上的地址，cpu 的计算速度是极快的，计算 block 地址的时间几乎可以忽略，那么读速度基本认为是受硬盘本身性能的影响而与文件系统无关。大多数稍大一点的文件可能都会存储在不连续的 block 上，而且使用了一段时间的文件系统可能会有不少碎片，这时硬盘的随机读取性能直接决定读数据的速度，这也是机械硬盘速度相比固态硬盘慢的多的多的原因之一，而且固态硬盘的随机读和连续读取速度几乎是一致的，对它来说，文件系统碎片的多少并不会影响读取速度。&lt;/p>
&lt;p>虽然 bmap 已经极大的优化了扫描，但是仍有其瓶颈：如果文件系统是 100G 呢？100G 的文件系统要使用 128*100=12800 个 1KB 大小的 block，这就占用了 12.5M 的空间了。试想完全扫描 12800 个很可能不连续的 block 这也是需要占用一些时间的，虽然快但是扛不住每次存储文件都要扫描带来的巨大开销。&lt;/p>
&lt;p>所以需要再次优化，如何优化？简而言之就是将文件系统划分开形成块组，至于块组的介绍放在后文。&lt;/p>
&lt;h2 id="inode表的出现-inode表的出现inode-表的出现">&lt;a href="#inode%E8%A1%A8%E7%9A%84%E5%87%BA%E7%8E%B0" title="inode表的出现">&lt;/a>inode 表的出现&lt;a class="td-heading-self-link" href="#inode%e8%a1%a8%e7%9a%84%e5%87%ba%e7%8e%b0-inode%e8%a1%a8%e7%9a%84%e5%87%ba%e7%8e%b0inode-%e8%a1%a8%e7%9a%84%e5%87%ba%e7%8e%b0" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>回顾下 inode 相关信息：inode 存储了 inode 号（注，同前文，inode 中并未存储 inode num）、文件属性元数据、指向文件占用的 block 的指针；每一个 inode 占用 128 字节或 256 字节。&lt;/p>
&lt;p>现在又出现问题了，一个文件系统中可以说有无数多个文件，每一个文件都对应一个 inode，难道每一个仅 128 字节的 inode 都要单独占用一个 block 进行存储吗？这太浪费空间了。&lt;/p>
&lt;p>所以更优的方法是将多个 inode 合并存储在 block 中，对于 128 字节的 inode，一个 block 存储 8 个 inode，对于 256 字节的 inode，一个 block 存储 4 个 inode。这就使得每个存储 inode 的块都不浪费。&lt;/p>
&lt;p>在 ext 文件系统上，将这些物理上存储 inode 的 block 组合起来，在逻辑上形成一张 inode 表 (inode table) 来记录所有的 inode。&lt;/p>
&lt;p>举个例子，每一个家庭都要向派出所登记户口信息，通过户口本可以知道家庭住址，而每个镇或街道的派出所将本镇或本街道的所有户口整合在一起，要查找某一户地址时，在派出所就能快速查找到。inode table 就是这里的派出所。它的内容如下图所示。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20180830092223810-1825870107.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20180830092223810-1825870107.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>再细细一思考，就能发现一个大的文件系统仍将占用大量的块来存储 inode，想要找到其中的一个 inode 记录也需要不小的开销，尽管它们已经形成了一张逻辑上的表，但扛不住表太大记录太多。那么如何快速找到 inode，这同样是需要优化的，优化的方法是将文件系统的 block 进行分组划分，每个组中都存有本组 inode table 范围、bmap 等。&lt;/p>
&lt;h2 id="imap的出现-imap的出现imap-的出现">&lt;a href="#imap%E7%9A%84%E5%87%BA%E7%8E%B0" title="imap的出现">&lt;/a>imap 的出现&lt;a class="td-heading-self-link" href="#imap%e7%9a%84%e5%87%ba%e7%8e%b0-imap%e7%9a%84%e5%87%ba%e7%8e%b0imap-%e7%9a%84%e5%87%ba%e7%8e%b0" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>前面说 bmap 是块位图，用于标识文件系统中哪些 block 是空闲哪些 block 是占用的。&lt;/p>
&lt;p>对于 inode 也一样，在存储文件 (Linux 中一切皆文件) 时需要为其分配一个 inode 号。但是在格式化创建文件系统后所有的 inode 号都已被事先计算好（创建文件系统时会为每个块组计算好该块组拥有哪些 inode 号），因此产生了问题：要为文件分配哪一个 inode 号呢？又如何知道某一个 inode 号是否已经被分配了呢？&lt;/p>
&lt;p>既然是” 是否被占用” 的问题，使用位图是最佳方案，像 bmap 记录 block 的占用情况一样。标识 inode 号是否被分配的位图称为 inodemap 简称为 imap。这时要为一个文件分配 inode 号只需扫描 imap 即可知道哪一个 inode 号是空闲的。&lt;/p>
&lt;p>imap 存在着和 bmap 和 inode table 一样需要解决的问题：如果文件系统比较大，imap 本身就会很大，每次存储文件都要进行扫描，会导致效率不够高。同样，优化的方式是将文件系统占用的 block 划分成块组，每个块组有自己的 imap 范围。&lt;/p>
&lt;h2 id="块组的出现-块组的出现块组的出现">&lt;a href="#%E5%9D%97%E7%BB%84%E7%9A%84%E5%87%BA%E7%8E%B0" title="块组的出现">&lt;/a>块组的出现&lt;a class="td-heading-self-link" href="#%e5%9d%97%e7%bb%84%e7%9a%84%e5%87%ba%e7%8e%b0-%e5%9d%97%e7%bb%84%e7%9a%84%e5%87%ba%e7%8e%b0%e5%9d%97%e7%bb%84%e7%9a%84%e5%87%ba%e7%8e%b0" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>前面一直提到的优化方法是将文件系统占用的 block 划分成块组 (block group)，解决 bmap、inode table 和 imap 太大的问题。&lt;/p>
&lt;p>在物理层面上的划分是将磁盘按柱面划分为多个分区，即多个文件系统；在逻辑层面上的划分是将文件系统划分成块组。每个文件系统包含多个块组，每个块组包含多个元数据区和数据区：元数据区就是存储 bmap、inode table、imap 等的数据；数据区就是存储文件数据的区域。注意块组是逻辑层面的概念，所以并不会真的在磁盘上按柱面、按扇区、按磁道等概念进行划分。&lt;/p>
&lt;h2 id="块组的划分-块组的划分块组的划分">&lt;a href="#%E5%9D%97%E7%BB%84%E7%9A%84%E5%88%92%E5%88%86" title="块组的划分">&lt;/a>块组的划分&lt;a class="td-heading-self-link" href="#%e5%9d%97%e7%bb%84%e7%9a%84%e5%88%92%e5%88%86-%e5%9d%97%e7%bb%84%e7%9a%84%e5%88%92%e5%88%86%e5%9d%97%e7%bb%84%e7%9a%84%e5%88%92%e5%88%86" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>块组在文件系统创建完成后就已经划分完成了，也就是说元数据区 bmap、inode table 和 imap 等信息占用的 block 以及数据区占用的 block 都已经划分好了。那么文件系统如何知道一个块组元数据区包含多少个 block，数据区又包含多少 block 呢？&lt;/p>
&lt;p>&lt;strong>它只需确定一个数据 —— 每个 block 的大小，再根据 bmap 至多只能占用一个完整的 block 的标准就能计算出块组如何划分&lt;/strong>。如果文件系统非常小，所有的 bmap 总共都不能占用完一个 block，那么也只能空闲 bmap 的 block 了。&lt;/p>
&lt;p>每个 block 的大小在创建文件系统时可以人为指定，不指定也有默认值。&lt;/p>
&lt;p>假如现在 block 的大小是 1KB，一个 bmap 完整占用一个 block 能标识 1024*8=8192 个 block (当然这 8192 个 block 是数据区和元数据区共 8192 个，因为元数据区分配的 block 也需要通过 bmap 来标识)。每个 block 是 1K，每个块组是 8192K 即 8M，创建 1G 的文件系统需要划分 1024/8=128 个块组，如果是 1.1G 的文件系统呢？128+12.8=128+13=141 个块组。&lt;/p>
&lt;p>每个组的 block 数目是划分好了，但是每个组设定多少个 inode 号呢？inode table 占用多少 block 呢？这需要由系统决定了，因为描述” 每多少个数据区的 block 就为其分配一个 inode 号” 的指标默认是我们不知道的，当然创建文件系统时也可以人为指定这个指标或者百分比例。见后文”&lt;a href="#deep_into_inode">inode 深入&lt;/a> “。&lt;/p>
&lt;p>使用 dumpe2fs 可以将 ext 类的文件系统信息全部显示出来，当然 bmap 是每个块组固定一个 block 的不用显示，imap 比 bmap 更小所以也只占用 1 个 block 不用显示。&lt;/p>
&lt;p>下图是一个文件系统的部分信息，在这些信息的后面还有每个块组的信息，其实这里面的很多信息都可以通过几个比较基本的元数据推导出来。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615093736759-1554527092.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615093736759-1554527092.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>从这张表中能计算出文件系统的大小，该文件系统共 4667136 个 blocks，每个 block 大小为 4K，所以文件系统大小为 &lt;code>4667136*4/1024/1024=17.8GB&lt;/code>。&lt;/p>
&lt;p>也能计算出分了多少个块组，因为每一个块组的 block 数量为 32768，所以块组的数量为 4667136/32768=142.4 即 143 个块组。由于块组从 0 开始编号，所以最后一个块组编号为 Group 142。如下图所示是最后一个块组的信息。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615093808509-902863729.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615093808509-902863729.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>将上文描述的 bmap、inode table、imap、数据区的 blocks 和块组的概念组合起来就形成了一个文件系统，当然这还不是完整的文件系统。完整的文件系统如下图&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20180727160411876-443793371.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20180727160411876-443793371.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>首先，该图中多了 Boot Block、Super Block、GDT、Reserver GDT 这几个概念。下面会分别介绍它们。&lt;/p>
&lt;p>然后，图中指明了块组中每个部分占用的 block 数量，除了 superblock、bmap、imap 能确定占用 1 个 block，其他的部分都不能确定占用几个 block。&lt;/p>
&lt;p>最后，图中指明了 Superblock、GDT 和 Reserved GDT 是同时出现且不一定存在于每一个块组中的，也指明了 bmap、imap、inode table 和 data blocks 是每个块组都有的。&lt;/p>
&lt;h2 id="引导块-引导块引导块">&lt;a href="#%E5%BC%95%E5%AF%BC%E5%9D%97" title="引导块">&lt;/a>引导块&lt;a class="td-heading-self-link" href="#%e5%bc%95%e5%af%bc%e5%9d%97-%e5%bc%95%e5%af%bc%e5%9d%97%e5%bc%95%e5%af%bc%e5%9d%97" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>即上图中的 Boot Block 部分，也称为 boot sector。它位于分区上的第一个块，占用 1024 字节，并非所有分区都有这个 boot sector，只有装了操作系统的主分区和装了操作系统的逻辑分区才有。里面存放的也是 boot loader，这段 boot loader 称为 VBR (主分区装操作系统时) 或 EBR (扩展分区装操作系统时)，这里的 Boot loader 和 mbr 上的 boot loader 是存在交错关系的。开机启动的时候，首先加载 mbr 中的 bootloader，然后定位到操作系统所在分区的 boot serctor 上加载此处的 boot loader。如果是多系统，加载 mbr 中的 bootloader 后会列出操作系统菜单，菜单上的各操作系统指向它们所在分区的 boot sector 上。它们之间的关系如下图所示。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170627160437071-1671926976.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170627160437071-1671926976.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>但是，这种方式的操作系统菜单早已经弃之不用了，而是使用 grub 来管理启动菜单。尽管如此，在安装操作系统时，仍然有一步是选择 boot loader 安装位置的步骤。&lt;/p>
&lt;h2 id="超级块-superblock-超级块superblock超级块-superblock">&lt;a href="#%E8%B6%85%E7%BA%A7%E5%9D%97-superblock" title="超级块(superblock)">&lt;/a>超级块 (superblock)&lt;a class="td-heading-self-link" href="#%e8%b6%85%e7%ba%a7%e5%9d%97-superblock-%e8%b6%85%e7%ba%a7%e5%9d%97superblock%e8%b6%85%e7%ba%a7%e5%9d%97-superblock" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>既然一个文件系统会分多个块组，那么文件系统怎么知道分了多少个块组呢？每个块组又有多少 block 多少 inode 号等等信息呢？还有，文件系统本身的属性信息如各种时间戳、block 总数量和空闲数量、inode 总数量和空闲数量、当前文件系统是否正常、什么时候需要自检等等，它们又存储在哪里呢？&lt;/p>
&lt;p>毫无疑问，这些信息必须要存储在 block 中。存储这些信息占用 1024 字节，所以也要一个 block，这个 block 称为超级块 (superblock)，它的 block 号可能为 0 也可能为 1。&lt;strong>如果 block 大小为 1K，则引导块正好占用一个 block，这个 block 号为 0，所以 superblock 的号为 1；如果 block 大小大于 1K，则引导块和超级块同置在一个 block 中，这个 block 号为 0。总之 superblock 的起止位置是第二个 1024 (1024-2047) 字节&lt;/strong>。&lt;/p>
&lt;p>使用 df 命令读取的就是每个文件系统的 superblock，所以它的统计速度非常快。相反，用 du 命令查看一个较大目录的已用空间就非常慢，因为不可避免地要遍历整个目录的所有文件。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi ~]# df -hT
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Filesystem Type Size Used Avail Use% Mounted on
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>/dev/sda3 ext4 18G 1.7G 15G 11% /
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>tmpfs tmpfs 491M 0 491M 0% /dev/shm
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>/dev/sda1 ext4 190M 32M 149M 18% /boot
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>superblock 对于文件系统而言是至关重要的，超级块丢失或损坏必将导致文件系统的损坏。所以旧式的文件系统将超级块备份到每一个块组中，但是这又有所空间浪费，所以 ext2 文件系统只在块组 0、1 和 3、5、7 幂次方的块组中保存超级块的信息，如 Group9、Group25 等。尽管保存了这么多的 superblock，但是文件系统只使用第一个块组即 Group0 中超级块信息来获取文件系统属性，只有当 Group0 上的 superblock 损坏或丢失才会找下一个备份超级块复制到 Group0 中来恢复文件系统。&lt;/p>
&lt;p>下图是一个 ext4 文件系统的 superblock 的信息，ext 家族的文件系统都能使用 dumpe2fs -h 获取。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615094025275-1008363481.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615094025275-1008363481.jpg" alt="">
&lt;/a>&lt;/p>
&lt;h2 id="块组描述符表-gdt-块组描述符表gdt块组描述符表-gdt">&lt;a href="#%E5%9D%97%E7%BB%84%E6%8F%8F%E8%BF%B0%E7%AC%A6%E8%A1%A8-GDT" title="块组描述符表(GDT)">&lt;/a>块组描述符表 (GDT)&lt;a class="td-heading-self-link" href="#%e5%9d%97%e7%bb%84%e6%8f%8f%e8%bf%b0%e7%ac%a6%e8%a1%a8-gdt-%e5%9d%97%e7%bb%84%e6%8f%8f%e8%bf%b0%e7%ac%a6%e8%a1%a8gdt%e5%9d%97%e7%bb%84%e6%8f%8f%e8%bf%b0%e7%ac%a6%e8%a1%a8-gdt" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>既然文件系统划分了块组，那么每个块组的信息和属性元数据又保存在哪里呢？&lt;/p>
&lt;p>ext 文件系统每一个块组信息使用 32 字节描述，这 32 个字节称为块组描述符，所有块组的块组描述符组成块组描述符表 GDT (group descriptor table)。&lt;/p>
&lt;p>虽然每个块组都需要块组描述符来记录块组的信息和属性元数据，但是不是每个块组中都存放了块组描述符。ext 文件系统的存储方式是：将它们组成一个 GDT，并将该 GDT 存放于某些块组中，存放 GDT 的块组和存放 superblock 和备份 superblock 的块相同，也就是说它们是同时出现在某一个块组中的。读取时也总是读取 Group0 中的块组描述符表信息。&lt;/p>
&lt;p>假如 block 大小为 4KB 的文件系统划分了 143 个块组，每个块组描述符 32 字节，那么 GDT 就需要 143*32=4576 字节即两个 block 来存放。这两个 GDT block 中记录了所有块组的块组信息，且存放 GDT 的块组中的 GDT 都是完全相同的。&lt;/p>
&lt;p>下图是一个块组描述符的信息 (通过 dumpe2fs 获取)。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615094101525-344682252.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615094101525-344682252.jpg" alt="">
&lt;/a>&lt;/p>
&lt;h2 id="保留gdt-reserved-gdt-保留gdtreserved-gdt保留-gdt-reserved-gdt">&lt;a href="#%E4%BF%9D%E7%95%99GDT-Reserved-GDT" title="保留GDT(Reserved GDT)">&lt;/a>保留 GDT (Reserved GDT)&lt;a class="td-heading-self-link" href="#%e4%bf%9d%e7%95%99gdt-reserved-gdt-%e4%bf%9d%e7%95%99gdtreserved-gdt%e4%bf%9d%e7%95%99-gdt-reserved-gdt" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>保留 GDT 用于以后扩容文件系统使用，防止扩容后块组太多，使得块组描述符超出当前存储 GDT 的 blocks。保留 GDT 和 GDT 总是同时出现，当然也就和 superblock 同时出现了。&lt;/p>
&lt;p>例如前面 143 个块组使用了 2 个 block 来存放 GDT，但是此时第二个 block 还空余很多空间，当扩容到一定程度时 2 个 block 已经无法再记录块组描述符了，这时就需要分配一个或多个 Reserved GDT 的 block 来存放超出的块组描述符。&lt;/p>
&lt;p>由于新增加了 GDT block，所以应该让每一个保存 GDT 的块组都同时增加这一个 GDT block，所以将保留 GDT 和 GDT 存放在同一个块组中可以直接将保留 GDT 变换为 GDT 而无需使用低效的复制手段备份到每个存放 GDT 的块组。&lt;/p>
&lt;p>同理，新增加了 GDT 需要修改每个块组中 superblock 中的文件系统属性，所以将 superblock 和 Reserved GDT/GDT 放在一起又能提升效率。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20180727160431015-373938073.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20180727160431015-373938073.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>如上图，除了 Data Blocks 其他的部分都解释过了。data block 是直接存储数据的 block，但事实上并非如此简单。&lt;/p>
&lt;p>数据所占用的 block 由文件对应 inode 记录中的 block 指针找到，不同的文件类型，数据 block 中存储的内容是不一样的。以下是 Linux 中不同类型文件的存储方式。&lt;/p>
&lt;ul>
&lt;li>对于常规文件，文件的数据正常存储在数据块中。&lt;/li>
&lt;li>对于目录，该目录下的所有文件和一级子目录的目录名存储在数据块中。
&lt;ul>
&lt;li>&lt;strong>文件名和 inode 号不是存储在其自身的 inode 中，而是存储在其所在目录的 data block 中。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;/li>
&lt;li>对于符号链接，如果目标路径名较短则直接保存在 inode 中以便更快地查找，如果目标路径名较长则分配一个数据块来保存。&lt;/li>
&lt;li>设备文件、FIFO 和 socket 等特殊文件没有数据块，设备文件的主设备号和次设备号保存在 inode 中。&lt;/li>
&lt;/ul>
&lt;p>常规文件的存储就不解释了，下面分别解释特殊文件的存储方式。&lt;/p>
&lt;h2 id="目录文件的data-block-目录文件的data-block目录文件的-data-block">&lt;a href="#%E7%9B%AE%E5%BD%95%E6%96%87%E4%BB%B6%E7%9A%84data-block" title="目录文件的data block">&lt;/a>目录文件的 data block&lt;a class="td-heading-self-link" href="#%e7%9b%ae%e5%bd%95%e6%96%87%e4%bb%b6%e7%9a%84data-block-%e7%9b%ae%e5%bd%95%e6%96%87%e4%bb%b6%e7%9a%84data-block%e7%9b%ae%e5%bd%95%e6%96%87%e4%bb%b6%e7%9a%84-data-block" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>目录的 data block 的内容如下图所示。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20191005161844399-1089052435.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20191005161844399-1089052435.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>由图可知，在目录文件的数据块中存储了其下的文件名、目录名、目录本身的相对名称”.” 和上级目录的相对名称”..”，还存储了这些文件名对应的 inode 号、目录项长度 rec_len、文件名长度 name_len 和文件类型 file_type。注意到除了文件本身的 inode 记录了文件类型，其所在的目录的数据块也记录了文件类型。由于 rec_len 只能是 4 的倍数，所以需要使用”\0” 来填充 name_len 不够凑满 4 倍数的部分。至于 rec_len 具体是什么，只需知道它是一种偏移即可。&lt;/p>
&lt;p>&lt;strong>需要注意的是，inode table 中的 inode 自身并没有存储每个 inode 的 inode 号，它是存储在目录的 data block 中的，通过 inode 号可以计算并索引到 inode table 中该 inode 号对应的 inode 记录，可以认为这个 inode 号是一个 inode 指针&lt;/strong> (当然，并非真的是指针，但有助于理解通过 inode 号索引找到对应 inode 的这个过程，后文将在需要的时候使用 inode 指针这个词来表示 inode 号。至此，已经知道了两种指针：一种是 inode table 中每个 inode 记录指向其对应 data block 的 block 指针，一个此处的『inode 指针』)。&lt;/p>
&lt;p>除了 inode 号，目录的 data block 中还使用数字格式记录了文件类型，数字格式和文件类型的对应关系如下图。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615094424884-1119563692.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615094424884-1119563692.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>注意到目录的 data block 中前两行存储的是目录本身的相对名称”.” 和上级目录的相对名称”..”，它们实际上是目录本身的硬链接和上级目录的硬链接。硬链接的本质后面说明。&lt;/p>
&lt;h2 id="如何根据inode号找到inode-如何根据inode号找到inode如何根据-inode-号找到-inode">&lt;a href="#%E5%A6%82%E4%BD%95%E6%A0%B9%E6%8D%AEinode%E5%8F%B7%E6%89%BE%E5%88%B0inode" title="如何根据inode号找到inode">&lt;/a>如何根据 inode 号找到 inode&lt;a class="td-heading-self-link" href="#%e5%a6%82%e4%bd%95%e6%a0%b9%e6%8d%aeinode%e5%8f%b7%e6%89%be%e5%88%b0inode-%e5%a6%82%e4%bd%95%e6%a0%b9%e6%8d%aeinode%e5%8f%b7%e6%89%be%e5%88%b0inode%e5%a6%82%e4%bd%95%e6%a0%b9%e6%8d%ae-inode-%e5%8f%b7%e6%89%be%e5%88%b0-inode" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>前面提到过，inode 结构自身并没有保存 inode 号（同样，也没有保存文件名），那么 inode 号保存在哪里呢？目录的 data block 中保存了该目录中每个文件的 inode 号。&lt;/p>
&lt;p>另一个问题，既然 inode 中没有 inode 号，那么如何根据目录 data block 中的 inode 号找到 inode table 中对应的 inode 呢？&lt;/p>
&lt;p>实际上，只要有了 inode 号，就可以计算出 inode 表中对应该 inode 号的 inode 结构。在创建文件系统的时候，每个块组中的起始 inode 号以及 inode table 的起始地址都已经确定了，所以只要知道 inode 号，就能知道这个 inode 号和该块组起始 inode 号的偏移数量，再根据每个 inode 结构的大小 (256 字节或其它大小)，就能计算出来对应的 inode 结构。&lt;/p>
&lt;p>所以，目录的 data block 中的 inode number 和 inode table 中的 inode 是通过计算的方式一一映射起来的。从另一个角度上看，目录 data block 中的 inode number 是找到 inode table 中对应 inode 记录的唯一方式。&lt;/p>
&lt;p>考虑一种比较特殊的情况：目录 data block 的记录已经删除，但是该记录对应的 inode 结构仍然存在于 inode table 中。这种 inode 称为孤儿 inode（orphan inode）：存在于 inode table 中，但却无法再索引到它。因为目录中已经没有该 inode 对应的文件记录了，所以其它进程将无法找到该 inode，也就无法根据该 inode 找到该文件之前所占用的 data block，这正是创建便删除所实现的真正临时文件，该临时文件只有当前进程和子进程才能访问。&lt;/p>
&lt;h2 id="符号链接存储方式-符号链接存储方式符号链接存储方式">&lt;a href="#%E7%AC%A6%E5%8F%B7%E9%93%BE%E6%8E%A5%E5%AD%98%E5%82%A8%E6%96%B9%E5%BC%8F" title="符号链接存储方式">&lt;/a>符号链接存储方式&lt;a class="td-heading-self-link" href="#%e7%ac%a6%e5%8f%b7%e9%93%be%e6%8e%a5%e5%ad%98%e5%82%a8%e6%96%b9%e5%bc%8f-%e7%ac%a6%e5%8f%b7%e9%93%be%e6%8e%a5%e5%ad%98%e5%82%a8%e6%96%b9%e5%bc%8f%e7%ac%a6%e5%8f%b7%e9%93%be%e6%8e%a5%e5%ad%98%e5%82%a8%e6%96%b9%e5%bc%8f" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>符号链接即为软链接，类似于 Windows 操作系统中的快捷方式，它的作用是指向原文件或目录。&lt;/p>
&lt;p>软链接之所以也被称为特殊文件的原因是：它一般情况下不占用 data block，仅仅通过它对应的 inode 记录就能将其信息描述完成；符号链接的大小是其指向目标路径占用的字符个数，例如某个符号链接的指向方式为”rmt –&amp;gt; ../sbin/rmt”，则其文件大小为 11 字节；只有当符号链接指向的目标的路径名较长 (60 个字节) 时文件系统才会划分一个 data block 给它；它的权限如何也不重要，因它只是一个指向原文件的” 工具”，最终决定是否能读写执行的权限由原文件决定，所以很可能 ls -l 查看到的符号链接权限为 777。&lt;/p>
&lt;p>注意，软链接的 block 指针存储的是目标文件名。也就是说，链接文件的一切都依赖于其目标文件名。这就解释了为什么 /mnt 的软链接 /tmp/mnt 在 /mnt 挂载文件系统后，通过软链接就能进入 /mnt 所挂载的文件系统。究其原因，还是因为其目标文件名”/mnt” 并没有改变。&lt;/p>
&lt;p>例如以下筛选出了 /etc/ 下的符号链接，注意观察它们的权限和它们占用的空间大小。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi ~]# ll /etc/ | grep &amp;#39;^l&amp;#39;
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 56 Feb 18 2016 favicon.png -&amp;gt; /usr/share/icons/hicolor/16x16/apps/system-logo-icon.png
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 22 Feb 18 2016 grub.conf -&amp;gt; ../boot/grub/grub.conf
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 11 Feb 18 2016 init.d -&amp;gt; rc.d/init.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 7 Feb 18 2016 rc -&amp;gt; rc.d/rc
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 10 Feb 18 2016 rc0.d -&amp;gt; rc.d/rc0.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 10 Feb 18 2016 rc1.d -&amp;gt; rc.d/rc1.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 10 Feb 18 2016 rc2.d -&amp;gt; rc.d/rc2.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 10 Feb 18 2016 rc3.d -&amp;gt; rc.d/rc3.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 10 Feb 18 2016 rc4.d -&amp;gt; rc.d/rc4.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 10 Feb 18 2016 rc5.d -&amp;gt; rc.d/rc5.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 10 Feb 18 2016 rc6.d -&amp;gt; rc.d/rc6.d
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 13 Feb 18 2016 rc.local -&amp;gt; rc.d/rc.local
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 15 Feb 18 2016 rc.sysinit -&amp;gt; rc.d/rc.sysinit
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 14 Feb 18 2016 redhat-release -&amp;gt; centos-release
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 11 Apr 10 2016 rmt -&amp;gt; ../sbin/rmt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>lrwxrwxrwx. 1 root root 14 Feb 18 2016 system-release -&amp;gt; centos-release
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;h2 id="设备文件fifo套接字文件-设备文件fifo套接字文件设备文件fifo套接字文件">&lt;a href="#%E8%AE%BE%E5%A4%87%E6%96%87%E4%BB%B6%E3%80%81FIFO%E3%80%81%E5%A5%97%E6%8E%A5%E5%AD%97%E6%96%87%E4%BB%B6" title="设备文件、FIFO、套接字文件">&lt;/a>设备文件、FIFO、套接字文件&lt;a class="td-heading-self-link" href="#%e8%ae%be%e5%a4%87%e6%96%87%e4%bb%b6fifo%e5%a5%97%e6%8e%a5%e5%ad%97%e6%96%87%e4%bb%b6-%e8%ae%be%e5%a4%87%e6%96%87%e4%bb%b6fifo%e5%a5%97%e6%8e%a5%e5%ad%97%e6%96%87%e4%bb%b6%e8%ae%be%e5%a4%87%e6%96%87%e4%bb%b6fifo%e5%a5%97%e6%8e%a5%e5%ad%97%e6%96%87%e4%bb%b6" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>关于这 3 种文件类型的文件只需要通过 inode 就能完全保存它们的信息，它们不占用任何数据块，所以它们是特殊文件。&lt;/p>
&lt;p>设备文件的主设备号和次设备号也保存在 inode 中。以下是 /dev/ 下的部分设备信息。注意到它们的第 5 列和第 6 列信息，它们分别是主设备号和次设备号，主设备号标识每一种设备的类型，次设备号标识同种设备类型的不同编号；也注意到这些信息中没有大小的信息，因为设备文件不占用数据块所以没有大小的概念。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi ~]# ll /dev | tail
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw---- 1 vcsa tty 7, 129 Oct 7 21:26 vcsa1
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw---- 1 vcsa tty 7, 130 Oct 7 21:27 vcsa2
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw---- 1 vcsa tty 7, 131 Oct 7 21:27 vcsa3
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw---- 1 vcsa tty 7, 132 Oct 7 21:27 vcsa4
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw---- 1 vcsa tty 7, 133 Oct 7 21:27 vcsa5
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw---- 1 vcsa tty 7, 134 Oct 7 21:27 vcsa6
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw---- 1 root root 10, 63 Oct 7 21:26 vga_arbiter
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw------- 1 root root 10, 57 Oct 7 21:26 vmci
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw-rw- 1 root root 10, 56 Oct 7 21:27 vsock
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crw-rw-rw- 1 root root 1, 5 Oct 7 21:26 zero
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>每个文件都有一个 inode，在将 inode 关联到文件后系统将通过 inode 号来识别文件，而不是文件名。并且访问文件时将先找到 inode，通过 inode 中记录的 block 位置找到该文件。&lt;/p>
&lt;h2 id="硬链接-硬链接硬链接">&lt;a href="#%E7%A1%AC%E9%93%BE%E6%8E%A5" title="硬链接">&lt;/a>硬链接&lt;a class="td-heading-self-link" href="#%e7%a1%ac%e9%93%be%e6%8e%a5-%e7%a1%ac%e9%93%be%e6%8e%a5%e7%a1%ac%e9%93%be%e6%8e%a5" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>虽然每个文件都有一个 inode，但是存在一种可能：多个文件的 inode 相同，也就即 inode 号、元数据、block 位置都相同，这是一种什么样的情况呢？能够想象这些 inode 相同的文件使用的都是同一条 inode 记录，所以代表的都是同一个文件，这些文件所在目录的 data block 中的 inode 号都是一样的，只不过各 inode 号对应的文件名互不相同而已。这种 inode 相同的文件在 Linux 中被称为” 硬链接”。&lt;/p>
&lt;p>硬链接文件的 inode 都相同，每个文件都有一个” 硬链接数” 的属性，使用 ls -l 的第二列就是被硬链接数，它表示的就是该文件有几个硬链接。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi ~]# ls -l
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>total 48
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>drwxr-xr-x 5 root root 4096 Oct 15 18:07 700
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-rw-------. 1 root root 1082 Feb 18 2016 anaconda-ks.cfg
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-rw-r--r-- 1 root root 399 Apr 29 2016 Identity.pub
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-rw-r--r--. 1 root root 21783 Feb 18 2016 install.log
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-rw-r--r--. 1 root root 6240 Feb 18 2016 install.log.syslog
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>例如下图描述的是 dir1 目录中的文件 name1 及其硬链接 dir2/name2，右边分别是它们的 inode 和 data block。这里也看出了硬链接文件之间唯一不同的就是其所在目录中的记录不同。注意下图中有一列 Link Count 就是标记硬链接数的属性。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20191005170242909-1745674821.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20191005170242909-1745674821.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>每创建一个文件的硬链接，实质上是多一个指向该 inode 记录的 inode 指针，并且硬链接数加 1。&lt;/p>
&lt;p>删除文件的实质是删除该文件所在目录 data block 中的对应的 inode 行，所以也是减少硬链接次数，由于 block 指针是存储在 inode 中的，所以不是真的删除数据，如果仍有其他 inode 号链接到该 inode，那么该文件的 block 指针仍然是可用的。当硬链接次数为 1 时再删除文件就是真的删除文件了，此时 inode 记录中 block 指针也将被删除。&lt;/p>
&lt;p>&lt;strong>不能跨分区创建硬链接&lt;/strong>，因为不同文件系统的 inode 号可能会相同，如果允许创建硬链接，复制到另一个分区时 inode 可能会和此分区已使用的 inode 号冲突。&lt;/p>
&lt;p>&lt;strong>硬链接只能对文件创建，无法对目录创建硬链接&lt;/strong>。之所以无法对目录创建硬链接，是因为文件系统已经把每个目录的硬链接创建好了，它们就是相对路径中的”.” 和”..”，分别标识当前目录的硬链接和上级目录的硬链接。每一个目录中都会包含这两个硬链接，它包含了两个信息：(1) 一个没有子目录的目录文件的硬链接数是 2，其一是目录本身，即该目录 datablock 中的”.”，其二是其父目录 datablock 中该目录的记录，这两者都指向同一个 inode 号；(2) 一个包含子目录的目录文件，其硬链接数是 2 + 子目录数，因为每个子目录都关联一个父目录的硬链接”..”。很多人在计算目录的硬链接数时认为由于包含了”.” 和”..”，所以空目录的硬链接数是 2，这是错误的，因为”..” 不是本目录的硬链接。另外，还有一个特殊的目录应该纳入考虑，即”/“目录，它自身是一个文件系统的入口，是自引用 (下文中会解释自引用) 的，所以”/“目录下的”.” 和”..” 的 inode 号相同，它自身不占用硬链接，因为其 datablock 中只记录 inode 号相同的”.” 和”..”，不再像其他目录一样还记录一个名为”/“的目录，所以”/“的硬链接数也是 2 + 子目录数，但这个 2 是”.” 和”..” 的结果。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi ~]# ln /tmp /mydata
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>ln: `/tmp&amp;#39;: hard link not allowed for directory
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>为什么文件系统自己创建好了目录的硬链接就不允许人为创建呢？从”.” 和”..” 的用法上考虑，如果当前目录为 /usr，我们可以使用”./local” 来表示 /usr/local，但是如果我们人为创建了 /usr 目录的硬链接 /tmp/husr，难道我们也要使用”/tmp/husr/local” 来表示 /usr/local 吗？这其实已经是软链接的作用了。若要将其认为是硬链接的功能，这必将导致硬链接维护的混乱。&lt;/p>
&lt;p>不过，通过 mount 工具的”–bind” 选项，可以将一个目录挂载到另一个目录下，实现伪” 硬链接”，它们的内容和 inode 号是完全相同的。&lt;/p>
&lt;p>硬链接的创建方法：&lt;code>ln file_target link_name&lt;/code>。&lt;/p>
&lt;h2 id="软链接-软链接软链接">&lt;a href="#%E8%BD%AF%E9%93%BE%E6%8E%A5" title="软链接">&lt;/a>软链接&lt;a class="td-heading-self-link" href="#%e8%bd%af%e9%93%be%e6%8e%a5-%e8%bd%af%e9%93%be%e6%8e%a5%e8%bd%af%e9%93%be%e6%8e%a5" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>软链接就是字符链接，链接文件默认指的就是字符链接文件 (注意不是字符设备)，使用”l” 表示其类型。&lt;/p>
&lt;p>硬链接不能跨文件系统创建，否则 inode 号可能会冲突。于是实现了软链接以便跨文件系统建立链接。既然是跨文件系统，那么软链接必须得有自己的 inode 号。&lt;/p>
&lt;p>软链接在功能上等价与 Windows 系统中的快捷方式，它指向原文件，原文件损坏或消失，软链接文件就损坏。&lt;strong>可以认为软链接 inode 记录中的指针内容是目标路径的字符串&lt;/strong>。&lt;/p>
&lt;p>创建方式：&lt;code>ln –s source_file softlink_name&lt;/code>，记住是 &lt;code>source_file&amp;lt;--link_name&lt;/code> 的指向关系 (反箭头)，以前我老搞错位置。&lt;/p>
&lt;p>查看软链接的值：&lt;code>readlink softlink_name&lt;/code>&lt;/p>
&lt;p>在设置软链接的时候，source_file 虽然不要求是绝对路径，但建议给绝对路径。是否还记得软链接文件的大小？它是根据软链接所指向路径的字符数计算的，例如某个符号链接的指向方式为”rmt –&amp;gt; ../sbin/rmt”，它的文件大小为 11 字节，也就是说只要建立了软链接后，软链接的指向路径是不会改变的，仍然是”../sbin/rmt”。如果此时移动软链接文件本身，它的指向是不会改变的，仍然是 11 个字符的”../sbin/rmt”，但此时该软链接父目录下可能根本就不存在 /sbin/rmt，也就是说此时该软链接是一个被破坏的软链接。&lt;/p>
&lt;h2 id="inode大小和划分-inode大小和划分inode-大小和划分">&lt;a href="#inode%E5%A4%A7%E5%B0%8F%E5%92%8C%E5%88%92%E5%88%86" title="inode大小和划分">&lt;/a>inode 大小和划分&lt;a class="td-heading-self-link" href="#inode%e5%a4%a7%e5%b0%8f%e5%92%8c%e5%88%92%e5%88%86-inode%e5%a4%a7%e5%b0%8f%e5%92%8c%e5%88%92%e5%88%86inode-%e5%a4%a7%e5%b0%8f%e5%92%8c%e5%88%92%e5%88%86" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>inode 大小为 128 字节的倍数，最小为 128 字节。它有默认值大小，它的默认值由 /etc/mke2fs.conf 文件中指定。不同的文件系统默认值可能不同。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi ~]# cat /etc/mke2fs.conf
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[defaults]
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> enable_periodic_fsck = 1
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> blocksize = 4096
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> inode_size = 256
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> inode_ratio = 16384
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[fs_types]
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> ext3 = {
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> features = has_journal
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> }
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> ext4 = {
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> inode_size = 256
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> }
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>同样观察到这个文件中还记录了 blocksize 的默认值和 inode 分配比率 inode_ratio。inode_ratio=16384 表示每 16384 个字节即 16KB 就分配一个 inode 号，由于默认 blocksize=4KB，所以每 4 个 block 就分配一个 inode 号。当然分配的这些 inode 号只是预分配，并不真的代表会全部使用，毕竟每个文件才会分配一个 inode 号。但是分配的 inode 自身会占用 block，而且其自身大小 256 字节还不算小，所以 inode 号的浪费代表着空间的浪费。&lt;/p>
&lt;p>既然知道了 inode 分配比率，就能计算出每个块组分配多少个 inode 号，也就能计算出 inode table 占用多少个 block。&lt;/p>
&lt;p>如果文件系统中大量存储电影等大文件，inode 号就浪费很多，inode 占用的空间也浪费很多。但是没办法，文件系统又不知道你这个文件系统是用来存什么样的数据，多大的数据，多少数据。&lt;/p>
&lt;p>当然 inode size、inode 分配比例、block size 都可以在创建文件系统的时候人为指定。&lt;/p>
&lt;h2 id="ext文件系统预留的inode号-ext文件系统预留的inode号ext-文件系统预留的-inode-号">&lt;a href="#ext%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E9%A2%84%E7%95%99%E7%9A%84inode%E5%8F%B7" title="ext文件系统预留的inode号">&lt;/a>ext 文件系统预留的 inode 号&lt;a class="td-heading-self-link" href="#ext%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e9%a2%84%e7%95%99%e7%9a%84inode%e5%8f%b7-ext%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e9%a2%84%e7%95%99%e7%9a%84inode%e5%8f%b7ext-%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e9%a2%84%e7%95%99%e7%9a%84-inode-%e5%8f%b7" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>Ext 预留了一些 inode 做特殊特性使用，如下：某些可能并非总是准确，具体的 inode 号对应什么文件可以使用”find /-inum NUM” 查看。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>Ext4的特殊inode
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Inode号 用途
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>0 不存在0号inode，可用于标识目录data block中已删除的文件
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>1 虚拟文件系统，如/proc和/sys
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>2 根目录 # 注意此行
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>3 ACL索引
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>4 ACL数据
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>5 Boot loader
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>6 未删除的目录
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>7 预留的块组描述符inode
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>8 日志inode
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>11 第一个非预留的inode，通常是lost+found目录
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>所以在 ext4 文件系统的 dumpe2fs 信息中，能观察到 fisrt inode 号可能为 11 也可能为 12。&lt;/p>
&lt;p>并且注意到”/“的 inode 号为 2，这个特性在文件访问时会用上。&lt;/p>
&lt;p>需要注意的是，每个文件系统都会分配自己的 inode 号，不同文件系统之间是可能会出现使用相同 inode 号文件的。例如：&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi ~]# find / -ignore_readdir_race -inum 2 -ls
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> 2 4 dr-xr-xr-x 22 root root 4096 Jun 9 09:56 /
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> 2 2 dr-xr-xr-x 5 root root 1024 Feb 25 11:53 /boot
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> 2 0 c--------- 1 root root Jun 7 02:13 /dev/pts/ptmx
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> 2 0 -rw-r--r-- 1 root root 0 Jun 6 18:13 /proc/sys/fs/binfmt_misc/status
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> 2 0 drwxr-xr-x 3 root root 0 Jun 6 18:13 /sys/fs
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>从结果中可见，除了根的 Inode 号为 2，还有几个文件的 inode 号也是 2，它们都属于独立的文件系统，有些是虚拟文件系统，如 /proc 和 /sys。&lt;/p>
&lt;h2 id="ext2-3的inode直接间接寻址-ext23的inode直接间接寻址ext23-的-inode-直接间接寻址">&lt;a href="#ext2-3%E7%9A%84inode%E7%9B%B4%E6%8E%A5%E3%80%81%E9%97%B4%E6%8E%A5%E5%AF%BB%E5%9D%80" title="ext2/3的inode直接、间接寻址">&lt;/a>ext2/3 的 inode 直接、间接寻址&lt;a class="td-heading-self-link" href="#ext2-3%e7%9a%84inode%e7%9b%b4%e6%8e%a5%e9%97%b4%e6%8e%a5%e5%af%bb%e5%9d%80-ext23%e7%9a%84inode%e7%9b%b4%e6%8e%a5%e9%97%b4%e6%8e%a5%e5%af%bb%e5%9d%80ext23-%e7%9a%84-inode-%e7%9b%b4%e6%8e%a5%e9%97%b4%e6%8e%a5%e5%af%bb%e5%9d%80" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>前文说过，inode 中保存了 blocks 指针，但是一条 inode 记录中能保存的指针数量是有限的，否则就会超出 inode 大小 (128 字节或 256 字节)。&lt;/p>
&lt;p>在 ext2 和 ext3 文件系统中，一个 inode 中最多只能有 15 个指针，每个指针使用 i_block [n] 表示。&lt;/p>
&lt;p>前 12 个指针 i_block [0] 到 i_block [11] 是直接寻址指针，每个指针指向一个数据区的 block。如下图所示。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615095614790-1724952851.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615095614790-1724952851.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>第 13 个指针 i_block [12] 是一级间接寻址指针，它指向一个仍然存储了指针的 block 即 i_block [12] –&amp;gt; Pointerblock –&amp;gt; datablock。&lt;/p>
&lt;p>第 14 个指针 i_block [13] 是二级间接寻址指针，它指向一个仍然存储了指针的 block，但是这个 block 中的指针还继续指向其他存储指针的 block，即 i_block [13] –&amp;gt; Pointerblock1 –&amp;gt; PointerBlock2 –&amp;gt; datablock。&lt;/p>
&lt;p>第 15 个指针 i_block [14] 是三级间接寻址指针，它指向一个任然存储了指针的 block，这个指针 block 下还有两次指针指向。即 i_block [13] –&amp;gt; Pointerblock1 –&amp;gt; PointerBlock2 –&amp;gt; PointerBlock3 –&amp;gt; datablock。&lt;/p>
&lt;p>其中由于每个指针大小为 4 字节，所以每个指针 block 能存放的指针数量为 BlockSize/4byte。例如 blocksize 为 4KB，那么一个 Block 可以存放 4096/4=1024 个指针。&lt;/p>
&lt;p>如下图。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615095634665-801241861.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615095634665-801241861.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>为什么要分间接和直接指针呢？如果一个 inode 中 15 个指针全是直接指针，假如每个 block 的大小为 1KB，那么 15 个指针只能指向 15 个 block 即 15KB 的大小，由于每个文件对应一个 inode 号，所以就限制了每个文件最大为 15*1=15KB，这显然是不合理的。&lt;/p>
&lt;p>如果存储大于 15KB 的文件而又不太大的时候，就占用一级间接指针 i_block [12]，这时可以存放指针数量为 1024/4+12=268，所以能存放 268KB 的文件。&lt;/p>
&lt;p>如果存储大于 268K 的文件而又不太大的时候，就继续占用二级指针 i_block [13]，这时可以存放指针数量为 [1024/4]^2+1024/4+12=65804，所以能存放 65804KB=64M 左右的文件。&lt;/p>
&lt;p>如果存放的文件大于 64M，那么就继续使用三级间接指针 i_block [14]，存放的指针数量为 [1024/4]^3+[1024/4]^2+[1024/4]+12=16843020 个指针，所以能存放 16843020KB=16GB 左右的文件。&lt;/p>
&lt;p>如果 blocksize=4KB 呢？那么最大能存放的文件大小为 ([4096/4]^3+[4096/4]^2+[4096/4]+12)*4/1024/1024/1024=4T 左右。&lt;/p>
&lt;p>当然这样计算出来的不一定就是最大能存放的文件大小，它还受到另一个条件的限制。这里的计算只是表明一个大文件是如何寻址和分配的。&lt;/p>
&lt;p>其实看到这里的计算数值，就知道 ext2 和 ext3 对超大文件的存取效率是低下的，它要核对太多的指针，特别是 4KB 大小的 blocksize 时。而 ext4 针对这一点就进行了优化，ext4 使用 extent 的管理方式取代 ext2 和 ext3 的块映射，大大提高了效率也降低了碎片。&lt;/p>
&lt;p>在 Linux 上执行删除、复制、重命名、移动等操作时，它们是怎么进行的呢？还有访问文件时是如何找到它的呢？其实只要理解了前文中介绍的几个术语以及它们的作用就很容易知道文件操作的原理了。&lt;/p>
&lt;p>注：在这一小节所解释的都是在单个文件系统下的行为，在多个文件系统中如何请看下一个小节：多文件系统关联。&lt;/p>
&lt;h2 id="读取文件-读取文件读取文件">&lt;a href="#%E8%AF%BB%E5%8F%96%E6%96%87%E4%BB%B6" title="读取文件">&lt;/a>读取文件&lt;a class="td-heading-self-link" href="#%e8%af%bb%e5%8f%96%e6%96%87%e4%bb%b6-%e8%af%bb%e5%8f%96%e6%96%87%e4%bb%b6%e8%af%bb%e5%8f%96%e6%96%87%e4%bb%b6" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>当执行 &lt;code>cat /var/log/messages&lt;/code> 命令在系统内部进行了什么样的步骤呢？该命令能被成功执行涉及了 cat 命令的寻找、权限判断以及 messages 文件的寻找和权限判断等等复杂的过程。这里只解释和本节内容相关的如何寻找到被 cat 的 /var/log/messages 文件。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>找到根文件系统的块组描述符表所在的 blocks，读取 GDT (已在内存中) 找到 inode table 的 block 号。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>因为 GDT 总是和 superblock 在同一个块组，而 superblock 总是在分区的第 1024-2047 个字节，所以很容易就知道第一个 GDT 所在的块组以及 GDT 在这个块组中占用了哪些 block。&lt;/p>
&lt;p>其实 GDT 早已经在内存中了，在系统开机的时候会挂载根文件系统，挂载的时候就已经将所有的 GDT 放进内存中。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>在 inode table 的 block 中定位到根”/“的 inode，找出”/“指向的 data block。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>前文说过，ext 文件系统预留了一些 inode 号，其中”/“的 inode 号为 2，所以可以根据 inode 号直接定位根目录文件的 data block。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>在”/“的 datablock 中记录了 var 目录名和 var 的 inode 号，找到该 inode 记录，inode 记录中存储了指向 var 的 block 指针，所以也就找到了 var 目录文件的 data block。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>通过 var 目录的 inode 号，可以寻找到 var 目录的 inode 记录，但是在寻找的过程中，还需要知道该 inode 记录所在的块组以及所在的 inode table，所以需要读取 GDT，同样，GDT 已经缓存到了内存中。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>在 var 的 data block 中记录了 log 目录名和其 inode 号，通过该 inode 号定位到该 inode 所在的块组及所在的 inode table，并根据该 inode 记录找到 log 的 data block。&lt;/strong>&lt;/li>
&lt;li>&lt;strong>在 log 目录文件的 data block 中记录了 messages 文件名和对应的 inode 号，通过该 inode 号定位到该 inode 所在的块组及所在的 inode table，并根据该 inode 记录找到 messages 的 data block。&lt;/strong>&lt;/li>
&lt;li>&lt;strong>最后读取 messages 对应的 datablock。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>将上述步骤中 GDT 部分的步骤简化后比较容易理解。如下：找到 GDT–&amp;gt; 找到”/“的 inode–&amp;gt; 找到 / 的数据块读取 var 的 inode–&amp;gt; 找到 var 的数据块读取 log 的 inode–&amp;gt; 找到 log 的数据块读取 messages 的 inode–&amp;gt; 找到 messages 的数据块并读取它们。&lt;/p>
&lt;p>当然，在每次定位到 inode 记录后，都会先将 inode 记录加载到内存中，然后查看权限，如果权限允许，将根据 block 指针找到对应的 data block。&lt;/p>
&lt;h2 id="删除重命名和移动文件-删除重命名和移动文件删除重命名和移动文件">&lt;a href="#%E5%88%A0%E9%99%A4%E3%80%81%E9%87%8D%E5%91%BD%E5%90%8D%E5%92%8C%E7%A7%BB%E5%8A%A8%E6%96%87%E4%BB%B6" title="删除、重命名和移动文件">&lt;/a>删除、重命名和移动文件&lt;a class="td-heading-self-link" href="#%e5%88%a0%e9%99%a4%e9%87%8d%e5%91%bd%e5%90%8d%e5%92%8c%e7%a7%bb%e5%8a%a8%e6%96%87%e4%bb%b6-%e5%88%a0%e9%99%a4%e9%87%8d%e5%91%bd%e5%90%8d%e5%92%8c%e7%a7%bb%e5%8a%a8%e6%96%87%e4%bb%b6%e5%88%a0%e9%99%a4%e9%87%8d%e5%91%bd%e5%90%8d%e5%92%8c%e7%a7%bb%e5%8a%a8%e6%96%87%e4%bb%b6" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>注意这里是不跨越文件系统的操作行为。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>删除文件分为普通文件和目录文件，知道了这两种类型的文件的删除原理，就知道了其他类型特殊文件的删除方法。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>对于删除普通文件：(1) 找到文件的 inode 和 data block (根据前一个小节中的方法寻找)；(2) 将 inode table 中该 inode 记录中的 data block 指针删除；(3) 在 imap 中将该文件的 inode 号标记为未使用；(4) 在其所在目录的 data block 中将该文件名所在的记录行删除，删除了记录就丢失了指向 inode 的指针（实际上不是真的删除，直接删除的话会在目录 data block 的数据结构中产生空洞，所以实际的操作是将待删除文件的 inode 号设置为特殊的值 0，这样下次新建文件时就可以重用该行记录）；(5) 将 bmap 中 data block 对应的 block 号标记为未使用（对于 ext 文件系统，这个步骤可能会导致删除大文件时间较久，资源消耗较多，对于其它文件系统，则视情况而定）。&lt;/p>
&lt;p>对于删除目录文件：找到目录和目录下所有文件、子目录、子文件的 inode 和 data block；在 imap 中将这些 inode 号标记为未使用；将 bmap 中将这些文件占用的 block 号标记为未使用；在该目录的父目录的 data block 中将该目录名所在的记录行删除。需要注意的是，删除父目录 data block 中的记录是最后一步，如果该步骤提前，将报目录非空的错误，因为在该目录中还有文件占用。&lt;/p>
&lt;p>关于上面的 (2)-(5)：当 (2) 中删除 data block 指针后，将无法再找到这个文件的数据；当 (3) 标记 inode 号未使用，表示该 inode 号可以被后续的文件重用；当 (4) 删除目录 data block 中关于该文件的记录，真正的删除文件，外界再也定位也无法看到这个文件了；当 (5) 标记 data block 为未使用后，表示开始释放空间，这些 data block 可以被其他文件重用。&lt;/p>
&lt;p>注意，在第 (5) 步之前，由于 data block 还未被标记为未使用，在 superblock 中仍然认为这些 data block 是正在使用中的。这表示尽管文件已经被删除了，但空间却还没有释放，df 也会将其统计到已用空间中 (df 是读取 superblock 中的数据块数量，并计算转换为空间大小)。&lt;/p>
&lt;p>什么时候会发生这种情况呢？当一个进程正在引用文件时将该文件删除，就会出现文件已删除但空间未释放的情况。这时步骤已经进行到 (4)，外界无法再找到该文件，但由于进程在加载该文件时已经获取到了该文件所有的 data block 指针，该进程可以获取到该文件的所有数据，但却暂时不会释放该文件空间。直到该进程结束，文件系统才将未执行的步骤 (5) 继续完成。这也是为什么有时候 du 的统计结果比 df 小的原因，关于 du 和 df 统计结果的差别，详细内容见：&lt;a href="https://www.junmajinlong.com/linux/du_df">详细分析 du 和 df 的统计结果为什么不一样&lt;/a>。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>重命名文件分为同目录内重命名和非同目录内重命名。非同目录内重命名实际上是移动文件的过程，见下文&lt;/strong>。&lt;/li>
&lt;/ul>
&lt;p>同目录内重命名文件的动作仅仅只是修改所在目录 data block 中该文件记录的文件名部分，不是删除再重建的过程。&lt;/p>
&lt;p>如果重命名时有文件名冲突 (该目录内已经存在该文件名)，则提示是否覆盖。覆盖的过程是覆盖目录 data block 中冲突文件的记录。例如 /tmp/ 下有 a.txt 和 a.log，若将 a.txt 重命名为 a.log，则提示覆盖，若选择覆盖，则 /tmp 的 data block 中关于 a.log 的记录被覆盖。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>移动文件&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>同文件系统下移动文件实际上是修改目标文件所在目录的 data block，向其中添加一行指向 inode table 中待移动文件的 inode 记录，如果目标路径下有同名文件，则会提示是否覆盖，实际上是覆盖目录 data block 中冲突文件的记录，由于同名文件的 inode 记录指针被覆盖，所以无法再找到该文件的 data block，也就是说该文件被标记为删除 (如果多个硬链接数，则另当别论)。&lt;/p>
&lt;p>所以在同文件系统内移动文件相当快，仅仅在所在目录 data block 中添加或覆盖了一条记录而已。也因此，移动文件时，文件的 inode 号是不会改变的。&lt;/p>
&lt;p>对于不同文件系统内的移动，相当于先复制再删除的动作。见后文。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615100156821-861349673.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615100156821-861349673.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>关于文件移动，在 Linux 环境下有一个非常经典网上却又没任何解释的问题：/tmp/a/a 能覆盖为 /tmp/a 吗？答案是不能，但 windows 能。为什么不能？见 &lt;a href="https://www.junmajinlong.com/linux/linux_file_cmd/#mv_problem">mv 的一个经典问题 (mv 的本质)&lt;/a>。&lt;/p>
&lt;h2 id="存储和复制文件-存储和复制文件存储和复制文件">&lt;a href="#%E5%AD%98%E5%82%A8%E5%92%8C%E5%A4%8D%E5%88%B6%E6%96%87%E4%BB%B6" title="存储和复制文件">&lt;/a>存储和复制文件&lt;a class="td-heading-self-link" href="#%e5%ad%98%e5%82%a8%e5%92%8c%e5%a4%8d%e5%88%b6%e6%96%87%e4%bb%b6-%e5%ad%98%e5%82%a8%e5%92%8c%e5%a4%8d%e5%88%b6%e6%96%87%e4%bb%b6%e5%ad%98%e5%82%a8%e5%92%8c%e5%a4%8d%e5%88%b6%e6%96%87%e4%bb%b6" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;ul>
&lt;li>对于文件存储
&lt;ul>
&lt;li>(1). 读取 GDT，找到各个 (或部分) 块组 imap 中未使用的 inode 号，并为待存储文件分配 inode 号；&lt;/li>
&lt;li>(2). 在 inode table 中完善该 inode 号所在行的记录；&lt;/li>
&lt;li>(3). 在目录的 data block 中添加一条该文件的相关记录；&lt;/li>
&lt;li>(4). 将数据填充到 data block 中。
&lt;ul>
&lt;li>注意，填充到 data block 中的时候会调用 block 分配器：一次分配 4KB 大小的 block 数量，当填充完 4KB 的 data block 后会继续调用 block 分配器分配 4KB 的 block，然后循环直到填充完所有数据。也就是说，如果存储一个 100M 的文件需要调用 block 分配器 100*1024/4=25600 次。&lt;/li>
&lt;li>另一方面，在 block 分配器分配 block 时，block 分配器并不知道真正有多少 block 要分配，只是每次需要分配时就分配，在每存储一个 data block 前，就去 bmap 中标记一次该 block 已使用，它无法实现一次标记多个 bmap 位。这一点在 ext4 中进行了优化。&lt;/li>
&lt;/ul>
&lt;/li>
&lt;li>(5) 填充完之后，去 inode table 中更新该文件 inode 记录中指向 data block 的寻址指针。&lt;/li>
&lt;/ul>
&lt;/li>
&lt;li>对于复制，完全就是另一种方式的存储文件。步骤和存储文件的步骤一样。&lt;/li>
&lt;/ul>
&lt;p>在单个文件系统中的文件操作和多文件系统中的操作有所不同。本文将对此做出非常详细的说明。&lt;/p>
&lt;h2 id="根文件系统的特殊性-根文件系统的特殊性根文件系统的特殊性">&lt;a href="#%E6%A0%B9%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E7%9A%84%E7%89%B9%E6%AE%8A%E6%80%A7" title="根文件系统的特殊性">&lt;/a>根文件系统的特殊性&lt;a class="td-heading-self-link" href="#%e6%a0%b9%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e7%9a%84%e7%89%b9%e6%ae%8a%e6%80%a7-%e6%a0%b9%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e7%9a%84%e7%89%b9%e6%ae%8a%e6%80%a7%e6%a0%b9%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e7%9a%84%e7%89%b9%e6%ae%8a%e6%80%a7" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>这里要明确的是，任何一个文件系统要在 Linux 上能正常使用，必须挂载在某个已经挂载好的文件系统中的某个目录下，例如 /dev/cdrom 挂载在 /mnt 上，/mnt 目录本身是在”/“文件系统下的。而且任意文件系统的一级挂载点必须是在根文件系统的某个目录下，因为只有”/“是自引用的。这里要说明挂载点的级别和自引用的概念。&lt;/p>
&lt;p>假如 /dev/sdb1 挂载在 /mydata 上，/dev/cdrom 挂载在 /mydata/cdrom 上，那么 /mydata 就是一级挂载点，此时 /mydata 已经是文件系统 /dev/sdb1 的入口了，而 /dev/cdrom 所挂载的目录 /mydata/cdrom 是文件系统 /dev/sdb1 中的某个目录，那么 /mydata/cdrom 就是二级挂载点。一级挂载点必须在根文件系统下，所以可简述为：文件系统 2 挂载在文件系统 1 中的某个目录下，而文件系统 1 又挂载在根文件系统中的某个目录下。&lt;/p>
&lt;p>再解释自引用。首先要说的是，自引用的只能是文件系统，而文件系统表现形式是一个目录，所以自引用是指该目录的 data block 中，”.” 和”..” 的记录中的 inode 号都对应 inode table 中同一个 inode 记录，所以它们 inode 号是相同的，即互为硬链接。而根文件系统是唯一可以自引用的文件系统。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi /]# ll -ai /
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>total 102
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> 2 dr-xr-xr-x. 22 root root 4096 Jun 6 18:13 .
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> 2 dr-xr-xr-x. 22 root root 4096 Jun 6 18:13 ..
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>由此也能解释 cd /. 和 cd /.. 的结果都还是在根下，这是自引用最直接的表现形式。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@xuexi tmp]# cd /.
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@xuexi /]#
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@xuexi tmp]# cd /..
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@xuexi /]#
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>注意，根目录下的”.” 和”..” 都是”/“目录的硬链接，且其 datablock 中不记录名为”/“的条目，因此除去根目录下子目录数后的硬链接数为 2。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# a=$(ls -ld / | awk &amp;#39;{print $2}&amp;#39;)
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# b=$(ls -l / | grep &amp;#34;^d&amp;#34; |wc -l)
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# echo $((a - b))
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>2
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;h2 id="挂载文件系统的细节-挂载文件系统的细节挂载文件系统的细节">&lt;a href="#%E6%8C%82%E8%BD%BD%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E7%9A%84%E7%BB%86%E8%8A%82" title="挂载文件系统的细节">&lt;/a>挂载文件系统的细节&lt;a class="td-heading-self-link" href="#%e6%8c%82%e8%bd%bd%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e7%9a%84%e7%bb%86%e8%8a%82-%e6%8c%82%e8%bd%bd%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e7%9a%84%e7%bb%86%e8%8a%82%e6%8c%82%e8%bd%bd%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e7%9a%84%e7%bb%86%e8%8a%82" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>挂载文件系统到某个目录下，例如”mount /dev/cdrom/mnt”，挂载成功后 /mnt 目录中的文件全都暂时不可见了，且挂载后权限和所有者 (如果指定允许普通用户挂载) 等的都改变了，知道为什么吗？&lt;/p>
&lt;p>下面就以通过”mount /dev/cdrom/mnt” 为例，详细说明挂载过程中涉及的细节。&lt;/p>
&lt;p>在将文件系统 /dev/cdrom (此处暂且认为它是文件系统) 挂载到挂载点 /mnt 之前，挂载点 /mnt 是根文件系统中的一个目录，”/“的 data block 中记录了 /mnt 的一些信息，其中包括 inode 号 inode_n，而在 inode table 中，/mnt 对应的 inode 记录中又存储了 block 指针 block_n，此时这两个指针还是普通的指针。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615100947634-2140254844.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615100947634-2140254844.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>当文件系统 /dev/cdrom 挂载到 /mnt 上后，/mnt 此时就已经成为另一个文件系统的入口了，因此它需要连接两边文件系统的 inode 和 data block。但是如何连接呢？如下图。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615101016571-14202340.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615101016571-14202340.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>在根文件系统的 inode table 中，为 /mnt 重新分配一个 inode 记录 m，该记录的 block 指针 block_m 指向文件系统 /dev/cdrom 中的 data block。既然为 /mnt 分配了新的 inode 记录 m，那么在”/“目录的 data block 中，也需要修改其 inode 指针为 inode_m 以指向 m 记录。同时，原来 inode table 中的 inode 记录 n 就被标记为暂时不可用。&lt;/p>
&lt;p>block_m 指向的是文件系统 /dev/cdrom 的 data block，所以严格说起来，除了 /mnt 的元数据信息即 inode 记录 m 还在根文件系统上，/mnt 的 data block 已经是在 /dev/cdrom 中的了。这就是挂载新文件系统后实现的跨文件系统，它将挂载点的元数据信息和数据信息分别存储在不同的文件系统上。&lt;/p>
&lt;p>挂载完成后，将在 /proc/self/{mounts,mountstats,mountinfo} 这三个文件中写入挂载记录和相关的挂载信息，并会将 /proc/self/mounts 中的信息同步到 /etc/mtab 文件中，当然，如果挂载时加了 - n 参数，将不会同步到 /etc/mtab。&lt;/p>
&lt;p>而卸载文件系统，其实质是移除临时新建的 inode 记录 (当然，在移除前会检查是否正在使用) 及其指针，并将指针指回原来的 inode 记录，这样 inode 记录中的 block 指针也就同时生效而找回对应的 data block 了。由于卸载只是移除 inode 记录，所以使用挂载点和文件系统都可以实现卸载，因为它们是联系在一起的。&lt;/p>
&lt;p>下面是分析或结论。&lt;/p>
&lt;p>(1). 挂载点挂载时的 inode 记录是新分配的。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span># 挂载前挂载点/mnt的inode号
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# ll -id /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>100663447 drwxr-xr-x. 2 root root 6 Aug 12 2015 /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# mount /dev/cdrom /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span># 挂载后挂载点的inode号
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# ll -id /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>1856 dr-xr-xr-x 8 root root 2048 Dec 10 2015 mnt
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>由此可以验证，inode 号确实是重新分配的。&lt;/p>
&lt;p>(2). 挂载后，挂载点的内容将暂时不可见、不可用，卸载后文件又再次可见、可用。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span># 在挂载前，向挂载点中创建几个文件
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# touch /mnt/a.txt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# mkdir /mnt/abcdir
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span># 挂载
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# mount /dev/cdrom /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span># 挂载后，挂载点中将找不到刚创建的文件
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# ll /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>total 636
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-r--r--r-- 1 root root 14 Dec 10 2015 CentOS_BuildTag
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>dr-xr-xr-x 3 root root 2048 Dec 10 2015 EFI
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-r--r--r-- 1 root root 215 Dec 10 2015 EULA
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-r--r--r-- 1 root root 18009 Dec 10 2015 GPL
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>dr-xr-xr-x 3 root root 2048 Dec 10 2015 images
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>dr-xr-xr-x 2 root root 2048 Dec 10 2015 isolinux
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>dr-xr-xr-x 2 root root 2048 Dec 10 2015 LiveOS
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>dr-xr-xr-x 2 root root 612352 Dec 10 2015 Packages
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>dr-xr-xr-x 2 root root 4096 Dec 10 2015 repodata
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-r--r--r-- 1 root root 1690 Dec 10 2015 RPM-GPG-KEY-CentOS-7
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-r--r--r-- 1 root root 1690 Dec 10 2015 RPM-GPG-KEY-CentOS-Testing-7
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-r--r--r-- 1 root root 2883 Dec 10 2015 TRANS.TBL
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span># 卸载后，挂载点/mnt中的文件将再次可见
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# umount /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>[root@server2 tmp]# ll /mnt
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>total 0
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>drwxr-xr-x 2 root root 6 Jun 9 08:18 abcdir
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>-rw-r--r-- 1 root root 0 Jun 9 08:18 a.txt
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>之所以会这样，是因为挂载文件系统后，挂载点原来的 inode 记录暂时被标记为不可用，关键是没有指向该 inode 记录的 inode 指针了。在卸载文件系统后，又重新启用挂载点原来的 inode 记录，”/“目录下的 mnt 的 inode 指针又重新指向该 inode 记录。&lt;/p>
&lt;p>(3). 挂载后，挂载点的元数据和 data block 是分别存放在不同文件系统上的。&lt;/p>
&lt;p>(4). 挂载点即使在挂载后，也还是属于源文件系统的文件。&lt;/p>
&lt;h2 id="多文件系统操作关联-多文件系统操作关联多文件系统操作关联">&lt;a href="#%E5%A4%9A%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E6%93%8D%E4%BD%9C%E5%85%B3%E8%81%94" title="多文件系统操作关联">&lt;/a>多文件系统操作关联&lt;a class="td-heading-self-link" href="#%e5%a4%9a%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e6%93%8d%e4%bd%9c%e5%85%b3%e8%81%94-%e5%a4%9a%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e6%93%8d%e4%bd%9c%e5%85%b3%e8%81%94%e5%a4%9a%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e6%93%8d%e4%bd%9c%e5%85%b3%e8%81%94" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>假如下图中的圆代表一块硬盘，其中划分了 3 个区即 3 个文件系统。其中根是根文件系统，/mnt 是另一个文件系统 A 的入口，A 文件系统挂载在 /mnt 上，/mnt/cdrom 也是一个文件系统 B 的入口，B 文件系统挂载在 /mnt/cdrom 上。每个文件系统都维护了一些 inode table，这里假设图中的 inode table 是每个文件系统所有块组中的 inode table 的集合表。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615101444509-1613755325.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615101444509-1613755325.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>如何读取 /var/log/messages 呢？这是和”/“在同一个文件系统的文件读取，在前面单文件系统中已经详细说明了。&lt;/p>
&lt;p>但如何读取 A 文件系统中的 /mnt/a.log 呢？首先，从根文件系统找到 /mnt 的 inode 记录，这是单文件系统内的查找；然后根据此 inode 记录的 block 指针，定位到 /mnt 的 data block 中，这些 block 是 A 文件系统的 data block；然后从 /mnt 的 data block 中读取 a.log 记录，并根据 a.log 的 inode 指针定位到 A 文件系统的 inode table 中对应 a.log 的 inode 记录；最后从此 inode 记录的 block 指针找到 a.log 的 data block。至此，就能读取到 /mnt/a.log 文件的内容。&lt;/p>
&lt;p>下图能更完整的描述上述过程。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615101506743-1757840484.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615101506743-1757840484.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>那么又如何读取 /mnt/cdrom 中的 /mnt/cdrom/a.rpm 呢？这里 cdrom 代表的文件系统 B 挂载点位于 /mnt 下，所以又多了一个步骤。先找到”/“，再找到根中的 mnt，进入到 mnt 文件系统中，找到 cdrom 的 data block，再进入到 cdrom 找到 a.rpm。也就是说，mnt 目录文件存放位置是根，cdrom 目录文件存放位置是 mnt，最后 a.rpm 存放的位置才是 cdrom。&lt;/p>
&lt;p>继续完善上图。如下。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615101532431-1952370802.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615101532431-1952370802.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>相比 ext2 文件系统，ext3 多了一个日志功能。&lt;/p>
&lt;p>在 ext2 文件系统中，只有两个区：数据区和元数据区。如果正在向 data block 中填充数据时突然断电，那么下一次启动时就会检查文件系统中数据和状态的一致性，这段检查和修复可能会消耗大量时间，甚至检查后无法修复。之所以会这样是因为文件系统在突然断电后，它不知道上次正在存储的文件的 block 从哪里开始、哪里结束，所以它会扫描整个文件系统进行排除 (也许是这样检查的吧)。&lt;/p>
&lt;p>而在创建 ext3 文件系统时会划分三个区：数据区、日志区和元数据区。每次存储数据时，先在日志区中进行 ext2 中元数据区的活动，直到文件存储完成后标记上 commit 才将日志区中的数据转存到元数据区。当存储文件时突然断电，下一次检查修复文件系统时，只需要检查日志区的记录，将 bmap 对应的 data block 标记为未使用，并把 inode 号标记未使用，这样就不需要扫描整个文件系统而耗费大量时间。&lt;/p>
&lt;p>虽说 ext3 相比 ext2 多了一个日志区转写元数据区的动作而导致 ext3 相比 ext2 性能要差一点，特别是写众多小文件时。但是由于 ext3 其他方面的优化使得 ext3 和 ext2 性能几乎没有差距。&lt;/p>
&lt;p>回顾前面关于 ext2 和 ext3 文件系统的存储格式，它使用 block 为存储单元，每个 block 使用 bmap 中的位来标记是否空闲，尽管使用划分块组的方法优化提高了效率，但是一个块组内部仍然使用 bmap 来标记该块组内的 block。对于一个巨大的文件，扫描整个 bmap 都将是一件浩大的工程。另外在 inode 寻址方面，ext2/3 使用直接和间接的寻址方式，对于三级间接指针，可能要遍历的指针数量是非常非常巨大的。&lt;/p>
&lt;p>ext4 文件系统的最大特点是在 ext3 的基础上使用区 (extent，或称为段) 的概念来管理。一个 extent 尽可能的包含物理上连续的一堆 block。inode 寻址方面也一样使用区段树的方式进行了改进。&lt;/p>
&lt;p>默认情况下，EXT4 不再使用 EXT3 的 block mapping 分配方式 ，而改为 Extent 方式分配。&lt;/p>
&lt;p>以下是 ext4 文件系统中一个文件的 inode 属性示例，注意最后两行的 EXTENTS。&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-plain" data-lang="plain">&lt;span style="display:flex;">&lt;span>Inode: 12 Type: regular Mode: 0644 Flags: 0x80000
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Generation: 476513974 Version: 0x00000000:00000001
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>User: 0 Group: 0 Size: 11
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>File ACL: 0 Directory ACL: 0
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Links: 1 Blockcount: 8
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Fragment: Address: 0 Number: 0 Size: 0
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> ctime: 0x5b628ca0:491d6224 -- Thu Aug 2 12:46:24 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> atime: 0x5b628ca0:491d6224 -- Thu Aug 2 12:46:24 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> mtime: 0x5b628ca0:491d6224 -- Thu Aug 2 12:46:24 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>crtime: 0x5b628ca0:491d6224 -- Thu Aug 2 12:46:24 2018
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>Size of extra inode fields: 28
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>EXTENTS:
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>(0):33409
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>(1). 关于 EXT4 的结构特征&lt;/p>
&lt;p>EXT4 在总体结构上与 EXT3 相似，大的分配方向都是基于相同大小的块组，每个块组内分配固定数量的 inode、可能的 superblock (或备份) 及 GDT。&lt;/p>
&lt;p>EXT4 的 inode 结构做了重大改变，为增加新的信息，大小由 EXT3 的 128 字节增加到默认的 256 字节，同时 inode 寻址索引不再使用 EXT3 的”12 个直接寻址块 + 1 个一级间接寻址块 + 1 个二级间接寻址块 + 1 个三级间接寻址块” 的索引模式，而改为 4 个 Extent 片断流，每个片断流设定片断的起始 block 号及连续的 block 数量 (有可能直接指向数据区，也有可能指向索引块区)。&lt;/p>
&lt;p>片段流即下图中索引节点 (index node block) 部分的绿色区域，每个 15 字节，共 60 字节。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615101630493-1536814900.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615101630493-1536814900.jpg" alt="">
&lt;/a>&lt;/p>
&lt;p>(2).EXT4 删除数据的结构更改。&lt;/p>
&lt;p>EXT4 删除数据后，会依次释放文件系统 bitmap 空间位、更新目录结构、释放 inode 空间位。&lt;/p>
&lt;p>(3).ext4 使用多 block 分配方式。&lt;/p>
&lt;p>在存储数据时，ext3 中的 block 分配器一次只能分配 4KB 大小的 Block 数量，而且每存储一个 block 前就标记一次 bmap。假如存储 1G 的文件，blocksize 是 4KB，那么每存储完一个 Block 就将调用一次 block 分配器，即调用的次数为 1024*1024/4KB=262144 次，标记 bmap 的次数也为 1024*1024/4=262144 次。&lt;/p>
&lt;p>而在 ext4 中根据区段来分配，可以实现调用一次 block 分配器就分配一堆连续的 block，并在存储这一堆 block 前一次性标记对应的 bmap。这对于大文件来说极大的提升了存储效率。&lt;/p>
&lt;p>最大的缺点是它在创建文件系统的时候就划分好一切需要划分的东西，以后用到的时候可以直接进行分配，也就是说它不支持动态划分和动态分配。对于较小的分区来说速度还好，但是对于一个超大的磁盘，速度是极慢极慢的。例如将一个几十 T 的磁盘阵列格式化为 ext4 文件系统，可能你会因此而失去一切耐心。&lt;/p>
&lt;p>除了格式化速度超慢以外，ext4 文件系统还是非常可取的。当然，不同公司开发的文件系统都各有特色，最主要的还是根据需求选择合适的文件系统类型。&lt;/p>
&lt;p>每一个分区格式化后都可以建立一个文件系统，Linux 上可以识别很多种文件系统，那么它是如何识别的呢？另外，在我们操作分区中的文件时，并没有指定过它是哪个文件系统的，各种不同的文件系统如何被我们用户以无差别的方式操作呢？这就是虚拟文件系统的作用。&lt;/p>
&lt;p>虚拟文件系统为用户操作各种文件系统提供了通用接口，使得用户执行程序时不需要考虑文件是在哪种类型的文件系统上，应该使用什么样的系统调用来操作该文件。有了虚拟文件系统，只要将所有需要执行的程序调用 VFS 的系统调用就可以了，剩下的动作由 VFS 来帮忙完成。&lt;/p>
&lt;p>&lt;a href="https://www.junmajinlong.com/img/linux/733013-20170615101808150-916356306.jpg">&lt;img src="https://www.junmajinlong.com/img/linux/733013-20170615101808150-916356306.jpg" alt="">
&lt;/a>&lt;/p></description></item><item><title>Blog: CPU 是如何读写内存的？</title><link>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/CPU-%E6%98%AF%E5%A6%82%E4%BD%95%E8%AF%BB%E5%86%99%E5%86%85%E5%AD%98%E7%9A%84/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/CPU-%E6%98%AF%E5%A6%82%E4%BD%95%E8%AF%BB%E5%86%99%E5%86%85%E5%AD%98%E7%9A%84/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/S3Cn6KsDGKqxxP58y2m67Q">https://mp.weixin.qq.com/s/S3Cn6KsDGKqxxP58y2m67Q&lt;/a>&lt;/p>
&lt;p>如果你觉得这是一个非常简单的问题，那么你真应该好好读读本文，&lt;strong>我敢保证这个问题绝没有你想象的那么简单&lt;/strong>。注意，一定要完本文，&lt;strong>否则可能会得出错误的结论&lt;/strong>。闲话少说，让我们来看看 CPU 在读写内存时底层究竟发生了什么。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494695-3520afa8-7698-4bb7-b054-63d8593e6183.png" alt="">
&lt;strong>谁来告诉 CPU 读写内存&lt;/strong>
我们第一个要搞清楚的问题是：谁来告诉 CPU 去读写内存？答案很明显，是程序员，更具体的是编译器。CPU 只是按照指令按部就班的执行，机器指令从哪里来的呢？是编译器生成的，程序员通过高级语言编写程序，编译器将其翻译为机器指令，机器指令来告诉 CPU 去读写内存。在精简指令集架构下会有特定的机器指令，Load/Store 指令来读写内存，以 x86 为代表的复杂指令集架构下没有特定的访存指令。精简指令集下，一条机器指令操作的数据必须来存放在寄存器中，不能直接操作内存数据，因此 RISC 下，数据必须先从内存搬运到寄存器，这就是为什么 RISC 下会有特定的 Load/Store 访存指令，明白了吧。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494595-c823fd37-ed5d-4ac8-bbb8-1a31ed3045a6.gif" alt="">而 x86 下无此限制，一条机器指令操作的数据可以来自于寄存器也可以来自内存，因此这样一条机器指令在执行过程中会首先从内存中读取数据。关于复杂指令集以及精简指令集你可以参考这两篇文章《&lt;a href="http://mp.weixin.qq.com/s?__biz=Mzg4OTYzODM4Mw==&amp;amp;mid=2247485740&amp;amp;idx=1&amp;amp;sn=5e21003aa245c64516225cbdec30fc25&amp;amp;chksm=cfe995acf89e1cbaf208a25999d6c9b08e505ea8b8a49564e08c63a819b0a4fa1160893a8047&amp;amp;scene=21#wechat_redirect">CPU 进化论：复杂指令集&lt;/a>》与《&lt;a href="http://mp.weixin.qq.com/s?__biz=Mzg4OTYzODM4Mw==&amp;amp;mid=2247485741&amp;amp;idx=1&amp;amp;sn=45afcce8e8e8ec198a9b09c32c1e6aa8&amp;amp;chksm=cfe995adf89e1cbb833ca61741028bee6ccfeb1e928efe60a3a8fcf1fa01da3df4ef49a063de&amp;amp;scene=21#wechat_redirect">不懂精简指令集还敢说自己是程序员？&lt;/a>》&lt;/p>
&lt;h5 id="两种内存读写">&lt;strong>两种内存读写&lt;/strong>&lt;a class="td-heading-self-link" href="#%e4%b8%a4%e7%a7%8d%e5%86%85%e5%ad%98%e8%af%bb%e5%86%99" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>现在我们知道了，是特定的机器指令告诉 CPU 要去访问内存。不过，值得注意的是，不管是 RISC 下特定的 Load/Store 指令还是 x86 下包含在一条指令内部的访存操作，这里读写的都是内存中的数据，除此之外还要意识到，CPU 除了从内存中读写数据外，还要从内存中读取下一条要执行的机器指令。毕竟，我们的计算设备都遵从冯诺依曼架构：&lt;strong>程序和数据一视同仁，都可以存放在内存中&lt;/strong>。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494722-62b1ce8b-3e11-48ac-bc69-66d8c2d7cf28.png" alt="">现在，我们清楚了 CPU 读写内存其实是由两个因素来驱动的：&lt;/p>
&lt;ol>
&lt;li>
&lt;p>程序执行过程中需要读写来自内存中的数据&lt;/p>
&lt;/li>
&lt;li>
&lt;p>CPU 需要访问内存读取下一条要执行的机器指令&lt;/p>
&lt;/li>
&lt;/ol>
&lt;p>然后 CPU 根据机器指令中包含的内存地址或者 PC 寄存器中下一条机器指令的地址访问内存。这不就完了吗？有了内存地址，CPU 利用硬件通路直接读内存就好了，你可能也是这样的想的。真的是这样吗？别着急，我们接着往下看，这两节只是开胃菜，正餐才刚刚开始。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494648-fe04d9ee-fbc6-4b6f-b939-b7c4f24dbe63.webp" alt="">&lt;/p>
&lt;h5 id="急性子吃货-vs-慢性子厨师">&lt;strong>急性子吃货 VS 慢性子厨师&lt;/strong>&lt;a class="td-heading-self-link" href="#%e6%80%a5%e6%80%a7%e5%ad%90%e5%90%83%e8%b4%a7-vs-%e6%85%a2%e6%80%a7%e5%ad%90%e5%8e%a8%e5%b8%88" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>假设你是一个整天无所事事的吃货，整天无所事事，唯一的爱好就是找一家餐厅吃吃喝喝，由于你是职业吃货，因此吃起来非常职业，1 分钟就能吃完一道菜，但这里的厨师就没有那么职业了，炒一道菜速度非常慢，大概需要 1 小时 40 分钟才能炒出一道菜，速度比你慢了 100 倍，如果你是这个吃货，大概率会疯掉的。而 CPU 恰好就是这样一个吃货，内存就是这样一个慢吞吞的厨师，而且随着时间的推移这两者的速度差异正在越来越大：&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494714-c2e50753-c4e8-43d1-afa6-3c923c6807d2.webp" alt="">在这种速度差异下，CPU 执行一条涉及内存读写指令时需要等**“很长一段时间“&lt;strong>数据才能&lt;/strong>”缓缓的“&lt;strong>从内存读取到 CPU 中，在这种情况&lt;/strong>你还认为 CPU 应该直接读写内存吗**？&lt;/p>
&lt;h5 id="无处不在的-28-定律">&lt;strong>无处不在的 28 定律&lt;/strong>&lt;a class="td-heading-self-link" href="#%e6%97%a0%e5%a4%84%e4%b8%8d%e5%9c%a8%e7%9a%84-28-%e5%ae%9a%e5%be%8b" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>28 定律我想就不用多介绍了吧，在《&lt;a href="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494774-8e88aec6-cda9-4df8-bc4a-c6b0721656b0.png">不懂精简指令集还敢说自己是程序员&lt;/a>集中起来然后呢？放到哪里呢？当然是放到一种比内存速度更快的存储介质上，这种介质就是我们熟悉的 SRAM，普通内存一般是 DRAM，这种读写速度更快的介质充当 CPU 和内存之间的 Cache，这就是所谓的缓存。&lt;/p>
&lt;h5 id="四两拨千斤">&lt;strong>四两拨千斤&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%9b%9b%e4%b8%a4%e6%8b%a8%e5%8d%83%e6%96%a4" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>我们把经常用到的数据放到 cache 中存储，CPU 访问内存时首先查找 cache，如果能找到，也就是命中，那么就赚到了，直接返回即可，找不到再去查找内存并更新 cache。我们可以看到，&lt;strong>有了 cache，CPU 不再直接与内存打交道了&lt;/strong>。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494726-1c190d71-806e-4781-bce8-ae233a4881b9.png" alt="">但 cache 的快速读写能力是有代价的，代价就是 Money，造价不菲，&lt;strong>因此我们不能把内存完全替换成 cache 的 SRAM，那样的计算机你我都是买不起的&lt;/strong>。因此 cache 的容量不会很大，但由于程序局部性原理，&lt;strong>因此很小的 cache 也能有很高的命中率&lt;/strong>，从而带来性能的极大提升，有个词叫&lt;strong>四两拨千斤&lt;/strong>，用到 cache 这里再合适不过。&lt;/p>
&lt;h5 id="天下没有免费的午餐">&lt;strong>天下没有免费的午餐&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%a4%a9%e4%b8%8b%e6%b2%a1%e6%9c%89%e5%85%8d%e8%b4%b9%e7%9a%84%e5%8d%88%e9%a4%90" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>虽然小小的 cache 能带来性能的极大提升，但，这也是有代价的。这个代价出现在写内存时。当 CPU 需要写内存时该怎么办呢？现在有了 cache，CPU 不再直接与内存打交道，因此 CPU 直接写 cache，但此时就会有一个问题，那就是 cache 中的值更新了，但内存中的值还是旧的，这就是所谓的不一致问题，inconsistent.就像下图这样，cache 中变量的值是 4，但内存中的值是 2。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494764-74ebde75-ea0b-4c97-9d10-32cf9cdd2be4.png" alt="">&lt;/p>
&lt;h5 id="同步缓存更新">&lt;strong>同步缓存更新&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%90%8c%e6%ad%a5%e7%bc%93%e5%ad%98%e6%9b%b4%e6%96%b0" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>常用 redis 的同学应该很熟悉这个问题，&lt;strong>可是你知道吗？这个问题早就在你读这篇文章用的计算设备其包含的 CPU 中已经遇到并已经解决了。&lt;strong>最简单的方法是这样的，当我们更新 cache 时一并把内存也更新了，这种方法被称为 write-through，很形象吧。可是如果当 CPU 写 cache 时，cache 中没有相应的内存数据该怎么呢？这就有点麻烦了，首先我们需要把该数据从内存加载到 cache 中，然后更新 cache，再然后更新内存。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494833-7d54bed1-0b2b-4dec-925f-f816342ede57.png" alt="">这种实现方法虽然简单，但有一个问题，那就是性能问题，在这种方案下&lt;/strong>写内存就不得不访问内存&lt;/strong>，上文也提到过 CPU 和内存可是有很大的速度差异哦，因此这种方案性能比较差。有办法解决吗？答案是肯定的。&lt;/p>
&lt;h5 id="异步更新缓存">&lt;strong>异步更新缓存&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%bc%82%e6%ad%a5%e6%9b%b4%e6%96%b0%e7%bc%93%e5%ad%98" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>这种方法性能差不是因为写内存慢，写内存确实是慢，更重要的原因是 CPU 在同步等待，因此很自然的，这类问题的统一解法就是把同步改为异步。关于同步和异步的话题，你可以参考这篇文章《&lt;a href="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494782-5d7755ab-d9a8-428d-b1ad-3f898aa5cdc4.png">从小白到高手，你需要理解同步和异步&lt;/a>现在你应该能看到，添加 cache 后会带来一系列问题，更不用说 cache 的替换算法，毕竟 cache 的容量有限，当 cache 已满时，增加一项新的数据就要剔除一项旧的数据，那么该剔除谁就是一个非常关键的问题，限于篇幅就不在这里详细讲述了，你可以参考《深入理解操作系统》第 7 章有关于该策略的讲解。&lt;/p>
&lt;h5 id="多级-cache">&lt;strong>多级 cache&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%a4%9a%e7%ba%a7-cache" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>现代 CPU 为了增加 CPU 读写内存性能，已经在 CPU 和内存之间增加了多级 cache，典型的有三级，L1、L2 和 L3，CPU 读内存时首先从 L1 cache 找起，能找到直接返回，否则就要在 L2 cache 中找，L2 cache 中找不到就要到 L3 cache 中找，还找不到就不得不访问内存了。因此我们可以看到，&lt;strong>现代计算机系统 CPU 和内存之间其实是有一个 cache 的层级结构的&lt;/strong>。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494897-db05b255-a5ca-42e7-beb9-e4b976167d71.png" alt="">你以为这就完了吗？哈哈，哪有这么容易的，否则也不会是终面题目了。那么当 CPU 读写内存时除了面临上述问题外还需要处理哪些问题呢？&lt;/p>
&lt;h5 id="多核多问题">&lt;strong>多核，多问题&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%a4%9a%e6%a0%b8%e5%a4%9a%e9%97%ae%e9%a2%98" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>当摩尔定律渐渐失效后鸡贼的人类换了另一种提高 CPU 性能的方法，既然单个 CPU 性能不好提升了，我们还可以堆数量啊，这样，CPU 进入多核时代，程序员开始进入苦逼时代。拥有一堆核心的 CPU 其实是没什么用的，&lt;strong>关键需要有配套的多线程程序才能真正发挥多核的威力&lt;/strong>，但写过多线程程序的程序员都知道，能写出来不容易，能写出来并且能正确运行更不容易，关于多线程与多线程编程的详细阐述请参见《深入理解操作系统》第 5、6 两章(关注公众号“码农的荒岛求生”并回复“操作系统”)。CPU 开始拥有多个核心后不但苦逼了软件工程师，硬件工程师也不能幸免。前文提到过，为提高 CPU 访存性能，CPU 和内存之间会有一个层 cache，但当 CPU 有多个核心后新的问题来了：&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494753-a8075ddc-1b20-4c77-ad15-d71c3d78ac07.png" alt="">
看出问题在哪里了吗？一个初始值为 2 的变量，在分别+2 和+4 后正确的结果应该是 2+2+4 = 8，但从上图可以看出&lt;strong>内存中 X 的值却为 6&lt;/strong>，问题出在哪了呢？&lt;/p>
&lt;h5 id="多核-cache-一致性">&lt;strong>多核 cache 一致性&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%a4%9a%e6%a0%b8-cache-%e4%b8%80%e8%87%b4%e6%80%a7" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>有的同学可能已经发现了，问题出在了内存中一个 X 变量&lt;strong>在 C1 和 C2 的 cache 中有共计两个副本，当 C1 更新 cache 时没有同步修改 C2 cache 中 X 的值&lt;/strong>。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494851-f1847fc5-1967-4cf7-9c17-f589ca806aaf.png" alt="">解决方法是什么呢？显然，如果一个 cache 中待更新的变量同样存在于其它核心的 cache，那么你需要一并将其它 cache 也更新好。现在你应该看到，CPU 更新变量时不再简单的只关心自己的 cache 和内存，&lt;strong>你还需要知道这个变量是不是同样存在于其它核心中的 cache&lt;/strong>，如果存在需要一并更新。当然，这还只是简单的读，写就更加复杂了，实际上，现代 CPU 中有一套协议来专门维护缓存的一致性，比较经典的包括 MESI 协议等。为什么程序员需要关心这个问题呢？原因很简单，&lt;strong>你最好写出对 cache 一致性协议友好的程序&lt;/strong>，&lt;strong>因为 cache 频繁维护一致性也是有性能代价的&lt;/strong>。同样的，限于篇幅，这个话题不再详细阐述，该主题同样值得单独成篇，敬请期待。&lt;/p>
&lt;h5 id="够复杂了吧">&lt;strong>够复杂了吧！&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%a4%9f%e5%a4%8d%e6%9d%82%e4%ba%86%e5%90%a7" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>怎么样？到目前为止，是不是 CPU 读写内存没有看上去那么简单？现代计算机中 CPU 和内存之间有多级 cache，&lt;strong>CPU 读写内存时不但要维护 cache 和内存的一致性，同样需要维护多核间 cache 的一致性&lt;/strong>。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494804-e27375bb-5047-4f46-aefe-0f5667fddf60.webp" alt="">你以为这就完了，NONO，最大的谜团其实是接下来要讲的。&lt;/p>
&lt;h5 id="你以为的不是你以为的">&lt;strong>你以为的不是你以为的&lt;/strong>&lt;a class="td-heading-self-link" href="#%e4%bd%a0%e4%bb%a5%e4%b8%ba%e7%9a%84%e4%b8%8d%e6%98%af%e4%bd%a0%e4%bb%a5%e4%b8%ba%e7%9a%84" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>现代程序员写程序基本上不需要关心&lt;strong>内存是不是足够这个问题&lt;/strong>，但这个问题在远古时代绝对是困扰程序员的一大难题。如果你去想一想，其实现代计算机内存也没有足够大的让我们随便申请的地步，&lt;strong>但是你在写程序时是不是基本上没有考虑过内存不足该怎么办？&lt;strong>为什么我们在内存资源依然处于匮乏的现代可以做到申请内存时却进入内存极大丰富的共产主义理想社会了呢？原来这背后的功臣是我们熟悉的&lt;/strong>操作系统&lt;/strong>。操作系统对每个进程都维护一个假象，即，每个进程独占系统内存资源；同时给程序员一个承诺，让程序员可以认为在写程序时有一大块连续的内存可以使用。这当然是不可能不现实的，因此操作系统给进程的地址空间必然不是真的，但我们又不好将其称之为“&lt;strong>假的地址空间&lt;/strong>”，这会让人误以为计算机科学界里骗子横行，因此就换了一个好听的名字，&lt;strong>虚拟内存&lt;/strong>，一个“&lt;strong>假的地址空间&lt;/strong>”更高级的叫法。&lt;strong>进程其实一直活在操作系统精心维护的幻觉当中&lt;/strong>，就像《盗梦空间》一样，关于虚拟内存的详尽阐述请参见《深入理解操作系统》第七章(关注公众号“码农的荒岛求生”并回复“操作系统”)。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494790-0d313ab7-571e-40a4-8135-4915c01d9d6f.webp" alt="">从这个角度看，其实最擅长包装的是计算机科学界，哦，对了，他们不但擅长包装还擅长抽象。&lt;/p>
&lt;h5 id="天真的-cpu">&lt;strong>天真的 CPU&lt;/strong>&lt;a class="td-heading-self-link" href="#%e5%a4%a9%e7%9c%9f%e7%9a%84-cpu" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>CPU 真的是很傻很天真的存在。上一节讲的操作系统施加的障眼法把 CPU 也蒙在鼓里。CPU 执行机器指令时，指令指示 CPU 从内存地址 A 中取出数据，然后 CPU 执行机器指令时下发命令：“给我从地址 A 中取出数据”，尽管真的能从地址 A 中取出数据，但这个地址 A 不是真的，不是真的，不是真的。因为这个地址 A 属于虚拟内存，也就是那个“假的地址空间”，现代 CPU 内部有一个叫做 MMU 的模块将这假的地址 A 转换为真的地址 B，将地址 A 转换为真实的地址 B 之后才是本文之前讲述的关于 cache 的那一部分。&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/ogei92/1625466494784-5941f257-6712-42f8-9a22-444bf53854d1.png" alt="">你以为这终于应该讲完了吧！NONO！CPU 给出内存地址，此后该地址被转为真正的物理内存地址，接下来查 L1 cache，L1 cache 不命中查 L2 cache，L2 cache 不命中查 L3 cache，L3 cache 不能命中查内存。各单位注意，各单位注意，到查内存时还不算完，现在有了虚拟内存，&lt;strong>内存其实也是一层 cache，是磁盘的 cache，也就是说查内存也有可能不会命中&lt;/strong>，因为内存中的数据可能被虚拟内存系统放到磁盘中了，&lt;strong>如果内存也不能命中就要查磁盘&lt;/strong>。So crazy，限于篇幅这个过程不再展开，《深入理解操作系统》第七章有完整的讲述。至此，CPU 读写内存时完整的过程阐述完毕。&lt;/p>
&lt;h5 id="总结">&lt;strong>总结&lt;/strong>&lt;a class="td-heading-self-link" href="#%e6%80%bb%e7%bb%93" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>现在你还认为 CPU 读写内存非常简单吗？这一过程涉及到的硬件以及硬件逻辑包括：L1 cache、L2 cache、L3 cache、多核缓存一致性协议、MMU、内存、磁盘；软件主要包括操作系统。&lt;strong>这一看似简单的操作涉及几乎所有计算机系统中的核心组件，需要软件以及硬件密切配合才能完成&lt;/strong>。这个过程给程序员的启示是：1)，现代计算机系统是非常复杂的；2),&lt;strong>你需要写出对 cache 友好的程序&lt;/strong>。我是小风哥，希望这篇文章对大家理解 CPU 以及内存读写有所帮助。***参考资料***&lt;strong>1,《深入理解操作系统》第七章&lt;/strong>，&lt;strong>关注公众号“码农的荒岛求生”并回复“操作系统”即可阅读&lt;/strong>。&lt;a href="http://mp.weixin.qq.com/s?__biz=Mzg4OTYzODM4Mw==&amp;amp;mid=2247485740&amp;amp;idx=1&amp;amp;sn=5e21003aa245c64516225cbdec30fc25&amp;amp;chksm=cfe995acf89e1cbaf208a25999d6c9b08e505ea8b8a49564e08c63a819b0a4fa1160893a8047&amp;amp;scene=21#wechat_redirect">&lt;strong>2，CPU 进化论：复杂指令集的诞生&lt;/strong>&lt;/a>&lt;a href="http://mp.weixin.qq.com/s?__biz=Mzg4OTYzODM4Mw==&amp;amp;mid=2247485741&amp;amp;idx=1&amp;amp;sn=45afcce8e8e8ec198a9b09c32c1e6aa8&amp;amp;chksm=cfe995adf89e1cbb833ca61741028bee6ccfeb1e928efe60a3a8fcf1fa01da3df4ef49a063de&amp;amp;scene=21#wechat_redirect">**3，不懂精简指令集还敢说自己是程序员？**&lt;/a>&lt;/p></description></item><item><title>Blog: Linux Torvalds 采访</title><link>https://desistdaydream.github.io/blog/copy/mVo3S_F0RoxCToawrTCnlA/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/mVo3S_F0RoxCToawrTCnlA/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/mVo3S_F0RoxCToawrTCnlA">https://mp.weixin.qq.com/s/mVo3S_F0RoxCToawrTCnlA&lt;/a>&lt;/p>
&lt;p>作者丨 Jeremy Andrews&lt;/p>
&lt;p>译者丨屠灵&lt;/p>
&lt;p>策划丨蔡芳芳&lt;/p>
&lt;p>Linux 诞生于 1991 年，距今已经 30 年了。虽然它一开始只是 Linus 的一个个人项目，而非出于要开发一个新操作系统的伟大梦想，但如今的 Linux 早已无处不在。&lt;/p>
&lt;p>30 年前，当 Linus Torvalds 第一次发布 Linux 内核时，他还是赫尔辛基大学的一名 21 岁的学生。他宣布说：“我正在开发一个（免费的）操作系统（这只是个爱好，不会做得很大，也不会很专业……）”。30 年后，500 强超级计算机和 70% 以上的智能手机都在运行 Linux。很显然，Linux 不仅大，而且很专业。&lt;/p>
&lt;p>30 年来，Linus Torvalds 一直在领导着 Linux 内核的开发，启发了无数开发者和开源项目。2005 年，Linus 开发了 Git，用来管理内核开发过程。Git 现在已经成为最流行的版本控制系统，受到无数开源和私有项目的信任。&lt;/p>
&lt;p>正值 Linux 诞生 30 周年之际，Linus Torvalds 通过电子邮件回复了 Tag 1 咨询公司的创始合伙人 / 首席执行官 Jeremy Andrews 的访谈问题（《An Interview With Linus Torvalds: Linux and Git - Part 1》），回顾并总结了过去这些年他在领导大型开源项目过程中得到的真知灼见。本文着重介绍 Linux 内核开发和 Git。InfoQ 对访谈内容进行了翻译，以飨读者。&lt;/p>
&lt;p>Linux 内核开发&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：Linux 无处不在，它是整个开源世界的灵感源泉。当然，事情并不是从一开始就这样的。1991 年，你在 comp.os.minix Usenet 新闻组中发布了一个 Linux 内核。十年后，你写了一本书，叫作“Just for Fun: The Story of an Accidental Revolutionary”（中译名：《只是为了好玩：Linux 之父林纳斯自传》），对那段历史进行了深度回顾。今年 8 月，Linux 将迎来它的 30 周年纪念日！在这个过程中，你是在什么时候开始意识到 Linux 并不仅仅是一个“爱好”的？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds：&lt;/strong> 这听起来可能有点荒谬，实际上我很早就开始意识到了。在 1991 年末（以及 1992 年初），Linux 已经比我预想的要大得多。&lt;/p>
&lt;p>那时候可能只有几百个用户（确切地说不是“用户”，因为人们还要不断地对它进行修修补补），从没想过 Linux 后来能够发展壮大。在我看来，最大的转折点是当我意识到其他人正在使用它，并对它感兴趣，它开始有了自己的生命。人们开始发送补丁，这个系统能做的事情比我最初预想的要多得多。&lt;/p>
&lt;p>1992 年 4 月的某个时候，X11 被移植到 Linux 上（其实我也记不太清具体时间了，毕竟那是很久以前的事了），这是一个重大进步，Linux 系统突然间有了 GUI 和一系列全新的功能。&lt;/p>
&lt;p>我一开始并没有什么大计划。这只是一个个人项目，并不是出于要开发一个新操作系统的伟大梦想。我当时只是想了解我的新 PC 硬件的来龙去脉。&lt;/p>
&lt;p>所以，在发布第一个版本时，实际上更多的是想“看看自己都做了些什么”。当然，我希望其他人会觉得它有趣，但它并不是一个真正可用的操作系统。它更多的是一种概念验证，而且只是一个我在当时做了几个月的个人项目。&lt;/p>
&lt;p>从“个人项目”到其他人开始使用它、给我反馈（和 bug 报告）和发送补丁，对我来说是一个巨大的转变。&lt;/p>
&lt;p>举个最基本的例子：最初的版权许可是“你可以以源代码的形式发布它，但不能用它赚钱”。&lt;/p>
&lt;p>对于当时的我来说，商业版 Unix 太贵了（作为穷学生，我已经为了买新 PC 花光了所有钱），所以我希望这个操作系统的源代码是公开可用的（这样人们就可以提供补丁），我希望将它开放给像我这样负担不起昂贵电脑和操作系统的人。&lt;/p>
&lt;p>1991 年末（或是 1992 年初），我把许可改为 GPLv2，因为有人想把它以软盘的形式分发给本地 Unix 用户组，但又想收回软盘的成本，并补偿他们拷贝软盘所花费的时间。我觉得这很合理，因为“免费”与否并不是最重要的，最重要的是要“公开源码”。&lt;/p>
&lt;p>最终的结果是：人们不仅在 Unix 用户组中发布它，在几个月之内还出现了 SLS 和 Slackware 的软盘发行版。&lt;/p>
&lt;p>与最初的那些根本性的变化相比，后来的一切都是“增量式”的。当然，有些增量式的变化也是大跨步（IBM 的加入、Oracle 数据库的移植、Red Hat 的首次公开募股，Android 在手机上的应用，等等），但在我看来，它们仍然不如最初的“我不认识的人都在使用 Linux”那样具有革命性。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：你是否曾经后悔修改了许可协议？或者说，其他人或公司用你开发的系统赚了很多钱，你因此感到后悔吗？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds：&lt;/strong> 我从来没有后悔过。&lt;/p>
&lt;p>首先，我过得还不错。我不是特别富有，但我是一个薪水很高的软件工程师，可以按照自己的节奏做我喜欢做的事情。&lt;/p>
&lt;p>关键是我百分之百认为这个许可是 Linux（以及 Git）取得成功的重要原因。我认为，当所有人都认为他们有平等的权利，没有人在这方面有特权的时候，他们才会变得更快乐。&lt;/p>
&lt;p>有很多项目采用了“双重许可”，一方面，原作者保留了商业许可（“只要你支付了许可费用，就可以使用它”），另一方面，项目也可以在 GPL 许可下开源。&lt;/p>
&lt;p>我认为要在这种情况下建立好的社区是非常困难的，因为开源那一方知道自己是“二等公民”。另外，为了让享有特权的那一方一直享有特殊的权利，需要做很多许可文书工作，这给项目带来了额外的阻力。&lt;/p>
&lt;p>另一方面，我见过很多基于 BSD（或 MIT 等类似的许可）许可的开源项目，当它们变得足够强大，大到具备商业价值时，它们就开始分裂，相关的公司不可避免地会将自己的那部分变成专有的。&lt;/p>
&lt;p>我认为 GPLv2 能够在“每个人都处于相同的规则之下”和“要求人们回馈社区”之间取得完美的平衡。每个人都知道，所有参与者都受到相同的规则的约束，所以这是非常公平的。&lt;/p>
&lt;p>当然，你的投入总会得到回报。如果你只是想轻度参与项目，或者只是想作为一名用户，那也是可以的。如果你真的只是这样，就也无法控制这个项目。如果你真的只需要一个基本的操作系统，而 Linux 已经具备你想要的所有功能，那也完全没有问题。但如果你有特殊的需求，想要为这个项目做一点事情，那么唯一的方法就是参与其中。&lt;/p>
&lt;p>这让每个人都秉持诚实的态度，包括我在内。任何人都可以 fork 这个项目，用他们自己的方式，然后说“再见了，Linus，我要维护自己的 Linux 版本”。我之所以“特别”，仅仅是因为人们相信我能把工作做好。&lt;/p>
&lt;p>“任何人都可以维护自己的 Linux 版本”，这让一些人对 GPLv2 产生了怀疑，但我认为这是一种优势，而不是劣势。我认为，这实际上是避免 Linux 出现分裂的原因：每个人都可以创建自己的项目分支。事实上，这也是“Git”的核心设计原则之一——代码库的每一个克隆都是一个分支，人们（和公司）再 fork 出自己的版本，完成开发工作。&lt;/p>
&lt;p>所以，分支不是问题，只要你能把好的部分合并回来。这就是 GPLv2 发挥作用的地方。能够拉取分支，并按照自己的方式修改代码，拥有这些权利很重要，但另一方面也同样重要——当一个分支被证明取得了成功，有权利把它合并回去。&lt;/p>
&lt;p>另一个问题是，除了要有支持这种工作流的工具，也要有可以支持它的心态。合并分支的一大障碍不仅是许可问题，还有“嫌隙”问题。如果分支是源于对立，那么要合并两个分支就非常困难——不是因为许可或技术方面的原因，而是因为分支之间太过对立。我认为 Linux 避免了这种情况的发生，主要是因为我们一直认为分支是一件很自然的事情。而且，当一些开发工作被证明取得了成功，尝试将其合并回来也是很自然的。&lt;/p>
&lt;p>虽然这个答案有点偏离正题，但我认为它很重要——我不后悔修改了许可，因为我真的认为 GPLv2 是 Linux 取得成功的一个重要原因。&lt;/p>
&lt;p>金钱不是一种很好的激励方式，它无法让人们团结在一起。我认为，参与一个共同的项目，并感觉到自己可以成为这个项目的合作伙伴，这样才能激励人们。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：现在，人们基于 GPLv2 发布源代码通常是因为 Linux。你当时是怎么找到这个许可的？你在调研其他许可方面又投入了多少时间和精力呢？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds：&lt;/strong> 那个时候，有关 BSD 和 GPL 的争论非常激烈。我在阅读各种新闻组（比如 comp.arch、comp.os.minix 等）时看到了一些有关许可的讨论。&lt;/p>
&lt;p>其中两个最主要的原因可能是 gcc 和 Lars Wirzenius。gcc 对 Linux 的发展起到了很大作用，因为我肯定需要一个 C 语言编译器。Lars Wirzenius 是我在念大学时另一个说瑞典语（瑞典语在芬兰是小语种）的计算机系学生。&lt;/p>
&lt;p>Lasu 比我更喜欢讨论与许可相关的事情。&lt;/p>
&lt;p>在我看来，选择 GPLv2 并不算是什么重大的政治问题，主要是因为我最初在选择许可时太过仓促，后来需要做出修改。况且，我很感恩有 gcc，并且 GPLv2 更符合我对“你必须把源代码合并回来”这种想法的期望。&lt;/p>
&lt;p>因此，与其另起炉灶新建一个许可，不如选择一个人们已经知道并且有一些律师参与其中的许可。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：通常情况下，你的一天是怎么过的？其中有多少时间花在写代码上，多少花在评审代码上，多少花在电子邮件上？你如何平衡个人生活和 Linux 内核开发工作？&lt;/strong>&lt;/p>
&lt;p>Linus Torvalds：我现在写的代码很少，而且已经很久没写了。再要写代码，通常是因为人们对某些特定的问题存在争议。我修改代码，并将其作为补丁发布出去，作为对解决方案的解释说明。&lt;/p>
&lt;p>换句话说，我写的大部分代码更多的是作为解决方案的示例，而补丁是一种非常具体的例子。人们很容易陷入理论讨论的陷阱，而我发现描述解决方案最好的方式是写代码片段，不一定要完整的程序，只要让解决方案具体化一些即可。&lt;/p>
&lt;p>我的工作时间都花在电子邮件上了。主要是沟通，而不是写代码。事实上，我认为这种与记者和技术博主之间的交流就是我工作的一部分——它可能比技术讨论优先级低一些，但我也花了相当多的时间在这类事情上。&lt;/p>
&lt;p>当然，我也会花一些时间在代码评审上。但老实说，当我收到一个 PR 时，有问题的代码通常已经被其他人评审过了。所以，虽然我仍然会看一下补丁，但实际上会更多地去关注注解，以及补丁的演化过程。但对于那些与我共事很久的人，我不会这么做：他们是自己子系统的维护者，我不需要对他们的工作指手画脚。&lt;/p>
&lt;p>所以，很多时候，我的主要工作就是“待在那里”，执行管理和发布任务。换句话说，我的工作通常更多地是关于维护过程，而不是底层代码。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：你的工作环境是怎样的？比如，你是喜欢黑暗、不会受人打扰的房间，还是喜欢能看到风景的房间？你喜欢在安静的环境下工作，还是喜欢一边听音乐一边工作？你通常使用哪种硬件？你是在终端上使用 vi 来评审代码，还是使用某种奇特的 IDE？你是否有偏爱的 Linux 发行版作为开发环境？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds：&lt;/strong> 我的房间并不“暗”，但我确实把桌子旁边窗户上的百叶窗关上了，因为我不想要强烈的阳光。所以，我的房间没有什么风景视野，只有一张（凌乱的）桌子，配了两个 4k 显示器，桌子下面有一台强劲的电脑主机。还有几台笔记本电脑供我测试和在路上用。&lt;/p>
&lt;p>我喜欢安静地工作。我很讨厌机械硬盘的滴答声，所以我把它们扔进了垃圾桶，现在只使用 SSD。这样已经 10 多年了。嘈杂的 CPU 风扇声也是不可接受的。&lt;/p>
&lt;p>代码评审都是在传统的终端上完成的，不过我没有使用 vi。我使用的是“micro-emacs”这个令人讨厌的东西。它与 GNU emacs 完全没有关系，只是有些键绑定与它相似。我在赫尔辛基大学时就习惯用它了，到现在还没改掉这个习惯。几年前，我给它增加了（非常有限的）utf-8 支持，但它确实很老旧了，所有的迹象都表明它是在 80 年代开发的，我使用的版本是一个自 90 年代中期以来就没有更新过的分支。&lt;/p>
&lt;p>赫尔辛基大学选择了这个工具，因为它可以在 DOS、VAX/VMS 和 Unix 上运行，这也是为什么我也会用它。到现在，我的手指已经对它形成肌肉记忆了。我真的需要换个有人维护并支持 utf-8 的工具，只是我增强的那部分功能用起来还好，所以一直没有强迫我的手指去接受新的工具。&lt;/p>
&lt;p>我的工作桌面相当简单：几个文本终端，一个打开了电子邮箱的浏览器（还打开了其他几个标签，主要是新闻和科技网站）。我喜欢大的桌面空间，因为我习惯使用大终端窗口（100x40 是我的默认初始大小），并且并排打开好几个。我使用了两个 4k 显示器。&lt;/p>
&lt;p>我在所有的机器上都安装了 Fedora 发行版，并不是因为我偏爱它，而是因为我习惯了。我并不太关心使用哪个发行版——对于我来说，选择发行版只是在机器上安装 Linux 和开发工具的一种方式。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：Linux 内核邮件组（https://lore.kernel.org/lkml/）是人们公开交流内核开发的地方，流量非常高。你是怎么处理这么多电子邮件的？你尝试过邮件组之外的其他协作和沟通解决方案吗？或者说，这种简单的邮件组对你的工作来说足够好吗？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：我没有直接阅读内核邮件组里的邮件，而且好几年都没有。邮件太多了。&lt;/p>
&lt;p>内核邮件组里的邮件会被抄送到所有的讨论当中。当新人加入讨论时，他们可以通过查看内核邮件组来了解相关的历史和背景。&lt;/p>
&lt;p>过去我会订阅邮件组，让所有没有抄送给我的电子邮件自动归档，默认不看它们。当一些问题需要我介入时，我可以找到所有相关的讨论，因为它们都在我的电子邮件里，只是在需要时才会出现在我的收件箱里。&lt;/p>
&lt;p>现在，我使用的是 lore.kernel.org 提供的功能，因为它很好用，而且我们还基于它开发了一些工具。这样就不需要让邮件自动归档了，我们换了一种讨论方式，但基本的工作流程是一样的。&lt;/p>
&lt;p>但很显然，我仍然会收到很多邮件——但从很多方面来看，这些年来情况变得越来越好，而不是越来越糟。其中很大一部分原因是 Git 和内核发布流程的改进：我们过去在代码流程和工具方面存在很多问题。在本世纪初是最为糟糕的，当时我们仍然在处理巨大的补丁炸弹，我们的开发流程存在严重的可伸缩性问题。&lt;/p>
&lt;p>邮件组模式确实运作得很好，但并不是说人们就不使用除电子邮件之外的其他沟通方式了：有些人喜欢各种实时聊天工具（比如传统的 IRC）。虽然我不是很喜欢这样，但很显然有些人喜欢用它们来进行头脑风暴。但这种“邮件组存档”模式运作得非常好，并且能够无缝地与“开发者之间以邮件的形式发送补丁”和“以邮件的形式发送问题报告”相结合。&lt;/p>
&lt;p>所以电子邮件仍然是主要的沟通渠道，并且因为邮件中可以包含补丁，我们可以更容易地讨论技术问题。而且邮件可以跨越时区，当参与者分布在不同地区时，这一点非常重要。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：我密切关注内核开发大约有 10 年了，并在 KernelTrap 上写与内核有关的博文，大概是在 3.0 内核发布时停止更新博客。3.0 内核的发布与 2.6.x 内核的发布相隔了 8 年。请总结一下自 3.0 版本以来内核开发中发生的一些有趣的事情。&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：那是很久以前的事了，我不知道该从哪里开始总结。从 3.0 版本到现在已经 10 年了，在这 10 年中发生了很多技术上的变化。ARM 已经发展成熟，ARM64 已经成为我们的主要架构之一，并出现了大量新的驱动程序和核心功能。&lt;/p>
&lt;p>如果说过去 10 年有什么有趣的事情，那一定是我们努力保持开发模式的稳定，以及那些没有发生改变的东西。&lt;/p>
&lt;p>在过去的几十年里，我们经历了多种不同的版本号方案和不同的开发模式，3.0 版本最终确定了后来一直使用的模式。它让“基于时间发布，版本号只是数字，与特性无关”这一说法落地了。&lt;/p>
&lt;p>在 2.6.x 版本中，我们就有了基于时间的发布模式，所以它并不是什么新东西，但 3.0 版本确实是让这种模式板上钉钉的至关重要的一步。&lt;/p>
&lt;p>我们以前使用随机编号方案（主要是在 1.0 版本之前），然后用“奇数表示开发版内核，偶数表示稳定的生产就绪版内核”，然后在 2.6.x 版本中，我们开始进入基于时间的发布模式。但人们仍然对“什么时候需要增加主版本号”存在疑问。3.0 版本正式发布后，宣告了主版本号没有任何意义，我们尽量简化数字，不要让它们变得太大。&lt;/p>
&lt;p>因此，在过去的 10 年里，我们做了巨大的改变（有了 Git，就可以很容易地得到一些数字统计数据：超过 1.7 万人提交了大约 75 万次代码），但开发模式仍然相当稳定。&lt;/p>
&lt;p>但并非一直都是这样的，内核开发的前 20 年经历了相当痛苦的开发模式变更，只是在过去 10 年中，发布可预测性才得到大幅提升。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：目前，最新的版本是 5.12-rc5。现在的发布流程标准是怎样的？例如，-rc1 和 -rc2 有什么不同？你会在什么情况下决定正式发布其中一个给定的版本？如果在正式发布之后出现了大量的回归会怎样？这种情况发生的频率是怎样的？这些年来，这个过程是如何演变的？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：我之前提到过，这个过程本身是很标准的，并且在过去十年里一直如此。在此之前，它经历了几次演变，但实际上从 3.0 开始它就像时钟一样走得很稳定。&lt;/p>
&lt;p>到现在为止，我们的发布节奏是这样的：先是两周的合并时间窗口，然后是大约 6 到 8 周的候选版本，然后是最终版本。这样子差不多 15 年了。&lt;/p>
&lt;p>规则一直都是一样的，尽管它们并不总是被完全严格执行：合并时间窗口是针对那些被认为已经“经过测试和准备就绪”的新代码，然后在接下来的大约两个月里进行修复，以确保所有的问题都得到解决。有时候，那些所谓的“就绪”代码会在发布之前会被禁用或完全推翻。&lt;/p>
&lt;p>这个过程会重复，所以我们大约每 10 周发布一次。&lt;/p>
&lt;p>达到可以发布的标准是我对候选版本有足够的信心，而这是以各种问题报告为基础的。如果某些方面在 rc 后期仍然会出问题，我就极力推翻这些内容，并建议将其放在后续的版本中。但总体而言，很少会出现这种情况。&lt;/p>
&lt;p>这样就完全没有问题了吗？不是的。一旦内核发布了，就会有新用户，他们会发现一些在 rc 版本中没有被发现的问题。这几乎是不可避免的。这也是为什么我们需要“稳定内核”树。在发布之后，我们可以继续修复代码。一些稳定内核比其他版本内核维护的时间更长，被称为 LTS（“Long Term Support”）版本。&lt;/p>
&lt;p>所有这些在过去十年里都没有什么变化，尽管后来有了更多的自动化流程。一般来说，内核测试自动化是很困难的——因为很多内核是驱动程序，十分依赖硬件的可用性。不过，我们有几个测试场同时进行引导和性能测试，以及各种随机负载测试。这些在这几年有了很大的改善。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：去年 11 月，有人说你对苹果公司在部分新款电脑中使用的 ARM64 芯片十分感兴趣。Linux 会支持它们吗？我看到一些代码被合并到 for-next。即将到来的 5.13 内核有可能在苹果 MacBook 上启动吗？你有可能是它的早期采用者吗？ARM64 有什么重大的意义？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：我偶尔会跟进一下，但现在说这些还为时过早。正如你所说的，早期支持可能会被合并到 5.13 中，但这只是一个开始，并不能说明 Linux 和苹果电脑将来会怎样。&lt;/p>
&lt;p>主要问题不是 arm64 架构，而是与之相关的所有硬件驱动程序（特别是 SSD 和 GPU）。到目前为止，一些底层的东西得到了支持，但除了可以启用硬件之外，没有任何有用的结果。要想达到可以被人们使用的程度，还需要一些时间。&lt;/p>
&lt;p>不仅仅是苹果的硬件得到了改进——arm64 架构总体上也已经成长了很多，内核在服务器领域也更具竞争力了。不久前，arm64 在服务器领域的竞争力还很弱，但亚马逊的 Graviton2 和安培的 Altra 处理器——都是基于改进后的 ARM Neoverse IP——比几年前的产品要好很多。&lt;/p>
&lt;p>我已经等了十多年都没能等到一个可用的 ARM 机器，可能还要继续等下去，但情况明显比以前好了一些。&lt;/p>
&lt;p>事实上，我很早之前就想要一台 ARM 机器。当我还是个少年，我真正想要的是一台 Acorn Archimedes，但可用性和价格让我最终选择了 Sinclair QL（M68008 处理器），然后几年后换成了 i386。&lt;/p>
&lt;p>所以，这个想法已经酝酿了几十年。但到现在它们还没有被广泛使用，而且对于我来说，它们在价格和性能方面都不具竞争力。希望在不久的将来，这个想法能够变成现实。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：内核中有什么东西需要进行完全的重写才能达到最优的吗？或者说，内核已经有 30 年的历史了，知识、编程语言和硬件在这 30 年里发生了很大的变化：如果现在让你从头开始重写，你会做出哪些改变？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：如果有必要的话我们会这么做的。我们真的很擅长重写，那些本来会造成灾难的东西很久以前就被我们重写了。&lt;/p>
&lt;p>我们有很多“兼容”层，不过它们一般不会造成太大问题。如果从头开始重写，这些兼容层是否要去掉，我们还不清楚——它们存在的目的是为了与旧二进制文件向后兼容（通常是与旧架构向后兼容，例如在 x86-64 上运行 32 位的 x86 应用程序）。因为我认为向后兼容是非常重要的，所以即使重写，我也希望保留这些兼容层。&lt;/p>
&lt;p>所以很明显，有很多东西并不是最优的，毕竟任何东西都有改进的空间。但就你提的这个问题，我不得不说，我不鄙视任何东西。有一些遗留驱动程序，可能没有人关心，也没有人去清理，会做一些丑陋的事情，但这主要是因为“没有人关心”。这些在过去不是问题，而一旦成为问题，我们就会积极把这些没人关心的东西移除掉。多年来，我们已经移除了很多驱动程序，当维护不再有任何意义时，我们会放弃整个架构支持。&lt;/p>
&lt;p>“重写”的主要原因是：整个架构不再有意义，但仍然存在一些应用场景。最有可能的情况是，一些小型嵌入式系统并不需要 Linux 提供的所有东西，它们的硬件很小，需要的是更简单、更少的系统功能。&lt;/p>
&lt;p>Linux 已经有了长足的发展。现在，即使是小硬件（比如手机等）也比当初开发 Linux 所使用的机器强大得多。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：如果用 Rust 来重写一部分系统会怎样？在这方面还有改进的余地吗？在内核开发方面，你觉得是否有可能用另一种语言（比如 Rust）来取代 C 语言？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds：&lt;/strong> 我不认为我们会用 Rust 取代 C 语言来开发内核，但可能会用来开发一些驱动程序，也许是整个驱动子系统，也许是文件系统。所以不是“取代 C 语言”，而是“在一些有意义的地方扩展我们的 C 代码”。&lt;/p>
&lt;p>当然，驱动程序几乎占了内核的一半代码，有非常大的重写空间，但我不认为所有人都会很期待使用 Rust 全盘重写现有的驱动程序。可能“有些人会用 Rust 开发新驱动程序，或者适当地重写一部分旧驱动程序”。&lt;/p>
&lt;p>现在更多的是“人们在尝试和体验”Rust，仅此而已。Rust 优势的背后肯定存在复杂性，所以我会采取观望的态度，看看这些优势是否真的奏效。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：内核中是否有你个人感到最自豪的部分？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：我最想说的是 VFS 层（虚拟文件系统，特别是路径名查找）和 VM。前者是因为 Linux 在做一些基础任务（在操作系统中查找文件名确实是一个核心的操作）时比其他系统都要好得多，后者主要是因为我们支持 20 多种架构，但仍然在使用一个基本统一的 VM 层，我认为这一点很了不起。&lt;/p>
&lt;p>但与此同时，这很大程度上取决于“你最关注内核的哪一部分”。内核很大，不同的开发者（和不同的用户）会关注不同的方面。有些人认为调度是内核中最令人感到兴奋的部分，有些人则关注设备驱动程序的细节（我们有很多这样的驱动程序）。我个人在 VM 和 VFS 这两个方面参与得更多，所以自然会提到它们。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：我看了这个关于路径名查找的描述（https://www.kernel.org/doc/html/latest/filesystems/path-lookup.html），它比我预想的要复杂。是什么让 Linux 在这方面比其他操作系统做得更好？你说的“更好”是什么意思？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：路径名查找是一个非常常见和基础的任务，以至于大多数非内核开发者不认为它会是一个问题：他们只知道打开文件，并认为这是理所当然的。&lt;/p>
&lt;p>但要做好其实是相当复杂的。确切地说，因为几乎所有地方都在用路径名查找，所以对性能要求很高，而且大家都希望它在 SMP 环境中具有良好的伸缩性，而在锁定方面又很复杂。你不想发生 IO，那么缓存就非常重要。路径名查找是如此的重要，以至于你不能把它留给底层的文件系统，因为我们有 20 多种不同的文件系统，让它们各自拥有自己的缓存和锁定机制将是一场彻头彻尾的灾难。&lt;/p>
&lt;p>所以，VFS 层的一个主要任务是处理所有路径名组件的锁定和缓存问题，以及所有的序列化和挂载点遍历问题，这些都是通过无锁算法（RCU）来完成的，但也会有一些非常智能的锁（Linux 内核的“lockref”锁是一种非常特殊的“带有引用计数的自旋锁”，表面上看是为 dcache 缓存而设计的，但本质上是一个专门的锁感知引用计数，可以在某些常见情况下消除锁）。&lt;/p>
&lt;p>最终结果是：底层文件系统仍然需要对未缓存的内容进行查找，但它们不需要关心缓存和一致性规则以及与路径名查找相关的原子性规则。VFS 会为它们处理好所有这些问题。&lt;/p>
&lt;p>而且它的性能比任何其他操作系统都要好，基本上可以在拥有数千个 CPU 的机器上完美运行。&lt;/p>
&lt;p>所以不仅仅是“更好”，而是“大写”的更好。没有什么能与之相提并论的了。Linux dcache 是独一无二的。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：过去的一年对全世界来说是艰难的一年。新冠疫情对内核开发进程带来了哪些影响？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：实际上，得益于我们一直以来的工作方式，它的影响非常小。电子邮件真的是一个很好的工具，我们并不依赖面对面的会议。&lt;/p>
&lt;p>是的，它确实影响了去年的年度内核峰会（今年的峰会仍悬而未决），大多数会议被取消或转为线上进行。以前在办公室工作的人大都开始在家里工作（但很多核心内核维护者在之前已经这么做了）。所以，周围的很多东西都发生了改变，但内核开发还是像以前一样。&lt;/p>
&lt;p>很显然，新冠疫情在其他方面影响了我们所有人的生活，但总的来说，作为几乎完全通过电子邮件进行交流的内核开发人员，我们可能是受影响最小的。&lt;/p>
&lt;p>版本控制系统 Git&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：Linux 只是你对开源做出的众多贡献中的一个。在 2005 年，你还创建了 Git，一个非常流行的分布式源代码控制系统。你快速地将 Linux 内核源代码树从专有的 Bitkeeper 迁移到开源的 Git 系统中，并在同年将维护工作移交给了 Junio Hamano。这里有很多有趣的故事，是什么原因促使你这么快就将项目的领导权移交了出来，你是如何找到并选择了 Junio 的？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：答案可以分为两个部分。&lt;/p>
&lt;p>首先，我并不想创建一个新的源代码控制系统。开发 Linux 是因为硬件和软件之间的底层接口很吸引我——基本上是出于个人的热爱和兴趣。相反，开发 Git 是因为确实有这个需要：不是因为我觉得源代码控制很有趣，而是因为我十分鄙视市面上的大多数源代码控制系统。而我觉得最合适的、在 Linux 开发当中很好用的 BitKeeper 已经无法维持下去了。&lt;/p>
&lt;p>我开发 Linux 已经超过 30 年了（距离第一个版本的周年纪念还有几个月，但在 30 年前我就开始研究 Linux 的“前身”了），并且一直在维护它。但 Git 呢？我从来没有想过我真的想要长期维护它。我喜欢用它，而且在某种程度上，我认为它是最好的 SCM，但它并不是我的兴趣所在。&lt;/p>
&lt;p>所以我总是希望别人来为我维护 SCM——事实上，如果当初我不用自己开发这个 SCM，我会很开心。&lt;/p>
&lt;p>以上就是故事的背景。&lt;/p>
&lt;p>至于 Junio，他实际上是最早加入 Git 开发队伍的人员之一。他在我将 Git 的第一个非常粗糙的版本公开后的几天内提交了第一次变更代码，所以 Junio 在 Git 一开始就参与其中了。&lt;/p>
&lt;p>但我之所以把项目交给 Junio，并不是因为他是第一批参与项目的人。在维护了 Git 几个月之后，让我决定将项目交给 Junio 维护者的真正原因是“好品味”——一个很难描述的概念。我真的想不到还有什么更好的描述：编程主要是为了解决技术问题，但如何解决这些问题以及如何思考也很重要。随着时间的推移，你开始意识到：有些人就有这种“好品味”，他总能选择正确的解决方案。&lt;/p>
&lt;p>我不想将编程说成是一门艺术，因为它实际上主要是关于“好的工程”。我很喜欢托马斯·爱迪生的那句“天才是百分之一的灵感加上百分之九十九的汗水”：编程涉及的几乎都是细枝末节的东西和日常繁重的工作。但是，那百分之一的“灵感”，也就是“好品味”，不仅要解决问题，而且要干净、漂亮地解决。&lt;/p>
&lt;p>Junio 就有那种“好品味”。&lt;/p>
&lt;p>每次提到 Git，我都想试着讲清楚：我在一开始提出了 Git 的核心思想，并经常因为这部分工作而获得太多荣誉。Git 的这 15 年，我也只是在第一年真正参与了项目。Junio 是一个优秀的维护者，是他让 Git 变成现在的样子。&lt;/p>
&lt;p>顺便说一下，关于“好品味”，以及找到拥有好品味的人，并信任他们——不仅仅 Git 是这样，Linux 也是这样。与 Git 不一样的是，Linux 这个项目我仍然在积极维护，但与 Git 一样的是，Linux 也是一个有很多人共同参与的项目。我认为，Linux 的一大成功是它拥有数百名维护者，他们都具备了“好品味”，并维护着内核的不同部分。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：你有没有过这样的经历：把控制权交给维护者，然后发现这是一个错误的决定？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：我们的维护体系从来就不是非黑即白的，所以不会出现这种情况。事实上，我们甚至没有将维护权正式记录下来：我们确实有一个 MAINTAINERS 文件，但那只是为了让你在遇到问题时能够找到对的人，并不是某种排他所有权的标志。&lt;/p>
&lt;p>所以，“谁负责什么东西”更像是一种流动的指南，以及“这个人很活跃，工作做得很好”，而不是“我们把所有权给了那个人，然后他搞砸了”。&lt;/p>
&lt;p>从某种意义上说，我们的维护体系也是流动的。假设你是某个子系统的维护者，如果你需要另一个子系统的东西，是可以跨界的。通常人们在这样做之前都会进行广泛的沟通，而且这种事情确实发生了。这并不是“你只能动这个文件”之类的硬性规定。&lt;/p>
&lt;p>实际上，这与前面讨论的有关许可的事情有些联系。“Git”的另一个设计原则是“每个人都有自己的代码树，但没有哪一个代码树是特殊的”。&lt;/p>
&lt;p>因为很多其他项目都使用了工具——比如 CVS 或 SVN——这些工具会让一些人变得“特殊”，赋予了他们某种“所有权”。在 BSD 世界里，他们称之为“commit bit”：给一个维护者“commit bit”意味着他可以将代码提交到中央代码库。&lt;/p>
&lt;p>我一直很讨厌这种模式，因为它会不可避免地导致政治“小团体”的出现。在这种模式下，总有一些人是特殊、隐性受信任的。问题的关键甚至不在于“隐性受信任”，而在于硬币的另一面——其他人不被信任，他们被定义成局外人，必须受制于监护者。&lt;/p>
&lt;p>同样，在 Git 开发中也不存在这种情况。每个人都是平等的，任何人都可以克隆代码，做自己的开发，做好了，就可以合并回来。&lt;/p>
&lt;p>所以，没有必要给人们特权，也不需要“commit bit”。这样就可以避免出现政治“小团体”，也不需要“隐性信任”。如果他们做得不好——或者更常见的是，最终消失了，并转向了另一个兴趣——他们的代码就不会被合并回来，也不会阻碍其他有新想法的人。&lt;/p>
&lt;p>&lt;strong>Jeremy Andrews：Git 有没有哪些新特性让你印象深刻，并成为你工作流的一部分？还有哪些特性是你想要增加的？&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Linus Torvalds&lt;/strong>：我对 Git 的需求总是最早得到满足的，所以，对于我来说，Git 没有“新”特性。&lt;/p>
&lt;p>这些年来，Git 确实有很大的改进，有一些在我的工作流中已经体现出来了。例如，Git 的速度一直都很快——毕竟这是我的设计目标之一——但它的大部分特性最初是围绕 shell 脚本而构建的。多年来，大多数 shell 脚本都已经消失了，这意味着我可以比原来更快地应用 Andrew Morton 的补丁。这一点令人感到欣慰，因为这实际上是我早期用于性能测试的基准之一。&lt;/p>
&lt;p>所以，Git 对我来说一直都很好，而且变得越来越好。&lt;/p>
&lt;p>Git 最大的改进在于“普通用户”的使用体验变得更好了。一部分原因是人们在学习 Git 工作流的过程中逐渐习惯了它，但更多的是因为 Git 本身变得更易于使用。&lt;/p>
&lt;p>本周好文推荐&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&amp;amp;mid=2651078021&amp;amp;idx=1&amp;amp;sn=2270db9fc57ad9e5be30261b1078c62a&amp;amp;chksm=bdb9c5d68ace4cc053648b7821ed0ea2a4ae1fd55291b4e41b12650d0db058171f0a3b40983d&amp;amp;scene=21#wechat_redirect">雷军：年轻人入职半年内不要提意见；网易回应HR不当招聘言论：已解除劳动合同；蚂蚁自研数据库OceanBase将开源 | Q资讯&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&amp;amp;mid=2651077990&amp;amp;idx=1&amp;amp;sn=04eb3055babd8ba2feefbf0fad02214a&amp;amp;chksm=bdb9c5358ace4c233e96fab1b19645698c7bc943b3615c9ed8af7a9851015bfb966c916a3b67&amp;amp;scene=21#wechat_redirect">Data Mesh，数据架构的下一个变革！&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&amp;amp;mid=2651077789&amp;amp;idx=1&amp;amp;sn=2daf0b27fe003778788303b3ac0e3628&amp;amp;chksm=bdb9c4ce8ace4dd8209a162be91e374043019db5e4c38859810d0ffedcaa278f1fcf29e77705&amp;amp;scene=21#wechat_redirect">近30年的开源项目被“夺权”，员工集体离职后成立新项目抗衡&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&amp;amp;mid=2651077685&amp;amp;idx=1&amp;amp;sn=7b53a1f32d84386a1dc9d2a289ed63df&amp;amp;chksm=bdb9c4668ace4d706d07ac5c25f43ed5b07ec7963786936b3c41e24590df30806ead4a06ab7c&amp;amp;scene=21#wechat_redirect">终于！Fuchsia OS正式公开可用，谷歌迈出了五年来最关键的一步&lt;/a>&lt;/p></description></item><item><title>Blog: 程序员的酒后真言</title><link>https://desistdaydream.github.io/blog/copy/s_QacAHM9ELc9_jkrxL2cw/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/s_QacAHM9ELc9_jkrxL2cw/</guid><description>
&lt;p>原文链接：&lt;a href="https://mp.weixin.qq.com/s/s_QacAHM9ELc9_jkrxL2cw">https://mp.weixin.qq.com/s/s_QacAHM9ELc9_jkrxL2cw&lt;/a>&lt;/p>
&lt;p>美国最大的论坛 Reddit，最近有一个热帖[1]。
一个程序员说自己喝醉了，软件工程师已经当了 10 年，心里有好多话想说，“我可能会后悔今天说了这些话。”&lt;/p>
&lt;p>他洋洋洒洒写了一大堆，获得 9700 多个赞。内容很有意思，值得一读，下面是节选。
&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/po3xhu/1627796096008-fc438234-b89d-4142-aa9a-75b0994b2a5a.png" alt="image.png">&lt;/p>
&lt;p>（1）职业发展的最好方法是换公司。&lt;/p>
&lt;p>（2）技术栈不重要。技术领域有大约 10-20 条核心原则，重要的是这些原则，技术栈只是落实它们的方法。你如果不熟悉某个技术栈，不需要过度担心。&lt;/p>
&lt;p>（3）工作和人际关系是两回事。有一些公司，我交到了好朋友，但是工作得并不开心；另一些公司，我没有与任何同事建立友谊，但是工作得很开心。&lt;/p>
&lt;p>（4）我总是对经理实话实说。怕什么？他开除我？我会在两周内找到一份新工作。&lt;/p>
&lt;p>（5）如果一家公司的工程师超过 100 人，它的期权可能在未来十年内变得很有价值。对于工程师人数很少的公司，期权一般都是毫无价值。&lt;/p>
&lt;p>（6）好的代码是初级工程师可以理解的代码。伟大的代码可以被第一年的 CS 专业的新生理解。&lt;/p>
&lt;p>（7）作为一名工程师，最被低估的技能是记录。说真的，如果有人可以教我怎么写文档，我会付钱，也许是 1000 美元。&lt;/p>
&lt;p>（8）网上的口水战，几乎都无关紧要，别去参与。&lt;/p>
&lt;p>（9）如果我发现自己是公司里面最厉害的工程师，那就该离开了。&lt;/p>
&lt;p>（10）我们应该雇佣更多的实习生，他们很棒。那些精力充沛的小家伙用他们的想法乱搞。如果他们公开质疑或批评某事，那就更好了。我喜欢实习生。&lt;/p>
&lt;p>（11）技术栈很重要。如果你使用 Python 或 C++ 语言，就会忍不住想做一些非常不同的事情。因为某些工具确实擅长某些工作。&lt;/p>
&lt;p>（12）如果你不确定自己想做什么东西，请使用 Java。这是一种糟糕的编程语言，但几乎无所不能。&lt;/p>
&lt;p>（13）对于初学者来说，最赚钱的编程语言是 SQL，干翻所有其他语言。你只了解 SQL 而不会做其他事情，照样赚钱。人力资源专家的年薪？也许 5 万美元。懂 SQL 的人力资源专家？9 万美元。&lt;/p>
&lt;p>（14）测试很重要，但 TDD （测试驱动的开发）几乎变成了一个邪教。&lt;/p>
&lt;p>（15） 政府单位很轻松，但并不像人们说的那样好。对于职业生涯早期到中期的工程师，12 万美元的年薪 + 各种福利 + 养老金听起来不错，但是你将被禁锢在深奥的专用工具里面，离开政府单位以后，这些知识就没用了。我非常尊重政府工作人员，但说真的，这些地方的工程师，年龄中位数在 50 岁以上是有原因的。&lt;/p>
&lt;p>（16）再倒一杯酒。&lt;/p>
&lt;p>（17）大多数头衔都无关紧要，随便什么公司都可以有首席工程师。&lt;/p>
&lt;p>（18）手腕和背部的健康问题可不是开玩笑的，好的设备值得花钱。&lt;/p>
&lt;p>（19）当一个软件工程师，最好的事情是什么？你可以结识很多想法相同的人，大家互相交流，不一定有相同的兴趣，但是对方会用跟你相同的方式思考问题，这很酷。&lt;/p>
&lt;p>（20）有些技术太流行，我不得不用它。我心里就会很讨厌这种技术，但会把它推荐给客户，比如我恨 Jenkins，但把它推荐给新客户，我不觉得做错了。&lt;/p>
&lt;p>（21）成为一名优秀的工程师意味着了解最佳实践，成为高级工程师意味着知道何时打破最佳实践。&lt;/p>
&lt;p>（22）发生事故时，如果周围的人试图将责任归咎于外部错误或底层服务中断，那么是时候离开这家公司，继续前进了。&lt;/p>
&lt;p>（23）我遇到的最好的领导，同意我的一部分观点，同时耐心跟我解释，为什么不同意我的另一部分观点。我正在努力成为像他们一样的人。&lt;/p>
&lt;p>（24）算法和数据结构确实重要，但不应该无限夸大，尤其是面试的时候。我没见过药剂师面试时，还要测试有机化学的细节。这个行业的面试过程有时候很糟糕。&lt;/p>
&lt;p>（25）做自己喜欢的事情并不重要，不要让我做讨厌的事情更重要。&lt;/p>
&lt;p>（26）越接近产品，就越接近推动收入增长。无论工作的技术性如何，只要它接近产品，我都感到越有价值。&lt;/p>
&lt;p>（27）即使我平时用 Windows 工作，Linux 也很重要。为什么？因为服务器是 Linux 系统，你最终在 Linux 系统上工作。&lt;/p>
&lt;p>（28）人死了以后，你想让代码成为你的遗产吗？如果是那样，就花很多时间在代码上面吧，因为那是你的遗产。但是，如果你像我一样，更看重与家人、朋友和生活中其他人相处的时光，而不是写的代码，那就别对它太在意。&lt;/p>
&lt;p>（29）我挣的钱还不错，对此心存感激，但还是需要省钱。&lt;/p>
&lt;p>（30）糟糕，我没酒了。&lt;/p>
&lt;p>（完）&lt;/p>
&lt;h3 id="references">References&lt;a class="td-heading-self-link" href="#references" aria-label="Heading self-link">&lt;/a>&lt;/h3>
&lt;p>[1] 热帖: &lt;em>&lt;a href="https://old.reddit.com/r/ExperiencedDevs/comments/nmodyl/drunk">https://old.reddit.com/r/ExperiencedDevs/comments/nmodyl/drunk&lt;/a>_post_things_ive_learned_as_a_sr_engineer/&lt;/em>&lt;/p></description></item><item><title>Blog: 程序员应如何理解内存：上篇</title><link>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BA%94%E5%A6%82%E4%BD%95%E7%90%86%E8%A7%A3%E5%86%85%E5%AD%98%E4%B8%8A%E7%AF%87/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BA%94%E5%A6%82%E4%BD%95%E7%90%86%E8%A7%A3%E5%86%85%E5%AD%98%E4%B8%8A%E7%AF%87/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/U7F5LyzZ07KVOFYJF74LtQ">https://mp.weixin.qq.com/s/U7F5LyzZ07KVOFYJF74LtQ&lt;/a>
本节是操作系统系列教程的第三篇文章，属于操作系统第一章即基础篇，在真正开始操作系统相关章节前在这一部分回顾一些重要的主题，算是温故知新吧，以下是目录，由于本文篇幅较多因此接下来会分三次发布，目录中黑体为本篇内容。&lt;/p>
&lt;hr>
&lt;p>&lt;strong>什么是内存&lt;/strong>&lt;/p>
&lt;p>&lt;strong>C/C++ 内存模型&lt;/strong>&lt;/p>
&lt;p>堆区与栈区的本质&lt;/p>
&lt;p>Java、Python 等内存模型&lt;/p>
&lt;p>Java 内存模型&lt;/p>
&lt;p>Jave 中的堆区与栈区是如何实现的&lt;/p>
&lt;p>Python 内存模型&lt;/p>
&lt;p>指针与引用&lt;/p>
&lt;p>进程的内存模型&lt;/p>
&lt;p>幻想大师 - 操作系统&lt;/p>
&lt;p>总结&lt;/p>
&lt;hr>
&lt;h5 id="什么是内存">什么是内存&lt;a class="td-heading-self-link" href="#%e4%bb%80%e4%b9%88%e6%98%af%e5%86%85%e5%ad%98" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>0 和 1 这两个简单的数字能做什么？在其它学科中也许什么都做不了，但是在计算机科学中这就是全部。精彩纷呈的计算机世界正是构筑在这样两个简单数字之上。&lt;/p>
&lt;p>内存本身其实非常简单，内存的作用就是用来装数字 0 和数字 1 的，如图所示，图中的一个盒子就是内存的一个基本单元，装的不是 0 就是装的 1。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/2db7a6af-6c98-44c4-8b4b-1615bb23c340/640" alt="">&lt;/p>
&lt;p>内存由一大堆的 “盒子” 组成，每个盒子中要么是 0 要么是 1，其中 8 个盒子被称之为一个“字节”，每 8 个盒子也就是一个字节都有一个编号，这些编号就是简单的从 0 开始依次累加的，这个编号就被称之为“&lt;strong>内存地址&lt;/strong>”。如图所示，你可以把内存理解为下面这张图，其中左边的数字是内存地址，每一排是一个字节，图中展示的就是一个 8 字节大小的内存。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/2db7a6af-6c98-44c4-8b4b-1615bb23c340/640" alt="">&lt;/p>
&lt;p>而对于我们平时使用的比如 2G、4G 甚至 8G 大小的内存来说，只不过就是 “盒子” 多一点能装的 01 多一点而已，本质上和我们在这里展示的 8 字节大小的内存没有任何区别。&lt;/p>
&lt;p>在后面的章节中我将用右图来表示内存，但是你的大脑里一定要有左图这样一个概念。当计算机在执行我们的程序时，无论是我们的机器指令还是机器指令操作的数据，都需要存放在这些小盒子中 (内存)。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/2db7a6af-6c98-44c4-8b4b-1615bb23c340/640" alt="">&lt;/p>
&lt;p>以上就是从硬件角度来看内存，那么从编程语言上来看，程序员应该如何理解内存呢？&lt;/p>
&lt;h5 id="cc-内存模型">C/C++ 内存模型&lt;a class="td-heading-self-link" href="#cc-%e5%86%85%e5%ad%98%e6%a8%a1%e5%9e%8b" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>对于 C/C++ 程序员来说，常用的 int，char 等变量都被装在盒子中，char 值只需要一排盒子就能装下 (8bit)，一个 int 值一般需要四排盒子才能装得下。连续几排装有同样类型变量的盒子就是数组 (array)，连续几排装有不同类型变量的盒子就是结构体 (struct)，C/C++ 语言中不管多么复杂的数据结构都是在此基础上构建出来的，都需要装在这些盒子里，没什么大不了的。&lt;/p>
&lt;p>现在你已经知道了对于 C/C++ 程序员来说，我们使用的变量是直接放在内存中的 (盒子)，&lt;strong>每一排盒子的地址就是我们熟知的 “指针”&lt;/strong>，请记住，指针就是你使用的变量在内存中的地址，仅此而已。&lt;/p>
&lt;p>C/C++ 程序在被执行时，需要在内存中划出两段区域用于存放数据，这两个区域就是我们熟悉的堆 (Heap) 和栈(Stack)，也称堆区和栈区，如图所示，其中数据段和代码段我们已经熟悉了(不熟悉的同学请参见&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247483677&amp;amp;idx=1&amp;amp;sn=09212e8e7ecf7d58bfee53fa04e74911&amp;amp;chksm=fcb98643cbce0f5503916804ffe95bdd30917c9829429bb7fca7191b84f8171409db83e6e28c&amp;amp;scene=21#wechat_redirect">链接器系列&lt;/a>文章)，在这里我们将进一步完善 C/C++ 程序在内存中的样子，如图所示，其中堆区紧邻数据段，在数据段之上，而栈在最上方，栈和堆之间是尚未被使用的内存，随着程序的运行，当程序申请内存时栈区和堆区之间的空隙会减小，当程序释放内存后空隙会扩大，这就是 C/C++ 程序的内存模型。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/2db7a6af-6c98-44c4-8b4b-1615bb23c340/640" alt="">&lt;/p>
&lt;p>每个函数运行时都会在栈区上占用一块内存，这块内存中保存的是调用函数的参数以及函数中的定义的局部变量，这些变量在函数调用完成后会被释放。从这里可以看出栈上的变量无需程序员关心其释放问题，当函数调用完毕后会&lt;strong>自动&lt;/strong>释放所占用的空间。&lt;/p>
&lt;p>和栈上的变量不同的是，堆上分配的内存不会像栈一样被自动释放，在堆上分配的内存需要程序员手动释放，如果程序员在堆上分配了一块内存，但在使用完后忘记释放，这种情况就被称之为 “内存泄漏”，所谓“内存泄漏” 就是使用完毕后的内存没有释放掉，但是这块内存也不能被用作其它地方从而导致堆占用的内存不断增大，表现出来的就是如果我们去检测程序所占用的内存，会发现程序所占用的内存不断增大，当操作系统是不可能坐视某个进程不断吞噬掉系统内存的，当出现系统内存资源不足时将触发操作系统的保护机制，这在 Linux 中就是著名的 OOM Killer，即 Out Of Memory Killer，OOM Killer 会根据一些策略 Killer 有问题的进程，这个进程通常都是占用内存最多的那个。&lt;/p>
&lt;p>下面我们用一小段 C 代码来实际演示一变量是如何在堆区栈区上分配的，不用担心，这段代码非常简单：&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-cpp" data-lang="cpp">&lt;span style="display:flex;">&lt;span>&lt;span style="color:#000">include&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">&amp;lt;&lt;/span>&lt;span style="color:#000">stdlib&lt;/span>&lt;span style="color:#000;font-weight:bold">.&lt;/span>&lt;span style="color:#000">h&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">&amp;gt;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#204a87;font-weight:bold">void&lt;/span> &lt;span style="color:#000">f2&lt;/span>&lt;span style="color:#000;font-weight:bold">()&lt;/span> &lt;span style="color:#000;font-weight:bold">{&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#204a87;font-weight:bold">int&lt;/span> &lt;span style="color:#000">c&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#204a87;font-weight:bold">int&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">*&lt;/span> &lt;span style="color:#000">heap&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">c&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">3&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">heap&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span> &lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#204a87;font-weight:bold">int&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">*&lt;/span>&lt;span style="color:#000;font-weight:bold">)&lt;/span>&lt;span style="color:#000">malloc&lt;/span>&lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#204a87;font-weight:bold">sizeof&lt;/span>&lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#204a87;font-weight:bold">int&lt;/span>&lt;span style="color:#000;font-weight:bold">));&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#ce5c00;font-weight:bold">*&lt;/span>&lt;span style="color:#000">heap&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">4&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#000;font-weight:bold">}&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#204a87;font-weight:bold">void&lt;/span> &lt;span style="color:#000">f1&lt;/span>&lt;span style="color:#000;font-weight:bold">()&lt;/span> &lt;span style="color:#000;font-weight:bold">{&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#204a87;font-weight:bold">int&lt;/span> &lt;span style="color:#000">b&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">b&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">2&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">f2&lt;/span>&lt;span style="color:#000;font-weight:bold">();&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#000;font-weight:bold">}&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#204a87;font-weight:bold">int&lt;/span> &lt;span style="color:#000">main&lt;/span>&lt;span style="color:#000;font-weight:bold">()&lt;/span> &lt;span style="color:#000;font-weight:bold">{&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#204a87;font-weight:bold">int&lt;/span> &lt;span style="color:#000">a&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">a&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">1&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">f1&lt;/span>&lt;span style="color:#000;font-weight:bold">();&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#204a87;font-weight:bold">return&lt;/span> &lt;span style="color:#0000cf;font-weight:bold">0&lt;/span>&lt;span style="color:#000;font-weight:bold">;&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#000;font-weight:bold">}&lt;/span>
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>如图所示，这就是以上代码运行过程中的样子，你会发现，每个函数在被执行的时候都在栈区上占有一小段，在这一小段中存放当前函数中定义的局部变量和传入函数的参数。每个函数所占用的这一段内存有一个很形象的名字，叫做 “栈帧 (stack frame)”，原因就在于栈是随着函数调用一帧一帧增加的，每个函数在被调用时都会在栈上分配一帧，所以就叫栈帧。这个词请大家不必去深究，每个被调函数在栈区上做占用的内存总要有个名字，栈帧只不过比较形象而已。&lt;/p>
&lt;p>这段代码中，main 函数会调用函数 f1，f1 会调用函数 f2()，其中变量 a，b，c 以及 heap 依次被放在各自函数的栈帧中，值得注意的一点在于，&lt;strong>heap 这个变量本身是在栈上的，但是 heap 所指向的内存是分配在堆上的&lt;/strong>，heap 本身仅仅保存的是 4 这个值在内存中的&lt;strong>位置&lt;/strong>，比如这里的 0x10，表示的就是 4 这个值放在了内存 0x10 的这个位置上，heap 就是 C/C++ 语言中所谓的指针。如图所示：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/2db7a6af-6c98-44c4-8b4b-1615bb23c340/640" alt="">&lt;/p>
&lt;p>你会发现随着函数的调用，栈是不断在扩大的，当 f2，f1 执行完毕返回 main 时就是如下图所示的样子。&lt;/p>
&lt;p>从图中我们可以看出，f2 在执行完毕后，f2 所占用的内存就被回收了，所谓 “回收” 就是这块内存又可以用作其它用途了。f1 执行完毕后所占用的内存同样也被回收，这样我们就又回到了 main()函数中。&lt;/p>
&lt;p>这个过程中我们还会发现一个很有意思的现象就是最先被使用的栈帧其实是最后才被释放的，这种先进后出的性质就被称之为 “栈”，如下图所示。所以你会看到 “栈 “这个词更多的是指顺序上的先进后出，只不过函数调用时所占用的内存在使用方式上也是先进后出的，所以这块内存就被称之为栈区了。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/2db7a6af-6c98-44c4-8b4b-1615bb23c340/640" alt="">&lt;/p>
&lt;p>在讲解完栈之后，我们来看看堆，不同于像 a，b，c 这样存在于栈区上的变量，栈区上的变量可以在函数执行完成后被自动释放掉，在堆区上的分配内存除非程序员&lt;strong>手动&lt;/strong>调用 free,delete 明确的告知内存使用完毕，否则这块内存就会一直被占用而不能用作其它用途，这就是堆区。&lt;/p>
&lt;p>你可能会问，什么样的变量在需要在堆上分配呢，我们知道，函数调用完成后栈上的分配的局部变量会因为栈帧被释放而不再可用，堆区的存在就是为了解决这个问题，堆区中申请的内存不会因为栈帧的释放而不再可用，使得变量的生命周期不再局限于某个函数，其生命周期是靠程序员用 malloc(new) 以及 free(delete) 来控制的，这样的变量在使用时可以跨越函数调用。&lt;/p>
&lt;p>另外一点值得注意的是，f2 函数中我们在堆上申请了一块内存用来存放整数，但是 f2 执行完成后并没有去释放这块内存，根据堆的性质我们知道这块函数在接下来的运行过程中无法再被使用，就好像这块内存被遗忘了一样，这就是内存泄漏。&lt;/p>
&lt;p>接下来的内容将在《程序员应如何理解内存：中篇》继续。&lt;/p>
&lt;hr>
&lt;p>&lt;strong>操作系统系列&lt;/strong>
&lt;a href="https://mp.weixin.qq.com/s/U7F5LyzZ07KVOFYJF74LtQ">https://mp.weixin.qq.com/s/U7F5LyzZ07KVOFYJF74LtQ&lt;/a>&lt;/p></description></item><item><title>Blog: 程序员应如何理解内存：下篇</title><link>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BA%94%E5%A6%82%E4%BD%95%E7%90%86%E8%A7%A3%E5%86%85%E5%AD%98%E4%B8%8B%E7%AF%87/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BA%94%E5%A6%82%E4%BD%95%E7%90%86%E8%A7%A3%E5%86%85%E5%AD%98%E4%B8%8B%E7%AF%87/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/Uu8z7GIiPnrfRhDTj93UZQ">https://mp.weixin.qq.com/s/Uu8z7GIiPnrfRhDTj93UZQ&lt;/a>
本节是操作系统系列教程的第三篇文章，属于操作系统第一章即基础篇，在真正开始操作系统相关章节前在这一部分回顾一些重要的主题，以下是目录，由于本文篇幅较多因此按&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247483829&amp;amp;idx=1&amp;amp;sn=b9c32f56e95bdc229315e2b5ffd365cd&amp;amp;chksm=fcb986ebcbce0ffdc6c087775b895f6a0c0b83c72a91ee5614e253bea005509de8abfab6fc0e&amp;amp;scene=21#wechat_redirect">上篇&lt;/a>、&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247483839&amp;amp;idx=1&amp;amp;sn=20276b1966b76530890e9f09c6f41892&amp;amp;chksm=fcb986e1cbce0ff73c50f1a3f943bf182d8db666b27b4e55d20bd7cbbdea3fadbfbcb7c68f26&amp;amp;scene=21#wechat_redirect">中篇&lt;/a>、下篇三次发布，目录中黑体为本篇内容，本文为该主题最后一篇。&lt;/p>
&lt;hr>
&lt;p>什么是内存&lt;/p>
&lt;p>C/C++ 内存模型&lt;/p>
&lt;p>堆区与栈区的本质&lt;/p>
&lt;p>Java、Python 等内存模型&lt;/p>
&lt;p>Java 内存模型&lt;/p>
&lt;p>Jave 中的堆区与栈区是如何实现的&lt;/p>
&lt;p>Python 内存模型&lt;/p>
&lt;p>&lt;strong>指针与引用&lt;/strong>&lt;/p>
&lt;p>&lt;strong>进程的内存模型&lt;/strong>&lt;/p>
&lt;p>&lt;strong>幻想大师 - 操作系统&lt;/strong>&lt;/p>
&lt;p>&lt;strong>总结&lt;/strong>&lt;/p>
&lt;hr>
&lt;p>指针与引用&lt;/p>
&lt;p>在各种编程语言中我们应该经常听到两个词，那就是引用或者指针。这两个词都是和内存相关的，指针和引用的作用都是 “如何找到存放在内存上的数据”。&lt;/p>
&lt;p>C/C++ 中有 “指针” 这样一个概念，而其它语言比如 Java、Python 有的只是 “引用” 这样一个概念。这两者有什么区别呢？我们打个比方你就能理解了。&lt;/p>
&lt;p>“引用”就好比一个人的外号一样，就好有个程序员叫令狐冲，但是令狐冲同学在 A 公司的英文名可能是 “Tom”，在 B 公司中可能又叫“Jerry”，那么在 A 公司中你只需要喊一声“Tom” 就能找到令狐冲同学。&lt;/p>
&lt;p>而 “指针” 强调的是位置，比如令狐冲在 A 公司的工位是“10 排第二个”，在 B 公司中的工位是“8 排第六个”，下班后回的位置在“中关村”。&lt;/p>
&lt;p>这个例子当中的令狐冲同学就好比程序语言中的对象，令狐冲的各种外号就好比对象的引用，令狐冲当前所在的位置就好比对象的指针。&lt;/p>
&lt;p>虽然通过 “引用” 和“指针”都能找到令狐冲同学，但是寻找的方式是不一样的。&lt;/p>
&lt;p>只有 C/C++ 这样的编译型语言才会有 “指针” 这样一个概念，指的是当前的对象放在了内存中的哪个位置上了。在比如 Java、Python 等语言中只有 “引用” 这样一个概念。在 C/C++ 语言中，我们可以通过指针直接找到一个对象，因为你知道这个对象就在内存中指针所指向的位置，但在 Java、Python 等语言中，当你利用引用找到对象时基本上是冲着解释器喊一句“Hey，解释器，帮我找到令狐冲这个对象”，解释器通过记录查找到这个对象，注意解释器是知道对象在内存中的真正位置的，由于直接管理内存是一项非常繁琐容易出错的事情(C/C++ 程序员一定对此有深刻体会)，因此解释器就接手了对内存直接管理，&lt;strong>Java、Python 等程序员是没有必要知道对象在内存中的真正位置的&lt;/strong>，没有指针也可以开心的写程序而且程序更加健壮，何乐不为呢，因此这些语言中是没有指针这样一个概念。&lt;/p>
&lt;p>Sun 的一篇论文中提到了为什么 Java 里没有指针。&lt;/p>
&lt;blockquote>
&lt;p>Most studies agree that pointers are one of the primary features that enable programmers to inject bugs into their code. Given that structures are gone, and arrays and strings are objects, the need for pointers to these constructs goes away. Thus, Java has no pointer data types. &amp;hellip;
You no longer have dangling pointers and trashing of memory because of incorrect pointers, because there are no pointers in Java.&lt;/p>
&lt;/blockquote>
&lt;p>大意是 Java 设计者认为指针太有技巧性以至于很容易出错，因此 Java 中没有指针。其实不只是 Java，流行的语言当中除了 C/C++ 之外几乎都没有指针。&lt;/p>
&lt;p>在这一节中，你只需要理解以下两点就可以啦。&lt;/p>
&lt;ul>
&lt;li>指针：直接在内存中找到变量所在位置。所以指针是实实在在的内存地址。&lt;/li>
&lt;li>引用：告诉解释器你想使用的变量，然后解释器再去内存中找到变量的位置。所以引用只是解释器的一个&lt;strong>承诺&lt;/strong>，只要这个变量存在，解释器就承诺能找到这个变量，程序员就可以使用这个变量，至于这个变量在内存中的什么地方是不需要程序员关心的。&lt;/li>
&lt;/ul>
&lt;h5 id="进程的内存模型">进程的内存模型&lt;a class="td-heading-self-link" href="#%e8%bf%9b%e7%a8%8b%e7%9a%84%e5%86%85%e5%ad%98%e6%a8%a1%e5%9e%8b" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>我们已经在前面几个小节中研究了 C/C++ 以及 Java、Python 程序的内存模型，接下来让我们回到操作系统。&lt;/p>
&lt;p>我们已经知道了，不管什么语言，最后操作系统看到的都是 C 程序，C 程序在内存运行起来就是进程。而在前面的小节当中我们已经知道进程在内存中的样子，但那里的描述其实是不完整的，也是不准确的。接下里我们就来看一下，操作系统中的进程在内存中到底是什么样子的，如下图所示 (注意这幅图描述的是 32 位操作系统下进程在内存中是什么样子的)，我们需要注意以下几点：&lt;/p>
&lt;ol>
&lt;li>在上图中多出了一块内存，注意，这块内存就是操作系统在运行的时候所占用的内存。&lt;/li>
&lt;li>每个进程独占一个连续的 4G 大小的内存，从内存地址 0 开始，一直到 0xffffffff，其中最上方的 1G 留给了操作系统使用，下方的 3G 是留给进程自己使用的，其中程序员可以操作的区域就是图中的堆区和栈区。&lt;/li>
&lt;li>你会发现代码段下方也有一点空隙没有使用，其实这是有特殊目的的，具体用途会在后面的章节中讲解。&lt;/li>
&lt;/ol>
&lt;p>现在你已经知道了进程在内存中的样子，你一定会有疑问吧，&lt;/p>
&lt;p>为什么每个进程认为自己占用的是 4G 内存呢？&lt;strong>如果我的 PC 上只有 2G 内存，进程还是认为自己拥有 4G 内存吗&lt;/strong>？&lt;/p>
&lt;p>操作系统上不是可以同时运行很多进程吗，内存是有限的，假如只有 2G，&lt;strong>每个进程都认为自己拥有 4G 内存，这不会有问题吗&lt;/strong>？&lt;/p>
&lt;p>我们首先来回答第一个问题：是的，每个进程都认为计算机上的真实内存就是 4G，而且是进程自己独占的，即使真正的物理内存只有 256MB。&lt;/p>
&lt;p>第二个问题：很显然，不管你现在看这篇文章用的电脑，iPad，安卓手机还是 iPhone，这些计算设备中的进程都是这么认为的，你能看到这篇文章说明进程认为自己拥有 4G 内存是不会出现问题的。&lt;/p>
&lt;p>在这里需要再次强调的是：&lt;/p>
&lt;p>每个进程都认为真实的内存就是 4G，其中 1G 被操作系统使用，剩余部分被进程使用，也就是可以被程序员使用。&lt;strong>注意这是不受真实物理内存限制的&lt;/strong>，也就是说，即使真实的物理只有 256MB，进程同样认为在内存是 4G，其中 1G 是操作系统的，剩余 3G 是进程自己独占的，程序员依然可以按照内存大小是 3G 来写程序。所以在大小 256MB 的真实物理内存上，程序员依然可以一次性申请超过 256MB 的内存而且可以申请成功，后续内存的使用也不受影响。&lt;/p>
&lt;p>就像我第一次知道这种魔法时一样，你肯定也会惊呼这怎么可能呢？&lt;strong>我们怎么能在 256MB 大小的内存上申请超过 256MB 的内存呢&lt;/strong>？但事实就是如此，你可以在物理内存大小为 256MB 的内存上面申请超过 256MB 的内存，而且无论物理内存大小，每个进程都认为自己拥有 4G 内存，而且是独占内存。&lt;/p>
&lt;p>这真的是太神奇了，这就是本课程的主角 - 操作系统带来的神奇魔法。&lt;/p>
&lt;h5 id="幻象大师操作系统">幻象大师——操作系统&lt;a class="td-heading-self-link" href="#%e5%b9%bb%e8%b1%a1%e5%a4%a7%e5%b8%88%e6%93%8d%e4%bd%9c%e7%b3%bb%e7%bb%9f" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>这种魔法确实是真实的，这个魔法就来自我们的幻象大师 -&lt;strong>操作系统&lt;/strong>，其实进程看到的内存是操作系统制造的幻觉。操作系统让每个进程都认为内存就只有两部分，一部分是操作系统的一部分是自己的，这种魔法就称之为虚拟内存。后面的章节中会重点介绍操作系统是如何实现这种魔法的。&lt;/p>
&lt;p>&lt;strong>在虚拟内存上程序员分配内存不受真实物理内存大小的限制&lt;/strong>。&lt;/p>
&lt;p>但这仅仅是进程自己这么认为，这是操作系统给进程制造的幻觉，所以被称之为虚拟内存。虚拟内存是操作系统中极为重要的概念，和进程一样，对虚拟内存的深刻理解也是编程高手的标志之一。我会在后续文章中来为大家透彻讲解操作系统是如何做到的。&lt;/p>
&lt;h5 id="总结">总结&lt;a class="td-heading-self-link" href="#%e6%80%bb%e7%bb%93" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>哈哈，这真是比较长的一节，希望你能坚持学到这里，没办法，内存真的是非常重要的，&lt;strong>要想学好操作系统，对内存的透彻理解是必不可少的&lt;/strong>。&lt;/p>
&lt;p>在这一节中我们认识到了其实内存仅仅就是一堆装 0 或 1 的小盒子组成，是没有什么神秘的。我们也了解了 C/C++、Java、Python 程序的内存模型，也知道了操作系统中的进程在内存中是什么样子的。同时操作系统中被被称为虚拟内存的神奇魔法也着实让人惊叹，想学习这么魔法请继续关注操作系统系列文章。&lt;/p>
&lt;p>完整阅读《程序员应如何理解内存》一文请参见下方的操作系统系列目录。&lt;/p>
&lt;hr>
&lt;p>&lt;strong>操作系统系列&lt;/strong>&lt;/p>
&lt;p>PS：我才知道原来从&lt;strong>去年三月份以后申请的公众号已经没有留言功能了&lt;/strong>，还在想为什么一直没有留言，这个问题目前还没有一个很好的解决方法，如果你有问题欢迎暂时&lt;strong>直接在我的公众号里发送消息&lt;/strong>，发送消息时注明针对哪篇文章，后面如果大家疑问较多我会建一个技术群供大家学习交流，对此如果你有其它好的想法也欢迎直接在公众号里发送消息，目的就是希望这个公众号能更好的帮到大家！如果你喜欢这类文章也请多多转发，不胜感激，今天周五，预祝大家周末愉快 :)
&lt;a href="https://mp.weixin.qq.com/s/Uu8z7GIiPnrfRhDTj93UZQ">https://mp.weixin.qq.com/s/Uu8z7GIiPnrfRhDTj93UZQ&lt;/a>&lt;/p></description></item><item><title>Blog: 程序员应如何理解内存：中篇</title><link>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BA%94%E5%A6%82%E4%BD%95%E7%90%86%E8%A7%A3%E5%86%85%E5%AD%98%E4%B8%AD%E7%AF%87/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A8%8B%E5%BA%8F%E5%91%98%E5%BA%94%E5%A6%82%E4%BD%95%E7%90%86%E8%A7%A3%E5%86%85%E5%AD%98%E4%B8%AD%E7%AF%87/</guid><description>
&lt;p>&lt;a href="https://mp.weixin.qq.com/s/x52e0aGl0fC1KhXhai6MPg">https://mp.weixin.qq.com/s/x52e0aGl0fC1KhXhai6MPg&lt;/a>
本节是操作系统系列教程的第三篇文章，属于操作系统第一章即基础篇，在真正开始操作系统相关章节前在这一部分回顾一些重要的主题，以下是目录，由于本文篇幅较多因此会按&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247483829&amp;amp;idx=1&amp;amp;sn=b9c32f56e95bdc229315e2b5ffd365cd&amp;amp;chksm=fcb986ebcbce0ffdc6c087775b895f6a0c0b83c72a91ee5614e253bea005509de8abfab6fc0e&amp;amp;scene=21#wechat_redirect">上篇&lt;/a>、中篇、下篇三次发布，目录中黑体为本篇内容。&lt;/p>
&lt;hr>
&lt;p>什么是内存&lt;/p>
&lt;p>C/C++ 内存模型&lt;/p>
&lt;p>&lt;strong>堆区与栈区的本质&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Java、Python 等内存模型&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Java 内存模型&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Jave 中的堆区与栈区是如何实现的&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Python 内存模型&lt;/strong>&lt;/p>
&lt;p>指针与引用&lt;/p>
&lt;p>进程的内存模型&lt;/p>
&lt;p>幻想大师 - 操作系统&lt;/p>
&lt;p>总结&lt;/p>
&lt;hr>
&lt;h5 id="堆与栈的本质是什么">堆与栈的本质是什么&lt;a class="td-heading-self-link" href="#%e5%a0%86%e4%b8%8e%e6%a0%88%e7%9a%84%e6%9c%ac%e8%b4%a8%e6%98%af%e4%bb%80%e4%b9%88" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>在编程语言中，堆区和栈区本质上都是内存，因此二者在本质上没有任何区别，只不过这两块内存的&lt;strong>使用方式&lt;/strong>是不一样的。&lt;/p>
&lt;p>在数据结构与算法中，我们也有堆和栈的概念，但那里指的不是内存，而是两种数据结构。&lt;/p>
&lt;p>你可能会想，我们为什么要费尽心力的提出堆和栈这两个概念呢？之所以需要区分两种内存用法，根源在于：&lt;strong>内存是有限的&lt;/strong>。&lt;/p>
&lt;p>如果计算机内存是无限的，那么我们根本就不用这么麻烦的给内存划分两个区域，在其中的一个区域中这样使用内存，另一区域那样使用内存，这些都是不需要的。即使在今天 PC 内存普遍都在 8G、16G，这依然是不够的，因此我们需要合理的来安排内存的使用，堆和栈就是为达到这一目的而采用的技术。&lt;/p>
&lt;p>你会发现栈其实是一种非常巧妙的内存使用方法。函数调用完成后，函数运行过程中占用的内存就会被释放掉，这样，只要程序员代码写的合理 (栈帧不至于过大)，那我们程序就可以一直运行下去，而不会出现内存不足的现象。程序员在栈区不需要担心内存分配释放问题，因为这一切都是自动进行的。而如果程序员想自己控制内存，那么可以选择在堆上进行内存分配。因此这里提供了两种选择，一种是 “自动的”，一种是 “手动的”，目的都是在合理使用内存的同时提供给程序员最大的灵活性。&lt;/p>
&lt;p>堆和栈是计算机科学中很优秀的设计思想，这种设计思想充分的体现了计算机如何&lt;strong>合理且灵活&lt;/strong>的使用有限资源。&lt;/p>
&lt;p>堆区和栈区对 C/C++ 程序员来说就是实实在在的内存，而对于 Java、Python 等语言的程序员来说又该如何理解内存呢?&lt;/p>
&lt;h5 id="javapython-等内存模型">Java、Python 等内存模型&lt;a class="td-heading-self-link" href="#javapython-%e7%ad%89%e5%86%85%e5%ad%98%e6%a8%a1%e5%9e%8b" aria-label="Heading self-link">&lt;/a>&lt;/h5>
&lt;p>当 Java、Python 等语言的程序在执行时其解释器的内存布局同样如下图所示，我们之前讲过，解释器也是一个 C/C++ 程序，因此这里的代码段包含的是解释器的实现代码而不是 Java、Python 等代码，这一点大家一定要注意。&lt;/p>
&lt;p>&amp;ldquo;C/C++ 程序员面对的是实实在在的物理内存，Java、Python 等程序面对的是解释器。&amp;rdquo;&lt;/p>
&lt;p>C/C++ 分配内存是直接在物理内存中进行的，而 Java、Python 等程序是将内存分配请求交给解释器，解释器再去物理内存上进行分配。希望大家务必理解这一点。&lt;/p>
&lt;p>Java、Python 等程序员是看不到如下图所示的内存布局的，因为这一切都是解释器才能看到的，解释器对 Java、Python 等程序员屏蔽了这些。Java、Python 等程序员也无需关心解释器的内存布局。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/20f93fbf-ca56-4444-9809-2d24fd93a6f0/640" alt="">&lt;/p>
&lt;p>Java、Python 等程序的一大优点就是内存的自动化管理，而 C/C++ 程序员需要自己来管理从堆上分配的内存。内存管理这一项工作在 Java、Python 等程序中被解释器接管了，解释器的这项功能被称为 “垃圾回收器”。&lt;/p>
&lt;p>在非 C/C++ 语言中，我们来看两个有代表性的语言，首先我们看一下 Java。&lt;/p>
&lt;h6 id="java-内存模型">Java 内存模型&lt;a class="td-heading-self-link" href="#java-%e5%86%85%e5%ad%98%e6%a8%a1%e5%9e%8b" aria-label="Heading self-link">&lt;/a>&lt;/h6>
&lt;p>Java 的内存模型中同样有栈和堆这样的概念，如下图所示，在 Java 函数中我们定义的内置数据类型比如 int a = 0，是直接存放在栈上的，引用类型，也就是用 new 关键字定义的变量是分配在堆上的。和 C/C++ 一样，每个 Java 函数在执行时都有自己的栈帧。随着函数的调用，栈不断的扩大。当函数调用完毕后栈帧被回收，在堆上分配的变量依然可以被后续函数使用。Java 程序员无需像 C/C++ 程序员一样需要关心内存回收的问题，这一切都是 Java 的解释器 JVM 来管理的。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/20f93fbf-ca56-4444-9809-2d24fd93a6f0/640" alt="">&lt;/p>
&lt;p>在用法上 Java 中的堆和栈和 C/C++ 是一样的，只不过 Java 程序员无需关心内存的释放问题。但是好奇的同学可能会问，C/C++ 中的堆和栈我已经清楚了，因为 C/C++ 程序运行时在内存中的样子已经在《C/C++ 内存模型》这一小节中详细的讲述了，那么 Java 中的堆和栈在内存中是什么样子的呢，就是和上图一样吗？要回答这个问题，就要涉及到 Java 中的堆和栈是如何实现的。&lt;/p>
&lt;h6 id="java-中的堆和栈是如何实现的">Java 中的堆和栈是如何实现的&lt;a class="td-heading-self-link" href="#java-%e4%b8%ad%e7%9a%84%e5%a0%86%e5%92%8c%e6%a0%88%e6%98%af%e5%a6%82%e4%bd%95%e5%ae%9e%e7%8e%b0%e7%9a%84" aria-label="Heading self-link">&lt;/a>&lt;/h6>
&lt;p>如果你自己设计过一门语言的话，你应该会很清楚这个问题。&lt;/p>
&lt;p>我们先回答上一节中提到的问题，那就是 Java 中的堆和栈就是如上图所示的那样吗？是这样的，作为 Java 程序员在写代码时脑海里有上面这张图基本上就够用了。但是，Java 中的堆和栈不同于 C/C++ 当中的堆和栈。&lt;/p>
&lt;p>我们已经知道 Java 中的内存管理其实是解释器 JVM 来搞定的，作为 C/C++ 程序，JVM 的内存布局就如下图所示。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/20f93fbf-ca56-4444-9809-2d24fd93a6f0/640" alt="">&lt;/p>
&lt;p>一般情况下，当 JVM 运行一个 Java 函数时需要在堆上创建出 Java 函数的栈帧，然后把这些栈帧放入栈中 (这里的栈指的是具有先进后出性质的数据结构)。希望大家不要被这句话绕晕，这里出现了两个 “栈”，但是含义完全不同。&lt;/p>
&lt;ul>
&lt;li>Java 栈帧：指的是上图中我们看到的栈。&lt;/li>
&lt;li>栈帧放入到栈：我们在数据结构课程中都学过栈，栈有 push 和 pop 两种操作，把栈帧放入栈指的是把栈帧 push 到 JVM 所持有的栈这种数据结构当中，以此来模拟 C/C++ 程序执行过程中函数栈帧先进后出的这种性质，当一个 Java 函数被执行完毕后，JVM pop 掉该函数的栈帧。
如果你想在代码级别来理解这个过程，大体上可以参考下面的代码，注意 JVM 是 C/C++ 程序，这里的代码是一个极其简单的描述。&lt;strong>你可以看到如何组织栈帧完全是 JVM 设计者来决定的，只要栈帧具备先进后出的性质就可以。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;div class="highlight">&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-cpp" data-lang="cpp">&lt;span style="display:flex;">&lt;span>&lt;span style="color:#204a87;font-weight:bold">void&lt;/span> &lt;span style="color:#000">RunJavaFunction&lt;/span>&lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#000">JVM&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">*&lt;/span> &lt;span style="color:#000">jvm&lt;/span>&lt;span style="color:#a40000">，&lt;/span> &lt;span style="color:#000">string&lt;/span> &lt;span style="color:#000">javaFunction&lt;/span>&lt;span style="color:#000;font-weight:bold">)&lt;/span> &lt;span style="color:#000;font-weight:bold">{&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">stackFrame&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">*&lt;/span> &lt;span style="color:#000">frame&lt;/span> &lt;span style="color:#ce5c00;font-weight:bold">=&lt;/span> &lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#000">stackFrame&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">*&lt;/span>&lt;span style="color:#000;font-weight:bold">)&lt;/span> &lt;span style="color:#000">malloc&lt;/span>&lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#204a87;font-weight:bold">sizeof&lt;/span>&lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#000">stackFrame&lt;/span>&lt;span style="color:#000;font-weight:bold">));&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">jvm&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">-&amp;gt;&lt;/span>&lt;span style="color:#000">stack&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">-&amp;gt;&lt;/span>&lt;span style="color:#000">push&lt;/span>&lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#000">frame&lt;/span>&lt;span style="color:#000;font-weight:bold">);&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">run&lt;/span>&lt;span style="color:#000;font-weight:bold">(&lt;/span>&lt;span style="color:#000">javaFunction&lt;/span>&lt;span style="color:#000;font-weight:bold">,&lt;/span> &lt;span style="color:#000">frame&lt;/span>&lt;span style="color:#000;font-weight:bold">);&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> &lt;span style="color:#000">jvm&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">-&amp;gt;&lt;/span>&lt;span style="color:#000">stack&lt;/span>&lt;span style="color:#ce5c00;font-weight:bold">-&amp;gt;&lt;/span>&lt;span style="color:#000">pop&lt;/span>&lt;span style="color:#000;font-weight:bold">();&lt;/span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#000;font-weight:bold">}&lt;/span>
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>JVM 会在自己的堆中为用 new 修饰的对象创建内存，这里的堆就是如上图所示的堆，是可以要记住 JVM 是一个 C/C++ 程序，JVM 看到的堆才是如上图所示的那样。所以你会发现，一般情况下，&lt;strong>Java 中的栈和 Java 对象都是 JVM 在自己的堆上分配出来的&lt;/strong>，这就是 Java 中堆和栈是如何实现的。&lt;/p>
&lt;p>在讲解完 Java 的内存模型后，我们来看一下 Python 的。&lt;/p>
&lt;h6 id="python-内存模型">&lt;strong>Python 内存模型&lt;/strong>&lt;a class="td-heading-self-link" href="#python-%e5%86%85%e5%ad%98%e6%a8%a1%e5%9e%8b" aria-label="Heading self-link">&lt;/a>&lt;/h6>
&lt;p>Python 的内存模型和 Java 其实是类似的，Java 程序员脑海中的那张图同样适用于 Python 程序员。&lt;/p>
&lt;p>Python 语言中的解释器比较多，比如 CPython，PyPy 等，在这里我们以 Python 默认的解释器 CPython 为例来说明，我们已经知道了解释器其实也是一个 C 程序，CPython 也不例外，下图左侧就是我们已经熟悉的 C/C++ 内存布局，我们把堆区放大，如下图右侧所示。我们可以看到 Python 的解释器把自己的堆区划分成了两部分，分别是 Object-specific memory 区域，以及 Python core 区域：&lt;/p>
&lt;p>Object-specific memory 这个区域专门用来存放 PyObject。你也许已经知道了，Python 中所有的数据类型比如 int，dict，str 等都是一个对象，叫做 PyObject。当我们在 Python 中创建一个变量比如 dict 时，CPython 就会在堆区的上半部分 (Object-specific memory) 中分配一块内存，创建一个 PyObject，这个 PyObject 用来存放我们的 dict。&lt;/p>
&lt;p>Python core：所有非 PyObject 的内存请求都在这里分配的。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/20f93fbf-ca56-4444-9809-2d24fd93a6f0/640" alt="">&lt;/p>
&lt;p>所以你会发现，Python 中所有的内存同样是解释器在自己的堆上分配的。&lt;/p>
&lt;p>&lt;em>本文最后一部分将在《程序员应如何理解内存：下篇》中继续。&lt;/em>&lt;/p>
&lt;hr>
&lt;p>&lt;strong>操作系统系列&lt;/strong>
&lt;a href="https://mp.weixin.qq.com/s/x52e0aGl0fC1KhXhai6MPg">https://mp.weixin.qq.com/s/x52e0aGl0fC1KhXhai6MPg&lt;/a>&lt;/p></description></item><item><title>Blog: 二十年老程序员的二十条心得：面试几乎没用，警惕很久没写过代码的“大牛”</title><link>https://desistdaydream.github.io/blog/copy/bHdkIkWCNZPmO-Hz-HQreQ/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/bHdkIkWCNZPmO-Hz-HQreQ/</guid><description>
&lt;p>原文链接：&lt;a href="https://mp.weixin.qq.com/s/bHdkIkWCNZPmO-Hz-HQreQ">https://mp.weixin.qq.com/s/bHdkIkWCNZPmO-Hz-HQreQ&lt;/a>&lt;/p>
&lt;p>作者 | Justin Etheredge&lt;/p>
&lt;p>译者 | 核子可乐&lt;/p>
&lt;p>务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛”。&lt;/p>
&lt;p>站在巨人的肩膀上当然更容易成功，所以我们才会希望行业前辈能给出一些有意义的建议。今天这些建议来自一位有二十年行业经验的软件工程师，他的总结在 Hacker News 上引发了大量的讨论，帖子多天来一直占据“热榜”第一。&lt;/p>
&lt;p>&lt;img src="https://mmbiz.qpic.cn/mmbiz_png/YriaiaJPb26VN3rGjM1ScFFyKk2sD3tY1oOnkJia2khSNfO6BlgBQPsOAQqnGfrhl7ia9qhyFcRLzAPic22w6icnXlYQ/640?wx_fmt=png&amp;amp;wxfrom=5&amp;amp;wx_lazy=1&amp;amp;wx_co=1" alt="">&lt;/p>
&lt;p>Justin Etheredge 最初在各类小型和初创企业中担任软件工程师，之后进入了咨询行业并开始为大型企业服务。Justin Etheredge 表示过去二十年以来的经历塑造了他对于软件的理解，并产生出一些坚定的信念。他把这些信念整理成一份明确的清单，希望能为大家带来一点帮助与启发。&lt;/p>
&lt;p>引起网友激烈讨论的二十条建议：&lt;/p>
&lt;ol>
&lt;li>我懂的并不多&lt;/li>
&lt;/ol>
&lt;p>“你怎么会不知道什么是 BGP？”“你难道没听说过 Rust？”&lt;/p>
&lt;p>类似的问题可能每天都会出现在我们面前。没错，投身于软件行业的很多人之所以热爱这份工作，就是因为它敦促着我们终身学习。&lt;/p>
&lt;p>在软件领域，无论我们朝哪个方向前进，都有着广阔的知识空间不断延伸而且每一天都有所变化。换句话说，这是一份能够承载我们度过几十年的职业生涯，而两位在类似岗位上分别工作了几十年的人之间也 &lt;strong>很可能存在巨大的知识差距&lt;/strong>。我们越早意识到这一点，就能越快摆脱“冒充者综合症”，成为一个乐于向他人学习、也乐于教导他人的积极分子。&lt;/p>
&lt;ol start="2">
&lt;li>软件里最难的部分，是构建正确的东西&lt;/li>
&lt;/ol>
&lt;p>我知道这种话大家肯定听过无数遍了，但大多数软件工程师仍拒不承认，理由是这种说法似乎在贬低他们的工作成果。我个人觉得这样的心态大可不必，这类表达其实是在突出软件开发环境中的复杂性与非理性因素，而这些都会加剧我们面临的挑战。我们当然可以设计出在技术上最令人印象深刻的东西，但却没人愿意用——这类困境随时都会出现。&lt;/p>
&lt;p>软件设计主要是一种聆听活动，开发者往往身兼软件工程师、通灵师乃至人类学家等多重角色。而我们对这种设计能力的每一点投资，无论是引入专业的用户体验师还是接受更进一步的自我教育，都能给开发成果带来巨大提升。毕竟与打磨设计能力相比，开发一款“没人用”的软件成本还是太高了、太高太高。&lt;/p>
&lt;ol start="3">
&lt;li>顶尖软件工程师会像设计师那样思考&lt;/li>
&lt;/ol>
&lt;p>伟大的软件工程师会深入思考代码成果的用户体验。虽然使用的术语或者切入点不同，但无论是对于外部 API、编程 API、用户界面、协议还是其他接口，优秀的工程师都会考虑由谁来使用、为什么要使用、如何使用以及对用户来说哪些因素真正重要等。总之，牢记用户需求才是实现良好体验的核心所在。&lt;/p>
&lt;ol start="4">
&lt;li>最好的代码就是没有代码，或者说不需要维护的代码&lt;/li>
&lt;/ol>
&lt;p>“程序员就是管编程的”，而且跟其他专业人士一样，我们也会在自己最擅长的方面犯错。这是人的本性，没办法。大多数软件工程师编写出的代码总是有点错误，而且往往无法用非技术方案来解决。&lt;/p>
&lt;p>另外有一种很神奇的现象，&lt;strong>越是有大量相当成熟的解决方案存在，工程团队就越是想“重新发明轮子”&lt;/strong>。想表达自我、加快专业成长当然是好事，但还请大家分清场合与需求，过度泛滥的发明欲望恐怕不利于编写出无需维护的代码。&lt;/p>
&lt;ol start="5">
&lt;li>软件是达成目的的手段&lt;/li>
&lt;/ol>
&lt;p>任何一位软件工程师的主要工作都是交付价值。但我发现大部分软件开发者并不理解这一点，能够将这个理念内化进日常工作的开发者就更少了。但只要能够完成内化，我们解决问题的方式、看待工具的角度都会有所变化。如果您真心相信软件要服从于结果，那就一定能找到“真正适合工作的工具”，而这种工具也许压根就不是软件。&lt;/p>
&lt;ol start="6">
&lt;li>有时候，你压根没时间磨刀&lt;/li>
&lt;/ol>
&lt;p>都说“磨刀不误砍柴工”，但刀磨久了反而让人心浮气躁、难以投入真正的工作。代码编写也是一样，研究多了容易让人陷入“分析瘫痪”。&lt;/p>
&lt;p>一旦出现这种状况，请马上给自己设定一个截止日期，之后再探索解决方案。在着手解决问题时，我们很快就能找到思路与线索、引导自己一步步迭代向更好的产出。&lt;/p>
&lt;ol start="7">
&lt;li>如果没法理解所有可能性，就设计不出优秀的系统&lt;/li>
&lt;/ol>
&lt;p>这也是我个人一直在努力解决的问题。我的职责变化导致自己距离常规软件工程任务越来越远，我发现跟上开发者生态的发展速度越来越难，有时候自己甚至不理解哪些趋势真正重要。总之，如果不能理解特定生态当中的那些可行性与可用选项，那么我们根本没办法为所有问题找到合理的解决方案。&lt;/p>
&lt;p>总而言之，&lt;strong>务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛”&lt;/strong>。&lt;/p>
&lt;ol start="8">
&lt;li>每套系统最终都很差劲，要勇于接受这一点&lt;/li>
&lt;/ol>
&lt;p>Bjarne Stroustrup 有句名言，“世界上只有两种语言，人们抱怨的语言和没人用的语言。”大型系统也是同理。并不存在“正确”的架构，我们永远无法偿还所有技术债务、设计不出完美的界面、也不可能永远拥有迅如闪电的测试速度。但做不到不代表什么都不做，这只是一种参考视角。优雅和完美本身就是种终极目标，我们当下的任务就是不断改进并创造一个更友好的系统环境，保证团队至少还用得下去、并以可持续的方式交付价值。&lt;/p>
&lt;ol start="9">
&lt;li>通于探索，不断追问&lt;/li>
&lt;/ol>
&lt;p>相信大家都听过“我们向来这么处理”之类的鬼话。这时候请关注那些新加入的成员，看看他们在哪里遇到了问题、又提出了哪些质疑。这些质疑中，是否存在某种有意义的功能诉求？请保证您明确理解他们提出的目标，以及驱动这种功能诉求的原因。如果得不到明确答案，就不断追问下去、直到弄明白为止。&lt;/p>
&lt;ol start="10">
&lt;li>相比于寻找 10 倍程序员，最好是消除 0.1 倍程序员&lt;/li>
&lt;/ol>
&lt;p>10 倍程序员就是个愚蠢的笑话。&lt;/p>
&lt;p>没有任何一个人能在一天之内搞定另一位同样有能力、工作态度端正而且经验丰富的程序员需要两个礼拜才能做完的工作。我只见过 10 倍代码量程序员，他们写出来的 bug 也是 10 倍。或者说，10 倍程序员唯一的存在可能性，就是身边有个 0.1 倍程序员——就是那种浪费时间、不关注反馈、不测试代码也不考虑极端情况的家伙……所以相较于寻找神话中的 10 倍程序员，及时清除团队中的 0.1 倍程序员才是正道。&lt;/p>
&lt;ol start="11">
&lt;li>高级工程师与初级工程师间的最大区别之一，在于二者形成意见的具体方式&lt;/li>
&lt;/ol>
&lt;p>如果某位高级工程师对现有工具或者软件构建流程没有任何意见，那我实在是感觉不太正常。我宁愿有人能反馈出强烈的批评意见，也不愿他们压根没有任何意见。只要正在实际使用工具，那大家或多或少会有正面或者负面的批价；对其他语言、库和范式的应用也是类似的情况。而这种对于工具及技术的评判与探索，往往可以快速提升我们的技能水平。&lt;/p>
&lt;ol start="12">
&lt;li>人们并不真正想要创新&lt;/li>
&lt;/ol>
&lt;p>人们经常讨论创新，但实际想要的只是更廉价的胜利与新鲜感。如果真正进行创新、改变人们处理工作的方式，那么对方大概率会给出负面反馈。但如果您真的相信自己的决定代表未来、相信这一切能改善产出，那请做好打一场持久战、拉锯战的准备。&lt;/p>
&lt;ol start="13">
&lt;li>数据是系统当中最重要的组成部分&lt;/li>
&lt;/ol>
&lt;p>我见过很多以数据完整性作为主要保障目标的系统。但在这类系统中，任何预期范围之外的操作都会产生某些“脏”数据，它们会在后续处理中演变为一场噩梦。&lt;/p>
&lt;p>请记住，&lt;strong>数据的存在周期往往比代码库更长&lt;/strong>，所以请花点精力保持数据的清洁和有序。从长远来看，这种好习惯必然带来高回报。&lt;/p>
&lt;ol start="14">
&lt;li>寻找技术“鲨鱼”&lt;/li>
&lt;/ol>
&lt;p>所谓技术“鲨鱼”，就是那些长久存在、能够有效解决问题，所以可以在技术领域的快速变化中幸存下来的技术方案。注意，它们是鲨鱼、不是恐龙，所以除非有充分的理由，否则千万不要轻易更换。这些工具没什么特别、也不激动人心，但它们总是稳定有效，能让人睡个好觉。&lt;/p>
&lt;ol start="15">
&lt;li>不要把谦虚当成无知&lt;/li>
&lt;/ol>
&lt;p>很多软件工程师不爱主动说话，除非问题被推到面前。所以，千万别以为别人没发言就是大家没意见。有时候，最吵闹的家伙反而是我们最不想倾听的对象。总之，积极与其他人交谈，寻求他们的反馈与建议。这招回报很高，一试就灵。&lt;/p>
&lt;ol start="16">
&lt;li>软件工程师应该保持写作的习惯&lt;/li>
&lt;/ol>
&lt;p>软件工程师应该定期写点博客、日记和说明文档，或者其他能够保持自己书面沟通技巧的东西。写作能帮助我们思考问题，也能培养起我们与团队甚至是未来的自己良好沟通的能力。良好的书面沟通可以说是每一位软件工程师都必须掌握的重要技能之一。&lt;/p>
&lt;ol start="17">
&lt;li>让流程尽可能精简&lt;/li>
&lt;/ol>
&lt;p>时至今日，每个人都在说“敏捷”，但敏捷的本质并不复杂——构建小小的单元块、从中学习、再迭代。如果有人把它弄得更晦涩，那恐怕就是想夹带私货。&lt;/p>
&lt;p>换句话说，那些最成功的科技企业或者大型开源项目不会过度吹嘘自己的 Scrum 流程有多棒。大道至简，精益才是成功的关键。相信你的团队，他们也会用产出回应你的信任。&lt;/p>
&lt;ol start="18">
&lt;li>软件工程师也是人，也需要找到当家作主的感觉&lt;/li>
&lt;/ol>
&lt;p>如果硬要把某人跟他的工作成果分开，那他们也就不关心自己在干什么了。也正因为如此，跨职能团队以及 DevOps 理念才在当下获得广泛认同。这不只是要消除无谓的交接与低效率环节，更重要的是让每个人从头到尾拥有整个流程，并负责直接交付价值。只要让一群充满激情的工作者完全掌握软件设计、构建与交付的所有权，他们一定会拿出令人兴奋的成果。&lt;/p>
&lt;ol start="19">
&lt;li>面试在反映开发者水平方面几乎毫无价值&lt;/li>
&lt;/ol>
&lt;p>面试的最大作用就是了解对方，主要是对方对于特定专业领域抱有多大的兴趣。另一方面，&lt;strong>面试在反映开发者技术水平方面几乎毫无价值&lt;/strong>。相信我，无论一个人多聪明、多博学，都不代表对方就真的适合我们的团队。没人会在面试中坦言自己不太可靠、暴躁易怒、自负自大或者从来不准时出席会议。为了拿到工作，每个人都或多或少要粉饰一下自己，而那些能在原则问题上坚持立场的人反而值得尊敬。“永远不要雇用那些在面试中询问休息时间的人”，这种鬼话就是纯纯的放屁！&lt;/p>
&lt;ol start="20">
&lt;li>始终坚持从小处着眼&lt;/li>
&lt;/ol>
&lt;p>在系统开发当中，种种因素似乎都在推动我们构建起更大的体系。预算分配、难以取舍的功能方案、一举打造“最佳版本”的愿望等等，都会让刚刚起步的项目快速变得臃肿不堪。请千万克服自己的冲动，努力通过迭代让系统从最初的简单粗糙变得精致优雅。而且跟很多朋友想象中不同，这也是打造精致优雅系统的唯一方法。&lt;/p>
&lt;p>&lt;strong>参考链接：&lt;/strong>&lt;/p>
&lt;p>&lt;a href="https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/">https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/&lt;/a>&lt;/p>
&lt;p>&lt;a href="https://news.ycombinator.com/item?id=28797485">https://news.ycombinator.com/item?id=28797485&lt;/a>&lt;/p></description></item><item><title>Blog: 函数运行时在内存中是什么样子？</title><link>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E5%87%BD%E6%95%B0%E8%BF%90%E8%A1%8C%E6%97%B6%E5%9C%A8%E5%86%85%E5%AD%98%E4%B8%AD%E6%98%AF%E4%BB%80%E4%B9%88%E6%A0%B7%E5%AD%90/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E5%87%BD%E6%95%B0%E8%BF%90%E8%A1%8C%E6%97%B6%E5%9C%A8%E5%86%85%E5%AD%98%E4%B8%AD%E6%98%AF%E4%BB%80%E4%B9%88%E6%A0%B7%E5%AD%90/</guid><description>
&lt;blockquote>
&lt;p>参考：&lt;a href="https://mp.weixin.qq.com/s/CIK6oYeAtjXyh9oCfCFnxA">公众号,码农的荒岛求生&lt;/a>&lt;/p>
&lt;/blockquote>
&lt;p>在开始本篇的内容前，我们先来思考几个问题。&lt;/p>
&lt;ol>
&lt;li>
&lt;p>我们先来看一段简单的代码：&lt;/p>
&lt;p>void func(int a) {
if (a &amp;gt; 100000000) return;
int arr[100] = {0};
func(a + 1);
}&lt;/p>
&lt;/li>
&lt;/ol>
&lt;p>你能看出这段代码会有什么问题吗？&lt;/p>
&lt;ol start="2">
&lt;li>
&lt;p>我们在上一篇文章《&lt;strong>高性能高并发服务器是如何实现的&lt;/strong>》中提到了一项关键技术——协程，你知道协程的本质是什么吗？有的同学可能会说是用户态线程，那么什么是用户态线程，这是怎么实现的？&lt;/p>
&lt;/li>
&lt;li>
&lt;p>函数运行起来后在内存中是什么样子？&lt;/p>
&lt;/li>
&lt;/ol>
&lt;p>这几个问题看似没什么关联，但这背后都指向一样东西，这就是所谓的函数&lt;strong>运行时栈&lt;/strong>，&lt;strong>run time stack&lt;/strong>。&lt;/p>
&lt;p>接下来我们就好好看看到底什么是函数运行时栈，为什么彻底理解函数运行时栈对程序员来说非常重要。&lt;/p>
&lt;p>&lt;strong>从进程、线程到函数调用&lt;/strong>&lt;/p>
&lt;p>汽车在高速上行驶时有很多信息，像速度、位置等等，通过这些信息我们可以直观的感受汽车的运行时状态。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863819-23f4e86d-49f6-4ae3-bc42-2d6b58e4b526.png" alt="">&lt;/p>
&lt;p>同样的，程序在运行时也有很多信息，像有哪些程序正在运行、这些程序执行到了哪里等等，通过这些信息我们可以直观的感受系统中程序运行的状态。&lt;/p>
&lt;p>其中，我们创造了进程、线程这样的概念来记录有哪些程序正在运行，关于进程和线程的概念请参见《&lt;strong>看完这篇还不懂进程、线程与线程池你来打我&lt;/strong>》。&lt;/p>
&lt;p>&lt;strong>进程和线程的运行体现在函数执行上&lt;/strong>，函数的执行除了函数内部执行的顺序执行还有子函数调用的控制转移以及子函数执行完毕的返回。其中函数内部的顺序执行乏善可陈，重点是函数的调用。&lt;/p>
&lt;p>因此接下来我们的视角将从宏观的进程和线程拉近到微观下的函数调用，重点来讨论一下函数调用是怎样实现的。&lt;/p>
&lt;p>&lt;strong>函数执行的活动轨迹：栈&lt;/strong>&lt;/p>
&lt;p>玩过游戏的同学应该知道，有时你为了完成一项主线任务不得不去打一些支线的任务，支线任务中可能还有支线任务，当一个支线任务完成后退回到前一个支线任务，这是什么意思呢，举个例子你就明白了。&lt;/p>
&lt;p>假设主线任务西天取经 A 依赖支线任务收服孙悟空 B 和收服猪八戒 C，也就是说收服孙悟空 B 和收服猪八戒 C 完成后才能继续主线任务西天取经 A；&lt;/p>
&lt;p>支线任务收服孙悟空 B 依赖任务拿到紧箍咒 D，只有当任务 D 完成后才能回到任务 B；&lt;/p>
&lt;p>整个任务的依赖关系如图所示：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863816-401e714c-969d-4c84-809d-da6dbda9afd5.png" alt="">&lt;/p>
&lt;p>现在我们来模拟一下任务完成过程。&lt;/p>
&lt;p>首先我们来到任务 A，执行主线任务：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863838-f93491ad-74b3-4a4d-b08d-25d9696c481f.png" alt="">&lt;/p>
&lt;p>执行任务 A 的过程中我们发现任务 A 依赖任务 B，这时我们暂停任务 A 去执行任务 B：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863822-2de8c022-ddff-4ed8-baa2-0f25fb36ccd2.png" alt="">&lt;/p>
&lt;p>执行任务 B 的时候，我们又发现依赖任务 D：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863845-17cae4f5-01ec-424e-ae6e-917c687207e5.png" alt="">&lt;/p>
&lt;p>执行任务 D 的时候我们发现该任务不再依赖任何其它任务，因此 C 完成后我们可以会退到前一个任务，也就是 B：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863842-63a7ee82-9067-443a-a905-0f89e32625f4.png" alt="">&lt;/p>
&lt;p>任务 B 除了依赖任务 C 外不再依赖其它任务，这样任务 B 完成后就可以回到任务 A：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863837-23f565d8-34ab-4b12-81b3-e95e1cb5c5eb.png" alt="">&lt;/p>
&lt;p>现在我们回到了主线任务 A，依赖的任务 B 执行完成，接下来是任务 C：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863822-9b6d5976-5e0b-4b48-b2c9-c74286a5a3bd.png" alt="">&lt;/p>
&lt;p>和任务 D 一样，C 不依赖任何其它其它任务，任务 C 完成后就可以再次回到任务 A，再之后任务 A 执行完毕，整个任务执行完成。&lt;/p>
&lt;p>让我们来看一下整个任务的活动轨迹：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863834-ae1821d1-8421-46e4-b2d9-fd695b0faabf.png" alt="">&lt;/p>
&lt;p>仔细观察，实际上你会发现这是一个 First In Last Out 的顺序，天然适用于栈这种数据结构来处理。&lt;/p>
&lt;p>再仔细看一下栈顶的轨迹，也就是 A、B、D、B、A、C、A，&lt;strong>实际上你会发现这里的轨迹就是任务依赖树的遍历过程&lt;/strong>，是不是很神奇，这也是为什么树这种数据结构的遍历除了可以用递归也可以用栈来实现的原因。&lt;/p>
&lt;p>&lt;strong>A Box&lt;/strong>&lt;/p>
&lt;p>函数调用也是同样的道理，你把上面的 ABCD 换成函数 ABCD，本质不变。&lt;/p>
&lt;p>因此，现在我们知道了，使用栈这种结构就可以用来保存函数调用信息。&lt;/p>
&lt;p>和游戏中的每个任务一样，当函数在运行时每个函数也要有自己的一个“小盒子”，&lt;strong>这个小盒子中保存了函数运行时的各种信息&lt;/strong>，这些小盒子通过栈这种结构组织起来，这个小盒子就被称为栈帧，stack frames，也有的称之为 call stack，不管用什么命名方式，总之，就是这里所说的小盒子，这个小盒子就是函数运行起来后占用的内存，&lt;strong>这些小盒子构成了我们通常所说的栈区&lt;/strong>。关于栈区详细的讲解你可以参考《&lt;strong>深入理解操作系统：程序员应如何理解内存&lt;/strong>》一文。&lt;/p>
&lt;p>那么函数调用时都有哪些信息呢？&lt;/p>
&lt;p>&lt;strong>控制转移&lt;/strong>&lt;/p>
&lt;p>我们知道当函数 A 调用函数 B 的时候，控制从 A 转移到了 B，所谓控制其实就是指 CPU 执行属于哪个函数的机器指令，CPU 从开始执行属于函数 A 的指令切换到执行属于函数 B 的指令，我们就说控制从函数 A 转移到了函数 B。&lt;/p>
&lt;p>控制从函数 A 转移到函数 B，那么我们需要有这样两个信息：&lt;/p>
&lt;ul>
&lt;li>我从哪里来 (返回)&lt;/li>
&lt;li>要到去哪里 (跳转)&lt;/li>
&lt;/ul>
&lt;p>是不是很简单，就好比你出去旅游，你需要知道去哪里，还需要记住回家的路。&lt;/p>
&lt;p>函数调用也是同样的道理。&lt;/p>
&lt;p>当函数 A 调用函数 B 时，我们只要知道：&lt;/p>
&lt;ul>
&lt;li>函数 A 对于的机器指令执行到了哪里 (我从哪里来，返回)&lt;/li>
&lt;li>函数 B 第一条机器指令所在的地址 (要到哪里去，跳转)&lt;/li>
&lt;/ul>
&lt;p>有这两条信息就足以让 CPU 开始执行函数 B 对应的机器指令，当函数 B 执行完毕后跳转回函数 A。&lt;/p>
&lt;p>那么这些信息是怎么获取并保持的呢？&lt;/p>
&lt;p>现在我们就可以打开这个小盒子，看看是怎么使用的了。&lt;/p>
&lt;p>假设函数 A 调用函数 B，如图所示：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863830-03b8519b-e4cf-487c-ace0-4898c498f187.png" alt="">&lt;/p>
&lt;p>当前，CPU 执行函数 A 的机器指令，该指令的地址为 0x400564，接下来 CPU 将执行下一条机器指令也就是:&lt;/p>
&lt;pre>&lt;code>call 0x400540
&lt;/code>&lt;/pre>
&lt;p>1
Plain Text&lt;/p>
&lt;p>这条机器指令是什么意思呢？&lt;/p>
&lt;p>这条机器指令对应的就是我们在代码中所写的函数调用，注意 call 后有一条机器指令地址，注意观察上图你会看到，&lt;strong>该地址就是函数 B 的第一条机器指令&lt;/strong>，从这条机器指令后 CPU 将跳转到函数 B。&lt;/p>
&lt;p>现在我们已经解决了控制跳转的“要到哪里去”问题，当函数 B 执行完毕后怎么跳转回来呢？&lt;/p>
&lt;p>原来，call 指令除了给出跳转地址之外还有这样一个作用，也就是&lt;strong>把 call 指令的下一条指令的地址，也就是 0x40056a push 到函数 A 的栈帧中&lt;/strong>，如图所示：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863876-d1603ae8-ef26-4c08-9ac2-b726e0bcd29d.png" alt="">&lt;/p>
&lt;p>现在，函数 A 的小盒子变大了一些，因为装入了返回地址：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863851-cab15852-0eac-40e6-a7f5-4a90c7945322.png" alt="">&lt;/p>
&lt;p>现在 CPU 开始执行函数 B 对应的机器指令，注意观察，函数 B 也有一个属于自己的小盒子(栈帧)，可以往里面扔一些必要的信息。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863856-d73384c9-8f41-4d32-9b45-6444bb58fa6f.png" alt="">&lt;/p>
&lt;p>如果函数 B 中又调用了其它函数呢？&lt;/p>
&lt;p>道理和函数 A 调用函数 B 是一样的。&lt;/p>
&lt;p>让我们来看一下函数 B 最后一条机器指令 ret，这条机器指令的作用是告诉 CPU 跳转到函数 A 保存在栈帧上的返回地址，这样当函数 B 执行完毕后就可以跳转到函数 A 继续执行了。&lt;/p>
&lt;p>至此，我们解决了控制转移中“我从哪里来”的问题。&lt;/p>
&lt;p>&lt;strong>传递参数与获取返回值&lt;/strong>&lt;/p>
&lt;p>函数调用与返回使得我们可以编写函数，进行函数调用。但调用函数除了提供函数名称之外还需要传递参数以及获取返回值，那么这又是怎样实现的呢？&lt;/p>
&lt;p>在 x86-64 中，多数情况下参数的传递与获取返回值是通过&lt;strong>寄存器&lt;/strong>来实现的。&lt;/p>
&lt;p>假设函数 A 调用了函数 B，函数 A 将一些参数写入相应的寄存器，当 CPU 执行函数 B 时就可以从这些寄存器中获取参数了。&lt;/p>
&lt;p>同样的，函数 B 也可以将返回值写入寄存器，当函数 B 执行结束后函数 A 从该寄存器中就可以读取到返回值了。&lt;/p>
&lt;p>我们知道寄存器的数量是有限的，当传递的参数个数多于寄存器的数量该怎么办呢？&lt;/p>
&lt;p>这时那个属于函数的小盒子也就是栈帧又能发挥作用了。&lt;/p>
&lt;p>原来，当参数个数多于寄存器数量时剩下的参数直接放到栈帧中，这样被调函数就可以&lt;strong>从前一个函数的栈帧中获取到参数了&lt;/strong>。&lt;/p>
&lt;p>现在栈帧的样子又可以进一步丰富了，如图所示：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863886-677bf64d-2fed-494a-9752-f05d4c190543.png" alt="">&lt;/p>
&lt;p>从图中我们可以看到，调用函数 B 时有部分参数放到了函数 A 的栈帧中，同时函数 A 栈帧的顶部依然保存的是返回地址。&lt;/p>
&lt;p>&lt;strong>局部变量&lt;/strong>&lt;/p>
&lt;p>我们知道在函数内部定义的变量被称为局部变量，这些变量在函数运行时被放在了哪里呢？&lt;/p>
&lt;p>原来，这些变量同样可以放在寄存器中，但是当局部变量的数量超过寄存器的时候这些变量就必须放到栈帧中了。&lt;/p>
&lt;p>因此，我们的栈帧内容又一步丰富了。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863839-6619e28e-de13-488e-8a5e-cea1eac87441.png" alt="">&lt;/p>
&lt;p>细心的同学可能会有这样的疑问，我们知道寄存器是共享资源可以被所有函数使用，既然可以将函数 A 的局部变量写入寄存器，那么当函数 A 调用函数 B 时，函数 B 的局部变量也可以写到寄存器，这样的话当函数 B 执行完毕回到函数 A 时寄存器的值已经被函数 B 修改过了，这样会有问题吧。&lt;/p>
&lt;p>这样的确会有问题，因此我们在向寄存器中写入局部变量之前，&lt;strong>一定要先将寄存器中开始的值保存起来&lt;/strong>，当寄存器使用完毕后再恢复原值就可以了。&lt;/p>
&lt;p>那么我们要将寄存器中的原始值保存在哪里呢？&lt;/p>
&lt;p>有的同学可能已经猜到了，没错，依然是函数的栈帧中。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863856-bcf721f0-0db5-4faa-9eae-99683999d194.png" alt="">&lt;/p>
&lt;p>最终，我们的小盒子就变成了如图所示的样子，当寄存器使用完毕后根据栈帧中保存的初始值恢复其内容就可以了。&lt;/p>
&lt;p>现在你应该知道函数在运行时到底是什么样子了吧，以上就是问题 3 的答案。&lt;/p>
&lt;p>&lt;strong>Big Picture&lt;/strong>&lt;/p>
&lt;p>需要再次强调的一点就是，上述讨论的栈帧就位于我们常说的栈区。&lt;/p>
&lt;p>栈区，属于进程地址空间的一部分，如图所示，我们将栈区放大就是图左边的样子。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/wid7ue/1616167863877-0efea1a4-debc-473e-88a6-977d82c4969f.png" alt="">&lt;/p>
&lt;p>关于栈区详细的讲解你可以参考《&lt;strong>深入理解操作系统：程序员应如何理解内存&lt;/strong>》这篇。&lt;/p>
&lt;p>最后，让我们回到文章开始的这段简单代码：&lt;/p>
&lt;pre>&lt;code>void func(int a) {
if (a &amp;gt; 100000000) return;
int arr[100] = {0};
func(a + 1);
}
void main(){
func(0);
}
&lt;/code>&lt;/pre>
&lt;p>1
2
3
4
5
6
7
8
9
10
Plain Text&lt;/p>
&lt;p>想一想这段代码会有什么问题？&lt;/p>
&lt;p>原来，&lt;strong>栈区是有大小限制的&lt;/strong>，当超过限制后就会出现著名的&lt;strong>栈溢出&lt;/strong>问题，显然上述代码会导致这一问题的出现。&lt;/p>
&lt;p>因此：&lt;/p>
&lt;ol>
&lt;li>不要创建过大的局部变量&lt;/li>
&lt;li>函数栈帧，也就是调用层次不能太多&lt;/li>
&lt;/ol>
&lt;p>&lt;strong>总结&lt;/strong>&lt;/p>
&lt;p>本章我们从几个看似没什么关联的问题出发，详细讲解了函数运行时栈是怎么一回事，为什么我们不能创建过多的局部变量。细心的同学会发现第 2 个问题我们没有解答，这个问题的讲解放到下一篇，也就是协程中讲解。&lt;/p>
&lt;p>希望这篇文章能对大家理解函数运行时栈有所帮助。&lt;/p></description></item><item><title>Blog: 神秘！申请内存时底层发生了什么？</title><link>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A5%9E%E7%A7%98%E7%94%B3%E8%AF%B7%E5%86%85%E5%AD%98%E6%97%B6%E5%BA%95%E5%B1%82%E5%8F%91%E7%94%9F%E4%BA%86%E4%BB%80%E4%B9%88/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://desistdaydream.github.io/blog/copy/%E5%85%AC%E4%BC%97%E5%8F%B7%E7%A0%81%E5%86%9C%E7%9A%84%E8%8D%92%E5%B2%9B%E6%B1%82%E7%94%9F-%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E8%AF%9D%E9%A2%98%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0/%E7%A5%9E%E7%A7%98%E7%94%B3%E8%AF%B7%E5%86%85%E5%AD%98%E6%97%B6%E5%BA%95%E5%B1%82%E5%8F%91%E7%94%9F%E4%BA%86%E4%BB%80%E4%B9%88/</guid><description>
&lt;blockquote>
&lt;p>参考：&lt;a href="https://mp.weixin.qq.com/s/DN-ckM1YrPMeicN7P9FvXg">公众号,码农的荒岛求生&lt;/a>&lt;/p>
&lt;/blockquote>
&lt;p>内存的申请释放对程序员来说就像空气一样自然，你几乎不怎么能意识到，有时你意识不到的东西却无比重要，申请过这么多内存，&lt;strong>你知道申请内存时底层都发生什么了吗&lt;/strong>？&lt;/p>
&lt;p>大家都喜欢听故事，我们就从神话故事开始吧。&lt;/p>
&lt;h1 id="三界">三界&lt;a class="td-heading-self-link" href="#%e4%b8%89%e7%95%8c" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;p>中国古代的神话故事通常有 “三界” 之说，一般指的是天、地、人三界，天界是神仙所在的地方，凡人无法企及；人界说的是就是人间；地界说的是阎罗王所在的地方，孙悟空上天入地无所不能就是说可以在这三界自由出入。&lt;/p>
&lt;p>有的同学可能会问，这和计算机有什么关系呢？&lt;/p>
&lt;p>原来，我们的代码也是分三六九等的，程序运行起来后也是有 “三界” 之说的，程序运行起来的 “三界” 就是这样的：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>x86 CPU 提供了 “四界”：0,1,2,3，&lt;strong>这几个数字其实就是指 CPU 的几种工作状态&lt;/strong>，数字越小表示 CPU 的特权越大，0 号状态下 CPU 特权最大，可以执行任何指令，数字越大表示 CPU 特权越小，3 号状态下 CPU 特权最小，不能执行一些特权指令。&lt;/p>
&lt;p>一般情况下系统只使用 0 和 3，因此确切的说是 “两界”，这两界可不是说天、地，这两界指的是“用户态(3)” 以及“内核态(0)”，接下来我们看看什么是内核态、什么是用户态。&lt;/p>
&lt;h2 id="内核态">内核态&lt;a class="td-heading-self-link" href="#%e5%86%85%e6%a0%b8%e6%80%81" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>什么是内核态？当 CPU 执行操作系统代码时就处于内核态，&lt;strong>在内核态下 CPU 可以执行任何机器指令、访问所有地址空间、不受限制的访问任何硬件&lt;/strong>，可以简单的认为内核态就是 “天界”，在这里的代码(操作系统代码) 无所不能。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;h2 id="用户态">用户态&lt;a class="td-heading-self-link" href="#%e7%94%a8%e6%88%b7%e6%80%81" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>什么是用户态？当 CPU 执行我们写的 “普通” 代码 (非操作系统、驱动程序员) 时就处于用户态，粗糙的划分方法就是除了操作系统之外的代码，就像我们写的 HelloWorld 程序。&lt;/p>
&lt;p>用户态就好比 “人界”，在用户态我们的代码处处受限，不能直接访问硬件、不能访问特定地址空间，否则神仙(操作系统) 直接将你 kill 掉，这就是著名的 Segmentation fault、不能执行特权指令，等等。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>关于这一部分的详细讲解，请参见《&lt;a href="https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU2NTYyOTQ4OQ==&amp;amp;action=getalbum&amp;amp;album_id=1433368223499796481#wechat_redirect">深入理解操作系统&lt;/a>》系列文章。&lt;/p>
&lt;h2 id="跨界">跨界&lt;a class="td-heading-self-link" href="#%e8%b7%a8%e7%95%8c" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>孙悟空神通广大，一个跟斗就能从人间跑到天上去骂玉帝老儿，程序员就没有这个本领了。普通程序永远也去不了内核态，只能以通信的方式从用户态往内核态传递信息。&lt;/p>
&lt;p>操作系统为普通程序员留了一些特定的暗号，这些暗号就和普通函数一样，程序员通过调用这些暗号就能向操作系统请求服务了，这些像普通函数一样的暗号就被称为&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247483880&amp;amp;idx=1&amp;amp;sn=26ab417ffdd46b2956e5dc07516477af&amp;amp;chksm=fcb986b6cbce0fa0e0959341ec9c7a0c2db0acd9f5a1250e5cbe33306da2f10f1f3cd08152aa&amp;amp;scene=21#wechat_redirect">&lt;strong>系统调用&lt;/strong>&lt;/a>，System Call，通过系统调用我们可以让操作系统代替我们完成一些事情，像打开文件、网络通信等等。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>你可能有些疑惑，什么，还有系统调用这种东西，为什么我没调用过也可以打开文件、进行网络通信？&lt;/p>
&lt;h2 id="标准库">标准库&lt;a class="td-heading-self-link" href="#%e6%a0%87%e5%87%86%e5%ba%93" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>虽然我们可以通过系统让操作系统替我们完成一些特定任务，但这些系统调用都是和操作系统强相关的，Linux 和 Windows 的系统调用就完全不同。&lt;/p>
&lt;p>如果你直接使用系统调用的话，那么 Linux 版本的程序就没有办法在 Windows 上运行，因此我们需要某种标准，该标准对程序员屏蔽底层差异，这样程序员写的程序就无需修改的在不同操作系统上运行了。&lt;/p>
&lt;p>在 C 语言中，这就是所谓的&lt;strong>标准库&lt;/strong>。&lt;/p>
&lt;p>注意，标准库代码也是运行在用户态的，并不是神仙 (操作系统)，一般来说，我们调用标准库去打开文件、网络通信等等，标准库再根据操作系统选择对应的系统调用。&lt;/p>
&lt;p>从分层的角度看，我们的程序一般都是这样的汉堡包类型：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>最上层是应用程序，应用程序一般只和标准库打交道 (当然，我们也可以绕过标准库)，标准库通过系统调用和操作系统交互，操作系统管理底层硬件。&lt;/p>
&lt;p>&lt;strong>这就是为什么在 C 语言下同样的 open 函数既能在 Linux 下打开文件也能在 Windows 下打开文件的原因&lt;/strong>。&lt;/p>
&lt;p>说了这么多，这和 malloc 又有什么关系呢？&lt;/p>
&lt;h1 id="主角登场">主角登场&lt;a class="td-heading-self-link" href="#%e4%b8%bb%e8%a7%92%e7%99%bb%e5%9c%ba" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;p>原来，我们分配内存时使用的 malloc 函数其实不是实现在操作系统里的，而是在标准库中实现的。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>现在我们知道了，malloc 是标准库的一部分，当我们调用 malloc 时实际上是标准库在为我们申请内存。&lt;/p>
&lt;p>这里值得注意的是，我们平时在 C 语言中使用 malloc 只是内存分配器的一种，实际上有很多内存分配器，像 tcmalloc，jemalloc 等等，它们都有各自适用的场景，对于高性能程序来说使用满足特定要求的内存分配器是至关重要的。&lt;/p>
&lt;p>那么接下来的问题就是 malloc 又是怎么工作的呢？&lt;/p>
&lt;h2 id="malloc-是如何工作的">malloc 是如何工作的&lt;a class="td-heading-self-link" href="#malloc-%e6%98%af%e5%a6%82%e4%bd%95%e5%b7%a5%e4%bd%9c%e7%9a%84" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>实际上你可以把 malloc 的工作理解为去停车场找停车位，停车场就是一片 malloc 持有的内存，可用的停车位就是可供 malloc 支配的空闲内存，停在停车场占用的车位就是已经分配出去的内存，特殊点在于停在该停车场的车宽度大小不一，malloc 需要回答这样一个问题：当有一辆车来到停车场后该停到哪里？&lt;/p>
&lt;p>通过上面的类比你应该能大体理解工作原理了，具体分析详见《&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247485171&amp;amp;idx=1&amp;amp;sn=d93f2f5e9d61b00515c043776d2f7330&amp;amp;chksm=fcb981adcbce08bb39d120d7bfd097308371fb4b4e4369ba9502ae4e4243028b450bd0fe3110&amp;amp;scene=21#wechat_redirect">自己动手实现一个 malloc 内存分配器&lt;/a>》。&lt;/p>
&lt;p>但是，请注意，&lt;strong>上面这 **&lt;strong>篇文章并不是故事的全部&lt;/strong>，在这篇文章中有一个问题我们故意忽略了，这个问题就是&lt;/strong>如果内存分配器中的空闲内存块不够用了该怎么办呢 **？&lt;/p>
&lt;p>在上面这篇文章中我们总是假定自己实现的 malloc 总能找到一块空闲内存，但实际上并不是这样的。&lt;/p>
&lt;h2 id="内存不够该怎么办">内存不够该怎么办？&lt;a class="td-heading-self-link" href="#%e5%86%85%e5%ad%98%e4%b8%8d%e5%a4%9f%e8%af%a5%e6%80%8e%e4%b9%88%e5%8a%9e" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>让我们再来看一下程序在内存中是什么样的：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>我们已经知道了，malloc 管理的是堆区，注意，在堆区和栈区之间有一片空白区域，这片空白区域的目的是什么呢？&lt;/p>
&lt;p>原来，栈区其实是可以增长的，随着调用深度的增加，相应的栈区占用的内存也会增加，关于栈区这一主题，你可以参考《&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484963&amp;amp;idx=1&amp;amp;sn=542d3bec57c6a9dfc17c83005fd2c030&amp;amp;chksm=fcb9817dcbce086b10cb44cad7c9777b0088fb8d9d6baf71ae36a9b03e1f8ef5bec62b79d6f7&amp;amp;scene=21#wechat_redirect">函数运行时在内存中是什么样子&lt;/a>》这篇文章。&lt;/p>
&lt;p>栈区的增长就需要占用原来的空白区域。&lt;/p>
&lt;p>相应的，堆区也可以增长：&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>堆区增长后占用的内存就会变多，这就解决了内存分配器空闲内存不足的问题，那么很自然的，malloc 该怎样让堆区增长呢？&lt;/p>
&lt;p>原来 malloc 内存不足时要向操作系统申请内存，&lt;strong>操作系统才是真大佬&lt;/strong>，malloc 不过是小弟，对每个进程，操作系统 (类 Unix 系统) 都维护了一个叫做 brk 的变量，brk 发音 break，这个 brk 指向了堆区的顶部。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>将 brk 上移后堆区增大，那么我们该怎么样让堆区增大呢？&lt;/p>
&lt;p>这就涉及到我们刚提到的系统调用了。&lt;/p>
&lt;h2 id="向操作系统申请内存">向操作系统申请内存&lt;a class="td-heading-self-link" href="#%e5%90%91%e6%93%8d%e4%bd%9c%e7%b3%bb%e7%bb%9f%e7%94%b3%e8%af%b7%e5%86%85%e5%ad%98" aria-label="Heading self-link">&lt;/a>&lt;/h2>
&lt;p>操作系统专门提供了一个叫做 brk 的系统调用，还记得刚提到堆的顶部吧，这个 brk() 系统调用就是用来增加或者减小堆区的。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>实际上不只 brk 系统调用，sbr、mmap 系统调用也可以实现同样的目的，mmap 也更为灵活，但该函数并不是本文重点，就不在这里详细讨论了。&lt;/p>
&lt;p>现在我们知道了，如果 malloc 自己维护的内存空间不足将通过 brk 系统调用向操作系统申请内存。这样 malloc 就可以把这些从操作系统申请到的内存当做新的空闲内存块分配出去。&lt;/p>
&lt;h1 id="看起来已经讲完的故事">看起来已经讲完的故事&lt;a class="td-heading-self-link" href="#%e7%9c%8b%e8%b5%b7%e6%9d%a5%e5%b7%b2%e7%bb%8f%e8%ae%b2%e5%ae%8c%e7%9a%84%e6%95%85%e4%ba%8b" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;p>现在我就可以简单总结一下了，当我们申请内存时，经历这样几个步骤：&lt;/p>
&lt;ol>
&lt;li>程序调用 malloc 申请内存，注意 malloc 实现在标准库中&lt;/li>
&lt;li>malloc 开始搜索空闲内存块，如果能找到一块大小合适的就分配出去，前两个步骤都是发生在用户态&lt;/li>
&lt;li>如果 malloc 没有找到空闲内存块那么就像操作系统发出请求来增大堆区，这是通过系统调用 brk(sbrk、mmap 也可以) 实现的，注意，brk 是操作系统的一部分，因此当 brk 开始执行时，此时就进入内核态了。brk 增大进程的堆区后返回，malloc 的空闲内存块增加，此时 malloc 又一次能找到合适的空闲内存块然后分配出去。&lt;/li>
&lt;/ol>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>故事就到这里了吗？&lt;/p>
&lt;h1 id="冰山之下">冰山之下&lt;a class="td-heading-self-link" href="#%e5%86%b0%e5%b1%b1%e4%b9%8b%e4%b8%8b" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;p>实际上到目前为止，我们接触到的仅仅是冰山一角。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>我们看到的冰山是这样的：我们向 malloc 申请内存，malloc 内存不够时向操作系统申请内存，之后 malloc 找到一块空闲内存返回给调用者。&lt;/p>
&lt;p>但是，你知道吗，&lt;strong>上述过程根本就没有涉及到哪怕一丁点物理内存&lt;/strong>！！！&lt;/p>
&lt;p>我们确实向 malloc 申请到内存了，malloc 不够也确实从操作系统申请到内存了，但这些内存都不是真的物理内存，&lt;strong>NOT REAL&lt;/strong>。&lt;/p>
&lt;p>实际上，进程看到的内存都是假的，是操作系统给进程的一个幻象，这个幻象就是由著名的&lt;strong>虚拟内存&lt;/strong>系统来维护的，我们经常说的这张图就是进程的虚拟内存。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>所谓虚拟内存就是假的、不是真正的物理内存，虚拟内存是给进程用的，操作系统维护了虚拟内存到物理内存的映射，当 malloc 返回后，程序员申请到的内存就是虚拟内存。&lt;/p>
&lt;p>注意，&lt;strong>此时操作系统根本就没有真正的分配物理内存，程序员从 malloc 拿到的内存目前还只是一张空头支票&lt;/strong>。&lt;/p>
&lt;p>那么这张空头支票什么时候才能兑现呢？也就是什么时候操作系统才会真正的分配物理内存呢？&lt;/p>
&lt;p>答案是当我们真正使用这段内存时，当我们真正使用这段内存时，这时会产生一个缺页错误，操作系统捕捉到该错误后开始真正的分配物理内存，操作系统处理完该错误后我们的程序才能真正的读写这块内存。&lt;/p>
&lt;p>这里只是简略的提到了虚拟内存，实际上虚拟内存是当前操作系统内部极其重要的一部分，关于虚拟内存的工作原理将在《&lt;a href="https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU2NTYyOTQ4OQ==&amp;amp;action=getalbum&amp;amp;album_id=1433368223499796481#wechat_redirect">深入理解操作系统&lt;/a>》系列文章中详细讨论。&lt;/p>
&lt;h1 id="完整的故事">完整的故事&lt;a class="td-heading-self-link" href="#%e5%ae%8c%e6%95%b4%e7%9a%84%e6%95%85%e4%ba%8b" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;p>现在，这个故事就可以完整讲出来了，当我们调用 malloc 申请内存时：&lt;/p>
&lt;ol>
&lt;li>malloc 开始搜索空闲内存块，如果能找到一块大小合适的就分配出去&lt;/li>
&lt;li>如果 malloc 找不到一块合适的空闲内存，那么调用 brk 等系统调用扩大堆区从而获得更多的空闲内存&lt;/li>
&lt;li>malloc 调用 brk 后开始转入内核态，此时操作系统中的虚拟内存系统开始工作，扩大进程的堆区，注意额外扩大的这一部分内存仅仅是虚拟内存，操作系统并没有为此分配真正的物理内存&lt;/li>
&lt;li>brk 执行结束后返回到 malloc，从内核态切换到用户态，malloc 找到一块合适的空闲内存后返回&lt;/li>
&lt;li>程序员拿到新申请的内存，程序继续&lt;/li>
&lt;li>当有代码读写新申请的内存时系统内部出现缺页中断，此时再次由用户态切换到内核态，操作系统此时真正的分配物理内存，之后再次由内核态切换回用户态，程序继续。&lt;/li>
&lt;/ol>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>以上就是一次内存申请的完整过程，可以看到一次内存申请过程是非常复杂的。&lt;/p>
&lt;h1 id="总结">总结&lt;a class="td-heading-self-link" href="#%e6%80%bb%e7%bb%93" aria-label="Heading self-link">&lt;/a>&lt;/h1>
&lt;p>怎么样，程序员申请内存使用的 malloc 虽然表面看上去非常简单，简单到就一行代码，但这行代码背后是非常复杂的。&lt;/p>
&lt;p>有的同学可能会问，为什么我们要理解这背后的原理呢？理解了原理后我才能知道内存申请的复杂性，对于高性能程序来讲频繁的调用 malloc 对系统性能是有影响的，那么很自然的一个问题就是我们能否避免 malloc？&lt;/p>
&lt;p>这个问题我们将在接下来的文章中讲解。&lt;/p>
&lt;p>希望本篇对大家理解内存分配的底层原理有所帮助。&lt;/p>
&lt;p>最后的最后，如果觉得文章对你有帮助的话，请多多&lt;strong>分享&lt;/strong>、&lt;strong>转发&lt;/strong>、&lt;strong>在看&lt;/strong>。&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>**长按关注 ****码农的荒岛求生 **&lt;/p>
&lt;p>&lt;strong>往期精选&lt;/strong>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484768&amp;amp;idx=1&amp;amp;sn=049db350af9e5eea5cf3523ceb83f447&amp;amp;chksm=fcb9823ecbce0b28ca28d021e68c78138cde4a1b86ea7209c0c667d3d544d223d8b2aecbccec&amp;amp;scene=21#wechat_redirect">&lt;strong>看完这篇还不懂线程与线程池你来打我&lt;/strong>&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484788&amp;amp;idx=1&amp;amp;sn=e2a084694bedf9b148bbcd5570747add&amp;amp;chksm=fcb9822acbce0b3cba63913ff6de1e37c133b878f02035bc816f7f2ec8423d908bd8560d3605&amp;amp;scene=21#wechat_redirect">&lt;strong>读取文件时，程序经历了什么？&lt;/strong>&lt;/a>&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484825&amp;amp;idx=1&amp;amp;sn=0c2304dda01b698d2d461bd55185d9a2&amp;amp;chksm=fcb982c7cbce0bd1335595031ef2801cbae3b5fdbad67e9a0d953fa9337d5377aea22b069192&amp;amp;scene=21#wechat_redirect">一文彻底理解 I/O 多路复用&lt;/a>&lt;/strong>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484851&amp;amp;idx=1&amp;amp;sn=30d68a28f926b3e8b53f4d86e5630b60&amp;amp;chksm=fcb982edcbce0bfbb213afdb2f0996f11771b21b940b535171c5d974c6b0b882a9b8bb3ef192&amp;amp;scene=21#wechat_redirect">&lt;strong>从小白到高手，你需要理解同步与异步&lt;/strong>&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484916&amp;amp;idx=1&amp;amp;sn=6b19b4b3277ab0ecfffcf388a96f138a&amp;amp;chksm=fcb982aacbce0bbc5419c4329e160e3f9fce2103adaa3128e6f8138d9a8cd0e306fbe68f62f4&amp;amp;scene=21#wechat_redirect">&lt;strong>程序员应如何彻底理解回调函数&lt;/strong>&lt;/a>&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484933&amp;amp;idx=1&amp;amp;sn=c4112a54f5751f38e841baf3e3cc35bd&amp;amp;chksm=fcb9815bcbce084de2823467d3ba9d3e835663a6bb69df1fc7f71677aef099584f93b0e01809&amp;amp;scene=21#wechat_redirect">高性能高并发服务器是如何实现的&lt;/a>&lt;/strong>&lt;/p>
&lt;p>&lt;strong>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484963&amp;amp;idx=1&amp;amp;sn=542d3bec57c6a9dfc17c83005fd2c030&amp;amp;chksm=fcb9817dcbce086b10cb44cad7c9777b0088fb8d9d6baf71ae36a9b03e1f8ef5bec62b79d6f7&amp;amp;scene=21#wechat_redirect">函数运行时在内存中是什么样子&lt;/a>&lt;/strong>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247484986&amp;amp;idx=1&amp;amp;sn=80c673b4bb0ce7ae235db990ed6c2604&amp;amp;chksm=fcb98164cbce0872e0669f7299cd645146ad05837e4391c88554d18aea902334ee54a701945e&amp;amp;scene=21#wechat_redirect">&lt;strong>程序员应如何理解协程&lt;/strong>&lt;/a>&lt;/p>
&lt;p>*&lt;strong>*&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247485059&amp;amp;idx=1&amp;amp;sn=c798550fb3eda73c6f66440659bdcd8d&amp;amp;chksm=fcb981ddcbce08cb74b6ea9412720ce827231c2e67e57811dbfcaac78c0e7af55e0596b72a7f&amp;amp;scene=21#wechat_redirect">线程间到底共享了哪些进程资源？&lt;/a>**&lt;/strong>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247485094&amp;amp;idx=1&amp;amp;sn=317bb31042c4432652a555ad91223541&amp;amp;chksm=fcb981f8cbce08ee2b5d28faa5627ce8a1a8cf74f62c6b7c4e8db4ae3dd0f27b2796151a9272&amp;amp;scene=21#wechat_redirect">*&lt;strong>* 线程安全代码到底是怎么编写的？**&lt;/strong>&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ==&amp;amp;mid=2247485171&amp;amp;idx=1&amp;amp;sn=d93f2f5e9d61b00515c043776d2f7330&amp;amp;chksm=fcb981adcbce08bb39d120d7bfd097308371fb4b4e4369ba9502ae4e4243028b450bd0fe3110&amp;amp;scene=21#wechat_redirect">*&lt;strong>* 自己动手实现一个 malloc 内存分配器 **&lt;/strong>&lt;/a>&lt;/p>
&lt;p>&lt;img src="https://notes-learning.oss-cn-beijing.aliyuncs.com/3ee0c566-76fb-4b04-b794-ee46baf1d822/640" alt="">&lt;/p>
&lt;p>&lt;strong>码农的荒岛求生&lt;/strong>
&lt;a href="https://mp.weixin.qq.com/s/DN-ckM1YrPMeicN7P9FvXg">https://mp.weixin.qq.com/s/DN-ckM1YrPMeicN7P9FvXg&lt;/a>&lt;/p></description></item></channel></rss>