在实际工程里时间复杂度和空间复杂度的权衡多数情况下是空间换时间。因为快是更好的用户体验。接口响应快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的倒排索引也是一个典型的例子。写入文档时额外构建一份倒排索引记录每个词出现在哪些文档里这会多占不少磁盘空间。但查询时不用扫描全部文档直接从索引定位到包含目标词的文档列表查询性能从全量扫描变成了近似常数时间。写入时多花空间换来查询时的大幅加速。参考的内容常见性能优化策略的总结 - 美团技术团队