深入理解JVM内存分配策略

深入理解JVM内存分配策略理解JVM内存分配策略三大原则+担保机制JVM分配内存机制有三大原则和担保机制具体如下所示:优先分配到eden区 大对象,直接进入到老年代 长期存活的对象分配到老年代 空间分配担保对象优先在Eden上分配如何验证对象优先在Eden上分配呢,我们进行如下实验。打印内存分配信息首先代码如下所示:publicclassA{publicst…

大家好,又见面了,我是你们的朋友全栈君。

理解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

1590876-20190921221905537-1022644497.png
因此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后如下所示。
1590876-20190921231530494-1972822920.png
这时候我们发现已经无法继续分了。

而查看日志的时候,我们发生了俩次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区域放到可放的地方,也就是在老年代这里

因此会发生我们这种情况。
1590876-20190921232224579-100960452.png

这就是整个过程。验证了对象有现在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的时候
1590876-20190921233346651-439005321.png

被发现7M全部扔到了eden里面。
如果我们制定了参数后,会发现结果变了。

参数如下所示:

-verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=6M

运行结果如下:

1590876-20190921233609974-1219626077.png

我们会发现7M进到了老年代。

长期存活对象进入老年代


参数如下:

-XX:MaxTenuringThreshold

每次进行回收的时候,如果没被回收,那对象的年龄+1

如果对象年龄到达阈值,就会进入老年代。

具体测试和上面的Max一样。就不占篇幅了。


空间分配担保

参数如下:

-XX:+HandlePromotionFailure

步骤如下:

  • 首先衡量有没有这个能力,然后才能进行分配。
  • 如果有这个能力放入,那么这个参数是‘+’号证明开启了内存担保,否则是‘-’号就是没开启。

总结:

JVM内存分配策略不是特别复杂,只要一步一步跟着虚拟机走,那么就可以去理解JVM内存分配的机制。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/146712.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • css3选择器总结[通俗易懂]

    css3选择器总结[通俗易懂]三大特性继承性:子标签继承父标签样式,默认优先级最低。有继承性:文本相关字体样式、粗细、大小、颜色、类型等无继承性:盒子模型相关边框、背景等层叠性:相同标签继承和定义的样式累加到一起互不冲突。优先级:离标签越近的选择器优先级越高,所以相同权重的样式后者才生效;内联样式表>头部样式表>导入样式表。权重权重为0000:通用选择器*{}组选择器h1,h2,

  • Jsp中EL表达式不解析问题

    Jsp中EL表达式不解析问题记一次很郁闷的Bug         前一天晚上写好的JSP页面,然后发布在Tomcat上面之后,一切正常。第二天早上打开之后,发现css样式始终加载不出来,刚开始以为网速问题(前一天晚上测试一切正常,因此排除代码问题),测试网络一切正常,这就跟尴尬了,那css加载不出来是什么意思,难不成遇见鬼了?于是在发布后的页面检查代码,发现页面没有解析EL表达式,找到问题就想办法解决,于是开始折腾,最终还是…

  • Latex数学公式-对齐方法[通俗易懂]

    Latex数学公式-对齐方法[通俗易懂]方法1使用begin{aligned}和end{aligned}将所需对齐的数学公式代码块包起来。其中&表示的是对齐的位置,\\表示换行举例如下$$\begin{aligned}5&=a+b\\7&=2a+b\end{aligned}$$显示的结果为:5=a+b7=2a+b\begin{aligned}5&=a+b…

  • 编译CTK「建议收藏」

    编译CTK「建议收藏」 使用ctkPluginFramework作为插件系统框架的确有着众多开发上的优势。最近收到一些站内信,大家都想使用ctkPluginFramework但是不知道如何编译,这篇教程就来讲一讲ctkPluginFramework插件系统在Windows下的编译过程。准备条件:https://wenku.baidu.com/view/83ef9e1be97101f69e3143323968011ca3…

  • ActionContext_session和page view

    ActionContext_session和page view在Struts2.0中,Action已经与Servlet API完全分离,这使得Struts2.0的Action具有了更加灵活和低耦合的特性,与Struts1.0相比较而言是个巨大的进步。虽然Struts2.0的Action已经与Servlet API完全分离,但我们在实现业务逻辑处理时经常需要访问Servlet中的对象,如Session、Application等。Struts2.0 提供了一个名

  • ZJOI2007时态同步

    ZJOI2007时态同步

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号