并发编程之java内存模型JMM & synchronize & volatile详解

简介: 并发编程之java内存模型JMM & synchronize & volatile详解

一. 什么是JMM模型?



JMM描述的是一组规范, 它类似于cpu和内存的架构. 这套模型是为了适配不同的操作系统, 不同的硬件结构, 屏蔽掉底层的微小的差异. jvm为什么可以跨平台呢? 有一方面就是JMM内存模型的设计. 尤其是多线程, 再调底层操作系统的时候, 为了屏蔽底层细节的差异, java抽象出来的一个概念, 叫做java线程的工作模型, 也叫java的内存模型


  • Java内存模型(Java Memory Model简称JMM)是一种抽象的概念,并不真实存在的
  • 它描述的是一组规则或规范,通过这组规范定义了程序中各个变量(包括实例字段,静态字段 和构成数组对象的元素)的访问方式。
  • JVM运行程序的实体是线程,而每个线程创建时 JVM都会为其创建一个工作内存(有些地方称为栈空间),用于存储线程私有的数据,而Java 内存模型中规定所有变量都存储在主内存,主内存是共享内存区域,所有线程都可以访问, 但线程对变量的操作(读取赋值等)必须在工作内存中进行,首先要将变量从主内存拷贝的自己的工作内存空间,然后对变量进行操作,操作完成后再将变量写回主内存,不能直接操作主内存中的变量,工作内存中存储着主内存中的变量副本拷贝,前面说过,工作内存是每个 线程的私有数据区域,因此不同的线程间无法访问对方的工作内存,线程间的通信(传值)必须通过主内存来完成。

 

二. JMM不同于JVM内存区域模型


  • JMM与JVM内存区域的划分是不同的概念层次
  • 更恰当说JMM描述的是一组规则通过这组规则控制程序中各个变量在共享数据区域和私有数据区域的访问方式
  • JMM是围绕原子性,有序性、可见性展开。
  • JMM与Java内存区域唯一相似点,都存在共享数据区域和 私有数据区域
  • 在JMM中主内存属于共享数据区域,从某个程度上讲应该包括了堆和方法 区,而工作内存属于私有数据区域,从某个程度上讲则应该包括程序计数器、虚拟机栈以及本地方法栈。

 

三. 线程,工作内存,主内存工作交互图(基于JMM规范)


1187916-20200825164203205-1745054546.png


下面来感受一下: 工作内存和主内存的概念.

现在有这样一段代码:

public class Main {
    private static boolean initFlag = false;
    public static void refresh() {
        System.out.println("refresh data.....");
        initFlag = true;
        System.out.println("refresh data success");
    }
    public static void main(String[] args) {
        // 线程A
        Thread threadA = new Thread(() ->{
           while (!initFlag) {
           }
            System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
        }, "threadA");
        threadA.start();
        // 中间休眠500hs
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 线程B
        Thread threadB = new Thread(() ->{
            while (!initFlag) {
                refresh();
            }
        }, "threadB");
        threadB.start();
    }
}

这样一段代码, 当程序启动以后, 其内存模型是什么样的呢?


1187916-20200825193649549-2058307888.png

  1. 线程A和线程B启动的时候, 都创建一个线程自己的工作内存. 这个工作内存是一个概念,并不是真实存在的.
  2. 工作内存用来存储线程需要使用到的变量, 准确来说, 是变量的副本.
  3. 线程A和线程B同时访问了变量initFlag, initFlag就是共享变量. 共享变量, 相对工作内存来说, 他保存在主内存中
  4. JMM和JVM是不同的, JVM是针对GC的, 内存的分配和回收; JMM是针对多线程运行的一个抽象的规范. 他是抽象的, 具体的实现有不同的场景和不同的虚拟机自己来实现.
  5. 当线程A启动的时候, 首先会拷贝initFlag到工作内存, 线程A的while循环调用了initFlag, 使用的是其工作内存中的变量.
  6. 当线程B启动的时候, 会拷贝initFlag到工作内存, 线程B的while循环调用initFlag, 其循环体修改了initFlag的值为true, 然后在将initFlag同步给主内存.

 

31. 主内存


  • 主要存储的是Java实例对象,所有线程创建的实例对象都存放在主内存中,不管该实例对象是成员变量还是方法中的本地变量(也称局部变量),当然也包括了共享的类信息、常 量、静态变量。
  • 由于是共享数据区域,多条线程对同一个变量进行访问可能会发生线程安全问题。


