HotSpot 内存分配的主要规则

布满荆棘的人生 2023-01-04 14:59 112阅读 0赞

分配与回收，是 Java 虚拟机自动管理内存的两个部分。

之前提的垃圾内存回收的三种算法与常见的垃圾收集器，这些都是内存的回收，那 JVM 是如何分配内存呢？

Java 虚拟机规范并没有规定对象的创建和存储的细节，每款收集器都有各自的实现。

我本地环境是：

**JDK 1.8、64 位、win7、HotSpot 默认 JVM 配置 **

**Parallel Scavenge + Parallel Old 组合，会加参数改收集器**

**1、新对象，一般会优先被分配到新生代 Eden 区，当 Eden 区没有足够空间虚拟机将发起 Minor GC**

代码：

package constxiong.jvm.gc;
    
    /**
     * 测试分配对象到 Eden 区
     */
    public class AllocateToEden {
    
        public static void main(String[] args) {
        }
    
    }

参数：

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails

GC 日志：

[![77834cb389680521804949a8c282d29f.png][]][77834cb389680521804949a8c282d29f.png 1]

说明：

> \-Xms20M 初试堆内存大小 20M  
> \-Xmx20M 最大堆内存大小 20M  
> \-Xmn10M 新生内存大小 10M  
> \-XX:SurvivorRatio=8 新生代中 Eden:Survivor:Survivor=8:1:1,Eden 占 80%  
> \-XX:+PrintGCDetails 打印 GC 日志详情  
> 这样配，
> 
> 堆的大小为 20M  
> 新生代：Eden 就 8M = 8192K，两个 Survivor(from、to) 分别为 1M = 1024K  
> 老年代：10M = 10240K  
>   
>   
> 上面代码启动并未分配对象，Eden 消耗了 2314K，元空间 Metaspace 消耗了 3458K

修改代码在 main 方法分配一个 2M 的字节数组

代码：

package constxiong.jvm.gc;
    
    /**
     * 测试分配对象到 Eden 区
     */
    public class AllocateToEden {
    
        public static void main(String[] args) {
            byte[] array1 = new byte[2 * 1024 * 1024];//2M 数组
        }
    
    }

GC 日志：

[![a76dc6f566ebe082e519b02099a4e823.png][]][a76dc6f566ebe082e519b02099a4e823.png 1]

说明：

> 2M 数组对象，别分配到了新生代的 Eden 区，未分配对象前 Eden 消耗 2314K，加上 2048K，等于 4362K

**2、占用连续空间的大对象(超长字符串、数组)，可以直接分配到老年代，避免在新生代的两个 Survivor 区来回复制大对象**

修改代码，再分配一个大对象 8M 数组：

package constxiong.jvm.gc;
    
    /**
     * 测试分配大对象到老年代
     */
    public class AllocateToOldGeneration {
    
        public static void main(String[] args) {
            byte[] array1 = new byte[2 * 1024 * 1024]; //2M 数组
            byte[] array2 = new byte[8 * 1024 * 1024]; //8M 数组
        }
    
    }

参数未变：

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails

GC 日志：

[![3b89088da4c056485e7177310a6487a0.png][]][3b89088da4c056485e7177310a6487a0.png 1]

说明：

> 新生代已经不够分配 8M 的数组对象，所以直接分配到老年代

\-XX:PretenureSizeThreshold 可以指定当对象大小超过这个阀值时，会被分配到老年代；但 Parallel Scavenge 并不支持，所以添加参数 -XX:PretenureSizeThreshold=3145728，指定垃圾收集器为 Serial ，同时修改代码，把 8M 的数组改为 3M

代码：

package constxiong.jvm.gc;
    
    /**
     * 测试分配对象到老年代
     */
    public class AllocateToOldGeneration {
    
        public static void main(String[] args) {
            byte[] array1 = new byte[2 * 1024 * 1024]; //2M 数组
            byte[] array2 = new byte[3 * 1024 * 1024]; //3M 数组
        }
    
    }

参数：

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails -XX:+UseSerialGC -XX:PretenureSizeThreshold=3145728

GC 日志：

[![76bb9223ac7940fba6c8d91a21b2ad8e.png][]][76bb9223ac7940fba6c8d91a21b2ad8e.png 1]

**3、存活超过一定年龄的对象会被移到老年代**

