为什么你的代码又慢又烂？因为你只在乎“功能实现”

最新推荐文章于 2025-08-25 14:23:10 发布

CV大魔王

最新推荐文章于 2025-08-25 14:23:10 发布

阅读量1.7k

点赞数 52

CC 4.0 BY-SA版权

分类专栏：别让烂代码，毁了你的职业生涯文章标签： java 时间复杂度空间换时间 dubbo spring springboot

本文链接：https://blog.csdn.net/qq_45740561/article/details/150534864

别让烂代码，毁了你的职业生涯专栏收录该内容

61 篇文章

订阅专栏

那段压垮了整个系统的“简单”代码

“交易服务CPU 100%！订单接口全线超时！” 凌晨 00:05，大促刚开始，作战室里刺耳的告警声，像一把把尖刀扎进每个工程师的心脏。

作为技术负责人，我死死盯着大盘，流量曲线像心电图一样疯狂抖动，而服务可用率曲线则断崖式下跌。DBA、SRE 团队轮番上阵，数据库连接池正常、Redis 缓存命中率 99%、网络带宽充裕……所有常规“嫌疑人”都被排除了。

恐慌开始蔓延。

“扩容！立刻扩容一倍！” 有人喊道。但我们都清楚，毫无头绪的扩容，不过是把更多薪柴扔进火坑。

“查代码！最近上线的变更！” 我强迫自己冷静下来。最终，在火焰图上，一个极其深邃的红色调用栈，将我们引向了一个月前上线的、由新同事小王写的商品推荐模块 —— findMatchingProducts。

方法很简单：根据当前商品，从一个推荐商品列表中，找出两个价格相加等于一个目标“优惠价”的商品组合。小王的代码逻辑清晰得像教科书：

// [错误/旧范式代码] - O(n*n) 的时间复杂度
public ProductPair findMatchingProducts(List<Product> productList, int targetPrice) {
    for (int i = 0; i < productList.size(); i++) {
        for (int j = i + 1; j < productList.size(); j++) {
            Product p1 = productList.get(i);
            Product p2 = productList.get(j);
            if (p1.getPrice() + p2.getPrice() == targetPrice) {
                return new ProductPair(p1, p2);
            }
        }
    }
    return null; // or throw exception
}

“这代码逻辑没问题啊，单元测试都过了！” 小王委屈地辩解。是的，逻辑上无懈可击，但在大促的“照妖镜”下，它成了魔鬼。当 productList 的大小从测试时的几十个，变成线上的几千个时，O(n²) 的时间复杂度，让计算量从几百次，飙升到了几百万次！每一次请求，都在服务器里引爆一颗计算炸弹。

一行 HashMap 的救赎

我记得在一个月前的 Code Review 上，我曾对这段代码提出过性能隐患，但当时项目排期紧张，加上“只是个内部推荐，量不大”的侥幸心理，这个问题被放过了。现在，这个被忽视的“小问题”，用几百万的损失，给我们上了最惨痛的一课。

没有时间责备了。我冲到白板前，写下了重构方案。

“空间换时间！” 我说，“把一次循环的结果存起来，第二次循环就不用傻傻地遍历，而是直接查询！”

// [正确/新范式代码] - O(n) 的时间复杂度
public ProductPair findMatchingProducts(List<Product> productList, int targetPrice) {
    Map<Integer, Product> priceMap = new HashMap<>();
    for (Product product : productList) {
        int complementPrice = targetPrice - product.getPrice();
        if (priceMap.containsKey(complementPrice)) {
            return new ProductPair(priceMap.get(complementPrice), product);
        }
        priceMap.put(product.getPrice(), product);
    }
    return null;
}

代码被迅速修改、打包、上线。当最后一个 Pod 更新完毕，奇迹发生了。CPU 占用率的曲线，像坐过山车一样，从 100% 的顶峰，瞬间俯冲到了 10% 的谷底。系统，活过来了。

但这还没完。在生产环境中，我们追求的是极致。

别让你的 HashMap 在关键时刻掉链子

在刚才的“救火版”代码中，HashMap 在添加元素时，如果内部数组满了，会触发 resize 操作——创建一个更大的新数组，并把旧数组的元素全部重新哈希一遍放进去。这是一个非常耗时的操作！在高并发场景下，频繁的 resize 会造成不必要的 CPU 抖动。

因此，终极的代码应该是这样的：

// 使用 Guava 预设容量，避免扩容
import com.google.common.collect.Maps;

public ProductPair findMatchingProducts(List<Product> productList, int targetPrice) {
    // 预估容量，直接一步到位，避免运行中动态扩容的开销
    Map<Integer, Product> priceMap = Maps.newHashMapWithExpectedSize(productList.size());
    for (Product product : productList) {
        int complementPrice = targetPrice - product.getPrice();
        if (priceMap.containsKey(complementPrice)) {
            return new ProductPair(priceMap.get(complementPrice), product);
        }
        priceMap.put(product.getPrice(), product);
    }
    return null;
}

一个小小的初始化优化，体现的是对底层原理的深刻理解和对生产环境的敬畏之心。

Spring 的基石：你以为这是算法题，其实是框架的灵魂

事故复盘会上，气氛凝重。我没有指责任何人，而是打开了 Spring 框架的源码。

“大家觉得我们今晚遇到的问题，是个例吗？” 我指向了 DefaultSingletonBeanRegistry 这个类。

“这是 Spring IoC 容器管理所有单例 Bean 的核心。你们看，它最关键的成员变量是什么？”

// 精确定位：org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
public class DefaultSingletonBeanRegistry ... {
    /** Cache of singleton objects: bean name --> bean instance */
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    ...
}

“一个 ConcurrentHashMap！当你的应用启动时，成百上千个 Bean 被创建并注册到这里。每次依赖注入，Spring 需要根据 Bean 的名字找到对应的实例。它是在遍历一个 List 吗？不！它利用 Map 提供了近乎 O(1) 的查找速度。如果 Spring 在这里用了 O(n) 的遍历，那么任何一个大型应用的启动和运行，都将是一场灾难。”