深入理解JVM内存分配策略
理解JVM内存分配策略
三大原则+担保机制
JVM分配内存机制有三大原则和担保机制
具体如下所示:
- 优先分配到eden区
- 大对象,直接进入到老年代
- 长期存活的对象分配到老年代
- 空间分配担保
对象优先在Eden上分配
如何验证对象优先在Eden上分配呢,我们进行如下实验。
打印内存分配信息
首先代码如下所示:
public class A {
public static void main(String[] args) {
byte[] b1 = new byte[4*1024*1024];
}
}
代码很简单,就是创建一个Byte数组,大小为4mb。
然后我们在运行的时候加上虚拟机参数来打印垃圾回收的信息。
-verbose:gc -XX:+PrintGCDetails
在我们运行后,结果如下所示。
Heap
PSYoungGen total 37888K, used 6718K [0x00000000d6000000, 0x00000000d8a00000, 0x0000000100000000)
eden space 32768K, 20% used [0x00000000d6000000,0x00000000d668f810,0x00000000d8000000)
from space 5120K, 0% used [0x00000000d8500000,0x00000000d8500000,0x00000000d8a00000)
to space 5120K, 0% used [0x00000000d8000000,0x00000000d8000000,0x00000000d8500000)
ParOldGen total 86016K, used 0K [0x0000000082000000, 0x0000000087400000, 0x00000000d6000000)
object space 86016K, 0% used [0x0000000082000000,0x0000000082000000,0x0000000087400000)
Metaspace used 2638K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 281K, capacity 386K, committed 512K, reserved 1048576K
手动指定收集器
我们可以看在新生代采用的是Parallel Scavenge收集器
其实我们可以指定虚拟机参数来选择垃圾收集器。
比方说如下参数:
-verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC
运行结果如下:
Heap
def new generation total 38720K, used 6850K [0x0000000082000000, 0x0000000084a00000, 0x00000000ac000000)
eden space 34432K, 19% used [0x0000000082000000, 0x00000000826b0be8, 0x00000000841a0000)
from space 4288K, 0% used [0x00000000841a0000, 0x00000000841a0000, 0x00000000845d0000)
to space 4288K, 0% used [0x00000000845d0000, 0x00000000845d0000, 0x0000000084a00000)
tenured generation total 86016K, used 0K [0x00000000ac000000, 0x00000000b1400000, 0x0000000100000000)
the space 86016K, 0% used [0x00000000ac000000, 0x00000000ac000000, 0x00000000ac000200, 0x00000000b1400000)
Metaspace used 2637K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 281K, capacity 386K, committed 512K, reserved 1048576K
其实JDK默认的不是Parallel收集器,但是JDK会依照各种环境来调整采用的垃圾收集器。
查看环境的代码如下:
java -version
因此JDK根据server的环境,采用了Paralled收集器。
而Serial收集器主要用在客户端的。
eden分配的验证
我们看到现在eden区域为34432K,使用了19%,那我们来扩大10倍是否eden就放不下了呢?
我们来验证一下。
public class A {
public static void main(String[] args) {
byte[] b1 = new byte[40*1024*1024];
}
}
运行结果如下:
Heap
def new generation total 38720K, used 2754K [0x0000000082000000, 0x0000000084a00000, 0x00000000ac000000)
eden space 34432K, 8% used [0x0000000082000000, 0x00000000822b0bd8, 0x00000000841a0000)
from space 4288K, 0% used [0x00000000841a0000, 0x00000000841a0000, 0x00000000845d0000)
to space 4288K, 0% used [0x00000000845d0000, 0x00000000845d0000, 0x0000000084a00000)
tenured generation total 86016K, used 40960K [0x00000000ac000000, 0x00000000b1400000, 0x0000000100000000)
the space 86016K, 47% used [0x00000000ac000000, 0x00000000ae800010, 0x00000000ae800200, 0x00000000b1400000)
Metaspace used 2637K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 281K, capacity 386K, committed 512K, reserved 1048576K
显然,我们还是正常运行了,但是eden区域没有增加,老年代区域却增加了,符合大对象直接分配到老年代的特征。。
所以我们适当的缩小每次分配的大小。
我们在此限制下eden区域的大小
参数如下:
-verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
这里我们限制内存大小为20M
Eden大小为8M
然后我们运行我们的代码:
代码如下所示:
public class A {
public static void main(String[] args) {
byte[] b1 = new byte[2*1024*1024];
byte[] b2 = new byte[2*1024*1024];
byte[] b3 = new byte[2*1024*1024];
byte[] b4 = new byte[4*1024*1024];
System.gc();
}
}
运行结果如下:
[GC (Allocation Failure) [DefNew: 7129K->520K(9216K), 0.0053010 secs] 7129K->6664K(19456K), 0.0053739 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[Full GC (System.gc()) [Tenured: 6144K->6144K(10240K), 0.0459449 secs] 10920K->10759K(19456K), [Metaspace: 2632K->2632K(1056768K)], 0.0496885 secs] [Times: user=0.00 sys=0.00, real=0.04 secs]
Heap
def new generation total 9216K, used 4779K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 58% used [0x00000000fec00000, 0x00000000ff0aad38, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
to space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
tenured generation total 10240K, used 6144K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 60% used [0x00000000ff600000, 0x00000000ffc00030, 0x00000000ffc00200, 0x0000000100000000)
Metaspace used 2638K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 281K, capacity 386K, committed 512K, reserved 1048576K
我们可以发现在eden区域为8192K 约为8M
也就是我们的b4的大小
而原先的b1,b2,b3为6M,被分配到了tenured generation。
原先的Eden区域如下所示,在分配完,b1,b2,b3后如下所示。
这时候我们发现已经无法继续分了。
而查看日志的时候,我们发生了俩次GC。
[GC (Allocation Failure) [DefNew: 7129K->520K(9216K), 0.0053010 secs] 7129K->6664K(19456K), 0.0053739 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[Full GC (System.gc()) [Tenured: 6144K->6144K(10240K), 0.0459449 secs] 10920K->10759K(19456K), [Metaspace: 2632K->2632K(1056768K)], 0.0496885 secs] [Times: user=0.00 sys=0.00, real=0.04 secs]
而在
[DefNew: 7129K->520K(9216K), 0.0053010 secs] 7129K->6664K(19456K), 0.0053739 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
中我们会看到,刚分配的对象并没有被回收。
上面的GC是针对新生代的。
而下面的FullGC是针对老年代的。
如果我们这时候要再分配4m的内存,虚拟机默认将原先的eden区域放到可放的地方,也就是在老年代这里
因此会发生我们这种情况。
这就是整个过程。验证了对象有现在Eden区域回收
大对象直接进入到老年代
指定大对象的参数。
-XX:PretenureSizeThreshold
测试代码:如下
-verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
public class A {
private static int M = 1024*1024;
public static void main(String[] args) {
byte[] b1 = new byte[8*M];
}
}
运行结果如下:
Heap
def new generation total 9216K, used 1149K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 14% used [0x00000000fec00000, 0x00000000fed1f718, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 8192K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 80% used [0x00000000ff600000, 0x00000000ffe00010, 0x00000000ffe00200, 0x0000000100000000)
Metaspace used 2637K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 281K, capacity 386K, committed 512K, reserved 1048576K
我们可以看到,结果数直接把8M扔到了老年代里面了。
而我们修改成7M的时候
被发现7M全部扔到了eden里面。
如果我们制定了参数后,会发现结果变了。
参数如下所示:
-verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=6M
运行结果如下:
我们会发现7M进到了老年代。
长期存活对象进入老年代
参数如下:
-XX:MaxTenuringThreshold
每次进行回收的时候,如果没被回收,那对象的年龄+1
如果对象年龄到达阈值,就会进入老年代。
具体测试和上面的Max一样。就不占篇幅了。
空间分配担保
参数如下:
-XX:+HandlePromotionFailure
步骤如下:
- 首先衡量有没有这个能力,然后才能进行分配。
- 如果有这个能力放入,那么这个参数是‘+’号证明开启了内存担保,否则是‘-’号就是没开启。
逃逸分析与栈上分配
如何将内存分配到栈上呢?
这时就需要我们使用逃逸分析,筛选出未发生逃逸对象。
逃逸分析的主要目标就是分析出对象的作用域。
public class A {
A obj;
//方法返回A对象,发生逃逸。
public A getInstance() {
return this.obj ==null?new A():obj;
}
//为成员属性赋值,发生逃逸
public void setObj() {
this.obj = new A();
}
//没有发生逃逸。对象的作用域尽在当前方法中有效,没有发生逃逸。
public void useA() {
A s = new A();
}
//
public void useA2() {
A s = getInstance();
}
}
总结,只要定义在方体中,对象的作用域不发生逃逸,否则发生逃逸。
所以尽量把变量放在方法体内,这样会提高效率。
总结:
JVM内存分配策略不是特别复杂,只要一步一步跟着虚拟机走,那么就可以去理解JVM内存分配的机制。
深入理解JVM内存分配策略的更多相关文章
- JVM内存分配策略,及垃圾回收算法
本人免费整理了Java高级资料,一共30G,需要自己领取;传送门:https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q 说起垃圾收集(Garbage Co ...
- JVM内存分配策略
在 JVM内存垃圾回收方法 中,我们已经详细讨论了内存回收,但是,我们程序中生成的对象是如何进行分配的呢?以下所述针对的是HotSpot虚拟机. 1.Java堆结构 以HotSpot为例,如下图: H ...
- JVM内存分配策略、各个代区、FullGC/MinorGC
主要讨论默认的Serial/Serial Old内存分配: 一.几种分配方案 1. 对象优先在Eden分配: 一般情况下,对象会在新生代的Eden区分配,Eden区没有足够空间时,虚拟机会 发起一次 ...
- 深入理解JVM内存分配和常量池
一.虚拟机的构成 虚拟结主要由运行时数据区.执行引擎.类加载器三者构成: 而我们所说的JVM内存模型指的就是运行时数据区,下面具体分析一下运行时数据区: 二.运行时数据区组成和各个区域的作用 我们看到 ...
- 深入了解java虚拟机(JVM) 第七章 内存分配策略
理解了jvm内存分配策略不仅是程序性能调优的重要知识,还能够给养成自己一种良好的代码思路,一个程序的代码差异往往都是在这里体现出来的. 一.对象优先分配到Eden区域 一般来说,新创建的对象都会直 ...
- GC之一--GC 的算法分析、垃圾收集器、内存分配策略介绍
一.概述 垃圾收集 Garbage Collection 通常被称为“GC”,它诞生于1960年 MIT 的 Lisp 语言,经过半个多世纪,目前已经十分成熟了. jvm 中,程序计数器.虚拟机栈.本 ...
- JVM内存分配和垃圾回收以及性能调优
JVM内存分配策略 一:堆中优先分配Eden 大多数情况下,对象都在新生代的Eden区中分配内存.而新生代会频繁进行垃圾回收. 二:大对象直接进入老年代 需要大量连续空间的对象,如:长字符串.数组等, ...
- 深入理解JVM(5)——垃圾收集和内存分配策略
1.垃圾收集对象 垃圾收集主要是针对堆和方法区进行. 程序计数器.虚拟机栈和本地方法栈这三个区域属于线程私有的,只存在于线程的生命周期内,线程结束之后也会消失,因此不需要对这三个区域进行垃圾回收. 哪 ...
- 深入理解java虚拟机(2)------垃圾收集器和内存分配策略
GC可谓是java相较于C++语言,最大的不同点之一. 1.GC回收什么? 上一篇讲了内存的分布. 其中程序计数器栈,虚拟机栈,本地方法栈 3个区域随着线程而生,随着线程而死.这些栈的内存,可以理解为 ...
随机推荐
- Alfred上可提高工作效率的Workflow推荐
温馨提示:本文中Alfred是Mac平台的工具,不适用于其他平台. Alfred是Mac平台上被很多人吹爆的一款效率提升软件,我刚毕业工作的时候就看到公司内网有人推荐,但没有尝试. 后来我跳槽后自己买 ...
- Windows 10“数字权利激活”永久性激活!!!
直接运行软件即可自动激活,等出现"激活成功"即可关闭软件. 注意事项: 激活软件不会帮你打开Windows update服务,如关闭系统自动更细服务的需要先启动服务. 可以在小娜搜 ...
- 漏洞挖掘技巧之利用javascript:
好久没更新博客了,更新一波. 场景: window.location.href=”” location=”” location.href=”” window.location.* 常见地点:任何二次跳 ...
- 亲,麻烦给个五星好评!—RatingBar
引言 上一篇的CheckBox已经让大家越来越接近实战演练了,本章我们继续分享干货给大家,今天介绍一个实用的UI控件RatingBar(星级评分条),对于使用过电商APP(某东,某宝等)的小伙伴们来说 ...
- 替代Flume——Kafka Connect简介
我们知道过去对于Kafka的定义是分布式,分区化的,带备份机制的日志提交服务.也就是一个分布式的消息队列,这也是他最常见的用法.但是Kafka不止于此,打开最新的官网. 我们看到Kafka最新的定义是 ...
- Codeforces 396C
题意略. 思路: 将树上的节点编好dfs序,然后就可以用树状数组区间修改点查询了. 我们用 lft[v] 和 rht[v]来表示v的子树在dfs序中的左端和右端,这样才方便我们对树状数组的操作. 其实 ...
- hdu2222 Keywords Search (AC自动机板子
https://vjudge.net/problem/HDU-2222 题意:给几个模式串和一个文本串,问文本串中包含几个模式串. 思路:贴个板子不解释. #include<cstdio> ...
- POJ-1847 Tram( 最短路 )
题目链接:http://poj.org/problem?id=1847 Description Tram network in Zagreb consists of a number of inter ...
- lightoj 1145 - Dice (I)(dp+空间优化+前缀和)
题目链接:http://www.lightoj.com/volume_showproblem.php?problem=1145 题解:首先只要是dp的值只和上一个状态有关系那么就可以优化一维,然后这题 ...
- CF980B Marlin 构造 思维 二十四
Marlin time limit per test 1 second memory limit per test 256 megabytes input standard input output ...