方法区---JVM(九)

最新推荐文章于 2022-04-19 10:09:09 发布
最新推荐文章于 2022-04-19 10:09:09 发布
阅读量228 收藏
点赞数 1
文章标签： jvm
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43860530/article/details/106307280
版权

b站尚硅谷的JVM学习笔记--https://www.bilibili.com/video/BV1PJ411n7xZ

方法区

在这里插入图片描述

方法区在哪里?

  《Java虚拟机规范》中明确说明:“尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。”但对 于HotSpotJVM而言，方法区还有一个别名叫做Non- Heap (非堆)，目的就是要和堆分开。所以，方法区看作是一块独立于Java堆的内存空间。
在这里插入图片描述

方法区的基本理解

  • 方法区(Method Area) 与Java堆一样，是各个线程共享的内存区域。
  • 方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都
    可以是不连续的。
  • 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。
  • 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区
    溢出，虚拟机同样会抛出内存溢出错误: java.lang.outofMemoryError:PermGen space或者java.lang.OutOfMemoryError: Metaspace
  • 关闭JVM就会释放这个区域的内存。

Hotspot中方法区的演进

  • 在jdk7及以前，习惯上把方法区，称为永久代。jdk8开始，使用元空间取代了永久代。
  • 本质上，方法区和永久代并不等价。仅是对hotspot而言的。《Java虚拟机规范》对如何实现方法区，不做统一要求。例如: BEA JRockit/IBM J9中不存在永久代的概念。
  • 现在来看，当年使用永久代，不是好的idea。导致Java程序更容易OOM (超过-XX:MaxPermSize上限)
  • 而到了JDK 8，终于完全废弃了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间(Metaspace) 来代替
  • 元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存。
  • 永久代、元空间二者并不只是名字变了，内部结构也调整了。
  • 根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将
    抛出0OM异常。

在这里插入图片描述

设置方法区内存的大小

方法区的大小不必是固定的，jvm可以根据应用的需要动态调整。
jdk7及以前:

  • 通过-xx: PermSize来设置永久代初始分配空间。默认值是20.75M
  • -XX:MaxPermSize来 设定永久代最大可分配空间。32位机器默认是64M，64位机器模式是82M
  • 当JVM加载的类信息容 量超过了这个值，会报异常OutOfMemoryError : PermGenspace。

jdk8及以后:

  • 元数据区大小可以使用参数-XX : MetaspaceSize和-XX :MaxMetaspaceSize低指定
    替代上述原有的两个参数。
  • 默认值依赖于平台。windows下，-XX :MetaspaceSize是21M，-XX :MaxMetaspaceSize的值是-1，即没有限制。
  • 与永久代不同，如果不指定大小，默认情况下，虛拟机会耗尽所有的可用系统内存。如果元数据区发生溢出，虚拟机一样会拋出异常OutOfMemoryError: Metaspace
  • -XX:MetaspaceSize设置初始的元空间大小。对于一-个64位的服务器端JVM来说其默认的-XX:MetaspaceSize值为21MB。这就是初始的高水位线，一旦触及这个水位线，Full GC将会被触发并卸载没用的类(即这些类对应的类加载器不再存活)，然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足，那么在不超过MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值。
  • 如果初始化的高水位线设置过低，，上述高水 位线调整情况会发生很多次。通过垃圾回收器的日志可以观察到Full GC多次调用。为了避免频繁地GC，建议将-XX:MetaspaceSize设置为一个相对较高的值。

如何解决这些OOM?

1、要解决OOM异常或heap space的异常，一般的手段是首先通过内存映像分析工具(如Eclipse Memory Analyzer) 对dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory Overflow) 。
2、如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与GCRoots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息，以及GC Roots 引用链的信息，就可以比较准确地定位出泄漏代码的位置。
3、如果不存在内存泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数(-Xmx与-Xms)，与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

在这里插入图片描述

方法区( Method Area )存储什么?

《深入理解Java虚拟机》书中对方法区(Method Area)存储内容描述如下：它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

在这里插入图片描述
下面说明以下几个信息，剩余的在后面会学到

类型信息

对每个加载的类型(类class、接口interface、枚举enum、注解annotation)，JVM必须在方法区中存储以下类型信息:

  1. 这个类型的完整有效名称(全名=包名.类名)
  2. 这个类型直接父类的完整有效名(对于interface或是java.lang.object，都没有父类)
  3. 这个类型的修饰符(public, abstract, final的某个子集)
  4. 这个类型直接接口的一个有序列表.
