【Java八股文总结】之JVM

文章目录

    • JVM
      • 一、JVM内存区域
        • 1、运行时数据区域
          • 1、程序计数器
          • 2、java虚拟机栈
            • Q:栈可能出现的两种错误
          • 3、本地方法栈
          • 4、堆
            • Q:堆中会出现的错误
            • Q:堆中对象的分配过程
          • 5、方法区
          • Q:堆和栈的区别?
        • 2、为什么要将永久代(PermGen)替换为元空间(MetaSpace)呢?
          • 1、方法区的常用参数有?
          • 2、运行时常量池
          • 3、字符串常量池
          • 4、jdk1.7 为什么将字符串常量池移到堆中?
          • 5、直接内存
        • 3、对象创建过程
          • Q:JVM创建对象,如何保证线程安全性?
          • 4、Java内存分配方式
          • 5、Java对象内存布局
            • Q:对象怎么访问定位?
        • 6、JVM中对象及常量、局部变量、全局变量的存储位置
        • 7、Java虚拟机的生命周期
      • 二、JVM 垃圾回收
        • 1、对象死亡的判断方法
        • 2、哪些对象可以作为GC Roots 呢?
        • 3、常见的引用类型(强软弱虚)
          • Q:如何判断一个常量是废弃变量?如何判断一个类是无用的类?
        • 4、垃圾回收算法
        • 5、垃圾回收器
          • CMS收集器
          • G1
          • Q:有了CMS,为什么还要引入G1?
          • Q:垃圾回收器负责的3个任务
        • 6、Minor GC/Young GC、Major GC/Old GC、Mixed GC、Full GC 都是什么意思?
          • Q:Minor GC的触发条件?
          • Q:什么时候会触发Full GC ?
          • Q:对象什么时候进入老年代?
      • 三、类加载过程
        • 1、类的生命周期
        • 2、类加载过程
          • 1、加载
          • 2、验证
          • 3、准备
          • 4、解析
          • 5、初始化
            • Q:初始化开始的时机
          • 6、卸载
        • 3、Java中的类加载器
          • Q:为什么要自定义类加载器?
          • Q:如何实现自定义类加载器?
        • 4、双亲委派模型
          • Q:双亲委派模型实现步骤?
          • Q:双亲委派模型的好处?
          • Q:如何判断两个Class对象是否是一个类?
          • Q:不想使用双亲委派模型怎么解决?
          • Q:3次打破双亲委派机制的案例?
          • Q:如何实现热部署?
        • 5、Tomcat的类加载机制?
      • 四、JVM调优参数
      • 五、JVM调优
        • 1、常用的命令行性能监控和故障处理工具?
        • 2、JVM可视化的性能监控和故障处理工具有?
        • 3、线上服务CPU占用过高怎么排查?
        • 4、内存飙升怎么排查?
        • 5、频繁的年轻代垃圾回收怎么办?
        • 6、频繁的整堆垃圾回收(full GC)怎么办?
        • 7、内存泄漏和内存溢出如何排查?

JVM

一、JVM内存区域

【Java八股文总结】之JVM_第1张图片
【Java八股文总结】之JVM_第2张图片
【Java八股文总结】之JVM_第3张图片

1、运行时数据区域

【Java八股文总结】之JVM_第4张图片
【Java八股文总结】之JVM_第5张图片
线程私有: 程序计数器、虚拟机栈、本地方法栈
线程共享: 堆、方法区、直接内存(非运行时数据区的一部分)
JDK 1.8同JDK 1.7比,最大的差别就是:元数据区取代了永久代。元空间与永久代之间最大的区别在于:元数据空间并不在虚拟机中,而是使用本地内存。

1、程序计数器

【Java八股文总结】之JVM_第6张图片

2、java虚拟机栈

【Java八股文总结】之JVM_第7张图片
【Java八股文总结】之JVM_第8张图片
【Java八股文总结】之JVM_第9张图片

Q:栈可能出现的两种错误

