我们总在代码里寻找“更快的路径”，却忽略了那些正在悄悄吞噬性能的角落。Java 性能问题的可怕之处，往往不在于某一行代码多么低效，而在于无数个微小的妥协累积成系统性的迟钝。今天我们就来撕开这些常见陷阱的伪装，看看它们到底是怎么拖垮你的应用的。

字符串拼接：隐藏在加号背后的“时间黑洞”

循环里写str += item是许多新手的第一堂性能课。每次拼接都会创建新的 StringBuilder，触发数组复制，甚至导致旧字符串对象进入老年代。更隐蔽的是，这种代价在循环次数极小时毫无感知，一旦达到十万级，停顿就变得刺眼。现代 JDK 对简单拼接做了优化，但循环内的+依然可能被编译成invokedynamic后的makeConcatWithConstants，尽管避免了中间 String 对象，却仍要不断构建新数组。

规避方法不是不要用加号，而是不要让加号出现在循环体内。在循环外声明 StringBuilder，设置预估容量，然后append。从 JIT 的角度看，这能减少逃逸对象的分配，让标量替换发挥作用。优化后你会发现，GC 频率和 CPU 占用同时下降，这是少见的双赢。

异常机制：用正常的业务逻辑去驱动异常流程

异常的开销远不止throw和catch本身。当 JVM 填充堆栈轨迹（stack trace）时，需要遍历整个调用栈、获取每个栈帧的类名、方法名、行号，这个动作极其昂贵。有人习惯用异常做流程控制，比如解析字符串时用NumberFormatException判断格式。这种写法在出错率极低的场景下尚可接受，但一旦输入数据里混入了 5% 的异常值，性能衰减可能达到指数级。更糟的是，异常对象会带着完整的调用栈进入堆，迫使年轻代提前晋升，引发不必要的 Full GC。

正确的姿态是：异常只用于真正的异常情况。用if前置校验代替 catch 解析错误。如果实在无法避免，至少考虑用StackTraceElement[]缓存或关闭某些栈帧填充（虽然不是标准 API），但最稳妥的还是调整数据校验逻辑。记住，异常处理的花费，大头不是 throw，而是逐层捕获时那个需要大量反射元数据的栈帧快照。

自动装箱与拆箱：对象的悄悄出生与死亡

Integer i = 0; i++;看似简单，实际发生了两次装箱、一次拆箱、一次 int 加法。在累加循环中，这种操作会产生数百个临时 Integer 对象。虽然现代 JIT 能通过逃逸分析消除部分分配，但在未分层编译时或对象逃逸时依然会真实分配。更头疼的是，自动装箱还容易引发null指针——拆箱时若值为 null，直接 NPE 且难以排查。

规避方法很简单：在性能关键路径上，把包装类型换成原始类型。集合框架需要泛型时，使用 IntStream、LongStream 或第三方原始类型集合（如 Eclipse Collections）。如果非用包装类型不可，至少复用缓存值或避免在循环体内创建新实例。JVM 对 Integer 缓存范围是 -128 到 127，超出范围的装箱每次都新建对象，这个细节很多人会忽略。

集合初始容量：扩容是看不见的性能杀手

ArrayList 默认容量是 10，如果你知道数据会达到上万条，那么每次扩容都要复制整个底层数组，大小呈 1.5 倍增长。最终你会发现，明明只是添加数据，却多做了十几次数组批量复制。HashMap 的扩容更夸张，不仅要重建数组，还要重新计算哈希、重新挂链或重建红黑树，在并发场景下还可能触发并发修改异常。

经验法则是：预估集合大小并设置初始容量。对于 HashMap，设置初始容量为元素数 / 0.75f + 1，避免 resize 的连锁开销。很多人误以为初始容量设大会浪费内存，实际上 JVM 分配数组是惰性的，初始容量过大只是预先生成大的连续数组，并不显著增加常驻内存。但不要盲目设大，一亿容量的列表直接打爆堆内存也常见。关键还是精准预测。

无界线程池：并发优雅背后的资源诅咒

Executors.newCachedThreadPool()或newFixedThreadPool不传队列上限，等于邀请线程无限增长。线程的创建和销毁需要操作系统调用，每个线程默认栈大小 1MB，1000 个线程就是 1GB 的虚拟内存。更重要的是，线程过多会导致 CPU 上下文切换开销急剧上升，甚至比业务执行还耗时。很多系统明明配置了 64 核，却因为线程池无界，性能反而不如 4 核下的适量线程。

规避方法：使用有界线程池，并显式定义阻塞队列的容量和拒绝策略。ThreadPoolExecutor的参数不是随便填的，核心线程数、最大线程数、队列长度之间需要根据任务类型（CPU密集、IO密集）动态测算。IO密集型的线程数可以设为CPU核心数 (1 + 等待时间/计算时间)。在核心业务上，建议使用虚拟线程（JDK 21+）进一步降低线程开销，但即便如此，也要控制并发任务总数，防呆不防傻。

过度同步与锁竞争：拿大炮打蚊子

synchronized关键字用起来太方便，于是很多人不加思考地把整个方法锁住。但锁的粒度越大，竞争越激烈，线程等待时间越长。甚至在某些场景下，锁竞争导致的线程阻塞比业务本身慢一个数量级。JVM 的偏向锁、轻量级锁在低竞争时有优化，但在高竞争时重量级锁直接交给操作系统，用户态与内核态切换的代价巨大。