域(Field)信息
  • JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
  • 域的相关信息包括:域名称、域类型、域修饰符(public, private, protected, static, final, volatile, transient的某个子集)
方法(Method)信息。
  • JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序
  • 方法名称
  • 方法的返回类型(或void)
  • 方法参数的数量和类型(按顺序)
  • 方法的修饰符(public, private, protected, static, final, synchronized, native, abstract的一个子集)
  • 方法的字节码(bytecodes)、 操作数栈、局部变量表及大小 (abstract和native方法除外)
  • 异常表( abstract和native方法除外)
    每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

补充说明:全局常量: static final

被声明为final的类变量的处理方法则不同，每个全局常量在编译的时候就会被分配了。

运行时常量池

  • 运行时常量池( Runtime Constant Pool) 是方法区的- -部分。
  • 常量池表( Constant Pool Table) 是Class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。运行时常量池，在加载类和接口到虛拟机后，就会创建对应的运行时常量池。JVM为每个己加载的类型(类或接口) 都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的。
  • 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址。
  • 运行时常量池，相对于Class文件常量池的另一重要特征是:具备动态性。运行时常量池类似于传统编程语言中的符号表(symboltable)，但是它所包含的数据却比符号表要更加丰富一些。
  • 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法
    区所能提供的最大值，则JVM会 抛OutOfMemoryError异常。
  • 常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

方法区的演进细节

  • 首先明确:只有HotSpot才有永久代。
    BEA JRockit、 IBM J9等来说，是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。
  • 方法区的变化：
jdk1.6及之前有永久代(permanent generation) ，静态变量存放在永久代上
jdk1.7有永久代(permanent generation) ，静态变量存放在永久代上
jdk1 .8及之后无永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆中

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

直接内存概述

  • 不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。
  • 直接内存是在Java堆外的、直接向系统申请的内存区间。来源于NIO，通过存在堆中的DirectByteBuffer操作Native内存
  • 通常，访问直接内存的速度会优于Java堆。即读写性能高。
      * 因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存。
      * Java的NIO库允许Java程序使用直接内存，用于数据缓冲区
  • 直接内存大小可以通过MaxDirectMemorySize设置，如果不指定，默认与堆的最大值-Xmx参数值一致
    本地内存的OOM: OutofMemoryError: Direct buffer memory
缺点
  • 分配回收成本较高
  • 不受JVM内存回收管理

永久代为什么要被元空间替换?

  • 随着Java8的到来，HotSpot VM中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间( Metaspace )。
  • 由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空
    间。
  • 这项改动是很有必要的，原因有:

  1. 为永久代设置空间大小是很难确定的。在某些场景下，如果动态加载类过多，容易产生Perm区的OOM。比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误。
    Exception in thread‘ dubbo client x.x connector' java.lang OutOfMemoryError: PermGenspace
    而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。

  2. 对永久代进行调优是很困难的。

  3. 有些人认为方法区(如HotSpot虚 拟机中的元空间或者永久代)是没有垃圾收集行为的，其实不然。《Java 虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在(如JDK 11时期的ZGC收集器就不支持类卸载)。一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。
    方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型。

  4. 判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:

  • 该类所有 的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
  • 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
  • 该类对应的java. 1ang . Class对象没有在任何地方被引用，无法在任何地方通过
    反射访问该类的方法。
  1. Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose: class以及-XX:+TraceClass-Loading、-XX:+TraceClassUnLoading查看类加载和卸载信息在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虛拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

StringTable为什么要调整?

  • jdk7中将StringTable放到了堆空间中。因为永久代的回收效率很低，在full gc的时候才会触发。而full gc是老年代的空间不足、永久代不足时才会触发。这就导致StringTable回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

静态变量补充

对于静态变量不同版本会改变位置，在JDK7后因为静态变量（指的是变量名或引用名）和字符串常量池改变到堆中，也随之存放在了堆中，但是new对象是始终放在堆中的。

String的基本特性

  • 字符串常量池中是不会存储相同内容的字符串的。
  • String的String Pool是一个固定大小的Hashtable，默认值大小长度是1009。如果放进String Pool 的String非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用String. intern时性能会大幅下降
  • 使用-XX:StringTableSize可设置StringTable的长度
  • 在jdk6中StringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快。StringTableSize设置没有要求
  • 在jdk7中，StringTable的长度默认值是60013，StringTableSize设置没有要求
  • Jdk8开始， 设置StrinaTable的长度的话，1009是可设置的最小值

