jvm默认堆内存大小
本文目录一览jvm默认多大的对象是大对象JVM认为大对象的默认大小是多少？对象的内存分配-对象首先在Eden中分配。
如果Eden区域没有足够的空间可供分配，则虚拟机将启动MinorGC。

在testAllocation()方法中，尝试分配3个大小为2MB的对象和1个大小为4MB的对象，由三个参数-Xms20M、-Xmx20M和-limited指定。 运行时的Xmn10M为20MB，无法扩展。 10MB分配给新生代，剩余的10MB分配给老年代。 -XX:SurvivorRatio=8决定新生代中Eden区和survivor区的空间比例为8:1。 从输出结果中，可以清晰地看到“edenspace8192K、fromspace1024K、tospace1024K”的信息，新生代总可用空间为9216KB（Eden区总容量+1个survivor区）。 当执行testAllocation()中分配allocation4对象的语句时，会执行一次MinorGC。 这次GC的结果是新生代的6651KB变成了162KB，而总内存使用量几乎保不变（因为Allocation1、Location2、Allocation3这三个对象）都在运行。 ，虚拟机几乎没有可回收的对象。 这次GC的原因是在为allocation4分配内存时，Eden有6MB占用，剩余空间不足以分配allocation4所需的4MB内存，所以发生了MinorGC。 在GC过程中，虚拟机现有的3个2MB对象无法全部放入survivor空间（survivor空间只有1MB），所以不得不通过分配保证机提前转移到老年代。 这次GC之后，4MBAllocation4对象在Eden中成功分配。 因此，程序执行的结果是Eden占用4MB（allocation4占用），Survivor处于不活动状态，老年代占用6MB（allocation1、allocation2占用）。 ，和分配3)。

我们看一下使用ParallelScavenge收集器时的情况：

没有发生新生代GC，Assignment4直接分配给了老一辈。
对象的内存分配-大对象直接进入老年代-典型的大对象
非常的字符串和数组
对象内存分配-大物体直接进入老年——大物体噩梦
比遇到大物体更糟糕的消息是遇到一群“生存”的“转瞬即逝的大物体”。 大对象很容易导致在内存还剩下大量空间的情况下提前触发垃圾收集，以便获得足够的连续空间来“放置”这些对象。
对象的内存分配-大对象直接分配到老年代-基本
大于设置值-XX:PretenureSizeThreshold的对象直接分配到老年代。 目的是避免Eden区和两个Survivor区之间进行大量的内存复。

PretenureSizeThreshold设置为3MB（即3145728，该参数不能像-Xmx等参数那样直接写入3MB），所以超过3MB的对象会直接写入分配给老年代。
PretenureSizeThreshold参数仅对Serial和ParNew收集器有效。 ParallelScavenge收集器通常无法识别此参数。
如果Eden区域没有足够的空间可供分配，则虚拟机将启动MinorGC。

在testAllocation()方法中，尝试分配3个大小为2MB的对象和1个大小为4MB的对象，由三个参数-Xms20M、-Xmx20M和-limited指定。 运行时的Xmn10M为20MB，无法扩展。 10MB分配给新生代，剩余的10MB分配给老年代。 -XX:SurvivorRatio=8决定新生代中Eden区和survivor区的空间比例为8:1。 从输出结果中，可以清晰地看到“edenspace8192K、fromspace1024K、tospace1024K”的信息，新生代总可用空间为9216KB（Eden区总容量+1个survivor区）。 当执行testAllocation()中分配allocation4对象的语句时，会执行一次MinorGC。 这次GC的结果是新生代的6651KB变成了162KB，而总内存使用量几乎保不变（因为Allocation1、Location2、Allocation3这三个对象）都在运行。 ，虚拟机几乎没有可回收的对象。 这次GC的原因是在为allocation4分配内存时，Eden有6MB占用，剩余空间不足以分配allocation4所需的4MB内存，所以发生了MinorGC。 在GC过程中，虚拟机现有的3个2MB对象无法全部放入survivor空间（survivor空间只有1MB），所以不得不通过分配保证机提前转移到老年代。 这次GC之后，4MBAllocation4对象在Eden中成功分配。 因此，程序执行的结果是Eden占用4MB（allocation4占用），Survivor处于不活动状态，老年代占用6MB（allocation1、allocation2占用）。 ，和分配3)。