3.2 工作内存


  • 主要存储当前方法的所有本地变量信息(工作内存中存储着主内存中的变量副本拷贝)
  • 每个线程只能访问自己的工作内存,即线程中的本地变量对其它线程是不可见的,就算是两个线程执行的是同一段代码,它们也会各自在自己的工作内存中创建属于当前线程的本地变量,当然也包括了字节码行号指示器、相关Native方法的信息。
  • 注意: 由于工作内存是每个线程的私有数据,线程间无法相互访问工作内存,因此存储在工作内存的数据不存在线程安 全问题。

 

3.3 对象的保存


  • 根据JVM虚拟机规范, 主内存与工作内存的数据存储类型以及操作方式,对于一个实例对 象中的成员方法而言,
  • 如果方法中包含本地变量是基本数据类型 (boolean,byte,short,char,int,long,float,double),将直接存储在工作内存的帧栈结构中,
  • 但倘若本地变量是引用类型,那么该变量的引用会存储在功能内存的帧栈中,而对象实例将存储在主内存(共享数据区域,堆)中。但对于实例对象的成员变量,不管它是基本数据类型或者包装类型(Integer、Double等)还是引用类型,都会被存储到堆区至于static变 量以及类本身相关信息将会存储在主内存中
  • 需要注意的是,在主内存中的实例对象可以被多线程共享,倘若两个线程同时调用了同一个对象的同一个方法,那么两条线程会将要操作 的数据拷贝一份到自己的工作内存中,执行完成操作后才刷新到主内存


如下图所示.

1187916-20200825165938946-683466681.png

3.4 Java内存模型与硬件内存架构的关系


  • 通过对前面的硬件内存架构、Java内存模型以及Java多线程的实现原理的了解,我们应该已经意识到,多线程的执行最终都会映射到硬件处理器上进行执行,但Java内存模型和硬 件内存架构并不完全一致
  • 对于硬件内存来说只有寄存器、缓存内存、主内存的概念,并没有工作内存(线程私有数据区域)和主内存(堆内存)之分,也就是说Java内存模型对内存的划分对硬件内存并没有任何影响,因为JMM只是一种抽象的概念,是一组规则,并不实际存 在,不管是工作内存的数据还是主内存的数据,对于计算机硬件来说都会存储在计算机主内存中,当然也有可能存储到CPU缓存或者寄存器中,因此总体上来说,Java内存模型和计算机硬件内存架构是一个相互交叉的关系,是一种抽象概念划分与真实物理硬件的交叉。(注意对于Java内存区域划分也是同样的道理)

1187916-20200825170714061-728268654.png


四. JMM存在的必要性



在明白了Java内存区域划分、硬件内存架构、Java多线程的实现原理与Java内存模型 的具体关系后,接着来谈谈Java内存模型存在的必要性。


  • 由于JVM运行程序的实体是线程,而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间),用于存储线程私有的数据,线程主内存中的变量操作必须通过工作内存间接完成,主要过程是将变量从主内存拷贝的每个线程各自的工作内存空间,然后对变量进行操作,操作完成后再将变量写回主内存,如果存在两个线程同时对一个主内存中的实例对象的变量进行操作就有可能诱发线程安全问题。

 

  • 假设主内存中存在一个共享变量x,现在有A和B两条线程分别对该变量x=1进行操作, A/B线程各自的工作内存中存在共享变量副本x

假设现在A线程想要修改x的值为2,而B线 程却想要读取x的值,那么B线程读取到的值是A线程更新后的值2还是更新前的值1呢?


答案是,不确定,即B线程有可能读取到A线程更新前的值1,也有可能读取到A线程更新后的值2,


这是因为工作内存是每个线程私有的数据区域,而线程A变量x时,首先是将变量从主内 存拷贝到A线程的工作内存中,然后对变量进行操作,操作完成后再将变量x写回主内,

而对于B线程的也是类似的,这样就有可能造成主内存与工作内存间数据存在一致性问题,假 如A线程修改完后正在将数据写回主内存,而B线程此时正在读取主内存,即将x=1拷贝到 自己的工作内存中,这样B线程读取到的值就是x=1,但如果A线程已将x=2写回主内存后, B线程才开始读取的话,那么此时B线程读取到的就是x=2,但到底是哪种情况先发生呢?