String的内存分配

  • 在Java语言中有8种基本数据类型和一种比较特殊的类型String。这些类型为了使它们在运行过程中速度更快、更节省内存，都提供了一种常量池的概念。
  • 常量池就类似一个Java系统级别提供的缓存。8种基本数据类型的常量池都是系统协调的，String类 型的常量池比较特殊。它的主要使用方法有两种。
  • 直接使用双引号声明出来的String对象会直接存储在常量池中
  • 如果不是用双引号声明的String对象，可以使用String提供的intern()方法。

在这里插入图片描述

字符串常量池的改动

  • Java 6及以前，字符串常量池存放在永久代
  • Java 7中Oracle 的工程师对字符串池的逻辑做了很大的改变，即将字符串常量池的位置调整到Java堆内。
  • 所有的字符串都保存在堆(Heap) 中，和其他普通对象一样，这样可以让你在进行调优应用时仅需要调整堆大小就可以了。
  • 字符串常量池概念原本使用得比较多，但是这个改动使得我们有足够的理由让我们重新考虑在Java 7中使用String.intern()。
  • Java8元空间，字符串常量在堆

字符串拼接操作

  • 常量与常量的拼接结果在常量池，原理是编译期优化
  • 常量池中不会存在相同内容的常量。
  • 只要其中有一一个是变量，结果就在堆中。变量拼接的原理是StringBuilder，拼接完后调用toString()转为String对象
  • 如果拼接的结果调用intern()方法，则主动将常量池中还没有的字符电对象放入池中，并返回此对象地址。
@override
public string tostring() {
// Create a copy, don't share the array
return new string(value, 0，count);
}
S1+S2

如下的s1 + s2的执行细节:
1.stringBuilder s = new StringBuilder();
2.s.append("a")
3.s.append("b")
4.s. tostring()

约等于new String( “ab”)
补充:在jdk5.0之后使用的是stringBuilder, 在jdk5. 0之前使用的是StringBuffer

细节:

  1. stringBuilder的append()的方式:自始至终中只创建过一个stringBuilder的对象使用string的字符串拼接方式:创建过多个StringBuilder和string的对象
  2. 使用string的字符串拼接方式:内存中由于创建了较多的stringBuilder和string的对象，内存占用更大；如果进行改进的空间：在实际开发中，如果基本确定要前前后后添加的字符串长度不高于某个限定值highLevel的情况下,建议使用如下构造初始化长度：
    StringBuilder s = new StringBuilder(highLevel)

String面试题摘录

题目一：new String("ab")会创建几个对象?

  • 答：两个
    一个对象是: new关键字在堆空间创建的
    另一个对象是：字符串常量池中的对象。字节码指令: ldc

题目二：new String("a") + new String ("b")创建了几个对象

new string(“a”) + new String(“b”)呢?
对象1：new stringBuilder()
对象2：new String(“a”)
对象3：常量池中的"a"
对象4：new string(“b”)
对象5：常量池中的"b"
对象6：stringBuilder 的tostring()中的new string(“ab”)

关键：toString()的调用，该方法里边的new String() 不会在字符串常量池中生成“ab” 详情可见字节码指令

题目三：

public class StringIntern1 {
	public static void main(String[] args) {
		string S = new string("1");
		s.intern();
		string s2 = "1";
		System.out.println(s == s2);
		string s3 = new string("1") + new string("1");
		s3.intern();
		string S4 = "11";
		System.out.println(s3 == s4);
	}
}

打印结果：
jdk6 结果： false false
jdk7以及之后结果： false true

这里最具争议的就是那个true，为什么呢，按上面之前分析过程，这里s3指向的是堆里的new String("11")，s4是字符串常量池的呀?
答：
这其实就是jdk1.7之后字符常量池位置的更改原因了，因为转移到了堆区，进行intern()时，JVM发现已经有一个new String("11")的值是一样的了，为了节省空间，就返回了这个引用。而JDK1.6之前的却是放在永久代中，没有上面这种搞法。

拓展

string s3 = new String( original: "1") + new String( original: "1");
执行完上一行代码以后，字符串常量池中，是否存在"11"呢? 答案:不存在! !
string s4 = "11";//在字符串常量池中生成对象"11"
string s5 = s3. intern();
System.out . println(S3 == s4);//false
System.out. println(s5 == s4);//true
想不通的在看看刚刚说的

