Java内存空间

just-julie

于 2024-05-27 20:55:40 发布

阅读量794

点赞数 17

文章标签： java jvm 开发语言

本文链接：https://blog.csdn.net/weixin_42824596/article/details/139151641

版权

Java内存空间划分

Java虚拟机在执行Java程序的过程中会把他管理的内存划分为若干个不同的数据区域，如图所示1.7和1.8两个版本的Java内存空间划分。
JDK1.7:
在这里插入图片描述
JDK1.8:

线程私有：

程序计数器
虚拟机栈
本地方法栈

线程共享：

堆
方法区
直接内存（非运行时数据区的一部分）

Java虚拟机规范对于运行时数据区域的规定是相当宽松的，以堆为例：堆可以是连续空间，也可以不连续。堆的大小可以固定，也可以在运行时按需扩展。虚拟机实现者可以使用任何垃圾回收算法管理堆，甚至完全不进行垃圾收集也可以。

程序计数器

程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器完成。
另外，线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”内存。

总结，程序计数器的两个作用：

字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理等。
在多线程情况下，程序计数器用于记录当前线程执行的位置，从而当线程切换回来的时候能够知道该线程上次运行到哪儿了。

注意：程序计数器是唯一一个不会出现OutOfMemoryError的内存区域，它的生命周期随线程的创建而创建，随线程的结束而死亡。

Java虚拟机栈

与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期和线程生命周期相同，随着线程的创建而创建，随着线程的死亡而死亡。

栈除了一些native方法调用是通过本地方法栈实现的，其他所有的Java方法调用都是通过栈来实现的。方法调用的数据需要通过栈进行传递，每一次方法调用都会有一个栈帧被压入栈中，每一个方法调用结束后，都会有一个栈帧被弹出。

栈由一个个栈帧组成，而每个栈帧都具有局部变量表、操作数栈、动态链接、方法返回地址。和数据结构上的栈类似，两者都是先进后出的数据结构，只支持入栈和出栈两种操作。
在这里插入图片描述
局部变量表
局部变量表主要存放编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）对象引用

操作数栈
操作数栈主要作为方法调用的中转站使用，用于存放方法执行过程中产生的中间计算结果，另外，计算过程中产生的临时变量也会存放在操作数栈中。

动态链接
动态链接主要服务一个方法需要调用其他方法的场景，Class文件的常量池里保存有大量的符号引用比如方法引用的符号引用。当一个方法要调用其他方法是，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用，动态链接的作用就是为了将符号引用转换为调用方法的直接引用，这个过程称为动态链接。
在这里插入图片描述
栈空间虽然不是无限的，但一般正常调用的情况下不会出现问题，不过，如果函数调用陷入无限循环的话，就会导致栈中被压入太多的栈帧而占用太多空间，导致栈空间过深。那么当线程请求栈的深度超过当前Java虚拟机栈的最大深度时，就会抛出StackOverFlowError错误。

Java方法有两种返回方式，一种是return语句正常返回，一种是抛出异常。不管哪种返回方式，都会导致栈帧被弹出，也就是说，栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。

除了StackOverFlowError，栈可能还会出现OutOfMemoryError错误，这是因为如果栈的内存大小可以动态扩展、如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError。

总结：

StackOverFlowError：如果栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前Java虚拟机栈的最大深度时，就会抛出StackOverFlowError错误。
OutOfMemoryError：如果栈的内存大小可以动态扩展，如果虚拟机在动态扩展时无法申请到足够的内存空间，则会抛出OutOfMemoryError。

本地方法栈

和虚拟机栈所发挥的作用非常相似，区别是：虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为虚拟机使用到的Native方法服务。

本地方法执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量、操作数、动态链接、出口信息。

方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现StackOverFlowError和OutOfMemoryError错误。

堆

Java虚拟机所管理的内存中最大的一块，Java堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。

Java堆是垃圾收集器管理的主要区域，因此也被称作GC堆。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以Java堆还可以细分为：新生代、老年代。进一步划分的目的是为了更好的回收内存，或者更快的分配内存。

在JDK1.7版本及之前，堆内存通常被分为下面三部分：

新生代内存（Young Generation）
老年代（Old Generation）
永久代（Permanent Generation）

下图所示Eden区、两个Survivor区S0和S1都属于新生代，中间一层属于老年代、最下面一层属于永久代。
在这里插入图片描述
JDK1.8版本之后Permanent被MetaSpace（元空间）取代，元空间使用的是本地内存。

大部分情况下，对象都会首先在Eden区域分配，在一次新生代垃圾回收后，如果对象还存在，则会进入S0或者S1，并且对象的年龄会加1（Eden区->Survivor区后对象的初始年龄变为1），当他的年龄增加到一定程度（默认为15），就会被晋升到老年代。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold 来设置，设置的值应该在0-15之间。

为什么年龄必须在0-15之间：因为记录年龄的区域在对象头中，这个区域的大小通常是4位，这4位表示的最大二进制数字是1111，即十进制的5.因此，对象的年龄被限制为0-15.

堆这里最容易出现的就是OutOfMemoryError错误，并且出现这种错误之后的表现形式有几种：

