书接上回说一说 JVM 中的方法区和直接内存

方法区：

在《Java虚拟机规范》中明确说明：尽管所有的方法区在逻辑上是堆内存的一部分，但一些简单的实现可能不会选择对方法区进行垃圾回收或者进行压缩。但对于 HotSpot 虚拟机来说，方法区还有一个名字叫 Non-Heap（非堆） 目的就是要和方法区分开。
所以，这样来看，方法区是一块独立于 Java 堆的内存空间

怎么看方法区？

• 方法区和堆一样，是各个线程共享的内存区域
• 方法区在 JVM 启动时就被创建，并且和堆一样，方法区的物理内存也可以是不连续的
• 方法区的大小可以和堆一样，选择固定大小或者是可扩展的
• 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，JVM 同样会抛出 java.lang.OutOfMemoryError: PermGen space 或者 java.lang.OutOfMemoryError: Metaspace
• 关闭 JVM 就会释放这个区域的内存

那么方法区都存些什么呢？？？

1. 类型信息：
   对于每个加载的类型（class、interface、enum、annotation），JVM 必须在方法区中存储以下类型信息：
   • 这个类型的完整有效名称（全名=包名.类名）
   • 这个类型直接父类的完整有效名（对于 interface 或是 java.lang.object 都没有父类）
   • 这个类的类型修饰符（public、abstract、final的某个子集）
   • 这个类型一个直接接口的一个有序列表
     
     
2. 域（Field）信息：
   • JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
   • 域的相关信息包括： 域名称、域类型、域修饰符(public, private, protected, static, final, volatile, transient的某个子集)
     
     

3.方法信息：
JVM必须保存所有方法的一下信息，同域信息一样包括声明顺序：

• 方法名称
• 方法的返回类型
• 方法参数的数量和类型（按照顺序）
• 方法的修饰符
• 方法的字节码、操作数栈、局部变量表及大小
• 异常表：每个异常处理的位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
  
  

4. non-final 的类变量

• 静态变量和类关联在一起，随着类的加载而加载,它们成为类数据在逻辑上的一部分
• 类变量被类的所有实例共享，即使没有类实例时你也可以访问它
  
  

5. 运行时常量池

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

方法区是否存在垃圾回收？为什么？

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

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型

• 先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用。字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量
  • 1、类和接口的全限定名
  • 2、字段的名称和描述符
  • 3、方法的名称和描述符
• HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。
• 回收废弃常量与回收Java堆中的对象非常类似
• 判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：
  • 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
  • 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
  • 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
• Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClassLoading -XX:+TraceClassUnloading查看类加载和卸载信息
• 在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

直接内存

概述

• 不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。
• 直接内存是在Java堆外的、直接向系统申请的内存区间。
• 来源于NIO，通过存在堆中的DirectByteBuffer操作Native内存
• 通常，访问直接内存的速度会优于Java堆。即读写性能高。
  • 因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存。
  • Java的NIO库允许Java程序使用直接内存，用于数据缓冲区

大小设置方式

• 也可能导致OutOfMemoryError异常
• 由于直接内存在Java堆外，因此它的大小不会直接受限于-Xmx指定的最大堆大小，但是系统内存是有限的，Java堆和直接内存的总和依然受限于操作系统能给出的最大内存。
• 缺点
  • 分配回收成本较高
  • 不受JVM内存回收管理
• 直接内存大小可以通过MaxDirectMemorySize设置
• 如果不指定，默认与堆的最大值-Xmx参数值一致

这期内容就是这样啦，没写详尽的地方大家就自己回去努努力吧！！！