同一个应用，同一套测试，同一个 JDK，没改架构。优化前：1198ms，优化后：239ms。吞吐量从 8.5 万飙到 41.9 万订单/秒。这不是魔法，这是找茬的艺术。
🎯 8 个让 Java"变慢"的隐形杀手
1️⃣ 循环里玩字符串拼接？你在堆内存里跑马拉松
// ❌ 别这么干，每次+都新建对象，10000次循环=5000万次字符拷贝
String report = "";
for (String line : logLines) {
report = report + line + "\n"; // O(n²) 的痛
}
// ✅ StringBuilder：一个缓冲区搞定，优雅永不过时
StringBuilder sb = new StringBuilder();
for (String line : logLines) {
sb.append(line).append("\n");
}
2️⃣ Stream 套循环？你在给 CPU 办健身卡
// ❌ 每个订单都遍历全列表，10000订单=1亿次比较
for (Order order : orders) {
long count = orders.stream() // 每次都是全量扫描
.filter(o -> sameHour(o, order)).count();
}
// ✅ 一次遍历搞定，O(n) 真香
for (Order order : orders) {
int hour = getHour(order);
ordersByHour.merge(hour, 1L, Long::sum); // 直接累加
}
3️⃣ String.format 在热路径？你在用显微镜拧螺丝
String.format() 每次都要解析格式字符串+正则匹配+Formatter 全家桶，慢就一个字。数字格式化用它，其他部分让编译器优化，或者直接用 StringBuilder。
4️⃣ 自动装箱在循环里？你在给 GC 发年终奖
// ❌ 每次循环都创建新 Long 对象，100 万次=16MB 堆内存垃圾
Long sum = 0L;
for (Long v : values) {
sum += v; } // 拆箱→计算→装箱，三连击
// ✅ 用原始类型，简单粗暴最有效
long sum = 0L;
for (long v : values) {
sum += v; }
5️⃣ 用异常当流程控制？你在给 fillInStackTrace 开派对
异常构造时要遍历整个调用栈生成堆栈信息，高频调用时这就是性能黑洞。先校验再 parse，别等异常了才后悔。
6️⃣ 同步锁范围太大？你在让线程排队买奶茶
// ❌ 整个方法同步，所有线程串行执行
public synchronized void increment(String key) {
... }
// ✅ ConcurrentHashMap + LongAdder，并发友好型组合
private final ConcurrentHashMap<String, LongAdder> counts = new ConcurrentHashMap<>();
public void increment(String key) {
counts.computeIfAbsent(key, k -> new LongAdder()).increment();
}
7️⃣ 重复创建"可复用"对象？你在每次吃饭都买新筷子
ObjectMapper、DateTimeFormatter、Gson 这些对象初始化成本很高，构造一次，复用一生。记得加 static final，线程安全且高效。
8️⃣ 虚拟线程 + synchronized + 阻塞 IO？你在给载体线程"上镣铐"（JDK 21-23）
虚拟线程遇到 synchronized 里的阻塞操作会被"钉住"，载体线程无法服务其他任务。解决方案：用 ReentrantLock 替代 synchronized，或者升级到 JDK 24+（JEP 491 已修复）。
🔍 怎么发现这些问题？
别猜，用数据说话！开启 Java Flight Recording (JFR)，看火焰图，找热点方法。那些"看起来没问题"的代码，在性能剖析器面前无所遁形。
💡 最后说句大实话
这些反模式不会让程序崩溃，它们只是悄悄地让你的应用变慢。单次执行差几毫秒，乘以百万级请求，就是用户体验的鸿沟。
🎯 记住：Java 很快，但你的代码可能在不自觉地"拖后腿"。定期性能剖析，让优化有据可依，别让"能跑"变成"跑得慢"。
你踩过哪个坑？欢迎在评论区分享你的"性能血泪史" 👇
