有人说Java的性能瓶颈都在GC、JIT和那些教科书上的算法复杂度里。可真到了线上告警你盯着火焰图找半天最后发现CPU时间被一个for循环里的String 、一个catch块里的parse、一条日志debug拼接消耗得干干净净。这些代码每一行看起来都无可厚非但组合在一起就是一台绞肉机。真正让Java服务变慢的往往不是宏大的架构设计而是那些被语法糖包装过的“日常习惯”。异常不是免费的安全网在很多团队的代码里try-catch被当成了if-else用。例如解析用户输入时直接Integer.parseInt(input)然后catchNumberFormatException返回一个默认值。这种写法干净但代价非常贵。每一次new Exception()都会触发fillInStackTrace()JVM要逐一记录当前线程的调用栈帧包括类名、方法名、行号。这个操作比普通对象分配高出一个数量级异常对象是JVM中最昂贵的对象之一它买的是安全筹码但你每次为它付的都是全额支票。高QPS下这等于在每个请求里偷偷插入了几十次栈快照。更隐蔽的是有些代码把异常写进循环。比如批量解析CSV时一行格式不对就抛异常外层循环继续处理下一行。结果每次解析失败都会生成一个栈对象然后被GC回收造成大量分配压力同时触发了老年代回收。如果这个循环每秒执行上千次GC报表立刻变得漂亮——不是优化了而是异常制造了垃圾。正确的做法是对可预期的分支用Optional或返回码处理只有真正无法恢复的状况才应该抛出异常。如果你确实需要在热路径上使用异常可以考虑重写fillInStackTrace()让异常对象不再快照栈可这会牺牲可诊断性需要权衡。字符串拼接藏在加号里的O(n²)“不要在循环里用拼接字符串”这句话几乎所有Java面试题都会考。但线上代码依然有String sql ; for (...) { sql condition; }。有人解释编译器不是会自动优化成StringBuilder吗没错但那是优化了字节码不是优化了算法。反编译后每次sql condition都等价于sql new StringBuilder(sql).append(condition).toString();这意味着每迭代一次都要创建一个新的StringBuilder执行一次toString()生成新字符串并复制旧字符串的全部内容。这个循环的总时间复杂度是O(n²)而不是O(n)。当n从10变成10000时耗时不是线性增长而是平方级增长。更糟糕的是很多人不知道StringBuilder构造函数里的容量参数。默认的StringBuilder只分配了16个字符的缓冲区一旦追加超过长度就要扩容并复制字符数组。如果你预先知道最终长度比如拼接1000条SQL的IN条件直接用new StringBuilder(estimatedLength)能减少90%的数组复制。另外String.format()也很贵它内部要解析格式串还有一堆格式化器。字符串拼接的代价不会抛异常它只会安静地让你的接口P99从10ms变成200ms。日志被忽略的“影子业务”日志是应用里最分裂的代码线上日志级别往往是INFO或WARN但代码里写满了logger.debug(用户 user.getId() 下单金额 order.getPrice())。这里的字符串拼接发生在logger方法调用之前无论日志级别是否开启参数表达式都会立即求值。也就是说如果日志级别是ERROR那么所有DEBUG级别的字符串拼接都在白白燃烧CPU。用SLF4J的占位符可以避免吗占位符logger.debug(订单{}金额{}, id, price)确实不会在禁用级别时立即执行格式化但要注意如果第2个参数本身就是金额: price这种表达式它依然在调用前就被算好了。所以更严格的做法是先用logger.isDebugEnabled()包住或者让业务对象延迟toString。另一个容易被忽视的点是同步日志的IO阻塞。每次log.info都要获取锁、格式化、写入文件或网络。如果磁盘出现瞬时高延迟整个线程池都会被同一个日志锁卡住流量越大拥堵越严重。Log4j2的异步Appender可以在一定程度上解决问题但异步有背压和丢日志风险需要结合业务场景决定。日志代码不产生业务价值却消耗着真实的CPU和IO——它是隐藏在所有方法里的“影子同事”。优化日志的第一步永远是把不需要的日志级别降到最低而不是研究怎么让日志更快。集合扩容是性能的“延迟炸弹”ArrayList默认容量10每次扩容到原来的1.5倍。如果你要存100万条数据ArrayList会从10开始经过二十多次扩容每次都新建一个大数组并把旧数组的元素全部复制过去。这些复制操作的总开销是O(n)级别但每次扩容瞬间都会有一个大数组的分配和拷贝高峰。如果将这段时间点对应到高并发请求上就形成了延迟毛刺。更可怕的是HashMap默认容量16负载因子0.75当元素超过12就开始rehash重建底层链表数组并重新计算每个元素的hash。一次rehash的成本可能比你插入前面所有元素的总和还高。很多开发者在构建查询结果时先new ArrayList()再逐条add。他们不知道如果结果集有1万条ArrayList在背后已经偷偷复制了十几次数组。更糟的是HashMap的扩容还会导致链表转红黑树如果数据分布不均匀碰撞严重读操作的复杂度会从O(1)恶化成O(log n)甚至O(n)。修复方式非常简单当你知道大小时务必设置初始容量比如new ArrayList(expectedSize)new HashMap((int)(expectedSize / 0.75f) 1)。在知道容量的场景下不指定初始容量等于让系统在业务最关键的时刻突然做一次全员搬家。这短短几行代码的改动往往比任何微服务拆分都有效。正则字符匹配中的“时间黑洞”正则表达式是文本处理的瑞士军刀但它的性能陷阱几乎是隐藏的。很多新手喜欢写str.matches(\\d)因为最简洁。可String.matches()内部每次都会调用Pattern.compile(regex)重新编译这个正则。一次编译的代价比执行匹配本身高出几个数量级如果这个调用出现在循环里等于每一行都重新浇灌一把瑞士军刀。正确做法是把Pattern定义为static final在类加载时编译一次循环里复用Matcher。比编译更危险的是灾难性回溯。像(a)$这样的正则在目标字符串匹配失败时会让引擎尝试所有可能的分组方式。如果输入是aaaaab引擎可能先尝试a分组再尝试aa再尝试aaa……这是一个指数级搜索。输入只要30个字符就有可能让CPU忙活几个小时。你的代码里没有while(true)但一个写得不严谨的正则能让你在监控图上看到一条漂亮的水平线——CPU 100%。避免这种陷阱的方法是避免嵌套量词和模糊匹配尽量使用非贪婪量词或者用String.indexOf、手写解析来替代。有些场景甚至可以用re2j库它通过自动机原理将性能控制在O(n)且不回溯。尾声性能优化的第一课是成本意识这五个瓶颈有一个共同特征它们都被语言特性、编译器优化、框架语义包装得很“正常”。你不会在一行String 、一个try-catch、一条日志、一个new ArrayList、一次matches调用上看见警报除非它们叠加在千万次调用上。性能优化的本质不是炫技而是对每一个隐式分配、每一次隐式复制、每一个隐式调用保持警觉。下一次写完代码问自己三个问题这段代码会被执行多少次每次执行会分配多少对象这些对象能复用吗答案写下来性能问题至少少一半。