JVM学习笔记(二)运行时数据区
上篇文章:JVM学习笔记(一)JVM体系结构
运行时数据区
本地方法栈
本地方法接口
简单地讲，一个Native Method就是一个Java调用非Java代码的接口。一个Native Method是这样一个Java方法:该方法的实现由非Java语言实现，比如c。这个特征并非Java所特有，很多其它的编程语言都有这一机制，比如在C++中，你可以用extern "C"告知C++编译器去调用一个c的函数。
"A native method is a Java method whose implementation isprovided by non-java code . "
在定义一个native method时，并不提供实现体（有些像定义一个Javainterface) ，因为其实现体是由非java语言在外面实现的。
本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序。
// 使用native 关键字标识的方法 就叫做本地方法 方法的具体实现是非Java语言实现的
public final native Class<?> getClass();
本地方法栈
Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。
木地方法栈,也是线程私有的。
允许被实现成固定或者是可动态扩展的内存大小。(在内存溢出方面是相同的)
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个 stackoverflowError异常。
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法中请到足够的内存，
或者在创建新的线程时没有足够的内存去创建对应的本地方法梭，那么Java虚拟机将会抛出一个outofMemoryError异常。
本地方法是使用c语言实现的。
它的具体做法是Native Method stack中登记native方法，在Execution Engine执行时加载本地方法库。
当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。
- 本地方法可以通过本地方法接口来访问虚报机内部的运行时数据区。
- 它甚至可以直接使用本地处理器中的寄存器
- 直接从本地内存的堆中分配任意数量的内存。
并不是所有的JVM都支持本地方法。因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法,也可以无需实现本地方法栈。
在Hotspot VM中，直接将本地方法栈和虚拟机栈合二为一。
堆
一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。
Java堆区在JM启动的时候即被创建，其空间大小也就确定了。是JVM管理的最大一块内存空间。
- 堆内存的大小是可以调节的。
《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区( ThreadLocal Allocation Buffer,TLAB)。
《Java虚拟机规范》中对Java堆的描述是:所有的对象实例以及数组都应当在运行时分配在堆上。(The heap is the run-time data area fromwhich memory for all class instances and arrays is allocated )
- 我要说的是:“几乎”所有的对象实例都在这里分配内存。—从实际使用角度看的。
数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。
在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除。
堆，是GC ( Garbage collection，垃圾收集器）执行垃圾回收的重点区域。
内存细分
现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为:
-
Java 7及之前堆内存逻辑上分为三部分:新生区+养老区+永久区
-
Java 8及之后堆内存逻辑上分为三部分:新生区+养老区+元空间
设置堆空间大小
Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项”一Xmx和一Xms来进行设置。
-Xms用于表示堆区的起始内存，等价于-XX:InitialHeapsize-Xmx则用于表示堆区的最大内存，等价于-XX: MaxHeppsize
一旦堆区中的内存大小超过“-Xmx所指定的最大内存时，将会抛出outOfMemoryError异常。
通常会将-xms和—Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。
默认情况下，初始内存大小:物理电脑内存大小/64
最大内存大小:物理电脑内存大小/4
/**
*
* 手动设置: -Xms600m -Xmx600m
* 开发者建议将初识堆内存大小 和 最大堆内存大小设置成相同的值
*
* 查看设置参数 方式一: jps / jstat -gc 进程Id
* 方式二: -XX:+PrintGCDetails
* @author tuxuchen
* @date 2021/12/10 14:33
*/
public class HeapTest {
public static void main(String[] args) {
// 返回Java虚拟机中堆内存总量
long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
// 返回Java虚拟机中试图使用的最大堆内存量
long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
System.out.println(String.format("-Xms:%sM", initialMemory));
System.out.println(String.format("-Xmx:%sM", maxMemory));
System.out.println(String.format("系统内存大小为:%sG", initialMemory*64.0/1024));
System.out.println(String.format("系统内存大小为:%sG", maxMemory*4.0/1024));
}
}
年轻代和老年代
存储在JVM中的Java对象可以被划分为两类:
- 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期
保持一致。
Java堆区进一步细分的话，可以划分为年轻代(YoungGen）和老年代(oldGen)
其中年轻代又可以划分为Eden空间、Survivor0空间和survivor1空间(有时也叫做from区、 to区).
配置年轻代和老年代
配置新生代与老年代在堆结构的占比。
- 默认
-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3 - 可以修改
-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5
在Hotspot中，(伊甸园)Eden空间和另外两个survivor空间缺省所占的比例是8:1:1
当然开发人员可以通过选项“-XX:SurvivorRatio”调整这个空间比例。比如-XX :SurvivorRatio=8
几乎所有的Java对象都是在Edenl区被new出来的。绝大部分的Java对象的销毁都在新生代进行了。
- IBM公司的专门研究表明，新生代中80%的对象都是“朝生夕死”的。
可以使用选项”-xmn"设置新生代最大内存大小
- 这个参数一般使用默认值就可以了。
对象分配过程
- new的对象先放伊甸园区。此区有大小限制。
- 当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区
- 然后将伊甸园中的剩余对象移动到幸存者S0区或S1区
4. 如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会
放到幸存者1区。
5. 如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
6. 啥时候能去养老区呢?可以设置次数。默认是15次。
- 可以设置参数:
-XX: MaxTenuringThreshold=进行设置。
7. 在养老区，相对悠闲。当养老区内存不足时，再次触发GC: Major GC，进行养老区的内存清理。
8. 若养老区执行了Major GC之后发现依然无法进行对象的保存，就会产生OOM异常
注意点:
- 伊甸园区满时 会触发YGC 进行垃圾回收,如果幸存者区满了不会触发YGC
- 针对幸存者S0,S1区的总结:复制之后有交换，谁空谁是to.
- 关于垃圾回收:频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集。
堆空间分代思想
为什么需要把Java堆分代?不分代就不能正常工作了吗?
其实不分代完全可以，分代的唯一理由就是优化GC性能。如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用这样就会对堆的所有区域进行扫描。而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
内存分配策略
如果对象在Eden出生并经过第一次MinorGC后仍然存活，并且能被survivor容纳的话，将被移动到survivor 空间中，并将对象年龄设为1 。对象在survivor区中每熬过一次Minorcc ，年龄就增加1 岁，当它的年龄增加到一定程度（默认为15 岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代中。
对象晋升老年代的年龄阈值，可以通过选项–XX:MaxTenuringThreshold来设置。
针对不同年龄段的对象分配原则如下所示:
1.优先分配到Eden
2.大对象直接分配到老年代
- 尽量避免程序中出现过多的大对象
3.长期存活的对象分配到老年代
4.动态对象年龄判断
- 如果survivor 区中相同年龄的所有对象大小的总和大于Survivor空
间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold 中要求的年龄。
5.空间分配担保-XX:HandlePromotionFailure
什么是空间分配担保
在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间
如果大于，则此次Minor GC是安全的
如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。
只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。
对象分配过程:TLAB
为什么有TLAB ( Thread Local Allocation Buffer ) ?
- 堆区是线程共享区域，任何线程都可以访问到堆区中的共亨数据
- 由于对象实例的创建在.JVM中非常频繁，囚此在并发环境下从堆区中划分内存空间是线程不安全的!
- 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配:速度。
什么是TLAB？
从内存模型而不是拉圾收集的角度。对Edcn区域继续进行划分，JVM为每个线程分配了一个私有缓存区域, 它包含在Eden空间内。
多线程同时分配内存时，使用TLAL可以避刻一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略。
据我所知所有OpenJDK衍生出来的.JVM都提供了TLAB的设计。
尽管不是所有的对象实例都能够在TLAB中成功分配内存，但JVM确实是将TLAB作为内存分配的首选。
在程序中，开发人员可以通过选项“-XX:UseTLAB”设置是否TLAB空间。
默认情况下，TLAB空间的内存非常小、仅占有整个Edon空间的1%， 当然我们可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占用Eden区的百分比大小。
一旦对象在TLAB空间分配内存失败是，JVM旧会尝试着通过使用加锁机制确保数据操作的原子性,从而直接在Eden空间中分配内存。
堆是分配对象存储的唯一选择吗?
在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述:
随着JIT编译期的发展与 ==逃逸分析技术 ==逐渐成熟，栈上分配、标量替换优化技术 将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是 如果经过逃逸分析(Escape Analysis)后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。
此外，前面提到的基于openJDK深度定制的TaoBaoVM，其中创新的GCIH (Gcinvisible heap)技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。
逃逸分析
- 如何将堆上的对象分配到栈。需要使用逃逸分析手段。
- 这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。
- 通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。
逃逸分析的基本行为就是分析对象动态作用域:
- 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
- 当一个对象在方法中被定义后,它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。
// 对象只在方法内部使用，则认为没有发生逃逸。
public void method(){
ClassLoaderTest classLoaderTest = new ClassLoaderTest();
....
classLoaderTest = null;
}
// 只要new的对象在方法外被使用 则发生了逃逸
参数设置:
在JDK 7版本之后,HotSpot中默认就已经开启了逃逸分析。
如果使用的是较早的版本，开发人员则可以通过:
- 选项“
-XX:+DoEscapeAnalysis"显式开启逃逸分析 - 通过选项“
-XX:+PrintEscapeAnalysis"查看逃逸分析的筛选结果。
使用逃逸分析，编译器可以对代码做优化：
栈上分配： 将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配
同步省略： 如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步
分离对象或标量替换： 有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而存储在 CPU 寄存器
同步省略(锁消除)
public void keep() {
Object keeper = new Object();
synchronized(keeper) {
System.out.println(keeper);
}
}
如上代码，代码中对 keeper 这个对象进行加锁，但是 keeper 对象的生命周期只在 keep()方法中，并不会被其他线程所访问到，所以在 JIT编译阶段就会被优化掉。优化成：
public void keep() {
Object keeper = new Object();
System.out.println(keeper);
}
分离对象或标量替换
public static void main(String[] args) {
alloc();
}
private static void alloc() {
Point point = new Point（1,2）;
System.out.println("point.x="+point.x+"; point.y="+point.y);
}
class Point{
private int x;
private int y;
}
以上代码中，point 对象并没有逃逸出 alloc() 方法，并且 point 对象是可以拆解成标量的。那么，JIT 就不会直接创建 Point 对象，而是直接使用两个标量 int x ，int y 来替代 Point 对象。
private static void alloc() {
int x = 1;
int y = 2;
System.out.println("point.x="+x+"; point.y="+y);
}
常用设置参数整理
| 命令 | 解释 |
|---|---|
| -XX:+PrintFlagsInitial | 查看所有的参数的默认初始值 |
| -XX:+PrintFlagsFinal | 查看所有的参数的最终值(可能会存在修改,不再是初始值) |
| -Xms | 初始堆空间内存(默认为物理内存的1/64) |
| -Xmx | 最大堆空间内存（默认为物理内存的1 /4) |
| -Xmn | 设置新生代的大小。（初始值及最大值) |
| -XX:NewRatio | 配置新生代与老年代在堆结构的占比 |
| -XX:SurvivorRatio | 设置新生代中Eden.和S0/s1空间的比例 |
| -XX:MaxTenuringThreshold | 设置新生代垃圾的最大年龄 |
| -XX:+PrintGCDetails | 输出详细的GC处理日志 |
| -XX:+PrintGC-XX | 打印GC简要信息 |
| -XX:HandlePromotionFailure | 是否设置空间分配担保 |
方法区
《Java虚拟机规范》中明确说明:"尽管所有的方法区在 逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。”但对于HotSpot JVM而言，方法区还有一个别名叫做Non-Heap (非堆)，目的就是要和堆分开。所以,方法区看作是一块独立于Java堆的内存空间。
- 方法区（Method Area）与 Java 堆一样，是所有线程共享的内存区域。
- 方法区的大小和堆空间一样，可以选择固定大小也可选择可扩展，方法区的大小决定了系统可以放多少个类，如果系统类太多，导致方法区溢出，虚拟机同样会抛出内存溢出错误
- JVM 关闭后方法区即被释放
栈,堆,方法区的交互关系
方法区的演进
在jdk7及以前，习惯上把方法区。称为永久代。jdk8开始，使用元空间取代了永久代。
本质上，方法区和永久代并不等价。仅是对hotspot而言的。《Java虚拟机规范》对如何实现方法区，不做统一要求。例如:BEA JRockit/IBM J9中不存在永久代的概念。
现在来看，当年使用永久代，不是好的主意。导致Java程序更容易OOM(超过-XX:MaxPermSize上限)
元空间的本质和永久代类似。都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于:元空间不在虚拟机设置的内存中，而是使用本地内存。
永久代、元空间二者并不只是名字变了,内部结构也调整了。
根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常。
演进细节
只有 HotSpot 才有永久代的概念
| jdk1.6及之前 | 有永久代，静态变量存放在永久代上 |
|---|---|
| jdk1.7 | 有永久代，但已经逐步“去永久代”，字符串常量池、静态变量移除，保存在堆中 |
| Jdk1.8及之后 | 取消永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆中 |
移除永久代原因
- 为永久代设置空间大小是很难确定的。
- 在某些场景下，如果动态加载类过多，容易产生 Perm 区的 OOM。如果某个实际 Web 工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现 OOM。而元空间和永久代最大的区别在于，元空间不在虚拟机中，而是使用本地内存，所以默认情况下，元空间的大小仅受本地内存限制
- 对永久代进行调优较困难
StringTable(字符串常量池)为什么要放在堆空间中
jdk7中将stringTable放到了堆空间中。因为永久代的回收效率很低，在full gc的时候才会触发。而full gc是老年代的空间不足、永久代不足时才会触发。
这就导致stringTable回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低,导致永久代内存不足。放到堆里，能及时回收内存。
设置方法区内存的大小
JDK8 及以后：
- 元数据区大小可以使用参数
-XX:MetaspaceSize和-XX:MaxMetaspaceSize指定，替代上述原有的两个参数 - 默认值依赖于平台。Windows 下，
-XX:MetaspaceSize是 21M，-XX:MaxMetaspacaSize的值是 -1，即没有限制 - 与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。如果元数据发生溢出，虚拟机一样会抛出异常 OutOfMemoryError:Metaspace
-XX:MetaspaceSize：设置初始的元空间大小。对于一个 64 位的服务器端 JVM 来说，其默认的-XX:MetaspaceSize的值为20.75MB，这就是初始的高水位线，一旦触及这个水位线，Full GC 将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置，新的高水位线的值取决于 GC 后释放了多少元空间。如果释放的空间不足，那么在不超过 MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值- 如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次，通过垃圾回收的日志可观察到 Full GC 多次调用。为了避免频繁 GC，建议将
-XX:MetaspaceSize设置为一个相对较高的值。
方法区内部结构
方法区用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。
类型信息
对每个加载的类型（类 class、接口 interface、枚举 enum、注解 annotation），JVM 必须在方法区中存储以下类型信息:
- 这个类型的完整有效名称（全名=包名.类名）
- 这个类型直接父类的完整有效名（对于 interface或是 java.lang.Object，都没有父类）
- 这个类型的修饰符（public，abstract，final 的某个子集）
- 这个类型直接接口的一个有序列表
域（Field）信息
- JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
- 域的相关信息包括：域名称、域类型、域修饰符（public、private、protected、static、final、volatile、transient 的某个子集）
方法（Method）信息
JVM 必须保存所有方法的
- 方法名称
- 方法的返回类型
- 方法参数的数量和类型 方法的修饰符（public，private，protected，static，final，synchronized，native，abstract 的一个子集）
- 方法的字符码（bytecodes）、操作数栈、局部变量表及大小（abstract 和 native 方法除外）
- 异常表（abstract 和 native 方法除外）
每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分，理解运行时常量池的话，我们先来说说字节码文件（Class 文件）中的常量（常量池表）
常量池
一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表（Constant Pool Table），包含各种字面量和对类型、域和方法的符号引用。
public class com.tuxc.FiledLoaderTest
minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
Constant pool: // 常量池
#1 = Methodref #4.#20 // java/lang/Object."":()V
#2 = Fieldref #3.#21 // com/tuxc/FiledLoaderTest.a:I
#3 = Class #22 // com/tuxc/FiledLoaderTest
#4 = Class #23 // java/lang/Object
#5 = Utf8 a
常量池可以看作是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型
运行时常量池
- 常量池表（Constant Pool Table）是 Class 文件的一部分，用于存储编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中
- 在加载类和结构到虚拟机后，就会创建对应的运行时常量池
- 运行时常量池中包含各种不同的常量，包括编译器就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或字段引用。此时不再是常量池中的符号地址了，这里换为真实地址
- 运行时常量池，相对于 Class 文件常量池的另一个重要特征是：动态性，Java 语言并不要求常量一定只有编译期间才能产生，运行期间也可以将新的常量放入池中，String 类的
intern()方法就是这样的 - 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则 JVM 会抛出 OutOfMemoryError 异常。
方法区的垃圾回收
一般来说这个区域的 回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。
方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型。
常量回收
先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用。字面量比较接近 Java 语言层次的常量概念，如文本字符串、被声明为 final 的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量：
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符
HotSpot 虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收
类回收
类型的卸载，条件相当苛刻
判定一个类型是否属于“不再被使用的类”，需要同时满足三个条件：
- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类及其任何派生子类的实例
- 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如 OSGi、JSP 的重加载等，否则通常很难达成
- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
JVM虚拟机被允许堆满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，不使用了就必然会回收。
是否对类进行回收，HotSpot 虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbose:class 以及 -XX:+TraceClassLoading 、-XX:+TraceClassUnLoading 查看类加载和卸载信息。
在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
GC垃圾回收初识
使用-XX:+PrintGCDeatils显示垃圾回收信息
Minor GC 、Major GC、Full GC
JVM在进行GC时，并非每次都对上面三个内存(新生代、老年代:方法区)区域一起回收的。
大部分时候回收的都是指新生代。
针对HotSpot VM的实现。它里面的GC按照回收区域又分为两大种类型:
- 一种是部分收集(Partial GC)
- 一种是整堆收集(Full GC)
部分收集: 不是完整收集整个Java堆的垃圾收集。其中又分为:
- 新生代收集(Minor GC / Young GC):只是新生代的垃圾收集
- 老年代收集(Major GC / old GC):只是老年代的垃圾收集。
目前,只有CMS GC会有单独收集老年代的行为。
注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
混合收集Mixed GC: 收集整个新生代以及部分老年代的垃圾收集。
- 目前,只有G1 GC会有这种行为
整堆收集Full GC: 收集整个java堆和方法区的垃圾收集。
年轻代Minor GC触发机制
- 当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC。（每次Minor GC会清理年轻代的内存。)
- 因为Java 对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁,一般回收速度也比较快。这一定义既清晰又易于理解。
- Minor GC会引发STM，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。
老年代Major GC/Full GC触发机制
- 指发生在老年代的GC，对象从老年代消失时，我们说“Major GC”或“Full GC”发生了。
- 出现了Major GC，经常会伴随至少一次的Minor GC(但非绝对的,在Paralle1Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)。
- 也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
- Major GC的速度一般会比Minor GC慢10倍以上.STW的时间更长。
- Major GC的速度一般会比Minor GC慢10倍以上。
- 如果Major GC后。内存还不足。就报OOM了.