jvm内存分布

---

一、JVM的内存分布图是什么样的？

JVM虚拟机包括：

1.类加载子系统

2.运行时数据区（内存模型）

堆（存储对象）

栈（线程）（具有先进后出特性）：每个线程启动时，都会从栈中分配一块独占的空间来存储每个方法栈帧——存储空间。栈帧存储包括以下部分：

本地方法栈

方法区（元空间）

程序计数器：存储下一条指令所在单元的地址位于

3。字节码执行引擎

将类文件放入方法区执行

改变程序计数器的当前值

---

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

在testAllocation()方法中，尝试分配3个2MB对象和1个4MB对象，运行时受到-Xms20M、-Xmx20M和-Xmn10M这三个参数的限制。Java堆大小为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被占用，剩余空间不足以分配allocation4所需的4MB内存，所以发生了MinorGC。GC时，VM发现现有的3个2MB对象无法放入Survivor空间（Survivor空间只有1MB大小），必须通过分配保证机制提前转移到老年代。。这次GC之后，4MBAllocation4对象在Eden中成功分配。因此，运行程序的结果是Eden占用4MB（allocation4占用），Survivor空闲，老年代占用6MB（allocation1、allocation2、allocation3占用）。

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

没有发生下一代GC，allocation4直接分配给older一代。
对象内存分配-大对象直接进入老年代-典型的大对象
非常长的字符串和数组
对象内存分配-大对象直接进入老年——大对象的噩梦
比遇到大对象最糟糕的消息是遇到一群“生死存亡”的“短命大对象”。当内存中仍有足够的空间来获得足够的连续空间来“放置”它们时，大对象很容易导致垃圾收集提前触发。
对象内存分配-大对象直接进入legacy代-原因
大于-XX:PretenureSizeThreshold参数值的对象直接分配在oldGeneration中。目标是避免Eden区域和两个Survivor区域之间存在大量内存副本。

PretenureSizeThreshold设置为3MB（即3145728，该设置不能像-Xmx等设置那样直接写入3MB），因此超过3MB的对象将直接分配在old中一代。
PretenureSizeThreshold参数仅对Serial和ParNew收集器有效。ParallelScavenge收集器通常无法识别此设置。