总结intern

jdk1.6中，将这个字符串对象尝试放入串池

  • 如果串池中有，则并不会放入。返回已有的串池中的对象的地址
  • 如果没有，会把此对象复制一份，放入串池，并返回串池中的对象地址:

Jdk1.7起，将这个字符串对象尝试放入串池

  • 如果串池中有，则并不会放入。返回已有的串池中的对象的地址
  • 如果没有，则会把对象的引用地址复制一份，放入串池，并返回串池中的引用地址

G1的String去重操作

  • UseStringDeduplication(bool)开启String去重，默认是不开启的，需要手动开启
    PrintstringDeduplicationStatistics(bool)打印详细的去重统计信息
    StringDeduplicationAgeThreshold(uintx)达到这个年龄的String对象被认为是去重的候选对象
  • 当垃圾收集器工作的时候，会访问堆上存活的对象。对每一个访问的对象都会检查是否是候选的要去重的String对象。
  • 如果是，把这个对象的一一个引用插入到队列中等待后续的处理。一个去重的线程在后台运行，处理这个队列。处理队列的-一个元素意味着从队列删除这个元素，然后尝试去重它引用的String对象。
  • 使用一个hashtable来记录所有的被string对象使用的不重复的char数组。当去重的时候，会查这个hashtable,来看堆上是否已经存在一个一模一样的char数组。
  • 如果存在，String对象会被调整引用那个数组，释放对原来的数组的引用，最终会被垃圾收集器回收掉。
  • 如果查找失败，char数组会被插入到hashtable，这样以后的时候就可以共享这个数组了。
