接手这个项目的时候，老同事意味深长地跟我说了一句话：“这套核心代码已经优化到了极致，别乱动。”我信了。打开代码一看，满屏的缓存、异步回调、位运算、对象池……注释里还写着“此处为了性能不能改成if-else”之类的话。我当时甚至有点自卑，觉得自己看不懂高阶代码一定是自己水平不行。
可接下来压测让我彻底懵了。一个平平无奇的用户详情接口，压到500并发时平均响应时间直接飙到1200ms，失败率4.7%。系统是Java写的，跑在8核16G的容器里，我第一反应是机器不够，但看监控CPU只用了55%，数据库连接池却被占满了。每个请求居然干了很多事情：先查Redis、再查两个内部RPC、又去数据库读一次，中间还穿插好几个CompletableFuture做异步合并。最离谱的是，客户端只想要用户基础信息，代码却非要去统计服务拉一堆行为画像塞到缓存里。而这个缓存更新策略是——只要用户表有任何一条记录变动，就删除整个前缀下的所有key。于是同一秒内所有请求全部穿透缓存，疯狂重建那个巨大的key集合，Redis和MySQL双双爆炸。
后来我实在耐不住性子，趁老同事休假时做了一个大胆决定：把那些“优化”全部删掉，只保留最直白的逻辑。用户查询就查用户表，返回需要的那十几个字段，不拉什么画像了。缓存就留用户字段级别的简单KV，TTL设成30分钟，更新时就set一次。那些位运算我根本不想去猜含义，全部改成十进制比较，正常人一眼就能看懂。异步回调导致一个请求串了三次线程切换，我也全改回同步顺序调用。三天时间，删掉了大概70%的代码，组里其他同事都以为我疯了，有人还在代码评审时写了长篇大论抨击我。
结果呢？同一个压测命令，500并发下平均响应时间从1200ms掉到了180ms，失败率从4.7%变成0。CPU占用从55%降到了30%，数据库连接池再也不告警了。整个过程中我没有做任何传统意义上“正经”的性能优化——没加索引，没加机器，没做削峰填谷，甚至没有改SQL。只是把多余的操作删掉，把复杂的状态改简单，把没必要的线程切换捋直。那段时间我反复想，为什么我会觉得这种“清理垃圾”能带来这么大的收益？答案其实特别简单：代码里的缓存一旦用错，就是双重开销；异步一旦用错，就是三倍线程切换；任何花哨的结构如果超出了业务需要的复杂度，它消耗的就是维护者的时间和机器的指令数。
后来的几个项目让我越来越确信：现代CPU的乱序执行、分支预测和JIT编译器，远比你手写的那些“微优化”要聪明得多。前几年我在一个C++项目里试图用位运算和手写内联汇编来加速配置项判断，结果编译器加了-O2之后生成的机器码比我的汇编还快了5%。从那一刻起我就明白了，编译器最擅长优化那些结构简单、语义直白的代码。而你费尽心机搞出来的“聪明实现”，它不但不领情，反而会被这些复杂逻辑挡住视线，产出更差的指令序列。
现在很多人一谈技术就喜欢搬出“性能优化”这个词，好像不在代码里搞点缓存、用上各种高逼格的并发模型就不算资深。可我经历的这些教训告诉我，真正的资深是把不必要的复杂度扛在自己肩上，而不是让所有接下来维护代码的人为你的炫技买单。我见过太多团队，为了“优化”一个几百毫秒的普通请求，引进了Redis集群和消息队列，结果整个系统延迟从300ms变成了800ms，还多了无数个宕机点。基础软件（比如Kafka、Netty）里的那些变态优化手段，放在业务代码和普通网络IO上，几乎都是反向优化。因为它们优化的前提是极端的访问模式、极致的资源利用率，而普通业务接口根本到不了那个量级。
做了几年开发，我发现自己最熟练的技能不是背HashMap底层原理，也不是花式调优GC，而是如何理直气壮地点击那个git revert按钮。现在每一次有人提“优化”的合并请求，我都会在代码评审里追问三个问题：第一，你的压测数据在哪里？第二，改动之后代码可读性会不会下降？第三，三个月后你回来维护这段逻辑，会不会想抽自己？只要有一个问题让人犹豫，我就会当场提议把改动回退。代码先要跑对、要让人能看懂，然后才有资格谈运行快慢。删除重复、打破复杂、保持直白——这才是如今我眼里最高级的优化。