我们看一下使用ParallelScavenge收集器时的情况：

没有发生新生代GC，Assignment4直接分配给了老一辈。
对象的内存分配-大对象直接进入老年代-典型的大对象
非常的字符串和数组
对象内存分配-大物体直接进入老年——大物体噩梦
比遇到大物体更糟糕的消息是遇到一群“生存”的“转瞬即逝的大物体”。 大对象很容易导致在内存还剩下大量空间的情况下提前触发垃圾收集，以便获得足够的连续空间来“放置”这些对象。
对象的内存分配-大对象直接分配到老年代-基本
大于设置值-XX:PretenureSizeThreshold的对象直接分配到老年代。 目的是避免Eden区和两个Survivor区之间进行大量的内存复。

PretenureSizeThreshold设置为3MB（即3145728，该参数不能像-Xmx等参数那样直接写入3MB），所以超过3MB的对象会直接写入分配给老年代。
PretenureSizeThreshold参数仅对Serial和ParNew收集器有效。 ParallelScavenge收集器通常无法识别此参数。
在大多数32位机器和Sun的JVM上，Java堆空间的默认大小是128MB，但也有例外。 例如，在32位Solaris作系统（SPARC平台版本）上，默认的最大堆空间和初始堆空间大小为-Xms=3670K和-Xmx=64M。 对于64位作系统，一般堆空间大小增加30%左右。 但如果使用Java1.5的吞吐量垃圾收集器，默认最大堆大小是物理内存的四分之一，起始堆大小是物理内存的十六分之一。 如果想知道默认的堆大小，可以开一个默认设置参数的程序，使用JConsole（JDK1.5以后支）查看。 您可以在VMSummary页面上查看最大堆大小。
使用此方法您可以更改根据您的程序的需要来设置堆大小，我强烈建议使用此方法而不是默认值。 如果你的程序很大，需要创建的对象很多，可以使用-Xms和-Xmx这两个参数来改变堆内存的大小。 Xms代表起始堆内存大小，Xmx代表最大堆内存大小。 还有一个参数-Xmn，表示newGeneration的大小（后面会提到）。 昌平电脑培训认为有一点需要注意。 您不能任意更改堆内存的大小。 您只能在启动JVM时设置它。
如果您的服务器有64GB内存，您可以使用以下JVM参数来优化Java程序的性能。
-Xmx：设置Java堆的最大内存使用量。 我们建议将此参数设置为总内存的50%到80%之间。 例如，您可以将其设置为-Xmx48g。 这意味着Java堆最多可以使用48GB内存。
-Xms：设置Java堆的初始内存使用量。 我们建议将此参数设置为总内存的25%到50%之间。 例如，您可以将其设置为-Xms16g。 这意味着Java堆最初使用16GB内存。
-Xmn：设置新生代的内存使用情况。 我们建议将此参数设置为Java堆的1/4到1/3。 例如，您可以将其设置为-Xmn16g。 这意味着新一代使用16GB内存。
-XX:+UseG1GC：使用G1垃圾收集器。 这是一个用于服务器端应用程序的垃圾收集器，可以有效地管理堆内存。
-XX:MaxGCPauseMillis：设置垃圾收集器的最大暂停时间。 我们建议将此参数设置在200ms到500ms之间。 例如，您可以设置-XX:MaxGCPauseMillis=200。 这意味着最大暂停时间为200ms。
-XX:+HeapDumpOnOutOfMemoryError：内存溢出时生成堆转储文件。 通过分析堆转储文件，可以内存漏等问题。
-XX:HeapDumpPath：指定堆转储文件的保存路径。
JVM参数示例：
java-Xmx48g-Xms16g-Xmn16g-XX:+UseG1GC-XX:MaxGCPauseMillis=200-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/path/to/dump/file-jaryour_application.jar注意：JVM参数设置可能需要根据您的具体情况进行调整。 如果您的应用程序的内存使用量较小，您可以相应地减少-Xmx和-Xms设置。 如果您的应用程序性能出现问题，请尝试调整与垃圾收集器相关的参数。