【Java八股文总结】之JVM_第10张图片

3、本地方法栈

【Java八股文总结】之JVM_第11张图片

4、堆

【Java八股文总结】之JVM_第12张图片
【Java八股文总结】之JVM_第13张图片

Q:堆中会出现的错误

【Java八股文总结】之JVM_第14张图片

Q:堆中对象的分配过程
  1. new 的对象先放在 Eden 区,大小有限制。
  2. 如果创建新对象时,Eden 空间填满了,就会触发 Minor GC,将 Eden 不再被其他对象引用的对象进行销毁,再加载新的对象放到 Eden 区,特别注意的是 Survivor 区满了是不会触发 Minor GC 的,而是 Eden 空间填满了,Minor GC 才顺便清理 Survivor 区。
  3. 将 Eden 中剩余的对象移到 Survivor0 区。
  4. 再次触发垃圾回收,此时上次 Survivor 下来的,放在 Survivor0 区的,如果没有回收,就会放到 Survivor1 区。
  5. 再次经历垃圾回收,又会将幸存者重新放回 Survivor0 区,依次类推。
  6. 默认是 15 次的循环,超过 15 次,则会将幸存者区幸存下来的转去老年区,jvm 参数设置次数 : -XX:MaxTenuringThreshold=N 进行设置。
  7. 频繁在新生区收集,很少在养老区收集,几乎不在永久区/元空间搜集。
5、方法区

【Java八股文总结】之JVM_第15张图片
【Java八股文总结】之JVM_第16张图片

Q:堆和栈的区别?

【Java八股文总结】之JVM_第17张图片

2、为什么要将永久代(PermGen)替换为元空间(MetaSpace)呢?

【Java八股文总结】之JVM_第18张图片

1、方法区的常用参数有?

【Java八股文总结】之JVM_第19张图片

2、运行时常量池

【Java八股文总结】之JVM_第20张图片

3、字符串常量池

【Java八股文总结】之JVM_第21张图片
【Java八股文总结】之JVM_第22张图片
【Java八股文总结】之JVM_第23张图片
【Java八股文总结】之JVM_第24张图片

4、jdk1.7 为什么将字符串常量池移到堆中?

【Java八股文总结】之JVM_第25张图片

5、直接内存

【Java八股文总结】之JVM_第26张图片

3、对象创建过程

①类加载(判断类是否被加载、解析、初始化过) --> ②分配内存(分配内存的方式) --> ③初始化零值 --> ④设置对象头 --> ⑤执行init方法
【Java八股文总结】之JVM_第27张图片
【Java八股文总结】之JVM_第28张图片

Q:JVM创建对象,如何保证线程安全性?
  • 采用 CAS分配重试 的方式来保证更新操作的原子性。
  • 每个线程 在Java堆中预先分配一小块内存 ,也就是本地线程分配缓冲(Thread Local Allocation Buffer,TLAB),要分配内存的线程,先在本地缓冲区中分配,只有本地缓冲区用完了,分配新的缓存区时才需要同步锁定。
4、Java内存分配方式

【Java八股文总结】之JVM_第29张图片

5、Java对象内存布局

【Java八股文总结】之JVM_第30张图片
【Java八股文总结】之JVM_第31张图片

Q:对象怎么访问定位?

【Java八股文总结】之JVM_第32张图片
【Java八股文总结】之JVM_第33张图片
【Java八股文总结】之JVM_第34张图片
HotSpot虚拟机主要使用 直接指针 来进行对象访问。

6、JVM中对象及常量、局部变量、全局变量的存储位置

  • 局部变量
    基本数据类型:变量名和变量值存储在 方法栈 中。
    引用数据类型:变量值存储在 方法栈 中(存储的是堆中对象的内存地址),所指向的对象是存储在堆内存中(如new出来的对象)。

  • 全局变量
    基本数据类型:变量名和变量值存储在 内存中。
    引用数据类型:变量名存储的是所引用对象的内存地址,变量名和变量值存储在 内存中。

