一个运行了三年的服务突然在某个午高峰CPU飙升到100%堆内存却毫无压力。你怀疑是JVM调优参数有问题把GC日志翻了个底朝天最后发现罪魁祸首是一行看起来人畜无害的String a b。这种故事在Java开发中每天都在上演性能陷阱往往不是藏在复杂的架构里而是躲在最普通的代码习惯中。以下十个场景是我从真实故障与压测报告中提炼出的高频雷区每一个都有代价分析也有对应的规避路径。字符串拼接隐藏的O(n²)String的不可变性决定了每次都会创建新对象。在循环中拼接字符串如果循环次数是n按常理认为是O(n)实际却是O(n²)——因为每次拼接都要把旧字符串复制一遍。更隐蔽的是使用StringBuffer的append方法时如果未设置初始容量它会在扩容时多次复制数组性能同样会退化。StringBuilder不是万能药但默认16的初始容量在长字符串拼接时仍会触发多次扩容。规避方法很简单预估最终长度用new StringBuilder(capacity)显式指定或者直接使用String.join和Collectors.joining。不要相信编译器优化它只对字面量拼接有效对循环内的动态拼接无能为力。异常作为控制流沉重且危险try-catch块本身几乎零成本但new Exception()会填充完整的堆栈信息这个操作开销极高。有人把异常当作业务判断分支比如用NumberFormatException检测数字格式或者用FileNotFoundException判断文件是否存在。在高并发下这种写法会让JVM在创建异常对象上浪费大量CPU同时堆内存被无用的堆栈引用撑满。异常只应在真正异常时抛出如果预期会有解析失败用if加正则或自定义校验先行处理。另外不要捕获异常后又吞掉那会让问题延迟到不可预测的时刻爆发。循环内创建大对象GC的噩梦在循环体内new一个即使很小的对象如果循环次数高都会导致频繁的Minor GC。更糟糕的是如果这个对象被某个集合持有它会晋升到老年代后续变成Full GC的导火索。我见过一个报表导出功能循环里每次生成一个SimpleDateFormat而SimpleDateFormat内部有Calendar占用空间不小。重用长生命周期对象比创建新对象快几个数量级但要注意线程安全问题——SimpleDateFormat放在局部变量就是为了避开线程安全这里可以通过ThreadLocal或改用DateTimeFormatter它是不可变的来优雅解决。对于其他临时大对象考虑对象池或直接复用局部变量。集合初始容量总被忽视的细节HashMap默认负载因子0.75意味着往默认容量16的map里放入超过12个元素就会扩容。扩容要重新计算哈希、重新搬移所有节点耗时是O(n)且产生临时垃圾。ArrayList同理默认10的容量在添加大量元素时会多次Arrays.copyOf。大多数集合性能问题的根源是指定容量的机会被白白浪费。如果你能预估大致的元素数量直接用new HashMap(expectedSize)并且手动计算expectedSize / 0.75 1作为容量值。ArrayList则可以直接用new ArrayList(list.size())。这个习惯能让插入操作提速数倍特别是在构建大列表时。无界线程池与无界队列慢下来的源头Executors.newFixedThreadPool内部使用LinkedBlockingQueue默认容量是Integer.MAX_VALUE意味着任务可以无限排队。当请求涌入速度超过处理速度每个任务都占用一个线程最后线程全部阻塞在任务上内存被队列中的任务对象逼近极限。而newCachedThreadPool又走向另一个极端如果任务阻塞它会不断创建新线程直到耗尽系统资源。线程池必须使用有界队列和拒绝策略同时根据实际平均响应时间计算线程数的上限。正确的做法是用ThreadPoolExecutor显式指定ArrayBlockingQueue或SynchronousQueue并配合CallerRunsPolicy或自定义降级逻辑。锁的粒度与死锁并发性能的分水岭在方法上加synchronized是最省事的做法但也是最粗暴的做法。如果一个方法里既有读操作又有写操作甚至包含耗时I/O整段代码被锁住其他线程只能排队。锁竞争的本质不是锁的机制慢而是临界区的长度决定了吞吐上限。把锁的范围缩小到真正需要互斥的字段操作用ReentrantReadWriteLock分离读写或者直接用ConcurrentHashMap的原子方法。如果并发量极高还可以考虑LongAdder代替AtomicLong它对热点计数有更好的分散性。记住锁本身不是反模式锁住不需要锁的范围才是。数据库N1查询比慢SQL更隐蔽在循环中逐条执行SQL是最典型的N1问题。比如查出一批用户的ID然后在循环里findById。每个查询的网络往返时间是微秒级当数量从10变成1000总耗时就从毫秒级涨到秒级。一次批量查询的成本往往远低于N次单条查询——即使是相同的查询条件批量也能省去大量网络和上下文切换开销。规避方法用IN子句或UNION或者使用ORM的join fetch一次取回关联数据。同时注意IN子句的数量Oracle和MySQL都有单条语句的参数上限一般控制在1000以内。如果数据量真的大到需要分页也要用游标或分页批量而不是循环拼接。日志过度输出磁盘与CPU双杀每个logger.info在压测时都可能是系统的隐形杀手。如果日志级别设为DEBUG而代码里到处是log.debug(id id)这种字符串拼接即使日志框架最终没有输出拼接操作也已经执行了。更麻烦的是大量日志写入磁盘会导致I/O成为瓶颈甚至会阻塞业务线程。日志框架的异步和级别过滤并不是你写垃圾日志的理由。正确做法使用占位符log.debug(id{}, id)避免字符串拼接生产环境日志级别设置为INFO或WARN对高频路径比如每个请求的响应体只记录摘要。还有不要在日志中打印整个对象toString方法可能包含大量嵌套信息。正则表达式回溯CPU无限燃烧一个看似简单的正则(\d)$在匹配长数字串时如果不匹配会发生灾难性回溯指数级消耗CPU。Java的String.matches每次都会编译正则这个编译成本比执行匹配高得多如果放在循环里等于重复造轮子。正则表达式的性能问题一半来自糟糕的表达式另一半来自重复编译。规避方法对于确定性的格式校验优先用indexOf、startsWith或拆字法如果必须用正则预编译Pattern并复用最重要的是避免嵌套量词和歧义分支。写正则之前用在线工具测试一下复杂输入下的匹配时间防患于未然。对象序列化隐藏的字节流代价把Java对象转JSON或写Redis传统方式用ObjectOutputStream或Jackson默认配置。序列化会反射遍历对象的字段如果对象层级深、字段多成本非常高。更常见的是把复杂对象存入Redis后取出来还要反序列化这一进一出可能比实际业务计算还耗时。序列化不是免费的它同样需要计算和内存。规避方法对高频传输的对象使用Protocol Buffers或Kryo这类更高效的序列化方案或者自定义字节编码。如果继续用JSON要配置字段过滤排除不必要的属性使用JsonIgnore。另外重写writeObject和readObject方法控制序列化逻辑可以有效避免整个对象图被遍历。性能优化本质是成本核算上面十个陷阱有一个共同特征它们都不是逻辑错误而是资源使用方式不经济。性能优化的第一原则是测量第二原则是避免第三原则才是优化。遇到性能问题时不要急着改代码先通过JFR、Arthas或简单的System.nanoTime定位热点。很多陷阱在微观基准测试下看起来只有几毫秒差异但在百万级请求下会被放大成灾难。我见过一个团队花一周优化某个缓存算法最后发现瓶颈是日志中的toString调用浪费了人力。把注意力放在数据规模和访问频率上如果一个方法一天只调用十次那它再烂也无所谓如果每秒调用十万次哪怕一次多余的new都要谨慎。记住那句老话过早优化是万恶之源但不优化是不负责任的放纵。在写每一行涉及循环、并发、I/O的代码之前先问自己这里会不会成为下一轮流量的爆破点