Java 虚拟机中的内存结构

2023-12-22 23:29:05

1 内存结构

1.1 程序计数器

image-20231222142726484

1.1.1 定义

Program Counter Register 程序计数器(寄存器)

作用:是记住下一条 jvm 指令的执行地址

特点:

  • 是线程私有的(每个线程独有自己的一份)
  • 不会存在内存溢出

1.1.2 作用

记住下一条 jvm 指令的执行地址 (0,3,4,5,...)

image-20231222143054213

线程私有的:

每个线程都有一个自己的程序计数器,里面存储了自己线程运行到了哪条指令

image-20231222144028283

1.2 虚拟机栈

image-20231222144244229

1.2.1 定义

Java Virtual Machine Stacks (Java 虚拟机栈)

  • 每个线程运行时所需要的内存,称为虚拟机栈
  • 每个栈由多个栈帧(Frame)组成,对应着每次方法调用所占用的内存
  • 每个线程只有一个活动栈帧,对应当前正在执行的那个方法

栈:线程运行需要的内存空间

栈中存储着多个栈帧,每个栈帧对应着一个调用过的方法,栈顶为活动栈帧,是当前正在运行的函数;当一个方法运行完成,这个方法对应的栈帧就会出栈

image-20231222144505865

问题辨析

  1. 垃圾回收是否涉及栈内存?

    不需要,每次方法结束时,栈内存就被回收掉了,不需要等待垃圾回收;垃圾回收是用来回收堆内存中的对象的

  2. 栈内存分配越大越好吗?

    • 可以用 -Xss size 指令设置栈内存的大小
    • Linux & macOS默认 1024 KB,Windows 依赖虚拟内存的大小
  3. 方法内的局部变量是否线程安全?

    • 如果方法内局部变量没有逃离方法的作用访问,是线程私有的,它是线程安全的

      image-20231222145641730

    • 如果是局部变量引用了对象,对象是共有的,并逃离方法的作用范围,需要考虑线程安全

      image-20231222145625818

/**
 * 局部变量的线程安全问题
 */

public class d1_local_var_safe {
    // 多个线程执行这个方法
    public static void method1(String[] args) {
        int x = 0;
        for (int i = 0; i < 5000; i++) {
            x++;
        }
        System.out.println(x);
    }
}

1.2.2 栈内存溢出

  • 栈帧过多导致栈内存溢出。例如方法的递归调用
image-20231222152256064
  • 栈帧过大导致栈内存溢出

1.2.3 线程运行诊断

案例一:CPU 占用过高

  • 可以用 top 命令定位哪个进程对 CPU 的占用过高

  • 找到进程后,我们想进一步的定位到具体的线程,可以用 ps 命令

    • ps H pid,tid,%cpu 可以把当前所有线程的 pid,tid,cpu的信息展示出来
    • 使用管道过滤出具体的进程号:ps h -eo pid,tid,%cpu | grep 32655
  • jstack 进程id 命令可以列出Java虚拟机中的所有的 Java 线程

    • 根据 ps 命令找到的线程号可以在 jstack 中找到对应的线程,里面给出该线程的状态和问题代码行号

案例二:程序运行很长时间没有结果

可能发生了死锁等等

使用 jstack 命令进行检查

1.3 本地方法栈

image-20231222154054304

我们可以通过本地方法调用一些用C/CPP写的更底层的方法,例如Object类中的clone , hashCode… 方法

1.4 堆

image-20231222154417878

1.4.1 定义

Heap 堆:

  • 通过 new 关键词创建对象会使用堆内存

特点:

  • 他是线程共享的,堆中对象需要考虑线程安全问题
  • 堆中有垃圾回收机制

1.4.2 堆内存溢出

不断的向堆中添加对象,且这些对象无法回收,一段时间后会导致堆内存溢出

1.4.3 堆内存诊断

package com.rainsun.d1_Java_memory_structure;
/**
 * 堆内存演示
 */
public class d2_heap_memory {
    public static void main(String[] args) throws InterruptedException {
        System.out.println("1.....");
        Thread.sleep(30000);
        byte[] array = new byte[1024 * 1024 * 10]; // 10Mb 空间
        System.out.println("2.....");
        Thread.sleep(30000);
        array = null;
        System.gc();
        System.out.println("3.....");
        Thread.sleep(100000L);
    }
}

查看堆内存信息:

  • jps 找到当前运行的线程id
  • jhsdb jmap --pid 线程id --heap 输出堆占用信息

1:

image-20231222160549701

2:

image-20231222160605952

3:没有G1 Heap了

  • jconsole 工具

    图形界面的,多功能的监测工具,可以连续监测

1.5 方法区

image-20231222161551426

方法区是线程共享的,存储类相关的信息(方法,构造器,特殊方法,运行时常量池等等)

Chapter 2. The Structure of the Java Virtual Machine (oracle.com)

image-20231222161731756

JDK1.6中的结构:

使用 PermGen 永久代实现

image-20231222161942216

JDK1.8中的结构:

元空间实现,使用操作系统中的本地内存实现:

