5、Java虚拟机 - JVM面试题（二）- 挑战高薪必备

9、如何判断堆上的对象没有被引用？？

引用计数法

引用计数法会为每个对象维护一个引用计数器，当对象被引用时加1，取消引用时减1。

当局部变量对A对象产生引用之后，A的计数器就会加1：

同样，当A对象对B对象产生引用之后，B的计数器会加1：

引用计数法的优点是实现简单，缺点有两点：

1.每次引用和取消引用都需要维护计数器，对系统性能会有一定的影响

2.存在循环引用问题，所谓循环引用就是当A引用B，B同时引用A时会出现对象无法回收的问题。

如下图：

A对象和B对象在局部变量中已经无法访问了，但是由于他们互相引用对方，导致对象不能被回收。

可达性分析法

Java使用的是可达性分析算法来判断对象是否可以被回收。可达性分析将对象分为两类：垃圾回收的根对象（GC Root）和普通对象，对象与对象之间存在引用关系。

下图中A到B再到C和D，形成了一个引用链，可达性分析算法指的是如果从某个到GC Root对象是可达的，对象就不可被回收。

哪些对象被称之为GC Root对象呢？

• 线程Thread对象，引用线程栈帧中的方法参数、局部变量等。

• 系统类加载器加载的java.lang.Class对象，引用类中的静态变量。

• 监视器对象，用来保存同步锁synchronized关键字持有的对象。

• 本地方法调用时使用的全局对象。

总结：

引用计数法会为每个对象维护一个引用计数器，当对象被引用时加1，取消引用时减1，存在循环引用问题所以Java没有使用这种方法。

Java使用的是可达性分析算法来判断对象是否可以被回收。可达性分析将对象分为两类：垃圾回收的根对象（GC Root）和普通对象。

可达性分析算法指的是如果从某个到GC Root对象是可达的，对象就不可被回收。最常见的是GC Root对象会引用栈上的局部变量和静态变量导致对象不可回收。

  10、JVM 中都有哪些引用类型？

强引用

强引用，JVM中默认引用关系就是强引用，即是对象被局部变量、静态变量等GC Root关联的对象引用，只要这层关系存在，普通对象就不会被回收。

package q5reference;  
import java.util.ArrayList; 
import java.util.List;  
//-Xmx10m -verbose:gc 
public  class  StrongReferenceDemo {  

private  static  int  _1MB  =  1024 * 1024 * 1 ; 
public  static  void  main (String[] args) { 
List<Object> objects = new  ArrayList <>();   
        while ( true ){  byte [] bytes = new  byte [_1MB];   
            //强引用   
            objects.add(bytes); 
        } 
    }
} 

  强引用的对象不会被回收掉，所以会出现内存溢出：

软引用

  软引用，软引用相对于强引用是一种比较弱的引用关系，如果一个对象只有软引用关联到它，当程序内存不足时，就会将软引用中的数据进行回收。软引用主要在缓存框架中使用。

package q5reference;

import java.lang.ref.SoftReference;
import java.util.ArrayList;
import java.util.List;

//-Xmx10m -verbose:gc
public  class SoftReferenceDemo {
    private  static  int  _1MB = 1024 * 1024 * 1;
    public  static  void main(String[] args) {
        List<SoftReference> objects = new ArrayList<>();

        for (int i = 0; i < 10; i++) {
            byte[] bytes = new  byte[ _1MB];
            //软引用
SoftReference<byte[]> softReferences = new SoftReference<byte[]>(bytes);
            //软引用对象放入集合中
objects.add(softReferences);

            System.out.println(i);
        }

        //有一部分对象因为内存不足，已经被回收了
 for (SoftReference softReference : objects) {
            System.out.println(softReference.get());
        }

    }
}

  内存不足时，触发了垃圾回收。

  所以前几个对象已经被回收了，但是后边几个会保留下来：

弱引用

  弱引用，弱引用的整体机制和软引用基本一致，区别在于弱引用包含的对象在垃圾回收时，不管内存够不够都会直接被回收，弱引用主要在ThreadLocal中使用。

package q5reference;

