欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

深入理解JVM内存分配策略

程序员文章站 2022-03-25 22:24:39
理解JVM内存分配策略 三大原则+担保机制 JVM分配内存机制有三大原则和担保机制 具体如下所示: 优先分配到eden区 大对象,直接进入到老年代 长期存活的对象分配到老年代 空间分配担保 对象优先在Eden上分配 如何验证对象优先在Eden上分配呢,我们进行如下实验。 打印内存分配信息 首先代码如 ......

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

深入理解JVM内存分配策略
因此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后如下所示。
深入理解JVM内存分配策略
这时候我们发现已经无法继续分了。

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

因此会发生我们这种情况。
深入理解JVM内存分配策略

这就是整个过程。验证了对象有现在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的时候
深入理解JVM内存分配策略

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

参数如下所示:

-verbose:gc -xx:+printgcdetails -xx:+useserialgc -xms20m -xmx20m -xmn10m -xx:survivorratio=8 -xx:pretenuresizethreshold=6m

运行结果如下:

深入理解JVM内存分配策略

我们会发现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内存分配的机制。