image-20231222162115139

1.5.4 运行时常量池

  • 常量池,就是一张表,虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息
  • 运行时常量池:
    • 常量池是 *.class 文件中的;
    • 当程序运行的时候,每个被加载的类,它的.class文件中常量池信息就都会放入运行时常量池,运行时常量池保存了所有被加载了的类中的常量池信息
    • 并把里面的符号地址变为真实地址

1.5.5 StringTable

public static void main(String[] args) {
    String s1 = "a";
    String s2 = "b";
    String s3 = "a" + "b";
    String s4 = s1 + s2;
}

反编译:

  • 常量池中的信息,都会被加载到运行时常量池中,这时 a , b 都是常量池中的符号,还没有变成 Java 字符串对象
  • ldc #2 会把 a 符号变为 “a” 字符串对象,并把 “a” 放入 StringTable 中,如果没有则加入新的,有则不加入新的

s1,s2,s3 字符串对象的产生是发生在字符串常量池的 StringTable 中

s4 字符串对象的产生是通过调用两次 makeConcatWithConstants 方法将常量池中的 “a” ,“b” 进行拼接,在堆中创建了一个新的字符串变量,最后存入临时变量 s4中的。

image-20231222174240646

这是 JDK 21 反编译的结果,JDK 8 不一样,可能是 append.append.toString

StringTable 特性

  • 常量池中的字符串仅是符号,第一次用到时才变为对象
  • 利用串池的机制,来避免重复创建字符串对象
  • 字符串变量拼接的原理是 StringBuilder (1.8)
  • 字符串常量拼接的原理是编译期优化
  • 可以使用 intern 方法,主动将串池中还没有的字符串对象放入串池
public static main(String[] args){
    String s = new String("a") + new String("b");
}

StringTable 中创建了字符串对象 [“a”,“b”]

在堆中产生了字符串对象,因为使用了 new 来创建 “a”,“b” ,“ab”

intern:

将字符串对象放入 StringTable,如果table中有则不会放入,没有则放入,并把 table 中的对象返回

String s2 = s.intern(); // 堆中的 "ab" 被放入了 StringTable中了, 并将table中的ab返回
public class d3_stringTable {
    // 常量池中的信息,都会被加载到运行时常量池中,这时 a , b 都是常量池中的符号,还没有变成 Java 字符串对象
    // ldc #2 会把 a 符号变为 "a" 字符串对象,并把 "a" 放入 StringTable 中,如果没有则加入新的,有则不加入新的
    public static void main(String[] args) {
        String s1 = "a";
        String s2 = "b";
        String s3 = "a" + "b"; //javac在编译期间的优化,变成了 "ab",结果在编译期就已经确定了
        String s4 = s1 + s2; // 堆中的ab: new String("ab")

        String s5 = "ab"; // == s3 在table中的ab
        String s6 = s4.intern(); // table中ab已经有了,返回table中的ab

        System.out.println(s3 == s4); //false
        System.out.println(s3 == s5); // true
        System.out.println(s3 == s6); // true

        String x2 = new String("c") + new String("d");
        String x1 = "cd";
        x2.intern();  // table中 cd 已经存在了,x2放不进去table,x2还是堆中的cd
        System.out.println(x1 == x2); // false

        /** 最后两行代码的位置调换:
         * String x2 = new String("c") + new String("d");
         * x2.intern(); // table 中 cd 不存在,x2放入table,x2 变成了table中的cd
         * String x1 = "cd"; // x1 用的是table中的cd
         * System.out.println(x1 == x2); // true
         */
    }
}

1.5.6 StringTable 位置

image-20231222200203414

1.6 中的StringTable在PermGen永久代中实现,它的回收时机比较晚,容易造成永久代的内存空间不足

在1.8中就将StringTable放入堆Heap中实现,它的垃圾回收时机触发比较早,可以更快回收不用的字符串空间

image-20231222162115139

1.5.7 StringTable 垃圾回收

那些没有用到的字符串常量会被垃圾回收

package com.rainsun.d1_Java_memory_structure;

/**
 * 演示 StringTable垃圾回收
 * -Xmx10m
 * -XX:+PrintStringTableStatistics : 打印 StringTable 信息
 * -XX:+PrintGCDetails -verbose:gc :打印垃圾回收信息
 */
public class d4_stringTable_GC {
    public static void main(String[] args) {
        int i = 0;
        try {
            for (int j = 0; j < 100000; j++) {
                String.valueOf(j).intern();
                i++;
            }
        }catch (Throwable e){
            e.printStackTrace();
        }finally {
            System.out.println(i);
        }
    }
}

image-20231222202328823

1.5.8 StringTable 调优

  1. -XX:StringTableSize=桶个数 可以设置String Table 中桶的个数,类似于一个哈希表,当表越大,每个桶中链表的长度就越小,查找的速度就越快
  2. 考虑将字符串对象是否入池
    • 如果字符串大量重复可以让字符串入池,减少重复字符串存在在heap中

1.6 使用操作系统中的直接内存