import java.lang.ref.SoftReference;
import java.lang.ref.WeakReference;
import java.util.ArrayList;
import java.util.List;

//-Xmx100m -verbose:gc
public  class WeakReferenceDemo {
    private  static  int _1MB = 1024 * 1024 * 1;
    public  static  void main(String[] args) {
        List<WeakReference<byte[]>> objects = new ArrayList<>();
        System.out.println( "-------------------" );
        for (int i = 0; i < 10; i++) {
            byte[] bytes = new  byte[_1MB];
            //弱引用
WeakReference<byte[]> weakReference = new WeakReference<byte[]>(bytes);
            //弱引用对象放入集合中
objects.add(weakReference);
        }

        //设置一个强引用
 byte[] last = objects.get(9).get();

        //手动执行一次垃圾回收，弱引用对象只要没有强引用，就会被直接回收
System.gc();
        System.out.println( "-------------------" );
        for (WeakReference softReference : objects) {
            System.out.println(softReference.get());
        }
    }
}

  手动触发垃圾回收之后，前9个都被回收了，最后一个由于存在强引用会保留下来：

虚引用

  虚引用（幽灵引用/幻影引用），不能通过虚引用对象获取到包含的对象。虚引用唯一的用途是当对象被垃圾回收器回收时可以接收到对应的通知。直接内存中为了及时知道直接内存对象不再使用，从而回收内存，使用了虚引用来实现。

package q5reference;

import java.lang.ref.PhantomReference;
import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
import java.lang.ref.WeakReference;
import java.util.ArrayList;
import java.util.List;

//-Xmx10m -verbose:gc
public  class PhantomReferenceDemo {
    private  static  int _1MB = 1024 * 1024 * 1;
    public  static  void main(String[] args) {
        ReferenceQueue<byte[]> queue = new ReferenceQueue();
        byte[] bytes = new  byte[_1MB];
        MyPhantomReference phantomReference = new MyPhantomReference(bytes, queue);

        //去除强引用
bytes = null;
        //执行垃圾回收
System.gc();

        //查看队列
MyPhantomReference ref = (MyPhantomReference) queue.poll();
        //清理
ref.clean();

    }
}

class MyPhantomReference extends PhantomReference<byte[]>{
    public  void clean(){
        System.out.println( "清理..." );
    }

    public MyPhantomReference(byte[] referent, ReferenceQueue<byte[]> q) {
        super(referent, q);
    }
}

  对象回收之后虚引用对象会进入队列，这样就可以获取对象执行指定的方法了。

终结器引用

  终结器引用，终结器引用指的是在对象需要被回收时，终结器引用会关联对象并放置在Finalizer类中的引用队列中，在稍后由一条由FinalizerThread线程从队列中获取对象，然后执行对象的finalize方法，在对象第二次被回收时，该对象才真正的被回收。

package q5reference;

import java.io.IOException;

//-verbose:gc
public  class FinalizeReferenceDemo {
    public  static  void main(String[] args) throws IOException {
        Demo demo = new Demo();
        demo = null;

        System.gc();

        System.in.read();
    }
}


class Demo{
    @Override
    protected  void finalize() throws Throwable {
        System.out.println( "触发finalize" );
        super.finalize();
    }
}

对象回收时，触发了finalize方法：

10、ThreadLocal中为什么要使用弱引用？

ThreadLocal可以在线程中存放线程的本地变量，保证数据的线程安全。

ThreadLocal中是这样去保存对象的：

1、在每个线程中，存放了一个ThreadLocalMap对象，本质上就是一个数组实现的哈希表，里边存放多个Entry对象。

2、每个Entry对象继承自弱引用，内部存放ThreadLocal对象。同时用强引用，引用保存的ThreadLocal对应的value值。

以代码为例：

 threadLocal.set(new User(1,"main线程对象"));

获取数据时：

         User user = threadLocal.get();

不再使用Threadlocal对象时， threadlocal = null；由于是弱引用，那么在垃圾回收之后，ThreadLocal对象就可以被回收。

此时还有Entry对象和value对象没有能被回收，所以在ThreadLocal类的set、get、remove方法中，在某些特定条件满足的情况下，会主动删除这两个对象。

