jvm内存大小(jvm默认堆内存大小)

---

一、jvm默认多大的对象是大对象JVM认为大对象的对象的默认大小是多少？对象内存分配：首先在Eden区分配对象
当Eden区没有足够的空间可供分配时，虚拟机将启动一次MinorGC。

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

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

没有发生下一代GC，allocation4直接分配给older一代。
对象内存分配-大对象直接进入老年代-典型的大对象
非常长的字符串和数组
对象内存分配-大物体直接进入老年：大物体的噩梦
遇到大物体最糟糕的消息就是遇到一群“生死存亡”的“大而短命的物体”。当内存中仍有足够的空间来获得足够的连续空间来“容纳”它们时，大对象很容易导致垃圾收集提前触发。
对象内存分配-大对象直接进入老年代-原因
大于-XX:PretenureSizeThreshold设置值的对象直接分配到老年代。这样做的目的是为了避免Eden区和两个Survivor区之间进行大量的内存复制。

PretenureSizeThreshold设置为3MB（即3145728，该参数不能像-Xmx这样的参数直接写入3MB），所以超过3MB的对象会直接分配到老年代。
PretenureSizeThreshold参数仅对Serial和ParNewbin有效。ParallelScavenge收集器不识别该参数，一般不需要设置。