如以下示例图所示案例:


1187916-20200825171657537-529289059.png

五. 数据同步的八大操作



还是上面的例子, 线程A是如何把变量initFlag读取到工作内存的? 他在工作内存是怎么工作的呢? 下面我们就来分析这个例子在内存模型中的使用.

public class Main {
    private static boolean initFlag = false;
    public static void refresh() {
        System.out.println("refresh data.....");
        initFlag = true;
        System.out.println("refresh data success");
    }
    public static void main(String[] args) {
        // 线程A
        Thread threadA = new Thread(() ->{
           while (!initFlag) {
           }
            System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
        }, "threadA");
        threadA.start();
        // 中间休眠500hs
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 线程B
        Thread threadB = new Thread(() ->{
            while (!initFlag) {
                refresh();
            }
        }, "threadB");
        threadB.start();
    }
}

这里是先执行线程A, 然后休眠5秒, 执行线程B.

运行结果:

1187916-20200825195114693-1202621412.png以上是关于主内存与工作内存之间的具体交互协议,即一个变量如何从主内存拷贝到工作 内存、如何从工作内存同步到主内存之间的实现细节,

 

Java内存模型定义了以下八种操作, 具体如下:


  1. lock(锁定):作用于主内存的变量,把一个变量标记为一条线程独占状态
  2. unlock(解锁):作用于主内存的变量,把一个处于锁定状态的变量释放出来,释放后 的变量才可以被其他线程锁定
  3. read(读取):作用于主内存的变量。把一个变量值从主内存传输到线程的工作内存 中,以便随后的load动作使用
  4. load(载入):作用于工作内存的变量。它把read操作从主内存中得到的变量值放入工 作内存的变量副本中
  5. use(使用):作用于工作内存的变量。把工作内存中的一个变量值传递给执行引擎
  6. assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋给工作内 存的变量
  7. store(存储):作用于工作内存的变量,把工作内存中的一个变量的值传送到主内存 中,以便随后的write的操作
  8. write(写入):作用于工作内存的变量,它把store操作从工作内存中的一个变量的值 传送到主内存的变量中


如果要把一个变量从主内存中复制到工作内存中,就需要按顺序地执行read和load操作,如果把变量从工作内存中同步到主内存中,就需要按顺序地执行store和write操作。但


Java内存模型只要求上述操作必须按顺序执行,而没有保证必须是连续执行。

1187916-20200825172043535-704329723.png

下面就之前的案例来分析一下, 线程到底是如何将initFlag这个变量从主内存拷贝到工作内存的?


java的内存模型定义了8大原子操作, 所谓的原子操作, 就是执行的过程中, 不可以被终端, 要么都成功, 要么都失败.  这8个操作, 其中有六个是用来做数据交互的(3-8), 有两个是做数据安全操作的(1-2).

 

线程A启动后,


首先. 执行read操作,作用于主内存, 将变量initFlag从主内存拷贝一份, 这时候还没有放到工作内存中. 而是放在了总线里. 如下图.


第二步: 执行load操作,作用于工作内存, 将上一步拷贝的变量, 放入工作内存中.


第三步: 执行use(使用)操作,作用于工作内存, 把工作内存中的变量传递给执行引擎. 对于线程A来说, 执行引擎会判断initFlag=true么? 不等于, 循环一直进行.


执行过程如下图

1187916-20200827195839065-1589944673.png


线程B启动后


首先: 执行read操作,作用于主内存, 从主内存拷贝initFlag变量, 这时候拷贝的变量还没有放到工作内存中, 这一步是为了load做准备


第二步:执行load操作,作用于工作内存, 将拷贝的变量放入到工作内存中,


第三步: 执行use操作, 作用于工作内存, 将工作内存中的变量传递给执行引擎, 执行引擎判断while==false, 那么执行循环体.


第四步: 执行assign操作,作用于工作内存,他把从执行引擎接收的值赋值给工作内存的变量, 即设置initFlag = true


第五步: 执行store操作,作用于工作内存,将工作内存中的变量initFlag=true传给主内存


第六步: 执行write操作, 作用于工作内存,将变量写入到主内存中

1187916-20200828111434149-1309427281.png


