我写了一个死循环Java 却偷偷算出了正确答案一次误打误撞的隐藏 bug调查两段螺旋矩阵代码输出一模一样一个跑 0.4 秒一个跑 1.7 秒。我以为发现了 Java 的 bug追了 21 亿次循环后真相让我后背发凉——这让我想起那款让全世界玩家等了十年的游戏。一、诡异的开场n1 明明该死循环输出却是对的事情要从一道经典题说起——顺时针螺旋矩阵。输入一个 n输出一个 n×n 的矩阵数字从 1 到 n² 按顺时针螺旋排列。比如 n31 2 3 8 9 4 7 6 5我写了一版就叫它版本 A核心循环长这样// luoxuan1.java —— 版本 A严格不等号while(cmax){for(;qrightcmax;q){data[l][q]c;c;}top;for(;lbottomcmax;l){data[l][q]c;c;}bottom--;for(;qleftcmax;q--){data[l][q]c;c;}left;for(;ltopcmax;l--){data[l][q]c;}right--;}室友写了另一版版本 B// luoxuan2.java —— 版本 B含端点while(cmax){for(qleft;qrightcmax;q)data[top][q]c;top;for(ltop;lbottomcmax;l)data[l][right]c;right--;for(qright;qleftcmax;q--)data[bottom][q]c;bottom--;for(lbottom;ltopcmax;l--)data[l][left]c;left;}两版跑 n2、n3、n5输出完全一致。直到我随手测了一下n1。按我的直觉版本 A 在 n1 时必死无疑topbottomleftright0lq0c1max1第一条边qright→00假第二条边lbottom→00假第三条边qleft→00假第四条边ltop→00假四个 for 一次都不进c永远是 1while(cmax)永远退不出来——标准死循环。可我一运行屏幕上干干净净地打出了1程序不仅没卡死还输出了正确答案。我盯着屏幕看了三秒第一反应是我是不是发现 Java 的隐藏 bug 了二、第一个线索它对得太慢了正常人看到 n1 输出正确可能就划走了。但我注意到一个不对劲的细节——程序卡了将近两秒才出结果。n1 啊就一个格子正常应该是毫秒级瞬出。这两秒它在干嘛我给两个版本分别计时版本n1 耗时版本 B正确写法约 0.39 秒基本是 JVM 启动时间版本 A“误打误撞”版约 1.73 秒更诡异的是版本 A 跑 n1、n2、n5耗时几乎一模一样都在 1.7 秒左右。一个 O(n²) 的算法耗时居然和 n 无关这说明无论 n 是多少程序最后都在做同一件固定开销巨大的事。我在 while 循环里塞了一个计数器跑出了让我瞳孔地震的数字正常退出! while迭代次数2147483648 data[0][0]12147483648 次。也就是 2³¹正好比Integer.MAX_VALUE2147483647多 1。一个 n1 的程序while 循环转了 21 亿圈。联想到GTA5 加载了十年的秘密看到这个数字我第一反应不是我的代码有 bug而是想起了GTA5。很多人不知道GTA5 Online 的加载画面曾经让全世界玩家等了快十年。每次进游戏进度条要磨好几分钟。玩家们骂 R星优化烂、骂自己电脑差、骂游戏文件太大——直到 2021 年一个网名叫t0st的逆向工程师把加载程序扒开真相才浮出水面加载慢根本不是因为游戏大而是因为代码在重复做无用功。一个约 10MB 的 JSON 配置文件解析函数在循环里每次都重新扫描整个字符串长度硬生生把 O(n) 写成了 O(n²)光这一项就吃掉约两分钟游戏物品去重不用哈希表用线性查找逐条比对又是一个 O(n²)再吃掉约一分钟。t0st 写了个补丁加载时间从约6 分钟直接砍到 1 分多钟。后来 R星在官方更新里修复了这个 bug还破例给了他1 万美元奖金——尽管这根本不在他们的漏洞赏金计划里。一个卖了几亿份的游戏一个全世界玩家每天都在经历的慢藏了快十年才被发现。原因和我的螺旋矩阵一模一样功能是正常的——能进游戏能玩能联机没人觉得不对只有当有人较真想弄明白它为什么这么慢时底下的 O(n²) 空转才浮出水面。我的 n1 程序空转 21 亿次和 GTA5 加载时重复扫描字符串本质上是同一种 bug输出正确所以没人怀疑只有耗时出卖了它。三、追凶21 亿圈里到底发生了什么我把每一轮的变量都打印出来真相浮出水面。n1 时四个 for 确实一次都没执行——data[0][0]从头到尾没被赋值c一直是 1。但是while 循环体里这四行代码是无条件执行的top;// 每轮 1bottom--;// 每轮 -1left;// 每轮 1right--;// 每轮 -1for 不干活这四个边界变量却在每轮疯狂自增自减。于是top: 0 → 1 → 2 → … → 2147483647 → ??? bottom: 0 → -1 → -2 → … → -2147483647 → ???top一路加到Integer.MAX_VALUE再加一次——int 溢出了。Java 的 int 是 32 位有符号整数用二进制补码表示。2147483647 1不会报错而是回绕成-2147483648Integer.MIN_VALUE。就在top溢出成-2147483648的这一轮第四条边的条件突然变了for(;ltopcmax;l--)// 0 -2147483648 → 真// 1 1 → 真边4 被激活了它执行了一次data[l][q]c;// data[0][0] 1然后 c 变成 2紧接着下一次判断cmax变成了21为假边4 停止。while 再判断cmax21为假循环终于退出。然后打印data[0][0]——正好是 1。四、最恐怖的地方它为什么“恰好”正确你可能觉得这只是个巧合。但仔细想这个巧合精准到令人发指位置对空转期间l和q从来没变过一直停在(0,0)——也就是唯一没被填的那个格子。溢出激活的边 4正好作用在(l,q)(0,0)上。数值对c一直停在 1正好是这个格子该填的数。只填一次填完c变成 2立刻超过max1循环干净利落地退出不多填一格。n2、n3、n5 也是同一个剧本版本 A 能填好外圈大部分格子但最后总会剩一个格子填不到然后空转 21 亿次靠 int 溢出把最后那格补上。因为l、q、c恰好停在“最后一格该有的状态”所以结果永远正确。这不是算法在工作这是整数溢出在替算法擦屁股。五、反转这不是 Java 的 bug是 Java 的“特性”追到这里我最初“发现 Java 隐藏 bug”的兴奋劲儿没了——因为这恰恰是 Java明确定义的行为。Java 语言规范JLS规定整数运算溢出时结果按二进制补码回绕不抛异常不报错。这是 Java 从第一天起就写进规范的设计目的是让整数运算行为可预测、跨平台一致。所以版本 A 能“正常输出”靠的不是 bug而是代码逻辑写错了严格不等号导致最后一格填不到while 退不出来本该死循环但边界变量持续自增触发了 Java 明确定义的 int 溢出回绕溢出后某条边条件意外成立补上了最后一格程序看起来正确一个写错的程序被语言的溢出定义给“救活”了。这才是真正细思极恐的地方如果 Java 像 Python 一样整数无界或者像某些语言一样溢出抛异常版本 A 就是一个彻头彻尾的死循环。但因为 Java 选择了“静默回绕”这个 bug 被藏得严严实实——输出全对测试全过只有耗时暴露了它。而如果把这段代码翻译成 C/C有符号整数溢出是未定义行为UB编译器可能优化掉空转、可能真死循环、也可能崩溃——结果完全不可预测。六、两版代码的本质差异回头看这两段几乎一样的代码差别只有几个符号对比项版本 Aluoxuan1版本 Bluoxuan2边条件qright/lbottom/qleft/ltop严格不等qright/lbottom/qleft/ltop含端点for 初始化for(;条件;…)复用外层l,qfor(qleft;…)每条边重置起点n1 行为空转 21 亿次后靠溢出补格第一条边直接填好耗时~1.7 秒与 n 无关~0.4 秒含 JVM 启动正确性输出正确但依赖溢出副作用逻辑正确名副其实可移植性换 C/C 可能 UB任何语言都成立版本 B 才是螺旋矩阵的标准写法每条边包含端点走完一条边立刻收缩对应边界下一条边从新边界起步。n1 时第一条边q从left0走到right0直接把data[0][0]填成 1干净利落。而版本 A 的“严格不等号 复用 l,q”写法本质上是想让每条边走到倒数第二个就停靠下一条边来接角点——这种写法在螺旋收缩到最后一格时没有任何一条边的条件能覆盖它于是留下了一个永远填不到的洞。七、这个故事给我们的三个教训1. 输出正确 ≠ 程序正确。版本 A 所有测试用例都过但它是错的。GTA5 能进游戏、能联机但加载代码是错的。判断程序对不对不能只看输出还要看它“怎么做到的”。耗时、资源、边界行为都是线索。2. 整数溢出是静默的杀手。Java 的溢出不报错、不提醒悄悄回绕。如果你在写金融、计数、索引相关的代码一个溢出可能让条件判断悄悄翻转产生极其隐蔽的 bug。关键路径上考虑用Math.addExact()等会抛异常的方法或者用long。3. “能跑”是最低标准“为什么能跑”才是工程师的修养。一个 n1 耗时 1.7 秒的程序很多人会视而不见一个加载 6 分钟的游戏玩家会骂电脑差而不是查代码。但正是这多出来的时间牵出了 21 亿次空转和一个藏了十年的 O(n²)。对异常保持敏感是排查深层 bug 的第一步。八、写在最后我最终没有发现 Java 的隐藏 bug却发现了一个更有意思的东西一段错误的代码在一种明确定义的语言行为下伪装成了正确答案。它提醒我编程世界里最危险的 bug从来不是那些一跑就崩的——而是那些输出全对、测试全绿、却在底层偷偷做着 21 亿次无用功的。就像 GTA5 的加载条转了快十年没人知道它在重复扫描同一串字符。下次你的程序莫名其妙就对了或者莫名其妙就是慢别急着换电脑、别怪语言、别骂优化烂。也许它只是还没溢出而已。附录两版完整代码版本 Aluoxuan1.java严格不等号靠 int 溢出“误打误撞”packagejava_demo;importjava.util.Scanner;publicclassproject1{publicstaticvoidmain(String[]args){ScannerscnewScanner(System.in);intnsc.nextInt();if(n1n31){int[][]datanewint[n][n];intmaxn*n;inttop,bottom,left,right;top0;bottomn-1;left0;rightn-1;intl,q;lq0;intc1;while(cmax){for(;qrightcmax;q){data[l][q]c;c;}top;for(;lbottomcmax;l){data[l][q]c;c;}bottom--;for(;qleftcmax;q--){data[l][q]c;c;}left;for(;ltopcmax;l--){data[l][q]c;}right--;}for(inti0;in;i){for(intj0;jn;j){System.out.printf(%4d,data[i][j]);}System.out.println();}}sc.close();}}版本 Bluoxuan2.java含端点标准正确写法packagejava_demo;importjava.util.Scanner;publicclassproject1{publicstaticvoidmain(String[]args){ScannerscnewScanner(System.in);intnsc.nextInt();if(n1n31){int[][]datanewint[n][n];intmaxn*n;inttop,bottom,left,right;top0;bottomn-1;left0;rightn-1;intl,q;lq0;intc1;while(cmax){for(qleft;qrightcmax;q)data[top][q]c;top;for(ltop;lbottomcmax;l)data[l][right]c;right--;for(qright;qleftcmax;q--)data[bottom][q]c;bottom--;for(lbottom;ltopcmax;l--)data[l][left]c;left;}for(inti0;in;i){for(intj0;jn;j){System.out.printf(%4d,data[i][j]);}System.out.println();}}sc.close();}}建议在版本 A 的 while 里加一个迭代计数器亲眼见证 2147483648 这个数字。
