不用 unsafe ，怎么让 Go 程序 Segment Fault

公司一个 Go 服务 panic 了，与往常不一样的是，错误不是解空指针，而是 unexpected fault address —— 访问非法地址。

1
2
3
4
5
6
7
8
9
10
11
12
13

unexpected fault address 0x1a6d
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1a6d pc=0x1a6d]

goroutine 69514 gp=0xc000336fc0 m=4 mp=0xc000080008 [running]:
runtime.throw({0x53decb?, 0x10?})
	/usr/local/go/src/runtime/panic.go:1023 +0x5c fp=0xc00031e600 sp=0xc00031e5d0 pc=0x438c1c
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:895 +0x285 fp=0xc00031e660 sp=0xc00031e600 pc=0x44fce5
kkkiio.io/algo/fib.unwrap({0x5157a0?, 0xc0005a8990?})
	/home/kkkiio/projects/algo/fib/fib.go:62 +0x1e fp=0xc00031e670 sp=0xc00031e660 pc=0x505e3e
kkkiio.io/algo/fib.Await.func2()
	/home/kkkiio/projects/algo/fib/fib.go:47 +0x3a fp=0xc00031e6a8 sp=0xc00031e670 pc=0x505d5a

日志指出，panic 是因为调用了一个函数值。

1
2
3
4
5
6
7
8
9
10

func unwrap(susp any) any {
	for {
		switch value := susp.(type) {
		case func() any:
			susp = value() // <- runtime.sigpanic
		default:
			return value
		}
	}
}

调用函数导致 panic，这可能吗？

几年前进了一家 toB 软件公司，主要产品功能都跑在一个大单体 Go 服务里。

一天我们接到一个性能优化任务，客户要求在千万级数据量、50 并发下，接口 90 分位耗时保持 500ms 以下。

当时我只在 ToC 公司工作过，并不觉得这是一个很高的要求，直到去测试环境上体验，发现到处都是接口超时错误。

Most of the tests in the ‘IntelliJ Platform’ codebase are model-level functional tests.

The tests run in a headless environment that uses real production implementations for most components, except for many UI components.
…
In a product with 20+ years of a lifetime that has gone through many internal refactorings, we find that this benefit dramatically outweighs the downsides of slower test execution and more difficult debugging of failures compared to more isolated unit tests.

– JetBrains s.r.o.^[1]

我最近工作的后端项目很难在本地运行。

之前在电商公司做商品发货的业务，我们后台管理系统里订单查询页面，需要支持灵活、丰富的筛选条件，比如筛选出供应商 X 昨天发货的话费充值订单，还要按创建时间倒序分页。

2020 年末 React Blog 介绍了 Server Component，它是一种可以在服务端渲染的 React 组件。
它几乎跟普通组件一样，只是没有交互功能，所以你可以先在服务端渲染这些组件，然后在客户端继续渲染剩下的部分。

React Server Component 的目标是提高 Web 应用的性能，但这篇文章更想讨论它架构可能带来的开发便利。

我们知道线程会占用内存和 CPU 调度资源，发生泄露时，程序内存会升高，运行效率也会因为过多的线程切换（context switch）而降低，一般上千个线程就会导致性能明显下降。既然 goroutine 被称为“轻量级线程”，那在泄露数量高了几个数量级后，是不是也会导致类似的问题呢？最近我刚好在生产环境遇到了这个问题。

几周前面试遇到一道题：在一个预约业务里，展示顾客复购的情况，是典型的在几张业务表上聚合信息的需求。

用 SQL 可以很方便统计出我们需要的数据，但每次查询都要扫全表性能很差，加缓存又担心维护成本高。
对于比较固定的统计需求，物化视图(Materialized View)是一个低成本的方案。
它是指预计算结果到一张新表，缩短读路径，提高查询性能。

强韧和反脆弱性的系统不必像脆弱的系统一样，后者必须精确地理解这个世界，因而它们不需要预测，这让生活变得简单许多。

要看看冗余是一种多么缺乏预测性，或者更确切地说，预测性更低的行为模式，让我们借用一下第 2 章的说法：如果你把多余的现金存入银行（再加上储藏在地下室的贸易品，如猪肉和豆泥罐头，以及金条），你并不需要精确地知道哪些事件可能会陷你于困境。这些事件可能是一场战争、一场革命、一场地震、一次经济衰退、一场疫情、一次恐怖袭击，或者新泽西州的分裂等任何事情，但你并不需要作太多的预测。

《反脆弱》 — [美] 纳西姆·尼古拉斯·塔勒布

三个士兵在打完仗回家乡的途中，他们又累又饿。当他们看到不远处的村庄时，情绪高涨，希望村民们会好心给他们一些饭吃。但在到达了村庄后，他们发现所有的门窗都关紧了。多年战乱，村民们尝过食物短缺的苦后，都十分珍惜自己的食物。

饥肠辘辘的士兵们没有放弃，他们煮了一锅水，并小心翼翼地放了三个石头进去。好奇的村民们走过来围观。

“这叫石头汤”，士兵解释。”这些石头就能做汤？“村民们好奇。”当然可以，不过加一些胡萝卜会更鲜甜“。一个村民跑开了，没过一会带着胡萝卜回来了。

汤继续煮了几分钟，又有村民问道：“靠这些东西就能做汤？”。“嗯”，士兵回答，”如果有土豆会更好喝“。于是另一个村民跑回家里。

在接下来的一个小时，士兵们继续列了更多佐料：盐、胡椒、葱、牛肉。每次都有村民跑回家去拿自己的储藏。

最后，一锅热气腾腾的、美味的汤做好了，士兵们把石头去掉，跟村民一起分享了这锅汤，在场所有人都喝到了他们过去几个月内尝到过的最好的汤。

《The Pragmatic Programmer》第四章讲了石头汤的故事，让我想起之前一个工作经历，是关于优化代码的。