Java应用突然变慢CPU飙高你搬出JProfiler、Arthas从大而全的接口一路追到字节码最后却找到了一个让人哭笑不得的答案——罪魁祸首并不是哪段算法而是一个个被忽略了很久的“小”性能细节。这些细节往往不会出现在教科书里也不会被性能监控工具直接标注却能在高并发、大数据量的场景下一层层累积让你的服务器在沉默中加速老化。接下来要谈的五个细节都不是高深的算法也不是花哨的工具。它们只是被误用、被省略、被当作“本来就该这样”的小地方。但恰恰是这些不起眼的写法在每秒处理数千次请求时会变成压垮系统的那一根根稻草。被误用的异常处理Java的异常处理机制被写入语言规范几乎没有人怀疑过它。可恰恰是这个“理所当然”让很多系统白白烧掉大量CPU。创建一个异常对象最贵的不在new操作本身而在于JVM要为它抓取完整的线程调用栈。这个栈快照要遍历虚拟机栈帧保存类名、方法名、行号等信息一次抛出的代价通常是普通对象创建的上百倍。如果你在一条频繁执行的方法里抛出异常那JVM每一次都要做一遍这样的“深度扫描”。更可怕的是异常被用于流程控制。比如一个循环里判断数据是否合法开发人员为了少写几行if直接靠捕获异常来跳出分支。这种情况下异常已经不是“意外”而是必然发生的常规路径。每循环一次JVM就完整地抓一次栈并发一高系统性能自然断崖式下跌。用异常做流程控制等于把系统的命运交给异常机制来拖拽。想象一下一个每天调用数百万次的接口每一次都因为一个“预期内”的格式错误抛一次异常这个损失有多大所以正确的姿态是异常只留给真正的异常场景。同时如果你确实需要频繁抛出自定义异常可以考虑重写fillInStackTrace()方法让它返回this从而跳过栈填充。JVM参数-XX:-StackTraceInThrowable也可以在全局层面关闭栈跟踪但需要谨慎评估诊断价值。优化异常性能不是消灭异常而是不滥用异常。字符串拼接的隐形陷阱在Java里“”是一个非常温和的运算符。可一旦进入循环它的表现就像一位披着羊皮的狼。比如在一个循环里你写String logInfo User i did action;然后再把它拼进一个结果中。Java编译器会对每次迭代的“”内部优化成new StringBuilder()因此循环体里实际创建了10000个StringBuilder对象再加上每次拼接时可能产生的临时数组垃圾回收的压力直线上升。循环体内的字符串拼接本质上是让编译器为你反复new对象。有人觉得可以用String.format来解决觉得它更优雅。但String.format需要解析格式描述符还要构造格式化内部组件性能和裸“”相比差了一个数量级。假如这段代码位于事件处理核心路径你甚至可以用手写的StringBuilder把所有字段拼在一起收益立竿见影。真正的高性能字符串构造永远是自己掌握拼接过程。这里要注意并不是说不能使用“”或String.format而是说在热点代码中要看清它们背后的分配行为。例如你完全可以在循环外声明一个StringBuilder循环内反复append这样整个循环只创建一个可变的字符序列对象。性能优化最怕的是用“优雅”遮蔽了成本。被忽略的集合容量账单HashMap是Java中最常用的数据结构但大多数人在new的时候不会指定容量。默认容量是16负载因子0.75一旦元素数量超过160.7512它就要扩容。扩容发生时旧数组里的所有元素都需要重新计算哈希并搬移到新数组这个过程的代价不是简单的复制而是一次二次散列。如果你的业务场景里一个HashMap预计会放入3000个键值对默认容量会导致它扩容多次从16到32再到64再到128、256、512……每次扩容都伴随全量rehash迁移最终浪费的时间远超你的想象。给集合一个合适的初始容量是最廉价、最容易被忽略的性能收益。一个简单的经验公式是初始容量 期望元素数 / 负载因子 1。对于负载因子0.75也就是期望元素数乘以1.34再加1。如果你预计放入10000个元素就new HashMap(13400)这样几乎不会触发扩容。虽然浪费了一点内存但换来了稳定的插入和查询性能。ArrayList也有同样的胃口。默认容量10当add操作超过这个阈值时它用Arrays.copyOf进行数组扩容每次扩容都要把老数据拷贝一遍。如果提前知道规模调用new ArrayList(expectedSize)或者add后使用ensureCapacity方法就可以避免多次冗余拷贝。性能事故往往源于集合的“自动增长”而不是集合本身的结构问题。自动装箱的无声损耗在Java语言中int和Integer之间可以自动转换长整型和包装类型之间也能无缝交互。这种语法糖方便却也隐藏着一个巨大的代价。来看一个常见的累加写法Long sum 0L; for (long i 0; i 1000000; i) { sum i; }这里sum是Long类型每次“sum i”都包含一次拆箱、一次Long加法、再一次装箱。也就是说这个循环会创建近百万个Long临时对象。它们很快成为垃圾触发GC然后又被回收整个循环都在为虚拟机的垃圾回收器打工。自动装箱在热点循环里是看不见的“内存漏水管”。更隐蔽的是在集合框架中ListInteger天然要求包装类型你无法用基本类型直接存储。可如果你在某个算法里反复使用get和set每一次都会拆箱装箱。此时可以考虑用Eclipse Collections或fastutil这类提供了原始类型集合的库或者将数据转为IntStream、LongStream使用利用它们的方法链完成过滤、求和、映射操作从而避免创建中间包装对象。把基本类型的集合操作交给基本类型的数据结构是高性能代码的一个基本素养。另外包装类型还有一层陷阱在比较两个值是否相等时Integer a 128; Integer b 128; a b返回的是false因为对象引用不同。这虽然是一个正确性陷阱但也会让开发人员为了保险而加equals而equals本身也需要方法调用和拆箱。性能优化的起点往往是先消除不必要的对象创建。日志性能的隐形漏斗日志框架是每个Java应用都离不开的依赖但很少有人把它当作性能资产来经营。一个经典的错误写法是logger.debug(User userId has logged in at System.currentTimeMillis());即使日志级别被设置为infodebug方法永远不会被打印但这一行代码里的字符串拼接已经完整地执行了一遍。如果你在此基础上拼接了一个对象的toString而该toString内部又访问了数据库那这个“没被打印”的日志反而会成为最昂贵的陷阱。日志框架最贵的不是输出而是那些压根不输出的拼接过程。参数化日志是首选的解药。使用logger.debug(User {} has logged in at {}, userId, time)日志框架只在确定要输出时才会进行格式化并且内部使用占位符替换。即便如此它仍然需要解析消息模板所以如果日志消息本身需要计算生成你还应该先调用logger.isDebugEnabled()做一次软判断。在SLF4J 2.x中还支持lambda表达式延迟构建消息logger.debug(User {} login, () - expensiveOperation())。这意味着只有在日志级别满足条件时expensiveOperation才会真正执行。让日志的成本只在需要打印时发生是大型分布式系统里的基本修养。不过也要小心过度优化如果日志本来就是一条固定字符串加不加参数化没有区别如果日志级别是info且输出到磁盘那么真正的瓶颈会是I/O而不是格式化。日志优化要分清主次但绝不能忽视字符串拼接这个隐形入口。回到开头那个问题当你的Java应用再次变慢时别急着怀疑数据库、中间件或架构不妨先看一眼代码里那些被随手写下的异常、拼接和自动装箱。慢往往不是来自一个庞然大物而是来自一千个微小的疏忽。但也要清醒地看到性能优化从来不是为了让代码变得晦涩难懂。在业务规模还很小的时候刻意追求极致性能会带来不必要的复杂度。正确的策略是在识别热点后用基准测试测量每一项优化的收益再决定是否值得动手。把性能预算花在最关键的地方才是工程师真正的功力。这五个细节——异常、字符串、集合容量、自动装箱、日志是Java开发中最容易忽略、也最有代表性的性能陷阱。它们都不难修复难的是养成一种“时刻留意隐藏成本”的敏感度。Java性能优化没有银弹只有一遍遍地把这些容易被忽略的细节打磨到极致。