时间复杂度与空间复杂度在实际工程中如何权衡取舍？

在实际工程里，时间复杂度和空间复杂度的权衡，多数情况下是空间换时间。因为快，是更好的用户体验。接口响应快100毫秒，用户的等待感就少一分，订单转化率可能就高一点。

这个判断当然也不是随口说的，我们来看一下日常用的框架和业务代码。

拿我们自己项目里的一个例子来说。库存服务有个场景，每次需要查某个物料分类下有哪些物料编码。如果每次都发起一次远程调用去物料中心查，一次查询可能就要几毫秒甚至几十毫秒的网络开销。实际上我们做了一个本地缓存：

// 最多缓存5000个分类，过期时间1天 categoryMaterialCodeCache = Caffeine.newBuilder() .maximumSize(5000) .expireAfterWrite(Duration.ofDays(1)) .build(categoryId -> materialFacade.queryMaterialByCategoryId(categoryId));

服务启动时初始化这个缓存，后续业务代码调用categoryMaterialCodeCache.get(categoryId)直接从内存拿结果，省掉了一次RPC调用。5000个分类的数据在内存里占不了多少空间，也就十几兆，但换来的是每次查询少了一次网络往返。这就是用空间换时间。

这种思路在JDK底层也有。你看一下Integer的源码，里面有一个叫IntegerCache的内部类，在JVM启动时预创建了-128到127这256个Integer对象。为什么这么做？因为Java里int的装箱操作非常频繁，循环计数器、数组下标、状态码这些场景到处都是小整数。如果每次Integer.valueOf(1)都new一个新对象，GC压力会很大。预创建好这256个对象放在数组里，后续用到直接返回引用，用一块固定的内存避免了大量临时对象的创建和回收。这同样是用空间换时间。

再来看一个相反的例子。我们系统里有些定时任务需要处理批量数据，比如每天晚上要对全量订单做统计汇总，数据量有几十万条。最暴力的做法是一次性把几百万条数据全部加载到内存里处理，这样只需要查一次数据库，处理速度也快。但实际上，大多数团队会选择每次只从数据库读取500条左右，处理完这一批再读下一批，循环几千次直到全部处理完。这种做法多花了很多时间，查询次数多了几十倍，总耗时也长了很多。但它换来了更少的内存占用，每次只有几百条数据在内存里，不会造成内存的瞬时峰值，对数据库的压力也更均匀，不会影响在线业务。定时任务不需要追求速度，执行慢一点没关系，系统稳定才是第一位的。这就是用时间换空间。

前面两个例子是空间换时间，第三个是时间换空间。那么问题来了：为什么工程实践中空间换时间的情况明显更多？

因为：CPU和内存通常都不是主要瓶颈。那瓶颈在哪？在IO，也就是数据库查询、网络调用、磁盘读写这些操作上。

美团技术博客上有一篇性能优化策略的总结，里面的真实案例也印证了这一点。他们列举的几个案例里，瓶颈无一例外都在IO层面：商家刷新任务的瓶颈是数据库查询次数太多，POI页面的瓶颈是数据库读流量扛不住，运营后台页面的瓶颈是执行了太多次小SQL查询。对应的优化手段，缓存、批量化、异步RPC，无一不是在减少IO次数。这些案例来自不同公司、不同业务场景，结论却基本一致。

所以一个比较务实的判断是：在常见的Web和后端服务中，性能瓶颈更多出现在IO层面，而不是CPU算力或内存不足。缓存之所以成为最常用的优化手段，就是因为它直接减少了IO次数，而减少IO的代价通常只是多占一些内存。

当然也有例外。前面提到的定时任务小批次处理就是一种时间换空间的场景。数据压缩存储也是，用CPU时间做压缩来节省磁盘空间。这些场景有一个共同特征：对时间不敏感。定时任务慢一点用户感知不到。一旦场景对时间敏感，比如面向用户的接口，空间换时间几乎是默认选择。

那在实际项目中具体怎么做判断？有一个简单的决策框架：先搞清楚你的系统瓶颈在哪。如果瓶颈在延迟，比如API响应慢、用户等待时间长，那就优先空间换时间。如果瓶颈在存储，比如日志量大、归档数据占满磁盘，那就考虑时间换空间。

具体到操作层面，有三个维度可以参考。

第一个是访问频率。高频读加上低频写的数据，适合加缓存，用空间换时间。低频读或一次性查询的数据，不值得缓存，直接查就行。比如系统配置信息、字典表这类变化少但读取频繁的数据，本地缓存是最合适的。反过来，一个报表查询可能一个月才跑一次，为它建缓存纯属浪费内存。

第二个是数据变化速度。变化极慢的数据，比如系统配置、枚举值，本地缓存就行，过期时间可以设长一些。变化较快的数据，比如商品库存、价格信息，需要分布式缓存加短过期时间，或者配合主动失效机制。实时性要求极高的数据，比如账户余额、库存可售数量，这类数据用缓存反而可能造成数据不一致，不如直接查数据库。

第三个是资源成本。内存成本、IO成本、CPU成本，哪个便宜就用哪个去换哪个贵的。大多数场景下，内存是最便宜的资源，所以空间换时间最常见。但在一些特定场景下，比如离线数据处理、日志归档，磁盘IO和计算资源可能更紧张，这时候用CPU做压缩来换存储空间，就是合理的选择。

美团在做POI数据缓存时，采用了多级缓存架构：本地缓存响应最快但容量有限，分布式缓存容量更大但需要一次网络往返，数据库容量最大但响应最慢。每一层都在用更多的存储空间换取更低的访问延迟，工程师要做的是根据业务需求决定在哪一层停下来。

Elasticsearch的倒排索引也是一个典型的例子。写入文档时，额外构建一份倒排索引，记录每个词出现在哪些文档里，这会多占不少磁盘空间。但查询时，不用扫描全部文档，直接从索引定位到包含目标词的文档列表，查询性能从全量扫描变成了近似常数时间。写入时多花空间，换来查询时的大幅加速。

参考的内容

• 常见性能优化策略的总结 - 美团技术团队