如果一直不调用set、get、remove方法或者调用了没有满足条件，这部分对象就会出现内存泄漏。强烈建议在ThreadLocal不再使用时，调用remove方法回收将Entry对象的引用关系去掉，这样就可以回收这两个对象了。

总结：

当threadlocal对象不再使用时，使用弱引用可以让对象被回收；因为仅有弱引用没有强引用的情况下，对象是可以被回收的。

弱引用并没有完全解决掉对象回收的问题，Entry对象和value值无法被回收，所以合理的做法是手动调用remove方法进行回收，然后再将threadlocal对象的强引用解除。

11、有哪些常见的垃圾回收算法？

1960年John McCarthy发布了第一个GC算法：标记-清除算法。

1963年Marvin L. Minsky 发布了复制算法。

本质上后续所有的垃圾回收算法，都是在上述两种算法的基础上优化而来。

标记清除算法

标记清除算法的核心思想分为两个阶段：

1.标记阶段，将所有存活的对象进行标记。Java中使用可达性分析算法，从GC Root开始通过引用链遍历出所有存活对象。

2.清除阶段，从内存中删除没有被标记也就是非存活对象。

优点：实现简单，只需要在第一阶段给每个对象维护标志位，第二阶段删除对象即可。

缺点：1.碎片化问题

由于内存是连续的，所以在对象被删除之后，内存中会出现很多细小的可用内存单元。如果我们需要的是一个比较大的空间，很有可能这些内存单元的大小过小无法进行分配。

2.分配速度慢。由于内存碎片的存在，需要维护一个空闲链表，极有可能发生每次需要遍历到链表的最后才能获得合适的内存空间。

复制算法

复制算法的核心思想是：

1.准备两块空间From空间和To空间，每次在对象分配阶段，只能使用其中一块空间（From空间）。

2.在垃圾回收GC阶段，将From中存活对象复制到To空间。

3.将两块空间的From和To名字互换。

优点：

• 吞吐量高，复制算法只需要遍历一次存活对象复制到To空间即可，比标记-整理算法少了一次遍历的过程，因而性能较好，但是不如标记-清除算法，因为标记清除算法不需要进行对象的移动

• 不会发生碎片化，复制算法在复制之后就会将对象按顺序放入To空间中，所以对象以外的区域都是可用空间，不存在碎片化内存空间。

缺点：

• 内存使用效率低，每次只能让一半的内存空间来为创建对象使用

标记整理算法

标记整理算法也叫标记压缩算法，是对标记清理算法中容易产生内存碎片问题的一种解决方案。

核心思想分为两个阶段：

1.标记阶段，将所有存活的对象进行标记。Java中使用可达性分析算法，从GC Root开始通过引用链遍历出所有存活对象。

2.整理阶段，将存活对象移动到堆的一端。清理掉存活对象的内存空间。

优点：

• 内存使用效率高，整个堆内存都可以使用，不会像复制算法只能使用半个堆内存

• 不会发生碎片化，在整理阶段可以将对象往内存的一侧进行移动，剩下的空间都是可以分配对象的有效空间

缺点：

• 整理阶段的效率不高，整理算法有很多种，比如Lisp2整理算法需要对整个堆中的对象搜索3次，整体性能不佳。可以通过Two-Finger、表格算法、ImmixGC等高效的整理算法优化此阶段的性能。

分代垃圾回收算法

现代优秀的垃圾回收算法，会将上述描述的垃圾回收算法组合进行使用，其中应用最广的就是分代垃圾回收算法(Generational GC)。

分代垃圾回收将整个内存区域划分为年轻代和老年代：

分代回收时，创建出来的对象，首先会被放入Eden伊甸园区。

随着对象在Eden区越来越多，如果Eden区满，新创建的对象已经无法放入，就会触发年轻代的GC，称为Minor GC或者Young GC。

Minor GC会把需要eden中和From需要回收的对象回收，把没有回收的对象放入To区。

接下来，S0会变成To区，S1变成From区。当eden区满时再往里放入对象，依然会发生Minor GC。