对象熬过一次 Minor GC 年龄就增加，默认配置年龄超过 15 之后，对象会被移到老年代，可以通过 -XX:MaxTenuringThreshold 进行配置该阀值

代码：

package constxiong.jvm.gc;
    
    /**
     * 测试移动超过一定年龄的对象到老年代
     */
    public class AllocateToOldGeneration {
    
        public static void main(String[] args) {
            byte[] array1 = new byte[1024 * 1024 / 10]; //0.1M
            byte[] array2 = new byte[4 * 1024 * 1024]; //4M
            array2 = null;
            array2 = new byte[4 * 1024 * 1024]; //4M
        }
    
    }

参数：

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=3 -XX:+PrintGCDetails -XX:+UseSerialGC -XX:MaxTenuringThreshold=1

GC 日志：

![bcee023117c990e2dd0eefc4304c505c.png][]

说明：

> \-XX:SurvivorRatio=3，eden=6M、from survivor=2M、to survivor=2M
> 
>  
> 
> byte\[\] array2 = new byte\[4 \* 1024 \* 1024\]; 这行代码执行的时候触发第一次 GC，此时 array1 和部分其他启动时创建的对象继续保留在新生代且年龄加 1
> 
>   
> 最后一行代码，array2 = new byte\[4 \* 1024 \* 1024\]; 代码执行，触发第二次 GC，由于参数中配置了 -XX:MaxTenuringThreshold=1，年龄大于等于 1 的对象都移动到老年代，此次 GC 后新生代为 0

修改参数，把 -XX:MaxTenuringThreshold=1 改为 15

代码不变，参数：

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=3 -XX:+PrintGCDetails -XX:+UseSerialGC -XX:MaxTenuringThreshold=15

GC 日志：

[![7e346f81ee0264fe44da29cc4bd53cbc.png][]][7e346f81ee0264fe44da29cc4bd53cbc.png 1]

说明：

> 修改 -XX:MaxTenuringThreshold=15，代码未变，array1 对象仍然保留在新生代，此时新生代不为 0
> 
>   
> 这条规则需要同时结合下一条：相同年龄所有对象占用内存之和，大于 Survivor 区空间一半时，大于等于该年龄的对象会被移到老年代。**如果本例中的参数 -XX:SurvivorRatio=3 仍然等于 8 的话，第二次 GC 之后新生代仍然为 0，因为相同年龄的对象和大于 survivor 区 1M 的一半了**

**4、相同年龄所有对象占用内存之和，大于 Survivor 区空间一半时，大于等于该年龄的对象会被移到老年代**

代码：

package constxiong.jvm.gc;
    
    /**
     * 测试相同年龄所有对象占用内存之和，大于 Survivor 区空间一半时，大于等于该年龄的对象会被移到老年代
     */
    public class AllocateToOldGeneration {
    
        public static void main(String[] args) {
            byte[] array1 = new byte[1024 * 1024 / 4]; //0.25M
            byte[] array2 = new byte[4 * 1024 * 1024]; //4M
            byte[] array3 = new byte[4 * 1024 * 1024]; //4M，触发第一次 GC
            array3 = null;
            array3 = new byte[4 * 1024 * 1024]; //4M，触发第二次 GC，把所有年轻代的对象移动到老年代
        }
    
    }

参数：

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails -XX:+UseSerialGC -XX:MaxTenuringThreshold=15

GC 日志：

[![4f3a68039dd95ce5bfbb2ff15d863ffd.png][]][4f3a68039dd95ce5bfbb2ff15d863ffd.png 1]

说明：

> byte\[\] array3 = new byte\[4 \* 1024 \* 1024\]; 这行代码执行的时候触发第一次 GC，此时 array2 被移到老年代，array1 和部分其他启动时创建的对象继续保留在新生代且年龄加 1  
> 最后一行代码，array3 = new byte\[4 \* 1024 \* 1024\]; 代码执行，触发第二次 GC，参数中配置了 XX:MaxTenuringThreshold=15，但相同年龄的对象占用内存大于 Survivor 区的一半，所有都移动到老年代，此次 GC 后新生代为 0

**5、分配担保**

主要解决的是，当老年代的连续可用空间不大于新生代的所有对象总内存时，这次 Minor GC 就是有风险的，根据参数 HandlePromotionFailure 决定是否进行担保分配的逻辑。

