性能翻车？揪出这5个隐藏的 Java 内存陷阱！

你以为 JVM 能自动搞定一切？这些暗坑分分钟让内存炸成烟花儿！

作为 Java 老司机，总以为 JVM 的 GC（垃圾回收）能自动处理内存。但真相是------有些坑连监控工具都难发现 ，直到某天服务卡死，日志里蹦出 OutOfMemoryError... 今天咱们就手撕代码，挖出这5个高频内存陷阱！

---

**陷阱1：字符串拼接的问题

这种骚操作方式估计很多人使用过，刚开始当java牛马时，我也是这么干的！

问题 ：String str = "a" + "b" + "c"; 这种写法在循环中会产生大量临时对象 ！
原理 ：每次 + 操作都生成新 String 对象，循环 1 万次就浪费 1 万个对象空间！

// 错误示范
String result = "";
for (int i = 0; i < 100000; i++) {
    result += i; // 每次循环创建新对象！
}

//  正确写法：用 StringBuilder
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++) {
    sb.append(i);
}
String result = sb.toString();

实测 ：循环 10 万次时，错误代码耗时 24510ms ，正确代码仅 9ms！

现在说说哪个爽？告诉我！

---

陷阱2：自动装箱的"堆内存刺客"

当后端接口返回的list对象时，给list赋值，你是不是经常也用的add,反正我是经常用！哈哈

问题 ：无意识的装箱操作（如 Integer vs int）在集合中疯狂吃内存！
示例 ：List<Integer> 存 100 万个数字，占用空间是 int[] 的 4 倍以上！

避坑 ：高频访问的数据（如缓存）优先用 int/long，集合类慎用包装类型！

---

陷阱3：静态集合的"内存泄漏黑洞"

问题 ：static Map 或 static List 引用未清理的对象，导致 GC 无法回收！

// 错误示范：内存泄漏！
public class UserCache {
    private static Map<Long, User> cache = new HashMap<>(); // ⚠ 静态 Map 常驻内存
    
    public void addUser(User user) {
        cache.put(user.getId(), user);
    }
    // 缺少移除逻辑！User 对象永远无法释放
}

//  正确姿势1：用 WeakHashMap（GC 自动回收）
private static Map<Long, User> cache = new WeakHashMap<>();

//  正确姿势2：定期清理 + LRU 策略
private static Map<Long, User> cache = new LinkedHashMap<>() {
    @Override
    protected boolean removeEldestEntry(Map.Entry eldest) {
        return size() > MAX_SIZE; // 超过容量自动删除旧数据
    }
};

关键点：长生命周期集合（如全局缓存）必须设计淘汰策略！

---

陷阱4：未关闭资源的引用

问题：文件流、数据库连接未关闭，不仅占内存，还可能导致句柄耗尽！

// 错误示范：文件流忘记关闭！
try {
    FileInputStream fis = new FileInputStream("largefile.txt");
    // 读取操作...
    // 忘记 fis.close()！JVM 无法释放非堆内存（直接内存）
} catch (IOException e) { /*...*/ }

//  正确操作：用 try-with-resources（自动关闭）
try (FileInputStream fis = new FileInputStream("largefile.txt")) {
    // 读取操作...
} catch (IOException e) { /*...*/ }

注意 ：连接池（如数据库）必须用 finally 块或框架注解（如 @Transactional）确保归还！

---

陷阱5：hashCode/equals 的"键冲突"

问题 ：自定义对象作为 Map 的 Key 时，错误的 hashCode/equals 会拖垮性能！

class Product {
    private String id;
    // 错误示范：未重写 hashCode/equals
}

Map<Product, Integer> cart = new HashMap<>();
cart.put(new Product("A001"), 1); 
// 每次 new Product("A001") 都是不同 Key！导致哈希冲突链变长，查询性能 O(1)→O(n)

原则：

1. 重写 equals 必须重写 hashCode
2. hashCode 计算用相同字段组合
3. 关键字段用 final 保证不可变

//  正确解法
@Override
public int hashCode() {
    return Objects.hash(id); // 保证相同 id 返回相同哈希值
}

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Product product = (Product) o;
    return Objects.equals(id, product.id);
}

---

总结

其实上述说的这5个问题，我们经常在做开发的时候遇到，感觉像是有爱"坑"情节一样，回回都往里跳呢啊！你啥时候能跳出来，真是的！ 再附一个上述的思维导图看一下，再别跳了哦！

graph TD A[Java 内存陷阱] --> B[字符串拼接] A --> C[自动装箱] A --> D[静态集合泄漏] A --> E[未关闭资源] A --> F[hashCode/equals错误] B --> G[用 StringBuilder] C --> H[优先原始类型数组] D --> I[WeakHashMap/LRU淘汰] E --> J[try-with-resources] F --> K[重写hashCode+equals]

---