java.lang.OutOfMemoryError: GC Overhead Limit Exceeded：当 JVM 花太多时间执行垃圾回收并且只能回收很少的堆空间时，就会发生此错误。
java.lang.OutOfMemoryError: Java heap space :假如在创建新的对象时, 堆内存中的空间不足以存放新创建的对象, 就会引发此错误（和配置的最大堆内存有关，且受限于物理内存大小，最大堆内存可通过-Xmx参数配置）。

方法区

方法区属于JVM运行时数据区域的一块逻辑区域，是各个线程共享的内存区域。

当虚拟机要使用一个类时，他需要读取并解析Class文件获取相关信息，再将信息放入到方法区。方法区会存储已被虚拟机加载的类信息、字段信息、方法信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

方法区和永久代以及元空间是什么关系：方法区和永久代以及元空间的关系很像Java中接口和类的关系，类实现了接口，这里的类可以看作是永久代和元空间，接口可以看作是方法区，即永久代和元空间是HotSpt虚拟机对虚拟机规范中方法区的两种实现方式。并且，永久代是1.8之前的方法区实现，元空间是1.8及之后的方法区实现。

为什么要将永久代替换为元空间：

元空间溢出风险更小：整个永久代有一个JVM本身设置的固定大小上限，无法进行调整（也就是受到JVM内存限制），而元空间使用的是本地内存，受本机可用内存限制，虽然元空间仍然可能溢出，但是几率小很多。可以使用-XX：MaxMetaspaceSize设置，默认为unlimited，意味着只受系统内存限制。-XX：MetaspaceSize调整标志定义元空间的初始大小，如果未指定，则Metaspace将根据运行时应用程序需求动态调整。
可以加载更多的类：元空间里面存放的是类的元数据，这样加载多少类的元数据就不由MaxPermSize控制，而由系统实际可用空间来控制。
兼容性：1.8将HotSpot和JRockit代码合并，JRockit从来没有一个叫永久代的东西，合并之后就没有必要额外设置永久代。
降低复杂度：永久代会为GC带来不必要的复杂度，并且回收效率偏低。

方法区常用参数

JDK1.8之前永久代还没被彻底删除的时候通常通过下面这些参数来调整方法区大小

-XX:PermSize = N //方法区（永久代）初始大小
-XX:MaxPermSize = N //方法区（永久代）最大大小，超过这个值将会抛出
 OutOfMemoryError 异常:java.lang.OutOfMemoryError: PermGen

相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入方法区后就“永久存在”了。

JDK1.8，方法区被彻底移出，元空间代替了永久代，下面是一些常用参数

-XX:MetaspaceSize = N //设置Metaspace的初始
-XX:MaxMetaspaceSize = N //设置Metaspace的最大大小

与永久代很大的不同是，如果不指定大小，随着更多类的创建，虚拟机会耗尽所有可用的系统内存。

运行时常量池（方法区的一部分）

Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有用于存放编译期生成的各种字面量（Literal）和符号引用的常量池表。

字面量是源代码中的固定值得表示法，即通过字面我们就能知道其值的含义。字面量包括整数、浮点数、和字符串字面量。常见的符号引用包括类符号引用、字段符号引用、方法符号引用、接口方法符号。

符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同，但是他们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在Class文件格式中。

直接引用：直接引用是可以直接指向目标的指针、相对偏移量是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

常量池表在类加载后存放到方法区的运行时常量池中。

字符串常量池

字符串常量池是JVM为了提升性能和减少内存消耗针对字符串（String类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。

// 在堆中创建字符串对象”ab“
// 将字符串对象”ab“的引用保存在字符串常量池中
String aa = "ab";
// 直接返回字符串常量池中字符串对象”ab“的引用
String bb = "ab";
System.out.println(aa==bb);// true

JDK1.7之前，字符串常量池存放在永久代，JDK1.7字符串常量池和静态变量从永久代移动到了Java堆中。

JDK1.7 为什么要将字符串常量池移动到堆中

主要是因为永久代的GC回收效率太低，只有在Full GC的时候才会执行。Java程序通常会有大量的被创建的字符串等待回收，将字符串常量池放到堆中，能够更高效及时的回收字符串内存。

直接内存

直接内存是一种特殊的内存缓冲区，并不在Java堆或者方法区中分配，而是通过JNI的方式在本地内存上分配。

零复制技术：零复制技术是一种在计算机系统中传输数据时减少或消除数据复制的技术，以提高效率和减少延迟。在传统的数据传输过程中，数据需要从一个应用程序缓冲区复制到操作系统内核缓冲区，然后再从内核缓冲区复制到网络接口，这种多次复制过程会消耗大量的CPU时间和内存带宽，从而降低整体性能。使用零复制技术，数据可以直接从发送应用程序的缓冲区传输到网络接口，无需在用户空间和内核空间之间多次复制。可以显著减少CPU负载，提高数据处理和传输的速度。

DirectByteBuffer可以直接在操作系统的内存中分配，而不是在JVM堆内存中。与常规的HeapByteBuffer相比，DirectByteBuffer优势在于可以通过操作系统的本地I/O操作直接读取或写入内存数据，而不需要将数据复制到JVM堆内存。