同步规则分析


  1. 不允许一个线程无原因地(没有发生过任何assign操作)把数据从工作内存同步回主内 存中
  2. 一个新的变量只能在主内存中诞生,不允许在工作内存中直接使用一个未被初始化(load或者assign)的变量。即就是对一个变量实施use和store操作之前,必须先执行assign和load操作
  3. 一个变量在同一时刻只允许一条线程对其进行lock操作,但lock操作可以被同一线程重复执行多次,多次执行lock后,只有执行相同次数的unlock操作,变量才会被解锁。lock 和unlock必须成对出现。
  4. 如果对一个变量执行lock操作,将会清空工作内存中此变量的值,在执行引擎使用这个 变量之前需要重新执行load或assign操作初始化变量的值。
  5. 如果一个变量事先没有被lock操作锁定,则不允许对它执行unlock操作;也不允许去 unlock一个被其他线程锁定的变量。 6)对一个变量执行unlock操作之前,必须先把此变量同步到主内存中(执行store和write 操作)

 

六. 并发编程的可见性原子性有序性问题


 

6.1 JMM三大特性


1. 原子性


原子性指的是一个操作是不可中断的,即使是在多线程环境下,一个操作一旦开始就不会被其他线程影响。


在java中,对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是,对 于32位系统的来说,long类型数据和double类型数据(对于基本数据类型,

byte,short,int,float,boolean,char读写是原子操作),它们的读写并非原子性的,也就是说 如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的,因 为对于32位虚拟机来说,每次原子读写是32位的,而long和double则是64位的存储单元, 这样会导致一个线程在写时,操作完前32位的原子操作后,轮到B线程读取时,恰好只读取 到了后32位的数据,这样可能会读取到一个既非原值又不是线程修改值的变量,它可能 是“半个变量”的数值,即64位数据被两个线程分成了两次读取。但也不必太担心,因为 读取到“半个变量”的情况比较少见,至少在目前的商用的虚拟机中,几乎都把64位的数 据的读写操作作为原子操作来执行,因此对于这个问题不必太在意,知道这么回事即可。


2 可见性


理解了指令重排现象后,可见性容易了,可见性指的是当一个线程修改了某个共享变量的值,其他线程是否能够马上得知这个修改的值。


对于串行程序来说,可见性是不存在的, 因为我们在任何一个操作中修改了某个变量的值,后续的操作中都能读取这个变量值,并且是修改过的新值。


但在多线程环境中可就不一定了,前面我们分析过,由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的,这就可能存在一个线程A修改了共享变量x的值,还未写回主内存时,另外一个线程B又对主内存中同一个共享变量x进行操作,但此时A线程工作内存中共享变量x对线程B来说并不可见,这种工作内存与主内存同步 延迟现象就造成了可见性问题另外指令重排以及编译器优化也可能导致可见性问题,通过前面的分析,我们知道无论是编译器优化还是处理器优化的重排现象,在多线程环境下,确实会导致程序轮序执行的问题,从而也就导致可见性问题。


3 有序性


有序性是指对于单线程的执行代码,我们总是认为代码的执行是按顺序依次执行的,这

样的理解并没有毛病,毕竟对于单线程而言确实如此,但对于多线程环境,则可能出现乱序 现象,因为程序编译成机器码指令后可能会出现指令重排现象,重排后的指令与原指令的顺 序未必一致,要明白的是,在Java程序中,倘若在本线程内,所有操作都视为有序行为,如 果是多线程环境下,一个线程中观察另外一个线程,所有操作都是无序的,前半句指的是单 线程内保证串行语义执行的一致性,后半句则指指令重排现象和工作内存与主内存同步延迟 现象。


6.2  JMM如何解决原子性&可见性&有序性问题

1. 可见性问题


volatile关键字保证可见性。

当一个共享变量被volatile修饰时,它会保证修改的值立即被其他的线程看到,即修改的值立即更新到主存中,当其他线程需要读取时,它会去内存中读取新值。

synchronized和Lock也可以保证可见性,因为它们可以保证任一时刻只有一个线程能访问共享资源,并在其释放锁之前将修改的变量刷新到内存中。

public class Main {
    private volatile static boolean initFlag = false;
   public static void refresh() {
        System.out.println("refresh data.....");
        initFlag = true;
        System.out.println("refresh data success");
    }
    public static void main(String[] args) {
        // 线程A
        Thread threadA = new Thread(() ->{
           while (!initFlag) {
           }
            System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
        }, "threadA");
        threadA.start();
        // 中间休眠500hs
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 线程B
        Thread threadB = new Thread(() ->{
            while (!initFlag) {
                refresh();
            }
        }, "threadB");
        threadB.start();
    }
}

