开篇就是一场事故现场。某个凌晨监控面板上CPU飙到95%接口响应时间从50ms跌到3000ms日志里全是OutOfMemoryError。你手忙脚乱地dump堆、查线程最后发现罪魁祸首不过是一行看似无辜的String 拼接。Java性能优化从来不是玄学它是代码、JVM、操作系统三者之间的一场精密博弈。性能问题的本质是资源分配与访问模式的错配——要么你让CPU空转了要么让内存溢出了要么让GC替你收拾烂摊子。真正的高手能从一行代码预判出JVM的行为能从一段日志定位到缓存失效的瞬间。代码层面的第一道防线别让编译器做猜谜游戏很多开发者对性能优化有误解以为要上什么黑魔法。实际上90%的性能提升来自于干掉明显的愚蠢代码。就拿字符串处理来说循环里用拼接每次都会创建新的StringBuilder然后丢弃再创建。如果你用的是JDK 9以上的版本编译期确实会自动优化为invokedynamic但循环体内的拼接依然会产生大量中间对象。更好的做法是在循环外显式声明StringBuilder或者干脆用String.join()、Collectors.joining()。别把JIT编译器的优化能力当作你写烂代码的底气它再聪明也猜不透你的业务意图。再看集合的使用。ArrayList和LinkedList的选择很多人背过八股文但真的落到代码里就忘了。如果你的场景是“频繁随机访问 尾部追加”ArrayList永远是对的如果是“频繁头部插入/删除”LinkedList也不是最优解——ArrayDeque才是。更关键的是初始容量。new ArrayList(1000)和new ArrayList()的差距在数据量大时是数量级的。容量预估是免费的午餐可惜99%的人不吃。同样HashMap的负载因子、初始容量直接决定它什么时候扩容而扩容是纯开销——重新哈希、重排桶位。异常处理也是性能陷阱的重灾区。try-catch本身几乎没有成本但如果你在循环里捕获异常并且异常被频繁抛出那代价就大了。异常的构造需要填充堆栈这个操作成本极高。所以别用异常来控制流程哪怕它写起来很“优雅”。比如解析数字时先判断正则或者类型再调用parse而不是指望捕获NumberFormatException。并发才是真正的分水岭锁的粒度与等待的艺术单线程优化到极致吞吐量也有天花板。并发性能的核心不是“让多个线程跑起来”而是“让线程之间不打架”。你用了synchronized但它默认是偏向锁竞争激烈时升级为轻量级锁再升级为重量级锁——每一次升级都是性能滑坡。锁的粒度决定了并发的上限。如果你把一个方法的this锁住等于把整段业务串行化。合理的做法是锁定最小共享资源或者使用ReadWriteLock、StampedLock把读和写分离。还有更细的维度——volatile和CAS。volatile保证可见性但不保证原子性你用它做计数器就是自寻死路。CAS是乐观锁但它会引发CPU总线风暴在高并发下自旋会耗尽CPU。这时候你需要LongAdder它把热点分散到多个单元在读多写少的场景下性能远超AtomicLong。记住一条铁律优先考虑无锁或读写锁其次才是重量级锁。线程池的配置同样是门玄学但有基本公式。CPU密集型的核心线程数设为CPU核数1IO密集型的可以设为核数2或者更多但还要看IO等待时间占比。贸然拉大线程池只会导致上下文切换开销超过任务执行收益。线程不是越多越好而是刚好够用才好。另外Executors.newFixedThreadPool()的默认队列是LinkedBlockingQueue无界队列会堆积任务直到OOM——你敢用它就敢死给你看。生产环境请手动创建ThreadPoolExecutor并且设置拒绝策略这是底线。JVM参数不是万能药先理解内存模型的物理意义很多人上来就调-Xmx、-Xms以为调大堆内存就能解决一切。堆内存越大GC暂停时间越长这不是线性关系而是非线性恶化。JVM的内存模型必须和应用的访问模式匹配你把-Xmx设为8G但应用实际只用了1G剩下的7G白白浪费——GC扫描的是整个堆哪怕大部分是空闲的。合理的堆大小设置应当让老年代的使用率维持在30%~70%之间。你可以用jstat观察实际使用曲线再反推初始值。新生代与老年代的比例同样至关重要。如果新生代太小短命对象频繁晋升到老年代然后触发Full GC如果新生代太大Minor GC耗时增加且老年代可能太小导致Full GC频发。默认比例-XX:NewRatio2老年代:新生代2:1不一定适合所有应用。一个典型的Web应用80%的对象朝生夕灭新生代应该给足空间但别超过堆的1/3。-XX:SurvivorRatio8的默认值也有讲究如果对象存活率低可以加大Eden的比例。GC算法的选择更是从JDK 8到JDK 17的关键跨越。JDK 8默认的Parallel Scavenge Parallel Old吞吐量优先但暂停时间长。如果你的接口延迟敏感请切换到G1并且设置-XX:MaxGCPauseMillis50——G1会主动调整区域大小和回收策略把停顿控制在目标附近。到了JDK 11ZGC和Shenandoah的出现让暂停时间降到个位数毫秒但代价是吞吐率略微下降。没有最好的GC只有最匹配的GC。你的业务是批处理还是在线交易决定了该选吞吐优先还是延迟优先。缓存与IO压死应用的最后一根稻草代码写得再快内存分配得再漂亮一旦遇到磁盘IO一切都归零。日志框架如果同步写盘在高并发下就是性能黑洞。所有IO操作必须异步化要么用log4j2的异步logger要么把日志写入内存队列由独立线程批量刷盘。异步不是银弹它只是把阻塞从调用线程转移到后台线程但至少解放了主流程。说回缓存。缓存的本质是用空间换时间但别把内存当成无限的。你使用HashMap做本地缓存不设上限不设过期时间最终就是内存泄漏。本地缓存请使用Caffeine它对并发访问、逐出策略、过期机制都有精妙的设计命中率远高于手工写的懒加载。更重要的原则是本地缓存只用来放“允许短暂不一致”的数据比如系统配置、字典表。对于价格、库存这类强一致数据宁可去打远程Redis也别用本地缓存。Redis本身也有性能陷阱。一次批量操作如果你用循环get网络往返耗时是几十毫秒但用pipeline合并成一次耗时降到几毫秒——网络IO是缓存性能的瓶颈所在而批量合并是唯一解药。还有别用keys命令扫描全库它会让Redis单线程长期阻塞用scan迭代或者更简单根本不要产生需要扫描全库的需求。监控与剖析没有数据的优化都是耍流氓性能优化最怕的是“我感觉”、“我猜”。没有监控数据你只是在盲人摸象。先测量再优化这是铁律。生产环境必须接入APM比如SkyWalking、Micrometer至少要有CPU、内存、GC、线程池的实时曲线。当接口变慢时第一步不是看代码而是看监控看是GC导致的暂停还是锁竞争导致的阻塞还是磁盘IO等待。JVM自带的分析工具足以应对90%的场景。jstat -gcutil看GC频率jmap -dump抓堆快照jstack查看线程栈jcmd做内置诊断。但工具有了你会用吗线上有个经典问题CPU飙升怎么定位先用top -Hp找到最耗CPU的线程ID转为十六进制再用jstack找到对应线程栈看它停在哪个方法。往往你会看到它卡在正则、卡在压缩算法、卡在无限自旋。定位问题的过程其实是对JVM执行模型理解的考验。性能测试更要前置。别等到上线前才压测那是给领导看汇报材料。从写第一行代码起就应该有基准测试意识。JMHJava Microbenchmark Harness是官方推荐的基准测试框架它能消除JIT预热、死代码消除等干扰测出方法真实的吞吐量。用JMH验证你的优化是否有效而不是靠“感觉变快了”。比如你打算把ArrayList换成int[]用JMH测一下数据量多大时换有收益收益多少一目了然。从代码到JVM的完整闭环一个实战案例假设有一个订单查询接口性能不佳。你按顺序排查先看代码发现SQL里用了OR导致索引失效这是数据库层再看服务层发现每次查询都调一次Redis取商品详情没有本地缓存这是缓存层再看JVM参数-Xms和-Xmx相等为4G但老年代使用率持续90%说明对象分配太快或晋升异常最后看GC日志Full GC平均耗时800ms一天触发12次。这就是典型的“每层都在慢性失血”。优化方案如下第一层改写SQL为UNION ALL让两个索引各自生效第二层引入Caffeine本地缓存减少Redis访问90%第三层调整新生代大小让短命对象在Eden就死掉避免晋升老年代第四层切换G1并设置-XX:MaxGCPauseMillis80把Full GC改为混合GC。最终效果接口P99从800ms降到120msFull GC频率从每天12次降到每周1次。从代码到JVM每一步优化都不是孤立的它们彼此咬合形成整体。性能优化的最佳实践是永远把“可维护性”放在“极致性能”之前。如果你用一段只有自己能懂的位运算换来了0.1ms的提升那是对团队的不负责任。先写成清晰的代码再基于测量结果做有针对性的优化。JVM的JIT编译器和现代CPU的乱序执行已经足够聪明你要做的是配合它们而不是和它们对着干。最后一条忠告性能问题越早暴露修复成本越低。架构设计时就要考虑容量规划、缓存策略、GC选型编码时就要警惕集合容量、字符串拼接、异常滥用上线后就必须依赖监控和压测。代码会变老JVM会升级唯有性能意识需要持续生长。现在打开你的IDE关掉那些自动补全生成的冗余循环从减少一次不必要的对象分配开始——每一次优化都是你和计算机的一次深度对话。