7、Java虚拟机的生命周期

Java虚拟机:执行Java程序。程序开始执行时它才运行,程序结束时它就停止。你在同一台机器上运行三个程序,就会有三个运行中的Java虚拟机。Java虚拟机总是开始于一个main()方法,这个方法必须是公有、返回void、只接受一个字符串数组。在程序执行时,你必须给Java虚拟机指明这个包或main()方法的类名。 Main()方法是程序的起点,它被执行的线程初始化为程序的初始线程。程序中其他的线程都由它来启动。Java中的线程分为两种:守护线程(daemon)和普通线程(non-daemon)。守护线程是Java虚拟机自己使用的线程,比如负责垃圾收集GC的线程就是一个守护线程。当然,你也可以把自己的程序用setDeamon设置为守护线程。包含Main()方法的初始线程不是守护线程。只要Java虚拟机中还有普通的线程在执行,Java虚拟机就不会停止。如果有足够的权限,你可以调用exit()方法终止程序。

二、JVM 垃圾回收

【Java八股文总结】之JVM_第35张图片
【Java八股文总结】之JVM_第36张图片
【Java八股文总结】之JVM_第37张图片
【Java八股文总结】之JVM_第38张图片
【Java八股文总结】之JVM_第39张图片
【Java八股文总结】之JVM_第40张图片
【Java八股文总结】之JVM_第41张图片
【Java八股文总结】之JVM_第42张图片

1、对象死亡的判断方法

【Java八股文总结】之JVM_第43张图片
【Java八股文总结】之JVM_第44张图片

2、哪些对象可以作为GC Roots 呢?

【Java八股文总结】之JVM_第45张图片

3、常见的引用类型(强软弱虚)

【Java八股文总结】之JVM_第46张图片
【Java八股文总结】之JVM_第47张图片

Q:如何判断一个常量是废弃变量?如何判断一个类是无用的类?

【Java八股文总结】之JVM_第48张图片

4、垃圾回收算法

【Java八股文总结】之JVM_第49张图片
【Java八股文总结】之JVM_第50张图片
在这里插入图片描述
【Java八股文总结】之JVM_第51张图片
【Java八股文总结】之JVM_第52张图片

5、垃圾回收器

【Java八股文总结】之JVM_第53张图片
注意:

  1. 注重吞吐量以及CPU资源情况下,优先选用Parallel Scavenge和Parallel Old收集器。
  2. CMS全称Concurrent Mark Sweep,是一款并发的、使用标记-清除算法的垃圾回收器。
  3. G1(garbage frist)优先回收垃圾存放最多的分区,垃圾回收暂停时间短,同时也能维持较好的吞吐量,还解决了CMS的浮动垃圾问题、内存碎片问题
  4. 吞吐量:CPU用于运行代码的时间与CPU总消耗时间的比值。

【Java八股文总结】之JVM_第54张图片
【Java八股文总结】之JVM_第55张图片
【Java八股文总结】之JVM_第56张图片
【Java八股文总结】之JVM_第57张图片

CMS收集器

【Java八股文总结】之JVM_第58张图片
在这里插入图片描述

G1

【Java八股文总结】之JVM_第59张图片

Q:有了CMS,为什么还要引入G1?

优点: CMS最主要的优点在名字上已经体现出来——并发收集、低停顿
缺点: CMS同样有三个明显的缺点。

  1. 标记算法会导致内存碎片比较多。
  2. CMS的并发能力比较依赖于CPU资源,并发回收时垃圾收集线程可能会抢占用户线程的资源,导致用户程序性能下降。
  3. 并发清除阶段,用户线程依然在运行,会产生所谓的“浮动垃圾”(Floating Garbage),本次垃圾收集无法处理浮动垃圾,必须到下一次垃圾收集才能处理。如果浮动垃圾太多,会触发新的垃圾回收,导致性能降低。
    G1主要解决了内存碎片过多的问题。
Q:垃圾回收器负责的3个任务