Eliza白
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
java面试之对象结构（常问到的Mark Word）
free-go的博客
10-09 790
对象头 在同步的时候是获取对象的monitor,即获取到对象的锁。那么对象的锁怎么理解？无非就是类似对对象的一个标志，那么这个标志就是存放在Java对象的对象头。 hotSpot虚拟机的对象头(Object Header)分为两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码(HashCode)、GC分代年龄(Generational GC Age)等，这部分数据的长度在32位和64位的虚拟机中分别为32个和64个Bits，官方称它为Mark Word，它是实现轻量级锁各偏向锁的关键。 另外一部.
JVM 方法区(Method Area)
TheAnnoyingDog的博客
05-01 2713
JVM 方法区 文章目录JVM 方法区方法区的理解栈、堆、方法区的交互关系HotSpot中方法区的演进永久代为什么要使用元空间替换字符串常量池(StringTable)为什么要调整方法区的内部结构类型信息域（Field）信息方法（Method）信息代码举例non-final 类型的类变量全局常量 static final运行时常量池解释常量池和运行时常量池方法区的垃圾回收类卸载常见面试题 方法区的理解 运行时数据区： 方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已
JVM-方法区
m0_49760452的博客
04-19 4132
文章目录栈、堆、方法区的交互关系 栈、堆、方法区的交互关系
【JVM】方法区
ShiJ的博客
05-15 178
方法区 方法区(Method Area)与Java堆一样，是各个线程共享的内存区域，**它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。**虽然《Java虚拟机规范》中把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫作“非堆”(Non-Heap)，目的是与Java堆区分开来。 方法区在实际物理内存和堆一样不连续 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机
jvm-方法区
itman_cx的博客
03-29 356
参考 尚硅谷：宋红康（b站视频） 一、方法区的理解 1.1 方法区的定位 《Java虚拟机规范》：尽管所有方法区在逻辑上属于堆一部分，但一些简单实现，可能不会进行垃圾收集或进行压缩。 对于HotSpot，方法区又名：Non-Heap（非堆），目的：区分堆。 方法区看作是一块独立于Java堆的内存空间 1.2 方法区和堆的区别 不同点 方法区主要存放Class（类元信息），堆中主要存放实例化对象 相同点 方法区/Java堆，各个线程共享内存区域 方法区/Java堆，在JVM启动时被创建，物
java技术面试必问：JVM-内存模型讲解.docx
12-16
JVM内存模型共分为5个区：堆（Heap）、方法区（Method Area）、程序计数器（Program Counter Register）、虚拟机栈（VM Stack）、本地方法栈（Native Method Stack）。其中，堆（Heap）、方法区（Method Area）为...
深入JVM内核 - 原理、诊断与优化
02-04
堆、栈、方法区等 JVM启动流程 内存模型和volatile实例 解释和编译运行的概念 介绍JVM的内部结构、启动流程以及内存模型。并介绍JVM字节码的执行方式。 第三课 常用JVM参数 堆的分配参数 栈分配及实例讲解 server...
JVM内存空间分配笔记
10-24
JVM（Java虚拟机）内存模型主要由以下几个部分组成：程序计数器、Java虚拟机栈、本地方法栈、Java堆以及方法区（在JDK 8之后称为元空间）。下面将对这几个部分进行详细介绍。 #### 二、程序计数器 程序计数器是一...
JavaGuide-main.rar
最新发布
08-28
理解Java虚拟机（JVM）的工作原理，包括类加载机制、内存区域（堆、栈、方法区等）、垃圾回收（GC）以及性能调优，对于解决内存泄漏和性能问题非常重要。 七、反射与动态代理 Java反射机制允许在运行时检查类、接口...
JavaNote-main
07-27
以上只是JavaNote-main可能涉及的部分内容，实际压缩包可能还包含更多如设计模式、数据库连接、JVM优化、反射、注解等进阶主题。学习Java时，理解并实践这些知识点将有助于成为一名熟练的Java开发者。
5.JVM方法区
郑学炜的技术博客
04-14 2825
JAVA虚拟机方法区介绍1、JVM内存模型    大多数JVM将内存分配为Method Area(方法区)、Heap(堆)、ProgramCounter Register(程序计数器)、JAVA MethodStack(JAVA方法栈)、Native MethodStack(本地方法栈)。1.1 Method Area    线程共享，存储已经被虚拟机加载的类信息、常量、静态变量、即时编译器编译后...
jvm中方法的存放位置
Jay112011的博客
08-20 2777
其实java方法是存在方法区的 方法区：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，方法编译出的字节码也是保存在这个区域。 栈区（虚拟机栈）：主要是存储局部变量表（当然也还有其他信息）。 说到这可能有人疑惑，平时在运行一个方法时总说在栈区中开辟一块内存，这是怎么回事呢。 其实栈区中的数据，也就是栈帧，他描述的是方法的一次执行瞬间。 栈帧里面放的就是一些方法中的局部变量和方法的形参。并且这些局部变量/形参的生命周期是比较短暂的，在本方法调用的时候拥有生命，调用结束后
细说方法区
weixin_30919235的博客
09-21 190
引文JDK7及之前版本的方法区（Method Area）和Java堆一样，是各个线程共享的内存区域，用于存储已经被虚拟机加载的类信息、常量、静态常量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但它有另外一个名字叫Non-Heap（非堆）。根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。细分...
JAVA中的方法存储在JVM的哪个区
wqq3670的博客
04-09 9935
聊到JAVA中的方法，大多数人对于方法存储在方法区还是栈区（虚拟机栈）是很迷茫的。 其实方法是存在方法区的 下面我们就细细说一下JVM中的 方法区 VS 栈区 方法区：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，方法编译出的字节码也是保存在这个区域。 栈区（虚拟机栈）：主要是存储局部变量表（当然也还有其他信息）。 说到这可能有人疑惑，平时在运行一个方法时总说在栈区...
JVM 方法区
qq_46153765的博客
12-03 978
一、栈、堆、方法区的交互关系 二、方法区的理解 一、方法区在哪里？ 《Java虚拟机规范》中明确说明：”尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾回收或者进行压缩。“但对于 HotSpot JVM 而言，方法区还有一个别名叫做 Non-Heap（非堆），目的就是要和堆分开。 所以，方法区看做是一块独立于 Java 堆的内存空间。 二、方法区的基本理解 方法区（Method Area）与 Java 堆一样，是各个线程共享的内存区域。 方法区在 JVM 启动的时候被
jvm 方法区
七月听雪的博客
02-17 133
串池： 以代码举例：
方法区
weixin_34345560的博客
12-23 58
方法区 类加载的时候,方法和全局变量以及final和static修饰的内容全部在方法区里面 转载于:https://www.cnblogs.com/nangongyibin/p/10164306.html
JVM——方法区
qq_52025570的博客
03-06 154
JVM——方法区
JVM调优深度解析：从基础到实践
文章的后续部分，如（一）和（二），可能涵盖了JVM的基本组件、内存模型以及相关的术语，例如堆内存、栈内存、方法区等，这些都是进行JVM调优前需要理解的基础。 3. 垃圾回收算法 在（三）至（五）中，作者详细讨论...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值