一、JVM堆内存结构概览JVM将堆内存划分为几个不同的区域每个区域有着不同的用途和回收策略1.1 新生代Young Generation新生代是大多数对象创建和消亡的地方。它进一步分为三个区域Eden空间新创建的对象首先分配在这里。绝大多数的对象生命周期很短会在Eden区被创建和回收。Survivor空间From和ToEden区经过一次Minor GC后存活的对象会被移到Survivor区。两个Survivor区From和To始终保持一个为空用于复制算法。新生代Minor GC当Eden区空间不足时会触发Minor GC也称为Young GC。由于大部分对象生命周期短Minor GC通常非常高效。1.2 老年代Old Generation / Tenured Space老年代用于存放经过多次Minor GC后仍然存活的对象或者大对象如大数组可能会直接分配到老年代。老年代Major GC当老年代空间不足时会触发Major GC也称Full GC。Full GC通常比Minor GC慢得多应尽量减少其发生频率。1.3 元空间Metaspace- JDK 1.8的变化在JDK 1.8之前这部分被称为永久代Permanent Generation用于存放类的元数据、常量池等。在JDK 1.8及以后永久代被移除取而代之的是元空间Metaspace元空间不再位于JVM堆内而是使用本地内存Native Memory默认情况下元空间的大小只受本地内存限制可以通过-XX:MetaspaceSize和-XX:MaxMetaspaceSize来控制二、堆内存的核心配置参数2.1 最大堆和初始堆的设置-Xms / -Xmx当Java进程启动时虚拟机会分配一块初始堆空间。如果初始堆不够用堆空间会逐步扩展直到达到最大堆空间上限。参数含义示例-Xms初始堆大小-Xms512m-Xmx最大堆大小-Xmx2g最佳实践建议将-Xms和-Xmx设置为相同的值。这样可以减少程序运行时堆空间动态扩容和缩容的开销从而提高性能。注意实际通过Runtime.getRuntime().maxMemory()获取的值会略小于-Xmx设定值因为部分空间被JVM用于垃圾回收等内部管理。2.2 新生代大小配置-Xmn-Xmn参数用于设置新生代的大小-Xmn1g # 新生代分配1GB新生代的大小建议设置为整个堆空间的1/3 到 1/4左右。设置过大则会减小老年代的大小可能导致频繁的Full GC设置过小则会导致对象过早晋升到老年代。2.3 SurvivorRatioEden与Survivor的比例-XX:SurvivorRatio用于设置Eden区与单个Survivor区的比例-XX:SurvivorRatio Eden / From Eden / To默认值为8即 Eden : From : To 8 : 1 : 1Eden占新生代的80%。示例设置-XX:SurvivorRatio2则 Eden : From : To 2 : 1 : 1Eden占新生代的50%。2.4 NewRatio老年代与新生代的比例-XX:NewRatio用于设置老年代与新生代的比例-XX:NewRatio 老年代 / 新生代默认值为2即老年代 : 新生代 2 : 1新生代占堆的1/3。示例-XX:NewRatio3表示老年代 : 新生代 3 : 1新生代占堆的1/4。2.5 各参数关系速查表参数作用默认值-Xms初始堆大小物理内存的1/64-Xmx最大堆大小物理内存的1/4-Xmn新生代大小堆的1/3~1/4-XX:SurvivorRatioEden/Survivor比例8-XX:NewRatio老年代/新生代比例2三、实战案例分析案例1观察堆内存分配过程public class HeapAlloc { public static void main(String[] args) { // 打印初始内存状态 System.out.println(maxMemory Runtime.getRuntime().maxMemory()); System.out.println(free mem Runtime.getRuntime().freeMemory()); System.out.println(total mem Runtime.getRuntime().totalMemory()); // 分配1MB byte[] b new byte[1 * 1024 * 1024]; System.out.println(分配了1M空间给数组); System.out.println(maxMemory Runtime.getRuntime().maxMemory()); System.out.println(free mem Runtime.getRuntime().freeMemory()); System.out.println(total mem Runtime.getRuntime().totalMemory()); // 分配4MB b new byte[4 * 1024 * 1024]; System.out.println(分配了4M空间给数组); System.out.println(maxMemory Runtime.getRuntime().maxMemory()); System.out.println(free mem Runtime.getRuntime().freeMemory()); System.out.println(total mem Runtime.getRuntime().totalMemory()); } }运行参数-Xmx20m -XX:PrintGCDetails -XX:PrintCommandLineFlags观察要点maxMemory始终不超过-Xmx设定值totalMemory从-Xms开始根据使用情况逐步增长当堆内存不足时会触发GC进行回收案例2新生代大小对GC的影响public class NewSizeDemo { public static void main(String[] args) { byte[] b null; for (int i 0; i 10; i) { b new byte[1 * 1024 * 1024]; } } }场景A新生代过小-Xmn2m -XX:SurvivorRatio2新生代总大小只有2MBEden区为1MB无法容纳1MB的数组对象导致频繁触发Minor GC大部分数组直接分配到老年代❌后果老年代很快被填满后续可能触发Full GC影响性能。场景B合理的新生代大小-Xmn8m -XX:SurvivorRatio2新生代足够容纳对象Minor GC可以正常回收失效对象3次Minor GC所有数组在新生代完成分配和回收老年代几乎无占用✅效果对象优先在新生代分配减少老年代压力。场景C更大的新生代-Xmn20m -XX:SurvivorRatio8Eden区高达16MB足以容纳所有10MB数组零次GC所有对象分配在Eden区程序结束时Eden区仍有空间✅最佳效果无GC开销性能最优。案例3堆溢出与Heap Dumpimport java.util.Vector; public class DumpOOM { public static void main(String[] args) { Vectorbyte[] v new Vector(); for (int i 0; i 25; i) { v.add(new byte[1 * 1024 * 1024]); } } }运行参数-Xmx20m -Xms5m -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPathd:/a.dump当堆内存耗尽时会触发OutOfMemoryError并导出堆转储文件。使用MATMemory Analyzer Tool等工具分析后可以清楚定位到内存累积点Vector对象持有大量byte[]引用泄漏嫌疑main线程的局部变量累积了约14.68MB内存四、生产环境配置参考以Nacos启动脚本为例可以看到典型的JVM参数配置JAVA_OPT$JAVA_OPT -server -Xms2g -Xmx2g -Xmn1g JAVA_OPT$JAVA_OPT -XX:MetaspaceSize128m -XX:MaxMetaspaceSize320m JAVA_OPT$JAVA_OPT -XX:HeapDumpOnOutOfMemoryError JAVA_OPT$JAVA_OPT -XX:HeapDumpPath$BASE_DIR/logs/java_heapdump.hprof JAVA_OPT$JAVA_OPT -XX:-OmitStackTraceInFastThrow JAVA_OPT$JAVA_OPT -XX:-UseLargePages参数解读参数说明-server启用Server模式性能更优-Xms2g -Xmx2g初始堆最大堆2GB避免动态扩缩容-Xmn1g新生代1GB约占堆的50%-XX:MetaspaceSize128m元空间初始128MB-XX:MaxMetaspaceSize320m元空间最大320MB-XX:HeapDumpOnOutOfMemoryErrorOOM时导出堆转储-XX:HeapDumpPath...堆转储文件路径-XX:-OmitStackTraceInFastThrow不省略异常堆栈便于调试五、核心要点总结内存模型堆 新生代 老年代JDK 1.8 用元空间替代永久代新生代 Eden From Survivor To Survivor对象优先分配在Eden区大对象可直接进入老年代Minor GC清理新生代Major GC/Full GC清理老年代参数配置原则-Xms与-Xmx建议相等减少动态调整开销新生代大小建议为堆的1/3~1/4SurvivorRatio默认8比较合理可根据对象存活率调整生产环境务必开启HeapDumpOnOutOfMemoryError性能优化思路尽量让对象在新生代完成生命周期避免晋升到老年代减少Full GC的频率因为Full GC通常更耗时通过GC日志分析找出内存分配的瓶颈常用JVM参数速查# 堆大小 -Xms512m -Xmx2g # 新生代 -Xmn512m # 比例配置 -XX:SurvivorRatio8 -XX:NewRatio2 # GC日志 -XX:PrintGCDetails -XX:PrintGCDateStamps # OOM处理 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump.hprof # 元空间JDK 1.8 -XX:MetaspaceSize128m -XX:MaxMetaspaceSize256m
一、JVM堆内存结构概览JVM将堆内存划分为几个不同的区域每个区域有着不同的用途和回收策略1.1 新生代Young Generation新生代是大多数对象创建和消亡的地方。它进一步分为三个区域Eden空间新创建的对象首先分配在这里。绝大多数的对象生命周期很短会在Eden区被创建和回收。Survivor空间From和ToEden区经过一次Minor GC后存活的对象会被移到Survivor区。两个Survivor区From和To始终保持一个为空用于复制算法。新生代Minor GC当Eden区空间不足时会触发Minor GC也称为Young GC。由于大部分对象生命周期短Minor GC通常非常高效。1.2 老年代Old Generation / Tenured Space老年代用于存放经过多次Minor GC后仍然存活的对象或者大对象如大数组可能会直接分配到老年代。老年代Major GC当老年代空间不足时会触发Major GC也称Full GC。Full GC通常比Minor GC慢得多应尽量减少其发生频率。1.3 元空间Metaspace- JDK 1.8的变化在JDK 1.8之前这部分被称为永久代Permanent Generation用于存放类的元数据、常量池等。在JDK 1.8及以后永久代被移除取而代之的是元空间Metaspace元空间不再位于JVM堆内而是使用本地内存Native Memory默认情况下元空间的大小只受本地内存限制可以通过-XX:MetaspaceSize和-XX:MaxMetaspaceSize来控制二、堆内存的核心配置参数2.1 最大堆和初始堆的设置-Xms / -Xmx当Java进程启动时虚拟机会分配一块初始堆空间。如果初始堆不够用堆空间会逐步扩展直到达到最大堆空间上限。参数含义示例-Xms初始堆大小-Xms512m-Xmx最大堆大小-Xmx2g最佳实践建议将-Xms和-Xmx设置为相同的值。这样可以减少程序运行时堆空间动态扩容和缩容的开销从而提高性能。注意实际通过Runtime.getRuntime().maxMemory()获取的值会略小于-Xmx设定值因为部分空间被JVM用于垃圾回收等内部管理。2.2 新生代大小配置-Xmn-Xmn参数用于设置新生代的大小-Xmn1g # 新生代分配1GB新生代的大小建议设置为整个堆空间的1/3 到 1/4左右。设置过大则会减小老年代的大小可能导致频繁的Full GC设置过小则会导致对象过早晋升到老年代。2.3 SurvivorRatioEden与Survivor的比例-XX:SurvivorRatio用于设置Eden区与单个Survivor区的比例-XX:SurvivorRatio Eden / From Eden / To默认值为8即 Eden : From : To 8 : 1 : 1Eden占新生代的80%。示例设置-XX:SurvivorRatio2则 Eden : From : To 2 : 1 : 1Eden占新生代的50%。2.4 NewRatio老年代与新生代的比例-XX:NewRatio用于设置老年代与新生代的比例-XX:NewRatio 老年代 / 新生代默认值为2即老年代 : 新生代 2 : 1新生代占堆的1/3。示例-XX:NewRatio3表示老年代 : 新生代 3 : 1新生代占堆的1/4。2.5 各参数关系速查表参数作用默认值-Xms初始堆大小物理内存的1/64-Xmx最大堆大小物理内存的1/4-Xmn新生代大小堆的1/3~1/4-XX:SurvivorRatioEden/Survivor比例8-XX:NewRatio老年代/新生代比例2三、实战案例分析案例1观察堆内存分配过程public class HeapAlloc { public static void main(String[] args) { // 打印初始内存状态 System.out.println(maxMemory Runtime.getRuntime().maxMemory()); System.out.println(free mem Runtime.getRuntime().freeMemory()); System.out.println(total mem Runtime.getRuntime().totalMemory()); // 分配1MB byte[] b new byte[1 * 1024 * 1024]; System.out.println(分配了1M空间给数组); System.out.println(maxMemory Runtime.getRuntime().maxMemory()); System.out.println(free mem Runtime.getRuntime().freeMemory()); System.out.println(total mem Runtime.getRuntime().totalMemory()); // 分配4MB b new byte[4 * 1024 * 1024]; System.out.println(分配了4M空间给数组); System.out.println(maxMemory Runtime.getRuntime().maxMemory()); System.out.println(free mem Runtime.getRuntime().freeMemory()); System.out.println(total mem Runtime.getRuntime().totalMemory()); } }运行参数-Xmx20m -XX:PrintGCDetails -XX:PrintCommandLineFlags观察要点maxMemory始终不超过-Xmx设定值totalMemory从-Xms开始根据使用情况逐步增长当堆内存不足时会触发GC进行回收案例2新生代大小对GC的影响public class NewSizeDemo { public static void main(String[] args) { byte[] b null; for (int i 0; i 10; i) { b new byte[1 * 1024 * 1024]; } } }场景A新生代过小-Xmn2m -XX:SurvivorRatio2新生代总大小只有2MBEden区为1MB无法容纳1MB的数组对象导致频繁触发Minor GC大部分数组直接分配到老年代❌后果老年代很快被填满后续可能触发Full GC影响性能。场景B合理的新生代大小-Xmn8m -XX:SurvivorRatio2新生代足够容纳对象Minor GC可以正常回收失效对象3次Minor GC所有数组在新生代完成分配和回收老年代几乎无占用✅效果对象优先在新生代分配减少老年代压力。场景C更大的新生代-Xmn20m -XX:SurvivorRatio8Eden区高达16MB足以容纳所有10MB数组零次GC所有对象分配在Eden区程序结束时Eden区仍有空间✅最佳效果无GC开销性能最优。案例3堆溢出与Heap Dumpimport java.util.Vector; public class DumpOOM { public static void main(String[] args) { Vectorbyte[] v new Vector(); for (int i 0; i 25; i) { v.add(new byte[1 * 1024 * 1024]); } } }运行参数-Xmx20m -Xms5m -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPathd:/a.dump当堆内存耗尽时会触发OutOfMemoryError并导出堆转储文件。使用MATMemory Analyzer Tool等工具分析后可以清楚定位到内存累积点Vector对象持有大量byte[]引用泄漏嫌疑main线程的局部变量累积了约14.68MB内存四、生产环境配置参考以Nacos启动脚本为例可以看到典型的JVM参数配置JAVA_OPT$JAVA_OPT -server -Xms2g -Xmx2g -Xmn1g JAVA_OPT$JAVA_OPT -XX:MetaspaceSize128m -XX:MaxMetaspaceSize320m JAVA_OPT$JAVA_OPT -XX:HeapDumpOnOutOfMemoryError JAVA_OPT$JAVA_OPT -XX:HeapDumpPath$BASE_DIR/logs/java_heapdump.hprof JAVA_OPT$JAVA_OPT -XX:-OmitStackTraceInFastThrow JAVA_OPT$JAVA_OPT -XX:-UseLargePages参数解读参数说明-server启用Server模式性能更优-Xms2g -Xmx2g初始堆最大堆2GB避免动态扩缩容-Xmn1g新生代1GB约占堆的50%-XX:MetaspaceSize128m元空间初始128MB-XX:MaxMetaspaceSize320m元空间最大320MB-XX:HeapDumpOnOutOfMemoryErrorOOM时导出堆转储-XX:HeapDumpPath...堆转储文件路径-XX:-OmitStackTraceInFastThrow不省略异常堆栈便于调试五、核心要点总结内存模型堆 新生代 老年代JDK 1.8 用元空间替代永久代新生代 Eden From Survivor To Survivor对象优先分配在Eden区大对象可直接进入老年代Minor GC清理新生代Major GC/Full GC清理老年代参数配置原则-Xms与-Xmx建议相等减少动态调整开销新生代大小建议为堆的1/3~1/4SurvivorRatio默认8比较合理可根据对象存活率调整生产环境务必开启HeapDumpOnOutOfMemoryError性能优化思路尽量让对象在新生代完成生命周期避免晋升到老年代减少Full GC的频率因为Full GC通常更耗时通过GC日志分析找出内存分配的瓶颈常用JVM参数速查# 堆大小 -Xms512m -Xmx2g # 新生代 -Xmn512m # 比例配置 -XX:SurvivorRatio8 -XX:NewRatio2 # GC日志 -XX:PrintGCDetails -XX:PrintGCDateStamps # OOM处理 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump.hprof # 元空间JDK 1.8 -XX:MetaspaceSize128m -XX:MaxMetaspaceSize256m
 Pt.4：“人体工程学”的trait实现、包装类型(Wrapper Types)、`Borrow` trait)
)
![[具身智能-634]：Python 封装的地平线 VIO 多媒体库：libsrcampy库详解](http://pic.xiahunao.cn/yaotu/[具身智能-634]：Python 封装的地平线 VIO 多媒体库：libsrcampy库详解)
