JVM堆内存分代管理，非连续空间：Young Gen（Eden、S0、S1）、Old Gen和Metaspace；对象优先分配Eden，触发Minor GC后存活对象复制或晋升，大对象可直接入Old Gen；字符串字面量存常量池，new String("abc")仅在堆建引用对象；Allocation Failure是GC正常触发提示，非OOM；逃逸分析可能使对象栈上分配。
堆内存不是“一整块连续空间”而是分代管理
很多人以为 new Object() 就是直接在堆里找个空位放进去，其实 JVM 堆被划为 Young Gen（含 Eden、S0、S1）、Old Gen 和（可选）Metaspace（JDK 8+，原永久代）。对象优先分配在 Eden 区，而不是整个堆的任意位置。
关键点：
- Eden 区满时触发
Minor GC，存活对象复制到 S0 或 S1； - 对象年龄达阈值（默认 15）或 S 区放不下时，晋升至 Old Gen；
- 大对象（如长数组）可能直接进入 Old Gen（由
-XX:PretenureSizeThreshold控制）； -
-Xms和-Xmx设置的是堆总大小，但各代比例由-XX:NewRatio或-XX:SurvivorRatio决定，不是均分。
为什么 new String("abc") 可能不分配堆内存
字符串字面量 "abc" 在编译期就进入字符串常量池（JDK 7+ 在堆中，JDK 6 在永久代），new String("abc") 才会在堆上创建新对象。但这个“新对象”只包含一个指向常量池中 "abc" 的引用，真正字符内容不重复拷贝。
容易混淆的操作：
立即学习“Java免费学习笔记（深入）”；
-
String s1 = "abc"; String s2 = "abc";→s1 == s2为true（都指向常量池同一实例）； -
String s3 = new String("abc");→s1 == s3为false（堆对象 ≠ 常量池对象），但s1.equals(s3)为true； - 频繁用
new String(str)会无谓增加 Young Gen 压力，尤其在循环中。
GC 日志里看到 “Allocation Failure” 并不等于 OOM
Allocation Failure 是 GC 触发的常规原因，表示 Eden 区无法容纳新对象，JVM 按策略回收并尝试分配——它只是 GC 日志的固定提示语，不是错误。
真正危险的信号是：
- GC 频率陡增（如每秒多次 Minor GC）；
- Old Gen 使用率持续 >90% 且不下降；
- Full GC 后 Old Gen 使用率几乎不变（说明有内存泄漏）；
- 出现
java.lang.OutOfMemoryError: Java heap space才是堆真正耗尽。
用 -XX:+PrintGCDetails -Xloggc:gc.log 开启日志后，别一看到 “Allocation Failure” 就 panic。
对象分配不只看大小，还受逃逸分析影响
JVM 在 JIT 编译阶段可能做逃逸分析：如果发现某个对象的引用 never 逃出当前方法作用域，就可能将其分配在栈上（标量替换），甚至完全优化掉（栈上分配 + 栈内消除）。
这意味着：
-
new ArrayList()在简单 for 循环中可能根本不出现在堆上； - 该优化默认开启（
-XX:+DoEscapeAnalysis），但仅限 server 模式且需运行足够时间触发 C2 编译； - 加了
synchronized或传入线程不安全容器，逃逸分析大概率失效； - 不能依赖它来“规避 GC”，它只是优化手段，行为不可控、不可预测。
堆内存分配策略背后是分代假设、局部性原理和运行时反馈的混合结果，静态代码看不出真实分配路径，得结合 GC 日志和 JFR 数据才能确认。