①分配内存;②确保被引用对象的内存不被错误的回收;③回收不在被引用的对象的内存空间。

6、Minor GC/Young GC、Major GC/Old GC、Mixed GC、Full GC 都是什么意思?

  • 部分收集 (Partial GC): 指目标不是完整收集整个Java堆的垃圾收集,其中又分为:

1、新生代收集(Minor GC/Young GC):指目标只是新生代的垃圾收集。当Eden区没有足够的空间时,就会触发Young GC来清理新生代。
2、老年代收集(Major GC/Old GC):指目标只是老年代的垃圾收集。目前只有CMS收集器会有单独收集老年代的行为。
3、混合收集(Mixed GC):指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器会有这种行为。

  • 整堆收集(Full GC): 收集整个Java堆和方法区的垃圾收集。
Q:Minor GC的触发条件?

① eden区满的时候,会触发Minor GC。
② 新创建的对象大小大于Eden区所剩下的空间大小时,会触发Minor GC。

Q:什么时候会触发Full GC ?

【Java八股文总结】之JVM_第60张图片

Q:对象什么时候进入老年代?

【Java八股文总结】之JVM_第61张图片

  • 长期存活的对象将进入老年代
    在对象的对象头信息中存储着对象的迭代年龄,迭代年龄会在每次YoungGC之后对象的移区操作中增加,每一次移区年龄加一。当这个年龄达到15(默认)后,这个对象将会被移入老年代。
    可以通过这个参数设置这个年龄值。-XX:MaxTenuringThreshold
  • 大对象直接进入老年代
    有一些占用大量连续内存空间的对象在被加载就会直接进入老年代。这样的大对象一般是一些数组,长字符串之类的。
    HotSpot虚拟机提供了这个参数来设置。-XX:PretenureSizeThreshold
  • 动态对象年龄判定
    为了能更好地适应不同程序的内存状况,HotSpot虚拟机并不是永远要求对象的年龄必须达到-XX:MaxTenuringThreshold才能晋升老年代,如果在 Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代。
  • 空间分配担保
    假如在Young GC之后,新生代仍然有大量对象存活,就需要老年代进行分配担保,把Survivor无法容纳的对象直接送入老年代。

三、类加载过程

1、类的生命周期

【Java八股文总结】之JVM_第62张图片

2、类加载过程

【Java八股文总结】之JVM_第63张图片
一个非数组类的加载阶段(加载阶段获取类的二进制字节流的动作)是可控性最强的阶段,这一步我们可以去自定义类加载器去控制字节流的获取方式(重写一个类加载器的loadclass()方法)。数组类型不通过类加载器创建,它由Java虚拟机直接创建。
所有的类都由类加载器加载,加载的作用就是将.class文件加载到内存。

1、加载

【Java八股文总结】之JVM_第64张图片

2、验证

【Java八股文总结】之JVM_第65张图片

3、准备

【Java八股文总结】之JVM_第66张图片

4、解析

【Java八股文总结】之JVM_第67张图片

5、初始化

【Java八股文总结】之JVM_第68张图片

Q:初始化开始的时机

【Java八股文总结】之JVM_第69张图片

6、卸载

【Java八股文总结】之JVM_第70张图片

注意: 接口加载过程与类加载过程稍有不同。当一个类在初始化时,要求其父类全部都已经初始化过了,但是一个接口在初始化时,并不要求其父接口全部都完成了初始化,当真正用到父接口的时候才会初始化。

3、Java中的类加载器

JVM类加载器分为两类:JVM自带的类加载器和自定义类加载器。
【Java八股文总结】之JVM_第71张图片

Q:为什么要自定义类加载器?

① 隔离加载类;② 修改类加载的方式;③ 扩展加载源;④ 防止源码泄漏。

Q:如何实现自定义类加载器?

继承抽象类java.lang.ClassLoader类的方式,实现自己的类加载器。

4、双亲委派模型