测试:

1. 当变量initFlag不加volatile关键字的时候, 线程B修改了共享变量, 线程A是看不到的

2. 当变量initFlag加上volatile关键字的时候, 线程B修改了共享变量, 线程A是可以看到的

3. 下面做另一个修改: 增加一个变量, initFlag去掉关键字volatile. 我们发现线程B修改了共享变量, 线程A是看不到的

public class Main {
    private static boolean initFlag = false;
    private static int counter = 0;
    public static void refresh() {
        System.out.println("refresh data.....");
        initFlag = true;
        System.out.println("refresh data success");
    }
    public static void main(String[] args) {
        // 线程A
        Thread threadA = new Thread(() ->{
           while (!initFlag) {
                counter ++;
           }
            System.out.println("线程:" + Thread.currentThread().getName() + "当前线程秀谈到initFlag的状态已经改变");
        }, "threadA");
        threadA.start();
        // 中间休眠500hs
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 线程B
        Thread threadB = new Thread(() ->{
            while (!initFlag) {
                refresh();
            }
        }, "threadB");
        threadB.start();
    }
}

4. 如果将int counter改为Integer counter, 会怎么样呢?


privatestaticInteger counter = 0;

我们发现, 线程B修改了共享变量, 线程A是可以看到了.

 

通过上面的例子, 我们得到的结论:


有的时候, 线程A的修改, 线程B是能看到的,有时候是看不到的. 其实, 线程A的修改, 线程B是可以看到的, 只是不能及时看到.


而我们加上volatile关键字以后, 可以及时看到变量的修改

 

2. 原子性


volatile可以保证可见性, 他能保证原子性么?


volatile不能保证原子性. 看下面的例子

public class VolatileTest {
    private static int counter = 0;
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            Thread threadA = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int j = 0; j < 1000; j++) {
                        counter ++;
                    }
                }
            });
            threadA.start();
        }
        try {
            Thread.sleep(1000l);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("统计:" + counter);
    }
}

起了10个线程, 每个线程加到1000, 10个线程, 一共是10000.

而实际结果,不到10000, 原因是: 有并发操作.

 

这时候, 如果我在counter上加关键字volatile, 可以保证原子性么?

private volatile static int counter = 0;

1187916-20200828122050950-2100044001.png


我们发现, 依然不是10000, 这说明volatile不能保证原子性.

每个线程, 只有一个操作, counter++, 为什么不能保证原子性呢?

其实counter++不是一步完成的. 他是分为多步完成的. 我们用下面的图来解释


1187916-20200828123459487-1034870849.png


线程A通过read,, load将变量加载到工作内存, 通过user将变量发送到执行引擎, 执行引擎执行counter++

这是线程B启动了, 通过read,, load将变量加载到工作内存, 通过user将变量发送到执行引擎, 然后执行复制操作assign, stroe, write操作. 我们看到这是经过了n个步骤. 虽然看起来就是简单的一句话.

当线程B执行store将数据回传到主内存的时候, 同时会通知线程A, 丢弃counter++, 而这时counter已经自加了1, 将自加后的counter丢掉, 就导致总数据少1.

 

如何能保证原子性呢? 加上Synchronize关键字

 

除了JVM自身提供的对基本数据类型读写操作的原子性外,可以通过 synchronized和Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码 块。

 

3. 有序性问题


在Java里面,可以通过volatile关键字来保证一定的“有序性”(具体原理在下一节讲述volatile关键字)。


另外可以通过synchronized和Lock来保证有序性,很显然, synchronized和Lock保证每个时刻是有一个线程执行同步代码,相当于是让线程顺序执行同步代码,自然就保证了有序性。


