jvm默认分配内存大小

---

一、jvm默认栈内存大小32位系统的默认值为512KB，64位系统的默认值为1024KB。

---

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

在testAllocation()方法中，尝试分配3个大小为2MB的对象和1个大小为4MB的对象，这受到三个参数-Xms20M、-Xmx20M和-的限制运行时Xmn10M。Java堆大小为20MB，无法扩展。10MB分配给新生代，剩余的10MB分配给老年代。-XX:SurvivorRatio=8决定新生代中Eden区和survivor区的空间比例为8:1。新一代有可用空间。当执行testAllocation()中的对象分配语句时，GC会更小。从这次GC来看，新生代的6651KB变成了162KB，而总内存使用量几乎没有变化（因为allocation1、allocation2、allocation3这三个对象存活下来，虚拟机没有发现可回收的对象）。这次之所以发生GC，是因为在为allocation4分配内存时，发现Eden的6MB被占用，而allocation4所需的剩余4MB内存没有分配，所以发生了MinorGC。通过GC，虚拟机检测到存活空间中存在的所有3个2MB大小的对象（存活空间只有1MB大小），必须先通过分配机制转移到老年代。。这次GC之后，建议的4MB分配已在Eden中成功分配。所以程序执行的结果是Eden占用4MB（被allocation占用），survival空闲，老年代占用6MB（allocation1、allocation2占用）。和分配3)。

使用Parallelsscavenge查看收集器的情况：

没有发生新的GC生成，allocation4直接分配。老一
事物的内存分配-伟大的事物直接进入远古一代-伟大物体的目标
带着很长的字符串和衣服进入老年-大物体的噩梦
比一个大对象碰上一群“短大对象”更糟糕的消息是“生死存亡”的大对象很容易导致垃圾回收提前触发，而里面还有很多空间内存获得足够的连续空间来“放置”它们。
对象的内存分配-大对象直接进入老年代-原因
大于-XX的对象：PretenureSizeThreshold值设置立即在老年代分配。这样做的目的是为了避免Eden区之间以及两个区域之间残留大量内存。

PretenureSize阈值设置为3MB（即3145728，该参数不能作为-Xmx等参数直接写入3MB），因此超过3MB的对象将直接分配。老一辈
PretenureSize预占大小仅对Serial和ParNew收集器有效。