编程与软件工程canonical.org
编程语言背后的内存模型
The Memory Models That Underlie Programming Languages
2016 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章系统梳理了各种编程语言背后的“内存模型”——即语言向程序员提供的内存组织与访问的概念模型，如数组、链表、GC 堆、Actor 隔离、Rust 所有权等，并分析各自的设计取舍。作者从打孔卡一路讲到现代语言，展示内存模型如何决定语言的表达能力。
为什么经久不衰：它把散落在各语言中的内存设计选择统一成一张概念地图，多年间三次登上 HN 首页，至今仍是理解语言设计取舍的绝佳入门读物。
HN 评论精选
Rust 的 zip 恰好解决了文中指出的并行数组索引无法校验的问题
写得非常好。文中讨论并行数组时提到编译器无法判断某个索引对哪些数组有效——在 Rust 里我很喜欢 Iterator 的 zip 函数，它确实能防止跨并行数组的索引问题。在数据库场景中把数据选成有序数组能大幅提速，Java 里没有索引越界保护，而 Rust 可以 zip 起来不用担心访问越界。
bluejekyll查看英文原文
Excellently written. One thing that jumped out at me is this in the discussion of the parallel arrays: > The compiler can’t tell which arrays a given index is or isn’t valid for, and neither can the debugger or garbage collector... (I know people are getting tired of hearing about the awesomeness of this but) in Rust I have grown very fond of the 'zip' function on 'Iterator', which actually does guard against index issues across the parallel arrays/iterators. This is a big deal to me, because to speed up access of datasets across databases or tables or partitions; selecting out ordered arrays of data could often speed up access in the DB by magnitudes. In Java there was no guard against an index violation, and there's not simple way to create a merged view of the returned parallel arrays. But in Rust you can zip them all together and not worry about access violations (though you should still probably detect them so that you know you don't have any data gaps). This was a great article. And made me start thinking of immutable memory in a different way when you consider punch cards!
质疑文中对早期 Lisp GC 开销的估计过于夸大
文章很美，但并非全部属实。分代 GC 出现之前的 Lisp 大约 5% 的时间花在 GC 上，个别糟糕情况到 10%。这固然不理想，但远不是文中说的“通常三分之一到一半的时间在跑垃圾回收”。我见过很长的 GC，甚至 15 分钟的，但从没见过 GC 吃掉三分之一的处理器周期。
simonbrooke查看英文原文
This is a beautiful essay, and I've really enjoyed it. However, while interesting and inspirational it doesn't all ring true. Lisps from the years before generational garbage collection might spend five percent of their time in GC; in particularly awkward cases it might rise to ten percent. I'm not saying this was desirable: it was not, particularly in interactive processes. But it was nothing like 'usually spent between a third and half of their time running the garbage collector'. I've seen some very long GCs indeed. I'm sure I've seen fifteen minute GCs. But I've never seen GC eat a third of the processor cycles. I don't believe it.
Erlang 实际上有内外两层内存模型，文中只涉及了 Actor 内部那层
关于 Erlang 的内存模型：Erlang 有两种内存模型，因为它有两种范式。Actor 内部是图内存模型（顺序部分可以用任何语言/模型写）；Actor 之外是 actor 的非图社会，更接近通用系统架构，很少被谈论，这大概解释了为什么很难找到它的内存模型描述。
di4na查看英文原文
About Erlang memory model : The answer is that Erlang has two different memory models, because it has two paradigms. Inside an Actor, you are running whatever you want. That sequential part of erlang has a graph memory model, but you could write it in any other language and model, as soon as you write an Actor. Outside an Actor, you are in the non graph society of actors. And this one is closer to general system architecture, and is rarely talked about. Which probably explain why it is rare to find a memory model of it.
提醒读者“内存模型”一词还指硬件层面的多核缓存一致性，与文中概念模型含义不同
“内存模型”还有第三种含义：多核 CPU 上操作之间的干扰，由复杂度不一的缓存系统调解。Java 最初的内存模型是第一个形式化的，结果在真实机器上不可实现，之后是 C++、C。真实多核机器分化为两种缓存一致性模型：宽容的 x86/Apple M1 阵营和较严格的非 Apple ARM/Power 阵营。程序常在无意中依赖 x86/M1 模型，而 Rust（不用 unsafe 时）在两边都能正常工作。
ncmncm查看英文原文
"Memory model" has yet a third meaning, referring to interference between operations in multiple CPU cores, and mediated by variously-shared parts of cache systems of varying complexity. Here, complexity of the memory model is traded off against complexity of the primitives to manage the interference, (compare-and-set, load-locked/store conditional, etc.) and with the complexity of the cache system. Java's original memory model, perhaps the first formally specified, turned out to be unimplementable on common actual machines. The next language to get a formal memory model was C++, followed shortly by C and then others. Real multicore machines have sorted themselves out into two models of cache coherency; one more forgiving represented by mainstream x86 and now Apple M1, relying on deeply complex cache designs, and the other by the remaining lottery survivors, non-Apple ARM, and Power. The various RISC-V implementations will probably straddle the divide, like ARM/ARM-M1. Java, C++, and C can with some discipine be coded to work transparently on either, but very often programs accidentally depend on the x86/Apple model, never having been tested beyond it. Rust, absent "unsafe", is happy on either. The Linux kernel works on either, and once supported other more exotic variations.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选