相关文章
|
16天前
|
安全 Java 程序员
深入理解Java内存模型与并发编程####
本文旨在探讨Java内存模型(JMM)的复杂性及其对并发编程的影响,不同于传统的摘要形式,本文将以一个实际案例为引子,逐步揭示JMM的核心概念,包括原子性、可见性、有序性,以及这些特性在多线程环境下的具体表现。通过对比分析不同并发工具类的应用,如synchronized、volatile关键字、Lock接口及其实现等,本文将展示如何在实践中有效利用JMM来设计高效且安全的并发程序。最后,还将简要介绍Java 8及更高版本中引入的新特性,如StampedLock,以及它们如何进一步优化多线程编程模型。 ####
21 0
|
16天前
|
存储 监控 算法
深入探索Java虚拟机(JVM)的内存管理机制
本文旨在为读者提供对Java虚拟机(JVM)内存管理机制的深入理解。通过详细解析JVM的内存结构、垃圾回收算法以及性能优化策略,本文不仅揭示了Java程序高效运行背后的原理,还为开发者提供了优化应用程序性能的实用技巧。不同于常规摘要仅概述文章大意,本文摘要将简要介绍JVM内存管理的关键点,为读者提供一个清晰的学习路线图。
|
18天前
|
存储 算法 Java
Java内存管理深度解析####
本文深入探讨了Java虚拟机(JVM)中的内存分配与垃圾回收机制,揭示了其高效管理内存的奥秘。文章首先概述了JVM内存模型,随后详细阐述了堆、栈、方法区等关键区域的作用及管理策略。在垃圾回收部分,重点介绍了标记-清除、复制算法、标记-整理等多种回收算法的工作原理及其适用场景,并通过实际案例分析了不同GC策略对应用性能的影响。对于开发者而言,理解这些原理有助于编写出更加高效、稳定的Java应用程序。 ####
|
15天前
|
存储 监控 算法
Java内存管理的艺术:深入理解垃圾回收机制####
本文将引领读者探索Java虚拟机(JVM)中垃圾回收的奥秘,解析其背后的算法原理,通过实例揭示调优策略,旨在提升Java开发者对内存管理能力的认知,优化应用程序性能。 ####
30 0
|
27天前
|
缓存 Prometheus 监控
Elasticsearch集群JVM调优设置合适的堆内存大小
Elasticsearch集群JVM调优设置合适的堆内存大小
211 1
|
25天前
|
Java
JVM内存参数
-Xmx[]:堆空间最大内存 -Xms[]:堆空间最小内存,一般设置成跟堆空间最大内存一样的 -Xmn[]:新生代的最大内存 -xx[use 垃圾回收器名称]:指定垃圾回收器 -xss:设置单个线程栈大小 一般设堆空间为最大可用物理地址的百分之80
|
26天前
|
Java
JVM运行时数据区(内存结构)
1)虚拟机栈:每次调用方法都会在虚拟机栈中产生一个栈帧,每个栈帧中都有方法的参数、局部变量、方法出口等信息,方法执行完毕后释放栈帧 (2)本地方法栈:为native修饰的本地方法提供的空间,在HotSpot中与虚拟机合二为一 (3)程序计数器:保存指令执行的地址,方便线程切回后能继续执行代码
21 3
|
27天前
|
存储 缓存 监控
Elasticsearch集群JVM调优堆外内存
Elasticsearch集群JVM调优堆外内存
45 1
|
1月前
|
Arthas 监控 Java
JVM进阶调优系列(9)大厂面试官:内存溢出几种?能否现场演示一下?| 面试就那点事
本文介绍了JVM内存溢出(OOM)的四种类型:堆内存、栈内存、元数据区和直接内存溢出。每种类型通过示例代码演示了如何触发OOM,并分析了其原因。文章还提供了如何使用JVM命令工具(如jmap、jhat、GCeasy、Arthas等)分析和定位内存溢出问题的方法。最后,强调了合理设置JVM参数和及时回收内存的重要性。
|
2月前
|
缓存 算法 Java
JVM知识体系学习六:JVM垃圾是什么、GC常用垃圾清除算法、堆内存逻辑分区、栈上分配、对象何时进入老年代、有关老年代新生代的两个问题、常见的垃圾回收器、CMS
这篇文章详细介绍了Java虚拟机(JVM)中的垃圾回收机制,包括垃圾的定义、垃圾回收算法、堆内存的逻辑分区、对象的内存分配和回收过程,以及不同垃圾回收器的工作原理和参数设置。
79 4
JVM知识体系学习六:JVM垃圾是什么、GC常用垃圾清除算法、堆内存逻辑分区、栈上分配、对象何时进入老年代、有关老年代新生代的两个问题、常见的垃圾回收器、CMS
下一篇
DataWorks