规避方法：尽量缩小同步块，只锁需要保护的数据。优先使用ReentrantReadWriteLock或StampedLock来区分读写，读多写少场景下性能提升明显。如果只是做原子计数，直接用AtomicLong或LongAdder，后者在争用激烈时通过分散热点来降低冲突。更进一步，考虑使用无锁数据结构（如ConcurrentLinkedQueue）或采用副本分离、ThreadLocal 等技术避免共享。不要迷信“同步是安全的”，同步只是让数据变得一致，而性能损失是实打实的。

大对象与频繁 GC：堆内存的慢性死亡

在 Java 里，大对象（比如大数组、大字符串、大集合）会直接进入老年代。如果每次请求都创建一个大对象，老年代空间很快被占满，然后触发 Full GC。Full GC 通常是 Stop-The-World 的，停顿几百毫秒甚至几秒，对在线服务是致命的。更隐蔽的是，那些被频繁创建的短生命周期对象，如果逃逸分析失败，会被晋升到老年代，造成“无形垃圾”堆积。

规避方法：采用池化技术复用大对象，尤其是字节数组、缓冲区。Netty 里用 ByteBuf 池化，Tomcat 里对连接和缓冲进行复用，都是这个原理。对于小对象，尽量保证它们不会逃逸到方法外部，JIT 的逃逸分析能帮我们做标量替换，但前提是代码写得不复杂。另外关注-Xms和-Xmx设置，初始堆大小与最大堆大小不一致时，扩容和缩容也会触发 STW。把堆大小一次性设置到位，比频繁调整更安全。还要注意避免在 finalize 或 Cleaner 中做清理，那会让 GC 负担加倍。

I/O 资源：未关闭的流与盲目的 NIO

很多人写完FileInputStream忘了 close，或者在 finally 里手动 close 但忘了处理异常。资源泄漏最终导致文件描述符耗尽，系统报“Too many open files”，这是灾难级故障。但在 Java 7 之后，try-with-resources 已经完美解决了这个问题，可有人仍然在手动关闭时忽略异常链，导致资源没被释放。NIO 里更常见的问题是使用ByteBuffer不当，比如allocateDirect创建的堆外内存不受 JVM 堆限制，如果不及时回收，会直接耗尽本机内存，引发OutOfMemoryError: Direct buffer memory。

规避方法：所有实现了 AutoCloseable 的资源，一律放入 try-with-resources。检查代码中是否存在Files.readAllLines这类便捷方法，它们会一次性把整个文件加载进内存，大文件时就爆了。改用Files.newBufferedReader逐行读取。对于直接缓冲区，必须配合显式的回收逻辑，或者依赖 Netty 的池化 Buffer 机制。IO 性能的瓶颈从来不是读写速度，而是资源的创建与销毁方式。

Stream 与并行流：函数式优雅的沉重代价

Stream API 让代码变得简洁，但滥用parallelStream()的案例比比皆是。默认并行流使用ForkJoinPool.commonPool()，线程数是 CPU 核心数减一。如果每个任务都是 CPU 密集型，并行流反而因为线程切换和任务切分开销变慢；如果任务包含阻塞 IO，公共池会被占满，其他无关任务也跟着遭殃。还有人在Stream.iterate里做无限流限制，或者用collect拼接大量小对象，性能远低于传统循环。

规避方法：在数据量足够大（通常超过 10 万）且计算耗时明显时，才考虑并行流。永远不要共享 ForkJoinPool，自己创建专用ForkJoinPool并设置合适的并行度。将流操作中的中间步骤尽量合并，减少遍历次数。对于复杂集合操作，传统的for循环在 JIT 优化后往往比 Stream 更快，但如果你更看重代码可读性，至少要先测量，别让“优雅”成为性能下沉的借口。

反射与动态代理：灵活性的增值税

反射调用方法比直接调用慢一两个数量级，因为需要解析类元数据、安全检查、参数包装。现代 JDK 对反射做了优化（比如方法句柄和常量池可缓存），但依然无法消除本质上的动态查找。Spring AOP 动态代理、MyBatis 的 Mapper 代理，几乎每个框架都在用反射和动态代理，这确实带来了巨大的灵活性，但如果你在业务代码中过度依赖反射，比如每个请求都动态生成代理对象，那性能损耗就会成为瓶颈。

规避方法：对于频繁使用的反射调用，缓存Method对象或MethodHandle。尽量在启动阶段完成反射初始化，运行时只执行invoke。如果性能要求极高，可以考虑使用LambdaMetafactory生成函数式接口，把反射调用编译为普通调用。动态代理方面，JDK 代理比 CGLIB 更轻，但只能代理接口，如果不需要额外逻辑，用静态绑定更好。Beans 转换这种场景，MapStruct等编译期工具彻底消除了反射，比BeanUtils.copyProperties快几十倍。代码里一旦出现getMethod或newProxyInstance，请立刻警觉——你在为灵活性支付高额税率。

性能问题从来不是孤立存在的，它们像藤蔓一样纠缠在一起：不合理的集合容量导致频繁扩容，扩容又引起 GC 压力，GC 停顿又放大线程池的阻塞效应。当你意识到陷阱就在那里，规避它们就已经成功了 50%。另 50% 在于，用真实的压测去验证每一次优化，而不是靠感觉和猜想来修改代码。在 Java 的世界里，最好的性能优化，是让代码的结构足够简单，让 JIT 和 GC 能发挥它们应有的聪明才智。剩下的，就是我们自己避免给运行时添堵。