代码优化这事，代码说穿了就是优化跟时间和空间打架。你多花点CPU，代码内存就能省下来；你多占点内存，优化速度就能提上去。代码但真正的优化高手，从不满足于这种粗暴的代码置换。他们追求的优化，是代码在不牺牲可读性的前提下，把每一行代码都榨出汁来。优化

最常见的代码优化手段，其实是优化“少干活”。我见过太多人写循环，代码明明可以提前跳出，优化非要遍历完整个数组。代码有一次我接手一个订单处理模块，线上响应慢得像蜗牛。翻代码发现，一个嵌套了三层的for循环，里面还在查数据库。其实业务逻辑很简单，就是找第一个符合条件的订单。加个break，响应时间从2秒降到了200毫秒。你看，有时候优化就这么朴实无华——少做无用功。

再往下说，就是数据结构的选择。这玩意儿选对了，效果立竿见影。Java里HashMap查东西是O(1)，ArrayList查东西是O(n)。有人图省事，全程用List，结果数据量一上来，接口直接超时。换成Map之后，世界清净了。别小看这个，很多性能问题，根子上就是数据结构用错了。你得对你的数据了如指掌——它有多少条？是读多写少还是写多读少？回答清楚这些问题，数据结构自然就浮出水面。

缓存是个老生常谈的话题，但真正用好的不多。我见过最蠢的写法，是每次请求都重新计算一个几乎不变的值。比如系统配置，明明一个月才改一次，却每个请求都去数据库查一遍。这就像你每天出门前都要重新学一遍怎么走路，纯属浪费。把这种高频读、低频写的数据塞进本地缓存或者Redis，性能提升是肉眼可见的。但缓存也有坑——你得想清楚失效策略，否则用户改了配置，线上还是老样子，那就要挨骂了。

说到并发优化，很多人第一反应是加锁。但锁是万恶之源，它让并行变成了串行。真正好的并发代码，是尽量无锁的。用原子变量，用CAS，用ThreadLocal，用不可变对象。我之前优化过一个库存扣减接口，原来用synchronized锁整个方法，QPS死活上不去。改成AtomicInteger做原子扣减，配合乐观锁重试机制，QPS直接翻了三倍。当然，无锁编程对脑子的要求高一些，容易写出隐蔽的bug，你得有足够的测试兜底。

最后说说代码层面的“瘦身”。重复代码是性能杀手，也是维护噩梦。同一个计算逻辑，散落在七八个地方，每个地方写法还略有不同。这不仅浪费空间，更可怕的是，将来改需求的时候，你漏改了一处，线上就出诡异的问题。抽个公共方法，或者用策略模式把变的部分隔离出来，代码清爽了，性能也上去了——因为JIT编译器对热点代码的优化，在方法足够小、足够清晰的时候，效果最好。

优化这事儿，最忌讳的是凭感觉。你得用profiler去看，到底是CPU忙还是内存缺，是锁竞争还是GC频繁。数据说话，别瞎猜。有一次我自信满满地优化了一段字符串拼接，改用StringBuilder，结果性能毫无变化。后来一查，JVM早就做了逃逸分析，自动优化掉了。所以说，别跟编译器较劲，它比你聪明。

代码优化没有银弹，它是一连串权衡的结果。有时候牺牲一点可读性换性能，值得；有时候为了维护方便，多花点资源，也值。关键是你得知道自己要什么——是要撑住双十一的流量，还是要让下一个接手的人少掉几根头发。想清楚了，优化才有方向。