我看过登陆火星的操作系统

2026 年 6 月 12 日，SpaceX 成功上市。

埃隆·马斯克成为人类历史上第一个万亿富豪。他的终极愿景，是让人类成为跨行星物种，最终移民火星。

我没有去过火星。按照我目前的年龄、身体状况以及资产负债表来综合评估，这辈子大概率是没机会去了。

但我看过登陆火星的操作系统。

更准确地说，我不但看过，还用过。

一台几十万美元的基站

刚进入北电时，新员工培训有一门课讲 RTOS，也就是实时操作系统。当时我对自己的操作系统知识颇有信心，并没有把这门课放在心上。

没过多久，我接到一个任务：需要在某款基站设备上做测试。

测试需要设备反复重启。几次之后，我面前那块远程连接着实验室的黑色控制台终端，突然停止了输出——基站连不上了。周围的办公室依然平静，但我反复敲击键盘，终端始终没有给出任何响应。那一刻，我有点慌了，转过头，硬着头皮问旁边的同事：这台设备大概要多少钱？

同事淡淡地说：“几十万美元吧。”

我表面上点了点头，心里已经开始盘算，按当时的月薪自己要不吃不喝工作多少年才赔得起。幸运的是，过了好一阵子，设备在漫长的自检后终于恢复了通信。

但这次虚惊动摇了我的盲目自信。为了彻底搞懂这台设备，我决定从操作系统入手。

我重新翻开那门没有被我放在心上的讲义，开始认真研究 RTOS 和 VxWorks。也就是在这个过程中，我发现了一个让我非常意外的事实：我们基站里使用的这个操作系统，竟然登陆过火星。

登陆火星的 VxWorks

1997 年 7 月 4 日，美国宇航局（NASA）的“火星探路者号”（Mars Pathfinder）成功登陆火星。

运行在探路者号着陆器上的操作系统，正是 VxWorks。

很多年后，在电影《火星救援》中，被独自留在火星上的宇航员马克·沃特尼为了重新与地球取得联系，长途跋涉挖出了早已停止工作的火星探路者号。当他擦去尘土，重新接通电源，最终利用它与 NASA 重新建立通信时，别人看到的是一个宇航员在火星上艰难求生，我看到的却是，“这系统，我熟啊。”

虽然电影里的主角身处火星，而我面对的只是办公室里的终端屏幕，但他面前那台设备运行的，正是和我当年使用过的同一款操作系统。

这让当时初出茅庐的我，顿时觉得自己的工作高级了不少。

毕竟，同样一行代码，运行在普通家用电脑上叫程序；运行在遥远的火星上，就叫人类文明。

火星上的第一个 Bug

VxWorks 是一款 RTOS，也就是实时操作系统。

⚙️ 技术备注：什么是 RTOS？ 实时操作系统（Real-Time Operating System）。它的特征不只是“快”，而是“确定性”——必须保证关键任务在规定时间内作出响应，不能出现不可控的延迟。

实时系统界有一句名言：A late response is a wrong response.（迟到的响应，就是错误的响应。）

网页晚一秒打开，最多让人有些不耐烦，但对基站、工业设备或航天器来说，一个结果即便数学上绝对正确，只要来得太晚，就毫无意义。导弹已经飞过去了，你才算出了最精准的拦截轨迹，这只适合写进事故报告。

为了保证大事不被耽误，系统会给不同任务划分明确的优先级。高优先级任务一旦需要运行，低优先级任务就必须让路。这套规则看似严密且符合直觉：越重要，越优先。

然而，探路者号登陆火星后不久，系统开始间歇性重启，导致当天的观测计划全部瘫痪。工程师最终发现，问题恰恰出在这套看似完美的机制上——在某种极端场景下，一个优先级很低的任务，竟然间接阻塞了最重要的核心任务。

在计算机科学中，这被称为“优先级倒转”。

⚙️ 技术备注：什么是优先级倒转（Priority Inversion）？ 简单来说，就是最高领导急等一份核心材料，负责写材料的基层员工刚要动笔，却被几个中层经理轮番拉去开一些无关紧要的业务会。基层员工脱不开身，中层经理们忙得热火朝天，而最高领导只能干等着。 在系统底层，表现为低优先级任务占用了共享资源（锁），导致高优先级任务挂起等待；此时若干个中等优先级任务不断抢占 CPU，使得低优先级任务无法释放资源，间接长期阻塞了高优先级任务。

宇宙的尽头，果然连操作系统也逃不过尴尬的组织管理问题。由于关键任务在限定时间内交不出差，系统的自我保护机制判定自己发生了严重故障，于是触发系统重启。

在火星上补完的一课

解决办法其实很直接。最高领导只需要向所有人宣告：这位基层员工现在手上的工作优先级最高，谁都不准打断他。等他把材料交差之后，再恢复原来的级别。

在技术上，这叫作“优先级继承”。

⚙️ 技术备注：什么是优先级继承（Priority Inheritance）？ 当高优先级任务因为等待共享资源而被阻塞时，系统临时将持有该资源的低优先级任务的优先级，提升到与高优先级任务相同的级别，确保其不被中等优先级任务打断，得以迅速释放资源。

当时的 VxWorks 已经具备这套机制，只是探路者号使用的那段系统服务没有启用它。

NASA 的工程师在地球实验室复现故障、定位原因，再通过深空网络向探路者号上传软件补丁，启用了优先级继承。此后，由这个问题引发的间歇性重启没有再出现。

让我意外的是，这个问题竟然是在探路者号登陆火星之后，才被最终定位和修复的。

在当时的我想象中，能够送上火星的设备，一定在实验室里经历过穷尽一切可能的极限测试。毕竟设备到了火星，不可能派人飞过去手动重启。但事实是，再严苛的测试也无法穷尽复杂系统的所有真实场景。

正如探路者号软件团队负责人 Glenn E. Reeves 后来在总结这次故障时所说：

“Even when you think you’ve tested everything that you can possibly imagine, you’re wrong.” （即使你以为自己已经测试了能想象到的所有情况，你依然会出错。）

优先级倒转并不是没人知道，解决办法也早已存在。但理论、系统与真实运行场景之间的最后一个缺口，直到火星上才真正暴露出来。

不再仰望

探路者号上的这个 Bug，也让我对那些所谓“顶级技术”有了新的认识。

回看刚进公司那会儿的自己，不过是一个没见过复杂商用系统的应届毕业生。嘴上带着年轻人的技术傲气，内心深处其实写满了对“电信级”“航天级”系统的敬畏。一台几十万美元的基站暂时连不上，就能让我心惊肉跳几天。

可当我真正一层层理解 RTOS 和 VxWorks，也看懂探路者号上的问题之后，我发现所谓登陆火星的航天系统，也不是什么无法理解的神迹。它同样由最基础的任务、队列、消息和调度构成；它同样会出现 Bug，甚至有些问题，要等到真正运行在火星上才会完全暴露。

就在那一刻，我心里突然萌生出一个多少有点年少轻狂的想法：

连登陆火星的操作系统我都看懂了，这世界上还有什么技术是学不会的？

看懂 VxWorks，当然不等于能去造火箭。但对当时缩在格子间里的年轻工程师来说，这种“膨胀”完成了一次重要的祛魅。它让我第一次明白：

技术可以复杂，但不必神秘；应当保持敬畏，但无需盲目仰望。

后来，我还成了这门 RTOS 课程的内部讲师。

再往后，很多年过去了，我已经记不清当年那台基站究竟为什么断连。

但我始终记得，当我真正看懂 VxWorks 的那一刻，火星似乎没有以前那么远了。