JDK 6 Update 24 开始，只要老年代的连续空间大于新生代对象总和或历次晋升的平均值，就会发生 Minor GC；否则进行 Full GC。

**补充：不同版本 JDK、不同参数，相同代码 GC 情况不一**

--------------------

### 【Java学习资源】整理推荐 ###

*  [MAT 分析堆内存快照][MAT]
 *  [jclasslib 查看类信息][jclasslib]
 *  [增大 MAT 堆内存][MAT 1]
 *  [JVM 常用配置参数(Java 8)][JVM _Java 8]
 *  [40 道JVM面试题解答][40 _JVM]
 *  [JVM 问题排查常用指令][JVM]
 *  [jvisualvm 远程连接服务器 JVM][jvisualvm _ JVM]
 *  [字节码指令分类][Link 1]
 *  [\-verbose:gc 和 -XX:+PrintGC 的区别][-verbose_gc _ -XX_PrintGC]
 *  [JVM字节码指令表][JVM 1]
 *  [图解 Class 文件结构][Class]
 *  [Class 文件的结构][Class 1]
 *  [JVM 故障处理工具列表][JVM 2]
 *  [HotSpot 内存分配的主要规则][HotSpot]
 *  [开启 GC 日志][GC]
 *  [垃圾收集器及特点][Link 2]
 *  [JVM垃圾回收算法][JVM 3]
 *  [什么样的 Java 对象会被当垃圾回收？][Java]
 *  [内存溢出复现][Link 3]
 *  [HotSpot VM 中对象的内存分析][HotSpot VM]
 *  [JVM 控制的内存区域][JVM 4]
 *  [JVM家族][JVM 5]
 *  [Java 的发展史][Java 1]
 *  [常见 JVM dump 指令][JVM dump]

--------------------

### 【Java面试题与答案】整理推荐 ###

*  [基础与语法][Link 4]
 *  [集合][Link 5]
 *  [网络编程][Link 6]
 *  [并发编程][Link 7]
 *  [Web][]
 *  [安全][Link 8]
 *  [设计模式][Link 9]
 *  [框架][Link 10]
 *  [算法与数据结构][Link 11]
 *  [异常][Link 12]
 *  [文件解析与生成][Link 13]
 *  [Linux][]
 *  [MySQL][]
 *  [Oracle][]
 *  [Redis][]
 *  [Dubbo][]