每一个类都有一个对应它的类加载器。系统中的ClassLoader在协同工作的时候会默认使用双亲委派模型。即在类加载的时候,系统会首先判断当前类是否被加载过。已经被加载的类会直接返回,否则才会尝试加载。加载的时候,首先会把该请求委派给父类加载器的loadClass()处理,因此所有的请求最终都应该传送到顶层的启动类加载器BootstrapClassLoader中。当父类加载器无法处理时,才由自己来处理。当父类加载器为null时,会使用启动类加载器BootstrapClassLoader作为父类加载器。
【Java八股文总结】之JVM_第72张图片
【Java八股文总结】之JVM_第73张图片
在这里插入图片描述
【Java八股文总结】之JVM_第74张图片

Q:双亲委派模型实现步骤?

①首先判断该类是否已经被加载;
②该类未被加载,同时父类不为空,交给父类加载;
③如果父类为空,交给启动类加载器Bootstrap ClassLoader加载;
④如果类还是无法被加载到,则触发findclass,抛出ClassNotFoundException(findclass这个方法当前只有一个语句,就是抛出ClassNotFoundException),如果想自己实现类加载器的话,可以继承ClassLoader后重写findclass方法,加载对应的类)。

Q:双亲委派模型的好处?

双亲委派模型 保证了Java程序的稳定运行,可以避免类的重复加载(JVM区分不同类的方式不仅仅根据类名,相同的类文件被不同的类加载器加载产生的是两个不同的类★★★),也保证了Java的核心API不被篡改。如果没有使用双亲委派模型,而是每个类加载器加载自己的话就会出现一些问题,比如我们编写一个称为 java.lang.Object类的话,那么程序运行的时候,系统就会出现多个不同的Object类。

Q:如何判断两个Class对象是否是一个类?

在JVM中表示两个Class对象是否为同一个类存在两个必要条件:

  • 类的 完整类名必须一致 ,包括包名。
  • 加载这个类的类加载器 ClassLoader (指ClassLoader实例对象)必须相同。

换句话说,在JVM中,即使这两个类对象(class对象)来源同一个Class文件,被同一个虚拟机所加载,但只要加载它们的ClassLoader实例对象不同,那么这两个类对象也是不相等的

Q:不想使用双亲委派模型怎么解决?

自定义加载器的话,需要继承ClassLoader。如果我们 不想打破双亲委派模型 ,就重写ClassLoader类中的findclass()方法即可,无法被父类加载器加载的类最终会通过这个方法被加载。但是,如果 想打破双亲委派模型 则需要重写loadClass()方法

Q:3次打破双亲委派机制的案例?
  • 第一次破坏
    第一次被破坏发生在双亲委派模型出现之前——即JDK 1.2之前。
  • 第二次破坏
    第二次被破坏是由这个模型自身的缺陷导致的,如果有基础类型又要调用回用户的代码,那该怎么办呢?如JDBC。
  • 第三次破坏
    第三次被破坏是由于用户对程序动态性的追求而导致的,例如代码热替换(Hot Swap)、模块热部署(Hot Deployment)等。
Q:如何实现热部署?

想要实现热部署可以分以下三个步骤:

  1. 销毁原来的自定义ClassLoader
  2. 更新class类文件
  3. 创建新的ClassLoader去加载更新后的class类文件。
    到此,一个热部署的功能就这样实现了。

5、Tomcat的类加载机制?

【Java八股文总结】之JVM_第75张图片

Tomcat破坏了双亲委派原则,提供隔离的机制,为每个web容器单独提供一个WebAppClassLoader加载器。每一个WebAppClassLoader负责加载本身的目录下的class文件,加载不到时再交给CommonClassLoader加载,这和双亲委派刚好相反。

四、JVM调优参数

【Java八股文总结】之JVM_第76张图片
【Java八股文总结】之JVM_第77张图片

【Java八股文总结】之JVM_第78张图片
【Java八股文总结】之JVM_第79张图片
【Java八股文总结】之JVM_第80张图片
【Java八股文总结】之JVM_第81张图片
【Java八股文总结】之JVM_第82张图片
【Java八股文总结】之JVM_第83张图片

