软件开发艰难攻克文章

凌晨三点，软件我盯着屏幕上那行红色的艰难报错信息，咖啡杯里映出自己发青的攻克脸。这已经是文章第七天了，那个诡异的软件并发问题像幽灵一样，只在生产环境出现，艰难本地测试永远复现不了。攻克

说实话，文章这种时刻我总会怀疑自己是软件不是入错行了。代码写了十二年，艰难按理说该见的攻克坑都见过了，可每次遇到这种“活见鬼”的文章bug，那种无力感还是软件像第一次面对空白的编辑器一样汹涌。

问题出在一个看似简单的艰难库存扣减接口上。用户下单时，攻克系统要检查库存、锁定库存、扣减库存，三个步骤必须原子性完成。但高并发下，偶尔会出现超卖——明明库存只剩一件，却有两三个订单同时成功。日志里看不出端倪，数据库记录也正常，可事实就摆在那里。

我试过加同步锁，性能直接掉了百分之八十，被运维同事骂得狗血淋头。试过用Redis分布式锁，可锁超时后依然有漏网之鱼。试过数据库乐观锁，版本号冲突时用户看到的是“购买失败”，体验糟糕透顶。

真正让我崩溃的是，隔壁团队用同样的方案，人家就没这问题。我翻遍他们的代码，甚至把每个变量的命名都对比过，就是找不到差异。那种感觉，就像考试时同桌交了一模一样的卷子，他满分，我零分，老师还说没判错。

转机出现在周四下午的代码走查。刚入职的小王指着我的事务注解说：“组长，这个REQUIRES_NEW是不是有问题？”我愣住了。那行代码是三个月前加的，当时为了处理一个边缘case，我特意让库存扣减在独立事务里执行。可我没意识到，这个注解会让锁的释放时机早于事务提交——也就是说，当第一个事务还在等待提交时，第二个事务已经拿到锁开始读库存了，读到的自然是旧值。

真相大白的那一刻，我靠在椅背上笑了半天。不是苦笑，是真的觉得好笑——我花了七天排查架构、网络、缓存，最后栽在自己随手加的一行注解上。这大概就是软件开发的残酷与迷人之处：它永远在提醒你，任何一行看似无关紧要的代码，都可能是压垮系统的最后一根稻草。

修复方案其实简单得可笑：把事务传播行为改成REQUIRED，让锁和事务同生共死。改完那行代码，我盯着屏幕看了十分钟，确认自己不是在做梦。上线后，超卖消失了，接口响应时间还快了百分之五。

事后复盘时，我写了篇很长的技术文档，但删掉了所有冠冕堂皇的总结，只留了一句话：“如果你觉得某个并发问题不可能发生，那一定是你对某个基础概念的理解还不够深。”这话很扎心，但真实。

现在每次带新人，我都会把这个故事讲给他们听。不是为了炫耀自己踩坑多，而是想让他们知道，软件开发里最难攻克的从来不是技术本身，而是那个总觉得自己“已经考虑周全”的傲慢念头。代码不会骗人，但人会——尤其是骗自己。

(责任编辑：休闲)