1.6.1 Direct Memory

  • 常见于 NIO 操作,用于数据缓冲区
  • 分配回收成本较高,但读写性能高
  • 不受 JVM 内存回收管理

  • 传统的阻塞式 IO 读取数据的方式:

CPU从Java的用户态转为系统的内核态,这样可以读取磁盘中的文件到系统的缓冲区,但是系统的缓冲区 Java 无法获取,所以还需要将系统缓冲区中的数据传给Java缓冲区

image-20231222203852847

  • 使用直接内存进行文件读取:

会产生一块 direct memory的区域,操作系统和Java都可以读取

image-20231222204121083

内存溢出问题

当direct memory占用太大会抛出内存溢出异常

1.6.2 分配和回收原理

  • 使用了 Unsafe 对象完成直接内存的分配回收,并且回收需要主动调用 freeMemory 方法

    package com.rainsun.d1_Java_memory_structure;
    
    import sun.misc.Unsafe;
    
    import java.io.IOException;
    import java.lang.reflect.Field;
    
    public class d5_direct_memory {
        static int _1Gb = 1024*1024*1024;
        public static void main(String[] args) throws IOException {
            Unsafe unsafe = getUnsafe();
            // 分配内存
            long base = unsafe.allocateMemory(_1Gb);
            unsafe.setMemory(base, _1Gb, (byte) 0);
            System.in.read();
    
            // 释放内存
            unsafe.freeMemory(base);
            System.in.read();
        }
    
        public static Unsafe getUnsafe() {
            try {
                Field f = Unsafe.class.getDeclaredField("theUnsafe");
                f.setAccessible(true);
                Unsafe unsafe = (Unsafe) f.get(null);
                return unsafe;
            } catch (NoSuchFieldException | IllegalAccessException e) {
                throw new RuntimeException(e);
            }
        }
    }
    
  • ByteBuffer 的实现类内部,使用了 Cleaner (虚引用)来监测 ByteBuffer 对象,一旦 ByteBuffer 对象被垃圾回收,那么就会由 ReferenceHandler 线程通过 Cleaner 的 clean 方法调用 freeMemory 来释放直接内存

    测试:

    public class d6_direct_byteBuffer {
        static int _1Gb = 1024*1024*1024;
        public static void main(String[] args) throws IOException {
            ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_1Gb);
            System.out.println("分配完毕");
            System.in.read();
            System.out.println("开始释放");
            byteBuffer = null;
            System.gc();
            System.in.read();
        }
    }
    

    原理:

    // 分配内存后:
    public static ByteBuffer allocateDirect(int capacity) {
        return new DirectByteBuffer(capacity);
    }
    
    DirectByteBuffer(int cap) { 
        super(-1, 0, cap, cap, null);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        Bits.reserveMemory(size, cap);
    
        long base = 0;
        try {
            base = UNSAFE.allocateMemory(size);
        } catch (OutOfMemoryError x) {
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        UNSAFE.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) {
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else {
            address = base;
        }
        try { // Cleaner检测this对象(ByteBuffer)是否被垃圾回收,如果被回收了就会调用clean方法调用 Deallocator 中的 run 方法 释放内存
            cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
        } catch (Throwable t) {
            // Prevent leak if the Deallocator or Cleaner fail for any reason
            UNSAFE.freeMemory(base);
            Bits.unreserveMemory(size, cap);
            throw t;
        }
        att = null;
    }
    // 实现 Runnable 接口
    private static class Deallocator implements Runnable {
        private long address;
        private long size;
        private int capacity;
    
        private Deallocator(long address, long size, int capacity) {
            assert (address != 0);
            this.address = address;
            this.size = size;
            this.capacity = capacity;
        }
        // Deallocator 中的 run 释放了内存
        public void run() {
            if (address == 0) {
                // Paranoia
                return;
            }
            UNSAFE.freeMemory(address); // 释放内存
            address = 0;
            Bits.unreserveMemory(size, capacity);
        }
    
    }
    
    // clean 方法调用 run 方法:
    public void clean() {
        if (!remove(this))
            return;
        try {
            thunk.run(); // Deallocator 中的 run 被调用
        } catch (final Throwable x) {
            AccessController.doPrivileged(new PrivilegedAction<>() {
                    public Void run() {
                        if (System.err != null)
                            new Error("Cleaner terminated abnormally", x)
                                .printStackTrace();
                        System.exit(1);
                        return null;
                    }});
        }
    }
    

1.6.3 禁用显示垃圾回收

-XX:+DisableExplicitGC 禁用显式的垃圾回收

显示垃圾回收写法:

System.gc();

这种垃圾回收都是 Full GC的,回收比较满,常用于性能调优

这可能会对Direct memory 的内存回收有影响,因为这里的Direct memory的内存回收是需要Java中的对象被回收时才会被触发的;

例如这里是ByteBuffer对象被回收,触发了分配的直接内存的回收。

所以还是用Unsafe对象手动的调用 freeMemory 进行回收比较好

文章来源:https://blog.csdn.net/qq_45364953/article/details/135161452
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。