五、JVM调优

1、常用的命令行性能监控和故障处理工具?

  • 操作系统工具
    top:显示系统整体资源使用情况。
    vmstat:监控内存和 CPU。
    iostat:监控 IO 使用。
    netstat:监控网络使用。
  • JDK性能监控工具
    jps:虚拟机进程查看。
    jstat:虚拟机运行时信息查看。
    jinfo:虚拟机配置查看。
    jmap:内存映像(导出)。
    jhat:堆转储快照分析。
    jstack:Java 堆栈跟踪。
    jcmd:实现上面除了jstat外所有命令的功能。

2、JVM可视化的性能监控和故障处理工具有?

JConsole、VisualVM、Java Mission Control(前3个为JDK自带)、MAT(Java堆内存分析工具)、GChisto(GC日志分析工具)、GCViewer(GC日志分析工具)、JProfiler(性能分析工具)、arthas(阿里开源诊断工具)

3、线上服务CPU占用过高怎么排查?

问题分析:CPU高一定是某个程序长期占用了CPU资源。
【Java八股文总结】之JVM_第84张图片

  1. 先找出是哪个进程占用CPU高:top 列出系统各个进程的资源占用情况。
  2. 然后根据找到对应进程里哪个线程占用CPU高:top -Hp 进程id 列出对应进程里面的线程占用资源情况。
  3. 找到对应线程id后,再打印出对应线程的堆栈信息:
    printf "%x\n" PID 把线程id转换为16进制。
    jstack PID 打印出进程的所有线程信息,从打印出来的线程信息中找到上一步转换为16进制的线程id对应的线程信息。
  4. 最后根据线程的堆栈信息定位到具体业务方法,从代码逻辑中找到问题所在。
    查看是否有线程长时间的watting或blocked,如果线程长期处于watting状态下,关注watting on xxxxxx,说明线程在等待这把锁,然后根据锁的地址找到持有锁的线程。

4、内存飙升怎么排查?

分析:内存飚高如果是发生在java进程上,一般是因为创建了大量对象所导致,持续飚高说明垃圾回收跟不上对象创建的速度,或者内存泄露导致对象无法回收。

  1. 先观察垃圾回收的情况
    jstat -gc PID 1000 查看GC次数、时间等信息,每隔一秒打印一次。
    jmap -histo PID | head -20 查看堆内存占用空间最大的前20个对象类型,可初步查看是哪个对象占用了内存。
    如果每次GC次数频繁,而且每次回收的内存空间也正常,那说明是因为对象创建速度快导致内存一直占用很高;如果每次回收的内存非常少,那么很可能是因为内存泄露导致内存一直无法被回收。
  2. 导出堆内存文件快照
    jmap -dump:live,format=b,file=/home/myheapdump.hprof PID dump 堆内存信息到文件。
  3. 使用visualVM对dump文件进行离线分析,找到占用内存高的对象,再找到创建该对象的业务代码位置,从代码和业务场景中定位具体问题。

5、频繁的年轻代垃圾回收怎么办?

优化Minor GC频繁问题:通常情况下,由于新生代空间较小,Eden区很快被填满,就会导致频繁Minor GC,因此可以通过 增大新生代空间-Xmn来降低 Minor GC的频率

6、频繁的整堆垃圾回收(full GC)怎么办?

Full GC的排查思路大概如下:
1. 清楚从程序角度,有哪些原因导致full GC?
· 大对象:系统一次性加载了过多数据到内存中(比如SQL查询未做分页),导致大对象进入了老年代。
· 内存泄漏:频繁创建了大量对象,但是无法被回收(比如IO对象使用完后未调用close方法释放资源),先引发full GC,最后导致OOM.
· 程序频繁生成一些长生命周期的对象,当这些对象的存活年龄超过分代年龄时便会进入老年代,最后引发full GC。
· 程序BUG
· 代码中显式调用了gc方法,包括自己的代码甚至框架中的代码。
· JVM参数设置问题:包括总内存大小、新生代和老年代的大小、Eden区和S区的大小、元空间大小、垃圾回收算法等等。