此时会回收eden区和S1(from)中的对象，并把eden和from区中剩余的对象放入S0。

注意：每次Minor GC中都会为对象记录他的年龄，初始值为0，每次GC完加1。

如果Minor GC后对象的年龄达到阈值（最大15，默认值和垃圾回收器有关），对象就会被晋升至老年代。

当老年代中空间不足，无法放入新的对象时，先尝试minor gc如果还是不足，就会触发Full GC，Full GC会对整个堆进行垃圾回收。

如果Full GC依然无法回收掉老年代的对象，那么当对象继续放入老年代时，就会抛出Out Of Memory异常。

程序中大部分对象都是朝生夕死，在年轻代创建并且回收，只有少量对象会长期存活进入老年代。分代垃圾回收的优点有：

1、可以通过调整年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能。

2、新生代和老年代使用不同的垃圾回收算法，新生代一般选择复制算法效率高、不会产生内存碎片，老年代可以选择标记-清除和标记-整理算法，由程序员来选择灵活度较高。

3、分代的设计中允许只回收新生代（minor gc），如果能满足对象分配的要求就不需要对整个堆进行回收(full gc),STW（Stop The World）由垃圾回收引起的停顿时间就会减少。

总结：

12、有哪些常用的垃圾回收器？

垃圾回收器是垃圾回收算法的具体实现。

由于垃圾回收器分为年轻代和老年代，除了G1之外其他垃圾回收器必须成对组合进行使用。

具体的关系图如下：

Serial垃圾回收器 + SerialOld垃圾回收器

Serial是是一种单线程串行回收年轻代的垃圾回收器。

-XX:+UseSerialGC 新生代、老年代都使用串行回收器。

回收年代和算法

• 年轻代复制算法

• 老年代标记-整理算法

优点

单CPU处理器下吞吐量非常出色

缺点

多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待

适用场景

Java编写的客户端程序或者硬件配置有限的场景

Parallel Scavenge垃圾回收器 + Parallel Old垃圾回收器

PS+PO是JDK8默认的垃圾回收器，多线程并行回收，关注的是系统的吞吐量。具备自动调整堆内存大小的特点。

回收年代和算法

• 年轻代复制算法

• 老年代标记-整理算法

优点

吞吐量高，而且手动可控。为了提高吞吐量，虚拟机会动态调整堆的参数

缺点

不能保证单次的停顿时间

适用场景

后台任务，不需要与用户交互，并且容易产生大量的对象

比如：大数据的处理，大文件导出

年轻代-ParNew垃圾回收器

ParNew垃圾回收器本质上是对Serial在多CPU下的优化，使用多线程进行垃圾回收

-XX:+UseParNewGC 新生代使用ParNew回收器，老年代使用串行回收器

回收年代和算法

• 年轻代

• 复制算法

优点

多CPU处理器下停顿时间较短

缺点

吞吐量和停顿时间不如G1，所以在JDK9之后不建议使用

适用场景

JDK8及之前的版本中，与CMS老年代垃圾回收器搭配使用

老年代- CMS(Concurrent Mark Sweep)垃圾回收器

CMS垃圾回收器关注的是系统的暂停时间，允许用户线程和垃圾回收线程在某些步骤中同时执行，减少了用户线程的等待时间。

参数：-XX:+UseConcMarkSweepGC

回收年代和算法

• 老年代

• 标记清除算法

优点

系统由于垃圾回收出现的停顿时间较短，用户体验好

缺点

1、内存碎片问题

2、退化问题

3、浮动垃圾问题

适用场景

大型的互联网系统中用户请求数据量大、频率高的场景

比如订单接口、商品接口等

CMS垃圾回收器存在的问题

1、CMS使用了标记-清除算法，在垃圾收集结束之后会出现大量的内存碎片，CMS会在Full GC时进行碎片的整理。这样会导致用户线程暂停，可以使用-XX:CMSFullGCsBeforeCompaction=N 参数（默认0）调整N次Full GC之后再整理。

2、无法处理在并发清理过程中产生的“浮动垃圾”，不能做到完全的垃圾回收。

3、如果老年代内存不足无法分配对象，CMS就会退化成Serial Old单线程回收老年代。

