多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
## **jvm怎么判断哪些对象(已经死亡)应该回收呢?** 在Java中,判断一个对象是否“死亡”通常是指判断对象是否可以被垃圾回收。JVM提供了几种机制来进行此类判断。 ### 1\. 引用计数法 **定义**:每个对象都有一个引用计数器,当有一个地方引用它时,计数器加1,当引用失效时,计数器减1。任何时刻引用计数器为0的对象就是不再被引用的,可以被认为是“死亡”。 **缺点**:无法解决循环引用的问题,即两个对象互相引用但没有其他地方引用它们时,引用计数器不会归零,无法被回收。 ### 2\. 可达性分析法(Reachability Analysis) 这是JVM判断对象是否可以被回收的主流算法,通过一系列称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链。如果一个对象到GC Roots没有任何引用链相连,则该对象是不可达的,可以被垃圾回收。 ## **哪些对象可以作为根对象(GC Roots)** 可以作为GC Roots的对象类别: 1. **虚拟机栈(栈帧中的本地变量表)中引用的对象**: * 任何在当前线程栈中活跃的局部变量和输入参数(这些变量存储在栈帧的本地变量表中)都可以作为GC Roots。 ~~~ java复制代码public void method() { Object obj = new Object(); // obj是GC Root } ~~~ 2. **方法区中的类静态属性引用的对象**: * 类静态属性(static修饰的变量)是全局引用,它们存储在方法区中,这些属性引用的对象也可以作为GC Roots。 ~~~ java复制代码public class MyClass { private static Object obj = new Object(); // obj是GC Root } ~~~ 3. **方法区中的常量引用的对象**: * 方法区中的常量引用,如字符串常量池中的字符串(String Pool)也可以作为GC Roots。 ~~~ java复制代码public class MyClass { private static final String CONSTANT = "constant"; // CONSTANT是GC Root } ~~~ 4. **本地方法栈中JNI(即一般说的Native方法)引用的对象**: * 本地方法接口(Java Native Interface,JNI)中持有的引用对象(通过native方法调用C/C++代码中持有的Java对象引用)也可以作为GC Roots。 ~~~ c复制代码// C/C++代码中使用的Java对象引用 jobject obj = (*env)->NewObject(env, cls, methodID); ~~~ 5. **活动线程(Active Threads)**: * 所有活动的线程(正在运行或等待的线程)本身及其持有的对象引用也可以作为GC Roots。 ~~~ java复制代码Thread t = new Thread(new Runnable() { public void run() { // 线程中的对象引用 } }); t.start(); // t是GC Root ~~~ 6. **系统类加载器(System Class Loader)**: * 系统类加载器及其加载的类也是GC Roots。 7. **常驻JVM的JNI全局引用**: * 通过JNI调用的全局引用(Global References)在JVM生命周期内一直存在,也是GC Roots。 8. **Java虚拟机内部的关键数据结构**: * 比如反映Java调用栈的相关数据结构等。 ## **CMS和G1都是有一个并发标记的过程,并发标记要解决什么问题?带来了什么问题?怎么解决这些问题呢?** CMS(Concurrent Mark-Sweep)和G1(Garbage-First)垃圾收集器在Java中都有一个并发标记过程。并发标记的主要目标是标记出所有存活的对象,以便在随后的垃圾收集过程中进行回收。并发标记在运行时与应用程序线程同时执行,旨在减少垃圾收集对应用程序响应时间的影响。然而,并发标记也带来了一些问题,需要通过特定的技术手段来解决。 ### 并发标记的目标和问题 #### 目标 * **减少停顿时间**:通过与应用程序线程并发运行,尽量减少垃圾收集对应用程序的停顿时间。 * **提高应用响应性**:避免长时间的暂停,提高应用程序的响应性。 #### 主要问题 1. **浮动垃圾(Floating Garbage)**: * **问题**:由于并发标记与应用程序线程同时运行,在标记过程中可能会有对象变为不可达,但这些对象在本次标记周期内不会被标记为垃圾,从而无法回收。 * **影响**:这部分垃圾只能等到下一次GC周期才能被回收,导致当前回收效率降低。 2. **标记准确性**: * **问题**:在并发标记过程中,应用程序线程可能会修改对象引用,使得标记结果不准确(标记漏掉存活对象或错误标记垃圾对象)。 * **影响**:需要保证标记过程能够正确反映对象的可达性,避免误回收或漏回收。 ### 解决方法 #### CMS(Concurrent Mark-Sweep)解决方法 1. **Initial Marking(初始标记)**: * **工作**:暂停所有应用程序线程,标记从根节点(GC Roots)直接可达的对象。 * **停顿时间**:短暂停顿,因为仅标记根对象。 2. **Concurrent Marking(并发标记)**: * **工作**:与应用程序线程并发运行,从初始标记的根对象开始标记所有可达对象。 * **停顿时间**:无,完全并发。 3. **Remarking(重新标记)**: * **工作**:再次暂停应用程序线程,标记在并发标记阶段发生变化的对象引用,确保标记准确性。 * **停顿时间**:相对较长,但比完全停顿的标记时间短。 4. **Concurrent Sweeping(并发清理)**: * **工作**:与应用程序线程并发运行,清理未标记的对象。 * **停顿时间**:无,完全并发。 #### G1(Garbage-First)解决方法 1. **Initial Marking(初始标记)**: * **工作**:暂停应用程序线程,标记从根节点(GC Roots)直接可达的对象,同时标记已知的存活对象。 * **停顿时间**:短暂停顿,因为仅标记根对象。 2. **Concurrent Marking(并发标记)**: * **工作**:与应用程序线程并发运行,从初始标记的根对象开始标记所有可达对象。 * **停顿时间**:无,完全并发。 3. **Final Marking(最终标记)**: * **工作**:暂停应用程序线程,处理在并发标记阶段发生变化的对象引用,确保标记准确性。 * **停顿时间**:短暂停顿,类似CMS的重新标记。 4. **Live Data Counting and Evacuation(存活数据计数和搬迁)**: * **工作**:与应用程序线程并发运行,统计存活对象,并在收集阶段将存活对象搬迁到新的内存区域,释放旧的内存区域。 * **停顿时间**:视具体实现而定。 ### 具体问题解决方法 1. **浮动垃圾的处理**: * **CMS**:浮动垃圾不会在当前GC周期内被回收,只能等待下一次GC。因此,CMS通常需要更多的内存来应对浮动垃圾。 * **G1**:G1通过分区(Region)和回收(Evacuation)的方式,较好地处理浮动垃圾,尽量减少未回收的垃圾数量。 2. **标记准确性的保证**: * **CMS**:通过重新标记阶段确保在并发标记过程中发生变化的引用得到正确处理。 * **G1**:通过最终标记阶段和SATB(Snapshot-At-The-Beginning)算法,确保并发标记的准确性。SATB在并发标记开始时对引用关系进行快照,确保标记过程中的引用变化能够被正确处理。 ### 总结 * **并发标记的目标**:减少GC停顿时间,提高应用程序的响应性。 * **主要问题**:浮动垃圾和标记准确性。 * **解决方法**: * CMS通过初始标记、并发标记、重新标记和并发清理来处理。 * G1通过初始标记、并发标记、最终标记和搬迁来处理,同时使用SATB算法保证标记准确性。