2. 清楚排查问题时能使用哪些工具?
JDK 的自带工具,包括jmap、jstat等常用命令:

# 查看堆内存各区域的使用率以及GC情况
jstat -gcutil -h20 pid 1000
# 查看堆内存中的存活对象,并按空间排序
jmap -histo pid | head -n20
# dump堆内存文件
jmap -dump:format=b,file=heap pid

可视化的堆内存分析工具:JVisualVM、MAT等

3. 排查指南
· 查看监控,以了解出现问题的时间点以及当前full GC的频率(可对比正常情况看频率是否正常)
· 了解该时间点之前有没有程序上线、基础组件升级等情况。
· 了解JVM的参数设置,包括:堆空间各个区域的大小设置,新生代和老年代分别采用了哪些垃圾收集器,然后分析JVM参数设置是否合理。
· 再对步骤1中列出的可能原因做排除法,其中元空间被打满、内存泄漏、代码显式调用gc方法比较容易排查。
· 针对大对象或者长生命周期对象导致的full GC,可通过 jmap -histo 命令并结合dump堆内存文件作进一步分析,需要先定位到可疑对象。
· 通过可疑对象定位到具体代码再次分析,这时候要结合GC原理和JVM参数设置,弄清楚可疑对象是否满足了进入到老年代的条件才能下结论。

7、内存泄漏和内存溢出如何排查?

内存泄漏是内在病源,外在病症表现可能有:(内存泄漏可能导致内存溢出,排查步骤和内存泄漏类似)

  • 应用程序长时间连续运行时性能严重下降。
  • CPU使用率飙升,甚至到100% 。
  • 频繁Full GC,各种报警,例如接口超时报警等。
  • 应用程序抛出OutOfMemoryError错误。
  • 应用程序偶尔会耗尽连接对象。

严重内存泄漏往往伴随频繁的Full GC,所以分析排查内存泄漏问题首先还得从查看Full GC入手。主要有以下操作步骤:

  1. 使用 jps 查看运行的 Java 进程 ID
  2. 使用 top -p [pid] 查看进程使用 CPU 和 MEM 的情况
  3. 使用 top -Hp [pid] 查看进程下的所有线程占 CPU 和 MEM 的情况
  4. 将线程 ID 转换为 16 进制:printf "%x\n" [pid],输出的值就是线程栈信息中的 nid。
  5. 抓取线程栈:jstack 29452 > 29452.txt,可以多抓几次做个对比。
  6. 使用 jstat -gcutil [pid] 5000 10 每隔 5 秒输出 GC 信息,输出 10 次,查看 YGC 和 Full GC 次数。通常会出现 YGC 不增加或增加缓慢,而 Full GC 增加很快。或使用 jstat -gccause [pid] 5000 ,同样是输出 GC 摘要信息。或使用 jmap -heap [pid] 查看堆的摘要信息,关注老年代内存使用是否达到阀值,若达到阀值就会执行 Full GC。
  7. 如果发现 Full GC 次数太多,就很大概率存在内存泄漏了
  8. 使用 jmap -histo:live [pid] 输出每个类的对象数量,内存大小(字节单位)及全限定类名。
  9. 生成 dump 文件,借助工具分析哪个对象非常多,基本就能定位到问题在那了。
  10. dump 文件分析
    可以使用 jhat 命令分析:jhat -port 8000 29471.dump,浏览器访问 jhat 服务,端口是 8000。或使用第三方式具分析的,如 JProfiler 也是个图形化工具,GCViewer 工具。Eclipse 或以使用 MAT 工具查看。或使用在线分析平台 GCEasy。
  11. 在 dump 文析结果中查找存在大量的对象,再查对其的引用。

你可能感兴趣的:(Java学习乐园,jvm,java,开发语言)