[77834cb389680521804949a8c282d29f.png]: /images/20221119/e694f047a4094fb9a1be5ee22a24ec08.png
[77834cb389680521804949a8c282d29f.png 1]: https://www.javanav.com/aimgs/image__20201120172458.png
[a76dc6f566ebe082e519b02099a4e823.png]: /images/20221119/0c79c43e96414302ad1b256ad53aa8cb.png
[a76dc6f566ebe082e519b02099a4e823.png 1]: https://www.javanav.com/aimgs/image__20201120172706.png
[3b89088da4c056485e7177310a6487a0.png]: /images/20221119/f51322d01b094705a6bff7139593aecf.png
[3b89088da4c056485e7177310a6487a0.png 1]: https://www.javanav.com/aimgs/image__20201120172740.png
[76bb9223ac7940fba6c8d91a21b2ad8e.png]: /images/20221119/7cfbb7809058472686b297c003f3deb2.png
[76bb9223ac7940fba6c8d91a21b2ad8e.png 1]: https://www.javanav.com/aimgs/image__20201120173311.png
[bcee023117c990e2dd0eefc4304c505c.png]: /images/20221119/bd0b94bb268b45d0ac39328b37d1f4ab.png
[7e346f81ee0264fe44da29cc4bd53cbc.png]: /images/20221119/8b804ca6c04c4d2085268dab72f90aee.png
[7e346f81ee0264fe44da29cc4bd53cbc.png 1]: https://www.javanav.com/aimgs/image__20201120173415.png
[4f3a68039dd95ce5bfbb2ff15d863ffd.png]: /images/20221119/18f5f1f00b5c4d38a221276df7d9aa77.png
[4f3a68039dd95ce5bfbb2ff15d863ffd.png 1]: https://www.javanav.com/aimgs/image__20201120173448.png
[MAT]: https://www.javanav.com/val/c3466d5a4ae54cbbacff48a77764eefc.html
[jclasslib]: https://www.javanav.com/val/f6c5cf9df8554a788b403bdc4c711564.html
[MAT 1]: https://www.javanav.com/val/60b1b34a85474c9ba01858ff435c0abe.html
[JVM _Java 8]: https://www.javanav.com/val/d76fe4761aa64973b6ae730326aa6d34.html
[40 _JVM]: https://www.javanav.com/val/93550f179edb4a77bbf4d35faa6d560c.html
[JVM]: https://www.javanav.com/val/731835b642a548e8a7d7c14aeab161e6.html
[jvisualvm _ JVM]: https://www.javanav.com/val/925604ea926e42aa9f936df96b6c69d0.html
[Link 1]: https://www.javanav.com/val/ecd6c327f9164c358ee168a8f4d6cdfa.html
[-verbose_gc _ -XX_PrintGC]: https://www.javanav.com/val/3159ceb444204e0a830b921dee94d9d1.html
[JVM 1]: https://www.javanav.com/val/2e69020292844506ac038fa6942f359f.html
[Class]: https://www.javanav.com/val/296686d016a147f5b91d8ad82c6f048d.html
[Class 1]: https://www.javanav.com/val/b21a17ddecf543239060a2af5ed9c21e.html
[JVM 2]: https://www.javanav.com/val/a52a3d4ee8df4a7b9d2262572ed303dd.html
[HotSpot]: https://www.javanav.com/val/6b9865caa5f84c348f9485c558df4551.html
[GC]: https://www.javanav.com/val/acbb4071b64240b49145a1baf7856551.html
[Link 2]: https://www.javanav.com/val/391b81f602e74370aa62b8e1b5d84d83.html
[JVM 3]: https://www.javanav.com/val/bbee490647d7459984be9d612dc4b75e.html
[Java]: https://www.javanav.com/val/00c98517d5e940248f6c50403d184dd5.html
[Link 3]: https://www.javanav.com/val/2a7fd81371534120a3e86935cc1ecb01.html
[HotSpot VM]: https://www.javanav.com/val/49e9ce5857744a39a88b1977d84086c7.html
[JVM 4]: https://www.javanav.com/val/34d7eadd6bdb4f179913fe172c4a144b.html
[JVM 5]: https://www.javanav.com/val/c850f57e1cee4024a12e3ac449d2757d.html
[Java 1]: https://www.javanav.com/val/f6a20dc008d6431bb54ba6afc71cbefe.html
[JVM dump]: https://www.javanav.com/val/200700af5dfe459d957e04e93c813a0c.html
[Link 4]: https://www.javanav.com/interview/93b0069472fd479393006c0e73043fc4.html
[Link 5]: https://www.javanav.com/interview/4147d95e693945e7a50345fd33ec817e.html
[Link 6]: https://www.javanav.com/interview/68a57ffc78de4133bb890bdd502ac418.html
[Link 7]: https://www.javanav.com/interview/36a24fa3258e45c89873f474ce914912.html
[Web]: https://www.javanav.com/interview/4e27cb63adb440c6825a159d35cf4010.html
[Link 8]: https://www.javanav.com/interview/03affb2ce3f04fda8853f714e5764906.html
[Link 9]: https://www.javanav.com/interview/07a32a9ff17a4006a53550ce658cafed.html
[Link 10]: https://www.javanav.com/interview/5c466456e9b54ab0a749b5948e51f1d3.html
[Link 11]: https://www.javanav.com/interview/943f917041ee4f05add24539f5b861b2.html
[Link 12]: https://www.javanav.com/interview/d3f058cfc05d4c6dadd821b622e84d36.html
[Link 13]: https://www.javanav.com/interview/67a50996c28f418e83b109ea42fc3eff.html
[Linux]: https://www.javanav.com/interview/00cccb81729540d1923bd0a0ef49533a.html
[MySQL]: https://www.javanav.com/interview/d311e78502a845f1a4bb307bd6aec2b3.html
[Oracle]: https://www.javanav.com/interview/5f29e9677edf4a16be3dce30d257c9ab.html
[Redis]: https://www.javanav.com/interview/066c62b3af4d4827b2243a822c3084a9.html
[Dubbo]: https://www.javanav.com/interview/9a3e7a7740324757abaab953f7ebc455.html