4、并发阶段会影响用户线程执行的性能

G1 – Garbage First 垃圾回收器

参数1： -XX:+UseG1GC 打开G1的开关，JDK9之后默认不需要打开

参数2：-XX:MaxGCPauseMillis=毫秒值

最大暂停的时间

回收年代和算法

• 年轻代+老年代

• 复制算法

优点

对比较大的堆如超过6G的堆回收时，延迟可控

不会产生内存碎片

并发标记的SATB算法效率高

缺点

JDK8之前还不够成熟

适用场景

JDK8最新版本、JDK9之后建议默认使用

什么是Shenandoah？

Shenandoah 是由Red Hat开发的一款低延迟的垃圾收集器，Shenandoah 并发执行大部分 GC 工作，包括并发的整理，堆大小对STW的时间基本没有影响。

什么是ZGC？

ZGC 是一种可扩展的低延迟垃圾回收器。ZGC 在垃圾回收过程中，STW的时间不会超过一毫秒，适合需要低延迟的应用。支持几百兆到16TB 的堆大小，堆大小对STW的时间基本没有影响。

垃圾回收器的技术演进

总结：

垃圾回收器的组合关系虽然很多，但是针对几个特定的版本，比较好的组合选择如下：

JDK8及之前：

ParNew + CMS（关注暂停时间）、Parallel Scavenge + Parallel Old (关注吞吐量)、 G1（JDK8之前不建议，较大堆并且关注暂停时间）

JDK9之后:

G1（默认）

从JDK9之后，由于G1日趋成熟，JDK默认的垃圾回收器已经修改为G1，所以强烈建议在生产环境上使用G1。

如果对低延迟有较高的要求，可以使用Shenandoah或者ZGC。

13、如何解决内存泄漏问题？

内存泄漏（memory leak）：在Java中如果不再使用一个对象，但是该对象依然在GC ROOT的引用链上，这个对象就不会被垃圾回收器回收，这种情况就称之为内存泄漏。

少量的内存泄漏可以容忍，但是如果发生持续的内存泄漏，就像滚雪球雪球越滚越大，不管有多大的内存迟早会被消耗完，最终导致的结果就是内存溢出。

解决内存泄漏问题总共分为四个步骤，其中前两个步骤是最核心的：

发现问题 – 堆内存状况的对比

正常情况

• 处理业务时会出现上下起伏，业务对象频繁创建内存会升高，触发MinorGC之后内存会降下来。

• 手动执行FULL GC之后，内存大小会骤降，而且每次降完之后的大小是接近的。

• 长时间观察内存曲线应该是在一个范围内。

出现内存泄漏

• 处于持续增长的情况，即使Minor GC也不能把大部分对象回收

• 手动FULL GC之后的内存量每一次都在增长

• 长时间观察内存曲线持续增长

生产环境通过运维提供的Prometheus + Grafana等监控平台查看

开发、测试环境通过visualvm查看

    package q7oom;

    import java.util.ArrayList;
    import java.util.List;

    //-Xmx10m -verbose:gc
    public  class OOMDemo {
        private  static  int _1MB = 1024 * 1024 * 1;
        public  static  void main(String[] args) throws InterruptedException {
            List<Object> objects = new ArrayList<>();

            while (true){
                byte[] bytes = new  byte[_1MB];
                //强引用
    objects.add(bytes);
                Thread.sleep(50);
            }

        }
    }

这段代码执行之后，使用visualvm查看结果：

处于持续增长的情况，手动FULL GC之后的内存量每一次都在增长，长时间观察内存曲线持续增长。属于内存泄漏的情况。

诊断 – 生成内存快照

当堆内存溢出时，需要在堆内存溢出时将整个堆内存保存下来，生成内存快照(Heap Profile )文件。

生成方式有两种

1、内存溢出时自动生成，添加生成内存快照的Java虚拟机参数：

-XX:+HeapDumpOnOutOfMemoryError：发生OutOfMemoryError错误时，自动生成hprof内存快照文件。

-XX:HeapDumpPath=：指定hprof文件的输出路径。

发生oom之后，就会生成内存快照文件：

