1.如何判断一个对象是否可以回收/死亡对象判断方法 （1）引用计数算法： 给对象添加一个引用计数器，当对象增加一个引用时计数器加1，引用失效时计数器减 1。引用计数为0的对象可被回收。 两个对象出现循环引用的情况下，此时引用计数器永远不为 0，导致无法对它们进行回收。正因为循环引用的存在，因此 Java 虚拟机不使用引用计数算法。 （2）可达性分析算法： 通过 GC Roots 作为起始点进行搜索，能够到达到的对象都是存活的，不可达的对象可被回收。
Java虚拟机中使用可达性分析算法判断对象是否可被回收：
GC Roots一般包括： 虚拟机栈中引用的对象 本地方法栈中引用的对象 方法区中类静态属性引用的对象 方法区中的常量引用的对象 2.对象有哪些引用类型 Java具有四种强度不同的引用类型： 强引用：被强引用关联的对象不会被回收。 (使用new一个新对象的方式来创建强引用) 软引用：被软引用关联的对象只有在内存不够的情况下才会被回收。 (使用SoftReference类创建软引用)Object obj = new Object(); SoftReference<Object> sf = new SoftReference<Object>(obj); obj = null; // 使对象只被软引用关联弱引用：被弱引用关联的对象一定会被回收。（下一次GC必死） (使用WeakReference类实现弱引用) 虚引用：又称幽灵引用或幻影引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象。 (使用PhantomReference实现虚引用) 为一个对象设置虚引用关联的唯一目的就是能在这个对象被回收时收到一个系统通知。 3.垃圾回收算法 (1)标记-清除：将存活的对象进行标记，然后清理掉未被标记的对象。 不足：标记和清除过程效率都不高。 会产生大量不连续的内存碎片，导致无法给大对象分配内存。 (2)标记-整理：让所有存活的对象都向一段移动，然后直接清理掉端边界以外的内存。 (3)复制：将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。 不足：只使用了内存的一半。
4.什么是Minor GC,Major GC,Full GC （minor少数的） 针对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 堆和方法区的垃圾 （6）JVM内存分配策略 对象优先在Eden分配 Eden空间不够时，发起Minor GC 大对象直接进入老年代 大对象是指需要连续内存空间的对象 -XX:PretenureSizeThreshold，大于此值的对象直接在老年代分配，避免在Eden区和 Survivor区之间的大量内存复制。 长期存活的对象进入老年代 为对象定义年龄计数器，每经过Minor GC依然存活并移动到Survivor中，年龄+1 -XX:MaxTenuringThreshold 用来定义年龄的阈值（通常是15）。 动态对象年龄判定 虚拟机并不是永远地要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在Survivor中相同年龄所有对象大小的总和大于Survivor空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄。 空间分配担保 在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC可以确认是安全的。 如果不成立的话虚拟机会查看 HandlePromotionFailure 设置值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC；如果小于，或者 HandlePromotionFailure 设置不允许冒险，那么就要进行一次 Full GC。 Eden满，触发Minor GC （7）什么情况下会触发Full GC 调用System.gc()：只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。 老年代空间不足：老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等。 为了避免以上原因引起的 Full GC： 1.不要创建过大的对象以及数组。 2.可以通过 -Xmn 虚拟机参数调大新生代的大小，让对象尽量在新生代被回收掉。 3.可以通过-XX:MaxTenuringThreshold 调大对象进入老年代的年龄。 空间分配担保失败：使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果担保失败会执行一次 Full GC。 JDK 1.7及以前的永久代空间不足：当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC仍然回收不了，那么虚拟机会抛出java.lang.OutOfMemoryError。 为避免以上原因引起的 Full GC，可采用的方法为增大永久代空间或转为使用 CMS GC。 Concurrent Mode Failure：执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足(可能是 GC 过程中浮动垃圾过多导致暂时性的空间不足)，便会报 Concurrent Mode Failure 错误，并触发 Full GC。 （8）Hotspot虚拟机中有哪些垃圾回收器 HotSpot是一款高性能的Java虚拟机，可以大大提高Java运行性能。Java原先是把源代码编译为字节码在虚拟机执行，这样整体执行效率不高。而HotSpot关注的是对部分热点（hot spot）代码的动态优化，将频繁执行的热点代码编译为本地原生代码，这样显著提高了性能。 （连线表示垃圾收集器可以配合使用） 单线程与多线程: 单线程指垃圾收集器只用一个线程进行收集，而多线程使用多个线程； 串行与并行: 串行指的是垃圾收集器与用户程序交替执行，这意味着在执行垃圾收集的时候需要停顿用户程序；并行指的是垃圾收集器和用户程序同时执行。 串行回收器：Serial、Serial old 并行回收器：ParNew、Parallel Scavenge、Parallel old 并发回收器：CMS、G1 新生代收集器：Serial、ParNew、Parallel Scavenge； 老年代收集器：Serial old、Parallel old、CMS； 整堆收集器：G1； Serial收集器（串行） 单线程、串行 优点：简单高效，对于单个 CPU 环境来说，由于没有线程交互的开销，因此拥有最高的单线程收集效率。 它是Client模式下的默认新生代收集器，因为在用户的桌面应用场景下，分配给虚拟机管理的内存一般来说不会很大。Serial 收集器收集几十兆甚至一两百兆的新生代停顿时间可以控制在一百多毫秒以内，只要不是太频繁，这点停顿是可以接受的。 ParNew 收集器（同新式） 多线程、并行 它是Serial收集器的多线程版本。 是Server模式下的虚拟机首选新生代收集器，除了性能原因外，主要是因为除了 Serial 收集器，只有它能与 CMS 收集器配合工作。 默认开启的线程数量与CPU数量相同，可以用-XX:ParallelGCThreads参数来设置线程数。 Parallel Scavenge收集器（并行/吞吐优先收集器） 多线程、并行 其目标是达到一个可控制的吞吐量，它被称为“吞吐量优先”收集器。这里的吞吐量指 CPU用于运行用户代码的时间占总时间的比值。（其它收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间） 高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互（停顿）的任务。 缩短停顿时间是以牺牲吞吐量和新生代空间来换取的: 新生代空间变小，垃圾回收变得频繁，导致吞吐量下降。 可以通过一个开关参数打开GC自适应的调节策略(GC Ergonomics)，就不需要手动指定新生代的大小(-Xmn)、Eden 和 Survivor 区的比例、晋升老年代对象年龄等细节参数了。虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。 Serial Old收集器 单线程、串行 是Serial收集器的老年代版本，也是给 Client 模式下的虚拟机使用。如果用在 Server 模式下，它有两大用途: · 在JDK 1.5以及之前版本(Parallel Old诞生以前)中与Parallel Scavenge收集器搭配使用。 · 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。 Parallel Old 收集器 多线程、并行 是 Parallel Scavenge 收集器的老年代版本。 在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器。 CMS收集器 多线程、并发 CMS(Concurrent Mark Sweep)，Mark Sweep 指的是标记 - 清除算法。 CMS收集器运行过程： 初始标记（标记GC Roots能直接关联到的对象，速度很快，需要停顿） 并发标记（进行GC Roots tracing的过程，时间较长，不需要停顿） 重新标记（修正并发标记期间因用户程序继续运行而导致标记变动的那一部分对象的标记记录，需要停顿） 并发清除（不需要停顿） CMS优点：并发收集、低停顿 CMS缺点：吞吐量低（低停顿时间是以牺牲吞吐量为代价的，导致 CPU 利用率不够高）、无法处理浮动垃圾、收集结束后会有大量空间碎片 由于CMS并发清理阶段用户线程还在运行着，伴随着运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉，这一部分垃圾就称为“浮动垃圾”（Floating Garbage）。 G1收集器 并发 G1(Garbage-First)，它是一款面向服务端应用的垃圾收集器，在多CPU和大内存的场景下有很好的性能。HotSpot 开发团队赋予它的使命是未来可以替换掉 CMS 收集器。 G1 可以直接对新生代和老年代一起回收。 G1GC 的目的就是高效地实现软实时性，能够让用户设置期望暂停时间。在确保吞吐量比以往的GC更好的前提下，实现了软实时性。 G1GC 能最大程度利用服务器上多处理器的优势，而且在处理巨大的堆时，也不会降低 GC 的性能。 G1GC 的执行过程是什么样的？ 初始标记 并发标记（concurrent marking）：和应用程序并发执行，针对区域内所有的存活对象进行标记。 最终标记 筛选回收：首先对各个Region中的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。 G1 选择的回收算法： 在新生代，G1采用的仍然是并行的复制算法，所以同样会发生Stop-The-World的暂停。 在老年代，大部分情况下都是并发标记，而整理（Compact）则是和新生代 GC 时捎带进行，并且不是整体性的整理，而是增量进行的。 特点: · 空间整合: 整体来看是基于“标记 - 整理”算法实现的收集器，从局部(两个 Region 之间)上来看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。 · 可预测的停顿: 能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在 GC上的时间不得超过N毫秒。 标签：收集器,对象,虚拟机,回收,GC,引用,JVM,垃圾 From： https://www.cnblogs.com/cjhtxdy/p/17372367.html