DirectByteBuffer和零复制的关系

DirectByteBuffer在实现零复制技术方面起着重要作用，以下是他们之间的关系和工作机制：

减少数据复制
- DirectByteBuffer通过在操作系统的本地内存中分配内存，可以避免将数据从堆内存复制到本地内存的开销。
- 例如，当进行网络I/O操作时，可以直接将数据从DirectByteBuffer写入网络通道，而不需要进行额外的内存复制。
提高I/O性能
- 由于减少了数据在用户空间和内核空间之间的复制次数， DirectByteBuffer可以显著提高I/O操作性能。
- 特别是在处理大数据量和高吞吐量的场景下，性能提升尤为明显。

代码示例

import java.io.RandomAccessFile;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class DirectByteBufferExample {
    public static void main(String[] args) {
        try {
            // 创建一个随机访问文件
            RandomAccessFile file = new RandomAccessFile("example.txt", "rw");
            FileChannel fileChannel = file.getChannel();

            // 分配一个直接缓冲区
            ByteBuffer buffer = ByteBuffer.allocateDirect(1024);

            // 写数据到缓冲区
            buffer.put("Hello, DirectByteBuffer!".getBytes());

            // 准备将缓冲区数据写入文件
            buffer.flip();
            fileChannel.write(buffer);

            // 清空缓冲区以备后续读操作
            buffer.clear();

            // 读取文件数据到缓冲区
            fileChannel.position(0);
            fileChannel.read(buffer);

            // 准备从缓冲区读取数据
            buffer.flip();
            byte[] data = new byte[buffer.remaining()];
            buffer.get(data);

            System.out.println("Read from file: " + new String(data));

            fileChannel.close();
            file.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

HotSpot虚拟机对象探秘

`对象的创建（重要！！）`

第一步：类加载检查

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析、初始化过，如果没有，那必须先执行相应的类加载过程。

第二步：分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存，对象所需内存大小在加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。分配方式有“指针碰撞”和“空闲列表”两种。选择哪种方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。

指针碰撞:
- 适用场合：堆内存规则（即没有内存碎片）的情况下
- 原理：用过的内存全部整合到一边，没有用过的内存放在另一边，中间有一个分界指针，只需要向着没用过的内存方向将指针移动对象内存大小位置即可
- 使用该分配方式的GC收集器：Serial、ParNew
空闲列表
- 适用场合：堆内存不规整的情况下
- 原理：虚拟机维护一个列表，该列表中会记录哪些内存快可用，在分配的时候，找一块足够大的内存块来划分给对象实例，最后更新列表记录。
- 使用该分配方式的GC收集器：CMS。

内存分配并发问题
在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全：

CAS+失败重试：CAS是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用CAS配上失败重试的方式保证更新操作的原子性。
TLAB：为每一个线程预先在Eden区分配一块内存，JVM再给线程中的对象分配内存时，首先在TLAB分配，当对象大于TLAB中的剩余内存或者TLAB内存已经用尽时，在采用上述的CAS进行内存分配。

第三步：初始化零值

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。

第四步：设置对象头

初始化零值完成后，虚拟机将要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象头中。另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。

第五步：执行init方法

在上面工作都完成后，从虚拟机的视角来看，一个新的对象产生了，但从Java程序的视角来看，对象创建才刚开始，init方法还没有执行，所有的字段都还为0，所以一般来说，执行new指令之后接着执行init方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

对象的内存布局

在Hotspot虚拟机中，对象在内存中的布局分为3个区域：对象头、实例数据、对其填充。

对象头部分信息：

标记字段：用于存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。
类型指针：对象指向他的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

实例数据部分是真正存储的有效信息，也是在程序中所定义的各种类型的字段内容。

对其填充不是必然存在的，也没有什么特别作用，仅仅起占位作用。因为Hotspot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数（1倍或者2倍），因此，当对象实例数据部分没有对齐时，就需要通过对其填充来补全。

对象的访问定位

建立对象是为了使用对象，Java程序通过栈上的reference数据来操作堆上的具体对象，对象的访问方式由虚拟机实现而定，目前主流的访问方式有：使用句柄、直接指针。

使用句柄
如果使用句柄的话，那么Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与对象类型数据各自的具体的地址信息。
在这里插入图片描述
直接指针
如果使用直接指针访问，reference中存储的直接就是对象的地址。

这两种对象访问方式各有优势，使用句柄的好处是reference中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而reference本身不需要修改，使用直接指针访问方式最大的好处就是速度快，他节省了一次指针定位时间开销。

just-julie

关注

17
点赞
踩
25

收藏

觉得还不错? 一键收藏
0
评论
Java内存空间

符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。在上面工作都完成后，从虚拟机的视角来看，一个新的对象产生了，但从Java程序的视角来看，对象创建才刚开始，init方法还没有执行，所有的字段都还为0，所以一般来说，执行new指令之后接着执行init方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。：因为记录年龄的区域在对象头中，这个区域的大小通常是4位，这4位表示的最大二进制数字是1111，即十进制的5.因此，对象的年龄被限制为0-15.
复制链接

扫一扫