Oracle HotSpot JVM Memory
Java HotSpot VM Heap space
Oracle Java 热点虚拟机中不同 Java 堆内存空间的高级概览。鉴于内存问题的频繁出现，对于任何参与生产支持的人来说，理解这一点非常重要。正确理解 Java VM 堆空间至关重要。您的 Java VM 基本上是 Java 程序的基础，为您提供动态内存管理服务、垃圾收集、线程、I/O 和本机操作等功能。Java 堆空间是运行时 Java 程序的内存“容器”，为您的 Java 程序提供所需的适当内存空间（包括 Java 堆和本地堆），并由 JVM 自身管理。
JVM HotSpot虚拟机的内存分为3个内存空间：
- The Java Heap —— Java堆
- The Metaspace 元空间（metaspace） / The PermGen (permanent generation) space —— PermGen（永久生成空间）
- The Native Heap (C-Heap) —— 本地堆（C-Heap）
内存空间分布
| 内存空间 | 启动参数 | 监控策略 | 描述 |
| Java堆 | -Xmx（最大堆空间）-Xms（最小堆尺寸）EX：-Xmx1024m -Xms1024m | verbose GC、JMX API、JConsole | Java堆正在存储您的主Java程序类实例。 |
| 本地堆（C-Heap） | 不能直接配置。对于32位虚拟机，CHeap容量=4Gig-Java堆为64位虚拟机，CHeap容量=物理服务器总内存和虚拟内存-Java堆 | svmon命令是在AIX操作系统上用于监视内存使用情况的命令。通过svmon命令，可以查看系统中进程的内存使用情况、虚拟内存使用情况、分页空间情况等。 | C-Heap正在存储类元数据对象，包括库文件、其他JVM和第三方本机代码对象。 |
- verbose GC选项可以在控制台上输出详细的垃圾回收信息，包括垃圾回收的时间、频率以及内存清理情况，有助于开发人员分析程序的内存使用情况以及垃圾回收的效率，从而优化程序的性能。
- JMX API（Java Management Extensions）是Java平台的一项管理和监控技术，它提供了一套标准的API，用于监控和管理应用程序、设备和服务。通过JMX API，开发人员可以在运行时获取JVM的状态信息，进行性能检测、故障诊断等操作。
- JConsole是Java自带的一款监控工具，通过JMX技术实现对Java应用程序的监控。开发人员可以使用JConsole来查看应用程序的内存使用情况、线程情况、类加载情况等，还可以通过JConsole执行一些轻量级的分析和管理操作。同时，JConsole也可以通过JMX连接到远程JVM，对远程应用程序进行监控和管理。
注意 C-Heap正在存储类元数据对象，包括库文件、其他JVM和第三方本机代码对象，Oracle也将开始删除热点VM的PermGen空间。
内存分布图
Oracle JRockit JVM Memory
JRockit VM内存被分成两个内存空间：
- Java堆（YoungGen和OldGen）
- 本机内存空间（类池、C-Heap、线程）
内存空间分布
| 内存空间 | 启动参数 | 监控策略 | 描述 |
| Java堆 | -Xmx（最大堆空间）-Xms（最小堆尺寸）EX：-Xmx1024m -Xms1024m | verbose GC、JMX API、JConsole | JRockit Java堆通常被分为年轻Gen（短寿命对象）和OldGen（长寿命对象）。 |
| 本机内存空间 | 不能直接配置。对于32位虚拟机，本地内存空间容量=2-4gig-Java堆进程大小限制为2 GB，3 GB或4 GB，这取决于您的操作系统对于64位虚拟机，本地内存空间容量=物理服务器总内存和虚拟内存-Java堆 | 总进程大小检查在窗口和Linux，pmap命令在Solaris和Linux - JRockit JRCMD工具 | JRockit本机内存空间正在存储Java类元数据、线程和对象，如库文件、其他JVM和第三方本机代码对象。 |
与IBM VM类似，JRockit VM没有PermGen空间 / metaspace空间。他们仅适用于热点虚拟机。JRockit VM使用本地堆处理类元数据相关数据。
JRockit VM倾向于使用更多的本地内存来换取更好的性能。JRockit没有一个解释模式，只有编译，所以由于它的额外的本机内存需求，进程大小往往使用比同等的Sun JVM大小大几百MB。
这应该不是一个大问题，除非您使用具有大型Java堆要求的32位JRockit；在这种情况下，JRockit虚拟机由于本机堆耗尽导致的内存错误的风险更高（例如对于32位虚拟机，Java堆越大，本机堆剩余的内存更小）。Oracle作为热点spot和JRockit产品线的供应商，其战略是将两个视频管理系统合并到一个JVM项目中，该项目将包含每个项目的最佳特性。这也将简化JVM调优，因为目前不理解这2VM之间的差异可能会导致糟糕的调优建议和性能问题。
关于正确的Java堆大小的提示
由于Java堆容量和调优不足，可能会出现多种性能问题。帮助您确定当前或新的生产环境的最佳Java堆大小，作为起点。其中一些技巧对于预防和解决内存外错误问题也非常有用，包括内存泄漏。
JVM —— 你总是害怕你不理解的东西
如何期望配置、调整和排除您不了解的问题？您可能永远没有机会编写和改进Java VM规范，但您仍然可以自由地学习它的基础，以提高您的知识和故障排除技能。有些人可能不同意，但从我看来，认为Java程序员不需要知道内部JVM内存管理的想法是一种错觉。
Java VM内存管理比通过-xmx尽可能地设置最大的价值要复杂得多。您必须从各个角度来看，包括您的本地和PermGen空间需求，以及来自物理主机的物理内存可用性（和CPU内核）。
操作系统位数
- 32位JVM来说，这尤其棘手，因为Java Heap和本机Heap正在竞争中。您的Java堆越大，本地堆就越小。尝试为一个32位虚拟机设置一个大的堆，例如2.5GB+会增加本机内存错误的风险，这取决于您的应用程序占用、线程数量等。
- 64位JVM解决了这个问题，但您仍然仅限于物理资源的可用性和垃圾收集开销（主要GC收集的成本随着大小的增加而上升）。底线是越大并不总是越好，所以请不要假设您可以在一个16GB 64位JVM 上运行所有的20个Java EE应用程序。
业务流量设置规则：检查动态内存占用需求
您的业务流量通常会决定您的动态内存占用空间。并发用户和请求生成JVM GC“心跳”，您可以从各种监视工具中观察到，因为短期和长期寿命对象的创建和垃圾收集非常频繁。
"正如您在上面的JVM图中看到的，Young Generation（年轻代）和Old Generation（老年代）的比例通常为1：3，或者是33%。对于典型的32位JVM，当设置Java Heap大小为2GB时（使用分代和并发收集器），通常会分配500MB给YoungGen空间，而OldGen空间则分配1.5GB。
尽可能减少主要的GC集合频率是实现最佳性能的关键因素，因此理解并估计在峰值负载期间需要多少内存非常重要。同时，您的应用程序和数据类型将决定您需要的内存量。对于需要大量Java堆和大量OldGen空间的应用程序，例如处理大型和非序列化会话数据（long-lived objects）的购物车类型应用程序，通常需要大量内存。而对于无状态和处理大量短命对象的XML应用程序，适当的YoungGen空间则至关重要，以最大程度地减少主要集合的频率。"
