当前位置:首页 > 内存 > 正文

jdk8jvm内存模型

  • 内存
  • 2024-06-08 19:15:55
  • 5107

一、一、Android虚拟机内存模型

剖析JVM运行时数据空间
刘望舒的博客
虚拟机内存模型

1.程序计数器:是唯一决定程序指令执行顺序的块。内存溢出区

虚拟机栈

**它也是线程私有的,存储方法内的局部变量、方法出口等。该方法的每次执行相当于压入一个栈帧。方法执行后,栈帧从Java虚拟机栈中弹出。

3.本地方法区
负责管理虚拟机中使用的C方法。

4.堆内存区域
Java堆是所有线程共享的区域,用于存储对象的实例。它们不必在物理上连续,只需在逻辑上连续即可。

5.方法区
方法区是所有线程共享的内存区域,存储Java虚拟机所使用的类的结构信息(运行时常量池、字段)。用于存储。、方法信息静态变量和其他数据。

类文件内容


二、java多线程的内存模型?


硬件内存模型

物理机并发处理方案是针对...JVM的内存模型的实现也有很大的参考作用,毕竟JVM也是做硬件层的事情,底层的架构也决定了上层的架构建模方式。


计算机中的并发不仅仅局限于多个处理器参与计算,而是会涉及到一系列的硬件问题,其中最直接的就是需要用于记忆交互。然而,计算机的存储设备与处理器的预算速度相差很大,根本无法满足处理器的处理速度。需要做的就是在内存之间添加一层读写速度接近处理器运行速度的缓存作为处理器和缓冲区。


缓存从内存中复制使用过的数据,以方便处理器快速运行,然后将计算出的数据与主存同步,这样处理器就不会需要等待。


缓存虽然解决了处理器和内存间的冲突,但也给计算机带来了另一个问题:缓存一致性。特别是当多个处理器具有相同的主存区域时,它们的缓存数据可能会不一致。


那么当出现矛盾时,谁应该获胜呢?


为了解决这个问题,处理器和内存之间的读写需要遵循一定的协议,包括:MSI、MESI、MOSI等。Synapse、Firefly、DragonProtocol等这就是上图中处理器、缓存和内存的处理方式。


除了缓存之外,为了充分利用处理器,处理器还会对输入代码的乱序执行进行优化指令,只要输出一致,就可以重新组织输入信息是乱序的,因此程序中语句计算的顺序与输入代码的顺序并不对应。



JVM内存模型

我们了解您的意思上面说了设备内存模型,以此为参考,我们来看看jvm内存模型。



jvm为了实现跨平台一致的内存访问效果而定义的一组Java内存模型,从而屏蔽消除了不同设备和操作系统之间内存访问的差异。这与C和C++不同。C和C++会直接使用操作系统的物理硬件和内存模型来进行处理,所以每个平台都会有差异。Java的情况并非如此。


Java的内存模型规定所有变量都存储在主存中。Java课程发现每个线程都有自己的工作内存,工作内存保存为线程使用的变量的主内存副本。所有操作、读取和变量赋值都必须由线程在工作内存中执行。主存变量不能直接写入。线程之间传递变量值需要主内存来完成。



三、JVM知识点补充——永久代和元空间

全面理解JVM:从永久代到元空间的演变


在探索JVM的世界时,我们接触到了许多核心概念。今天我们将重点讨论尚未详细解释的部分-持久代和元空间以及它们如何塑造JVM内存管理的关键方面。


永久代:往事的回忆

在JDK8之前,热点虚拟机中的方法区有一个特殊的名字——永久代。该名称源自早期Java应用程序中类的静态性质,它们被认为是持久的且不易卸载。由于类是JVM的一部分,因此它们不属于程序员创建的堆内存,而是处于没有堆的“永久代”中。


永久代的大小可以通过设置-XX:MaxPermSize参数来预设。例如,32位系统的默认值为64MB,64位系统的默认值为85MB。然而,一旦类元数据超过指定值,此功能也会引入内存溢出的问题。尤其是JDK7之前,字符串常量池的内存消耗较大,导致性能问题和内存溢出。


Metaspace:新时代的解决方案

为了解决这些问题,Hotspot在JDK8中引入了Metaspace。元空间本质上是一种方法空间优化,但与永久代有显着不同。元空间并不驻留在虚拟机内,而是依赖于本地存储,因此其大小由本地存储限制决定。-XX:MetaspaceSize和-XX:MaxMetaspaceSize等参数可以让用户更灵活地管理元空间。


元空间内存管理更加高效。类加载器的生命周期决定了其元数据的生命周期,从而避免类元数据的意外释放。将元空间垃圾收集与堆内存分离可以减少内存溢出问题,并使监视自定义类加载器变得更加容易。


运行时常量池:位置变化

在JDK6之前,运行时常量池是方法区的一部分,但随着Hotspot的更新,它被移到了堆中。以提高性能。()方法保证了常量池的唯一性,优化了字符串管理。


挑战与未来:Metaspace的局限性

虽然Metaspace解决了一些问题,但它仍然面临着挑战,例如:由类加载器类型确定的块大小与实际碎片要求之间可能会出现不匹配。幸运的是,元空间虚拟机尚不支持压缩操作,这使得碎片管理成为一个紧迫的问题。


JVM的世界未来还会继续发展,我们期待进一步的优化措施。如果您对JVM内存管理感兴趣,欢迎访问我的博客或者关注我的平台。或许还有更多惊喜等着你。


注意:本文内容不包含链接和作者信息,重点介绍JVM内存管理的核心知识点。