2、导出运行中系统的内存快照，比较简单的方式有两种，注意只需要导出标记为存活的对象：

通过JDK自带的jmap命令导出，格式为：

jmap -dump:live,format=b,file=文件路径和文件名 进程ID

通过arthas的heapdump命令导出，格式为：

heapdump --live 文件路径和文件名

诊断 – MAT定位问题

使用MAT打开hprof文件，并选择内存泄漏检测功能，MAT会自行根据内存快照中保存的数据分析内存泄漏的根源。

修复问题

修复内存溢出问题的要具体问题具体分析，问题总共可以分成三类：

• 代码中的内存泄漏，由于代码的不合理写法存在隐患，导致内存泄漏

• 并发引起内存溢出 - 参数不当,由于参数设置不当，比如堆内存设置过小，导致并发量增加之后超过堆内存的上限。解决方案：设置合理参数

• 并发引起内存溢出 – 设计不当，系统的方案设计不当，比如：

  • 从数据库获取超大数据量的数据
  • 线程池设计不当
  • 生产者-消费者模型，消费者消费性能问题

解决方案：优化设计方案

常用的JVM工具

JDK自带的命令行工具：

jps 查看java进程，打印main方法所在类名和进程id

jmap 1、生成堆内存快照

2、打印类的直方图

第三方工具：

VisualVM 监控

Arthas 综合性工具

MAT 堆内存分析工具

监控工具：

Prometheus + grafana

14、 常见的JVM参数？

  参数1 ： -Xmx 和 –Xms

  -Xmx参数设置的是最大堆内存，但是由于程序是运行在服务器或者容器上，计算可用内存时，要将元空间、操作系统、其它软件占用的内存排除掉。

  案例： 服务器内存4G，操作系统+元空间最大值+其它软件占用1.5G，-Xmx可以设置为2g。

  最合理的设置方式应该是根据最大并发量估算服务器的配置，然后再根据服务器配置计算最大堆内存的值。

  建议将-Xms设置的和-Xmx一样大,运行过程中不再产生扩容的开销。

参数2 ： -XX:MaxMetaspaceSize 和 -Xss

-XX:MaxMetaspaceSize=值 参数指的是最大元空间大小，默认值比较大，如果出现元空间内存泄漏会让操作系统可用内存不可控，建议根据测试情况设置最大值，一般设置为256m。

-Xss256k 栈内存大小，如果我们不指定栈的大小，JVM 将创建一个具有默认大小的栈。大小取决于操作系统和计算机的体系结构。比如Linux x86 64位 ： 1MB，如果不需要用到这么大的栈内存，完全可以将此值调小节省内存空间，合理值为256k – 1m之间。

参数3：-Xmn 年轻代的大小

默认值为整个堆的1/3，可以根据峰值流量计算最大的年轻代大小，尽量让对象只存放在年轻代，不进入老年代。但是实际的场景中，接口的响应时间、创建对象的大小、程序内部还会有一些定时任务等不确定因素都会导致这个值的大小并不能仅凭计算得出，如果设置该值要进行大量的测试。G1垃圾回收器尽量不要设置该值，G1会动态调整年轻代的大小。

打印GC日志

JDK8及之前 ： -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:文件路径

JDK9及之后 ： -Xlog:gc*:file=文件路径

-XX:+DisableExplicitGC

禁止在代码中使用System.gc()， System.gc()可能会引起FULLGC，在代码中尽量不要使用。使用DisableExplicitGC参数可以禁止使用System.gc()方法调用。

-XX:+HeapDumpOnOutOfMemoryError：发生OutOfMemoryError错误时，自动生成hprof内存快照文件。

-XX:HeapDumpPath=：指定hprof文件的输出路径。

JVM参数模板：

-Xms1g-Xmx1g-Xss256k
-XX:MaxMetaspaceSize=512m 
-XX:+DisableExplicitGC
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/opt/dumps/my-service.hprof
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-Xloggc:文件路径

注意：

JDK9及之后gc日志输出修改为 -Xlog:gc*:file=文件名

堆内存大小和栈内存大小根据实际情况灵活调整。