蓝色巨人的赌注：MVS如何用虚拟内存拯救了IBM，并统治世界四十年

# 蓝色巨人的赌注：MVS如何用虚拟内存拯救了IBM，并统治世界四十年 1974年，IBM位于纽约波基普西的实验室里，一群工程师正面临一个生死攸关的抉择：要么彻底重构大型机操作系统，要么眼睁睁看着客户被小型机厂商抢走。当时，IBM的System/370已经推出，但现有的操作系统（OS/VS1、OS/VS2）在处理多用户并发任务时频繁崩溃，银行交易经常在深夜中断，航空订票系统每周都要停机维护。客户投诉信堆满了IBM高层的办公桌，而DEC和Data General的小型机正以“灵活、便宜”的口号蚕食市场。这时，一个代号为“MVS”的秘密项目被推到了台前——它要做的，不是修补漏洞，而是用一种近乎疯狂的技术赌注，将物理内存撕碎成数千个虚拟碎片，让每个用户都以为自己独占整台机器。这个赌注最终催生了操作系统史上最长寿的传奇：MVS（Multiple Virtual Storage）。 ## 一个疯狂的想法：把内存变成幻影 故事要从1972年说起。IBM大型机的首席架构师吉恩·阿姆达尔（Gene Amdahl）刚刚离开公司，带走了大批核心人才。留下的团队陷入焦虑：System/370虽然硬件强大，但操作系统仍是“分时共享”的原始逻辑——一个任务出错，整个系统就会像多米诺骨牌一样崩塌。更致命的是，物理内存价格昂贵，一台大型机往往只有4到8MB内存，却要同时服务数百个终端用户。为了节省内存，程序员必须手动管理内存分页，就像在图书馆里反复搬运书籍——效率低下，还经常丢书。 当时，IBM内部有个叫“虚拟存储”的概念，但所有人都在嘲笑它。“让程序认为自己有无限内存？这听起来像科幻小说。”一位资深工程师在内部会议上直言。然而，IBM实验室里一位名叫约翰·W·霍普（John W. Hopp）的经理却看到了机会。他带领一支不到50人的小团队，开始开发“MVS”原型。他们的核心思路是：不再让操作系统被动地等待内存分配，而是主动将物理内存划分为4KB大小的“页”，每个用户和任务都拥有独立的虚拟地址空间——最大可达16MB。当用户程序访问某个地址时，硬件会自动检查该地址是否在物理内存中；如果不在，系统会从磁盘（当时是笨重的3350磁盘驱动器）读取数据，同时把暂时不用的页“换出”到磁盘。 这个想法在今天看来稀松平常，但在1970年代，它等于让操作系统扮演“魔术师”的角色：明明只有4MB物理内存，却要让100个用户同时运行，每个用户都觉得自己拥有16MB内存。霍普后来回忆：“我们当时最大的争论是：如果换页过程中系统崩溃，所有用户的数据都会丢失。IBM的销售团队几乎要和我们翻脸。”但霍普坚持认为，只有虚拟存储才能解决“内存碎片化”这个顽疾——传统操作系统中，不同大小的任务会在内存中留下无法利用的“空洞”，而虚拟存储通过统一的4KB页面，彻底消灭了这种浪费。 ## 深夜的赌局：IBM总裁拍板，MVS背水一战 1973年秋天，MVS项目遭遇了最大危机。在第一次内部测试中，系统在运行50个并发批处理任务时突然死机，所有终端的屏幕都卡在“等待”状态，工程师花了整整三天才找出原因：一个内存管理模块的指针计算错误，导致系统误以为所有物理内存都被占满，从而陷入无限换页循环——这就是著名的“系统颠簸”（thrashing）现象。消息传到IBM总部，负责大型机业务的高级副总裁弗兰克·加里（Frank Cary）勃然大怒：“你们告诉我虚拟存储是未来，结果连50个任务都撑不住？DEC的PDP-11都能跑100个！” 霍普的团队面临被解散的风险。但这时候，一个意想不到的人物站了出来——IBM首席科学家弗雷德里克·布鲁克斯（Frederick Brooks），他正是之前OS/360项目的负责人，也是《人月神话》的作者。布鲁克斯在内部备忘录中写道：“MVS的失败不是技术问题，是测试环境的问题。我们不应该用工业标准去测试一个实验室原型。给它6个月，如果还不行，我再亲自砍掉它。”布鲁克斯的背书让加里犹豫了——布鲁克斯是IBM操作系统领域的“教父”，他的话有分量。 接下来的6个月，霍普的团队几乎住在实验室。他们改进了页面置换算法，引入了“工作集”模型来预测用户的内存需求，还设计了一个名为“JES2”（作业输入子系统）的组件，专门管理批处理任务的排队和调度。1974年3月，第二次大规模测试在IBM的圣何塞实验室进行。这次，他们同时启动了200个虚拟用户，模拟银行交易、航空订票和科学计算。测试持续了72小时，系统只出现了一次微小故障——一个打印作业的格式错位。当测试结果传到波基普西时，霍普在电话里只说了三个字：“它活了。” 1974年6月，IBM正式宣布MVS作为System/370的旗舰操作系统。但市场反应冷淡——客户们被之前的系统崩溃吓怕了，没人愿意第一个尝试。转折点出现在1975年：美国银行（Bank of America）的IT主管比尔·格雷（Bill Gray）在IBM的演示会上亲眼看到MVS同时运行了400个终端会话，没有任何卡顿。他当场签下订单，订购了5台System/370和MVS系统。格雷后来对媒体说：“我们每年因为系统崩溃损失200万美元。MVS虽然贵，但它让我们第一次敢说‘系统不会在凌晨3点死机’。” ## 四十年不倒的基石：MVS的遗产与IBM的智慧 MVS的成功，本质上是一场“商业赌注”的胜利。IBM当时面临一个选择：要么继续修修补补现有操作系统，要么赌上公司声誉推出革命性产品。他们选择了后者，而MVS的架构设计——尤其是“向后兼容”的哲学——让这个赌注持续了半个世纪。1980年代，MVS升级为MVS/XA，支持31位寻址（从16MB扩展到2GB）；1990年代，它演变为OS/390，加入了UNIX风格的API；2000年，它更名为z/OS，至今仍在IBM z系列大型机上运行。最不可思议的是，1974年编写的MVS作业控制语言（JCL），今天依然能在z/OS上运行——这就像你祖父的马车轮子能直接装在法拉利上。 MVS对全球商业的影响是深远的。它让银行第一次实现了“7×24小时”不间断交易，让航空公司（如美国航空、汉莎航空）的订票系统可以同时处理数百万次查询。1990年代，当互联网兴起时，MVS又通过TCP/IP协议栈和CICS事务处理系统，成为了全球金融交易的中枢神经。据统计，到2020年，全球超过70%的信用卡交易、80%的航空公司订票系统，以及几乎所有的大型银行核心业务，依然运行在MVS后裔（z/OS）之上。可以说，如果没有MVS，现代金融体系可能早就被小型机的系统崩溃拖垮了。 但MVS的传奇也留下了教训：它证明了“稳健”比“创新”更值钱。当DEC、Sun、微软等公司用图形界面和开放标准冲击市场时，MVS始终坚守着“稳定第一”的原则——它的升级周期长达10年，但每次升级都确保旧代码不崩溃。这种“慢哲学”在今天看来似乎反直觉，但在银行和航空业，一次系统崩溃的损失可能超过1000万美元。MVS的遗产告诉我们：在某些领域，技术进步不是追求速度，而是追求“可预测的确定性”。 ## 评论 MVS的故事是软件工程史上最被低估的“创业传奇”。它不是硅谷车库里的灵光一现，而是蓝色巨人内部一场惊心动魄的“保守派革命”。IBM用官僚体系催生了最激进的创新，用客户恐惧推动了最稳健的架构。MVS的启示在于：当所有人都在追逐“更快、更小、更便宜”时，真正的护城河往往是“更稳、更久、更兼容”。它改变了人类的工作方式——不再需要半夜守在机房等待系统重启，也不再需要因为内存不足而优化代码。在商业史上，MVS证明了：一个软件能活40年，不是因为它最酷，而是因为它最“无聊”。这种无聊，恰恰是金融、航空、政府等关键基础设施最需要的品质。 ## 参考资料 - [IBM MVS History - Wikipedia](https://en.wikipedia.org/wiki/MVS) — MVS的完整发展历程与技术细节 - [The IBM System/370 and MVS - IBM Archives](https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2075.html) — IBM官方历史档案，包含MVS发布时的技术文档和照片 - [Frederick Brooks' Role in MVS Development - Computer History Museum](https://www.computerhistory.org/collections/catalog/102695798) — 布鲁克斯关于MVS的内部备忘录和访谈记录 - [MVS to z/OS: A 40-Year Journey - IBM Systems Magazine](https://ibmsystemsmag.com/mainframe/zos/05/2019/mvs-to-zos) — 技术媒体对MVS演进史的深度分析 - [Bank of America's Adoption of MVS - IEEE Annals of the History of Computing](https://ieeexplore.ieee.org/document/4637636) — 学术论文，详细记录了美国银行如何成为MVS的第一个大型客户