【死磕JVM】看完这篇我也会排查JVM内存太高了 就是玩儿!

前言

CPU 是时分的,操做系统里面有不少线程,每一个线程的运行时间由CPU决定,CPU会分给每个线程一个时间片,时间片是一个很短的时间长度,若是在时间片内,线程一直占有,就是100%,咱们应该意识到,CPU运行速度很快(主频很是高),除非是密集型耗费CPU的运算,其余类型的任务都会在小于时间片的时间内结束。java

内存太高通常有两种状况:内存溢出和内存泄露面试

  • 内存溢出: 程序分配的内存超过物理机的内存大小,致使没法继续分配内存,出现OOM报错
  • 内存泄露: 再也不使用的对象一直占据着内存不释放,致使这块内存浪费掉,长此以往,内存泄露的对象堆积起来,也会致使物理机的内存被耗尽,出现OOM报错

具体操做

如何监控JVM,咱们能够经过一个案例在了解一些实际当中的操做,你们能够看到下面的代码,下面的代码只是模拟了当中的一个场景,一个风险控制的场景,通常银行或者第三方公司在向一我的发放贷款的时候,会调用这我的的征信已经还款能力,给出响应的评级。服务器

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class FullGCTest {


    //模拟银行卡的类
    private static class CardInfo {
        //小农的银行卡信息记录
        BigDecimal price = new BigDecimal(10000000.0);
        String name = "牧小农";
        int age = 18;
        Date birthdate = new Date();

        public void m() {}
    }

    //线程池 定时线程池
    //50个,而后设置 拒绝策略
    private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,
            new ThreadPoolExecutor.DiscardOldestPolicy());

    public static void main(String[] args) throws Exception {
        executor.setMaximumPoolSize(50);

        for (;;){
            modelFit();
            Thread.sleep(100);
        }
    }

    /** * 对银行卡进行风险评估 */
    private static void modelFit(){
        List<CardInfo> taskList = getAllCardInfo();
        //拿出每个信息出来
        taskList.forEach(info -> {
            // do something
            executor.scheduleWithFixedDelay(() -> {
                //调用M方法
                info.m();

            }, 2, 3, TimeUnit.SECONDS);
        });
    }

    private static List<CardInfo> getAllCardInfo(){
        List<CardInfo> taskList = new ArrayList<>();
        //每次查询100张卡出来
        for (int i = 0; i < 100; i++) {
            CardInfo ci = new CardInfo();
            taskList.add(ci);
        }

        return taskList;
    }
}
复制代码

程序的设计其实比较简单,就是咱们用信用卡的案例来进行说明,好比CardInfo就是信用卡类,咱们把这我的对应的信用卡的记录都调用出来,以后作一些本身响应的业务处理方法来对它进行处理和计算,来看看咱们这个模型是否符合modelFit,具体怎么作呢,在应用程序中有一个类是CardInfo,有一个方法叫作getAllCardInfo,每次都是拿100个出来,拿100个以后用线程池作计算,线程池用的是ScheduledThreadPoolExecutor (定时任务),new出来线程池以后,50个线程池,而后作对应的业务逻辑处理,会调用 modelFit(),使用100毫秒模拟业务的停顿。markdown

首先咱们须要使用javac 命令将Java文件进行编译 javac FullGCTest.java进行编译,而后打印GC日志,进行风险监控多线程

打印GC日志:java -Xms200M -Xmx200M -XX:+PrintGC FullGCTest运维

在这里插入图片描述

怎么知道JVM内存太高?

在公司里面,若是遇到了JVM内存太高的状况,那么通常是运维团队首先受到报警信息,而后通知对应的开发人员去查看,那么开发人员应该如何查看,或者怎么样去排查呢?jvm

一、top 查看进程

受到报警信息后,拿top命令去查询ide

[root@root ~]# top 在这里插入图片描述工具

查看内存不断增加,CPU占用率居高不下的。top后你会看到它的PID(31061)。它占比比较高。测试

二、top -Hp 查看线程

找到CPU占用比较高的进程PID,这里咱们以 java 的进程为例 使用命令 top -Hp 31061,这个时候它会把这个进程里面全部的线程所有线程都罗列出来吗,这些都是Java这个进程里面内部的一些线程,以下图所示:

在这里插入图片描述

咱们会看到每一个线程的占比都差很少,偶尔会有某一个线程比较高,在某些线程占得比较高的时候,这个小例子最终会是垃圾回收的线程占得比较高,由于垃圾回收不过来了,因此须要不停的来回回收,每次都回收一点点,实际这种例子里面很是有多是你业务逻辑线程,那一块的业务逻辑线程占比很是高,这是时候就须要用到另外的命令——jstack

三、jstack

当咱们使用 top -Hp 知道了是哪一个线程后,咱们下一步就可使用 jstack 命令,好比咱们要查看31083这个线程号,31061是咱们的进程PID,咱们要定位某一个线程cpu的占比会比其余cpu高不少,那么咱们就要定位这个线程里面究竟是什么样的问题的时候,就须要把这个线程号(31083)记下来。

由于 jstack 用到的线程号是16进制的,因此咱们须要把31083的10进制转换成16进制才能够

特色:

  • 每一个线程有本身的线程号码,里面有线程的状态,能够观察线程是否阻塞,若是长时间的wait和block说明这个线程是有问题的

四、转换16进制

由于Java线程文件中的线程ID是16进制,因此须要将线程ID从十进制转换成十六进制 命令:echo "obase=16;31083" | bc 在这里插入图片描述

五、jstack用法解析

[root@root ~]# jstack
Usage:
    jstack [-l] <pid>
        (to connect to running process)
    jstack -F [-m] [-l] <pid>
        (to connect to a hung process)
    jstack [-m] [-l] <executable> <core>
        (to connect to a core file)
    jstack [-m] [-l] [server_id@]<remote server IP or hostname>
        (to connect to a remote debug server)

Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung) -m to print both java and native frames (mixed mode) -l long listing. Prints additional information about locks -h or -help to print this help message 复制代码

六、jstack查看输出

咱们也能够用 jps或者java ps -ef| java来查看Java进程,这里咱们用jps来查看

[root@root ~]# jps

在这里插入图片描述 [root@root ~]# jstack 31061

"pool-1-thread-3" #10 prio=5 os_prio=0 tid=0x00007f3568105800 nid=0x7961 waiting on condition [0x00007f35455cf000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

"pool-1-thread-2" #9 prio=5 os_prio=0 tid=0x00007f3568103800 nid=0x7960 waiting on condition [0x00007f35456d0000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

"pool-1-thread-1" #8 prio=5 os_prio=0 tid=0x00007f3568102000 nid=0x795f waiting on condition [0x00007f35457d1000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007f35680b4000 nid=0x795d runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f35680b1000 nid=0x795c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f35680af000 nid=0x795b waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f35680ad800 nid=0x795a runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f356807c800 nid=0x7959 in Object.wait() [0x00007f3558301000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f3568077800 nid=0x7958 in Object.wait() [0x00007f3558402000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007f3568009800 nid=0x7956 waiting on condition [0x00007f356ed59000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at FullGCTest.main(FullGCTest.java:35)

"VM Thread" os_prio=0 tid=0x00007f356806e000 nid=0x7957 runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007f35680b7000 nid=0x795e waiting on condition 

JNI global references: 205
复制代码

在这里插入图片描述 经过thread dump分析线程状态

大多数状况下会基于thead dump 分析当前各个线程的运行状况,如是否存在死锁,是否存在一个线程长时间持有锁不释放等等

在dump中,线程通常存在以下几种状态: 一、RUNNABLE,线程处于执行中 二、BLOCKED,线程被阻塞 三、WAITING,线程正在等待

locked <0x000000076bf62208>说明线程 对地址为0x000000076bf62208对象进行了加锁; waiting to lock <0x000000076bf62208> 说明线程 在等待地址为0x000000076bf62208对象上的锁; waiting for monitor entry [0x000000001e21f000]说明线程 是经过synchronized关键字进入了监视器的临界区,并处于"Entry Set"队列,等待monitor; waiting on <0x0000000088ca3310> (a java.lang.Object)等待锁的释放

假若有一个进程中有100个线程,不少线程都在waiting on 某一把锁,而后线程不应阻塞的被阻塞了,该结束的没结束掉,必定要找到哪一个线程持有这把锁 ,咱们能够搜索 jstack dump 的信息,找到<0X...>的信息,看哪一个线程只有了这把锁,通常这个线程状态是RUNNABLE,表示这个线程正在运行可是一直持有这把锁不释放,那么就会致使整个线程的死锁

七、jstack分析死锁

public class TestDeadLock {

    private static Object obj1 = new Object();
    private static Object obj2 = new Object();

    public static void main(String[] args) {
        new Thread(new Thread1()).start();
        new Thread(new Thread2()).start();
    }

    private static class Thread1 implements Runnable {
        @Override
        public void run() {
            synchronized (obj1) {
                System.out.println("Thread1 拿到了 obj1 的锁!");
                try {// 停顿2秒的意义在于,让Thread2线程拿到obj2的锁
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (obj2) {
                    System.out.println("Thread1 拿到了 obj2 的锁!");
                }
            }
        }
    }


    private static class Thread2 implements Runnable {
        @Override
        public void run() {
            synchronized (obj2) {
                System.out.println("Thread2 拿到了 obj2 的锁!");
                try {
                    // 停顿2秒的意义在于,让Thread1线程拿到obj1的锁
                    Thread.sleep(2000);
                } catch (Exception e) {
                    e.printStackTrace();
                }
                synchronized (obj1) {
                    System.out.println("Thread2 拿到了obj1的锁!");
                }
            }
        }
    }

}

复制代码

在这里插入图片描述 经过命令查看分析日志

[root@root fuccGC]# jps
485 Bootstrap
9877 Jps
10629 QuorumPeerMain
9846 TestDeadLock
[root@root fuccGC]# jstack 9846
复制代码

在这里插入图片描述

内存监控工具的使用

咱们可使用jvm自带的命令去进行监控GC的信息: jinfo pid: 这个命令就是把这个进程的一些详细信息列出来 [root@root ~]# jinfo 9846 这个只是有帮助,可是帮助不是特别大,你们只要记住有这个命令就行,不作深刻了解 在这里插入图片描述 jstat -gc pid 1000: 这个就是每一秒钟将GC的日志打印出来,动态 观察GC状况/阅读GC日志发现频繁GC等等,可是这个信息看起来不是很直观,可以分析出来的东西也很少,因此通常使用的也不是不少 在这里插入图片描述

咱们用的最多的仍是经过工具去查看,好比 jconsole/jvisualvm

一、 jconsole

这两个是JDK自带的一个工具,也是 一个图形界面的工具,只要你装了JDK就有这两个工具,能够从本机去跟踪远程服务器上的一个进程,做为Linux服务器,不多有人会装图形界面,以下图所示: 在这里插入图片描述

在咱们程序启动的时候要加入参数:

java -Djava.rmi.server.hostname=101.XX.XXX.XX -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.rmi.port=8080 FullGCTest
复制代码

在这里插入图片描述

在这里插入图片描述

基本状况以下,咱们就能够监控到咱们远程服务器上面的内存信息 在这里插入图片描述

二、 jvisualvm

双击 jvisualvm 在这里插入图片描述

选择远程-点击文件按钮

在这里插入图片描述 选择添加JMX链接 在这里插入图片描述 输入咱们的地址和帐号密码就能够登陆了 在这里插入图片描述

这样就能够查看咱们远程服务的内存信息了 在这里插入图片描述

在这里插入图片描述 在这里咱们就知道怎么定位问题了,哪个类占用了多少内存,就会显示出来,点击抽样器,内存,以后就会对远程的那台机器的JAVA进程内存,在图形化界面中显示,有多少个类,占用了多少个字节,这样咱们就能够具体定位到是哪一个类有问题了

面试中如何回答定位内存溢出(OOM)

若是面试官咱们如何定位OOM的问题,可是咱们不能回答用图形界面,由于做为一个服务来说,在不断的运行,当咱们开一个JMX服务的时候,会形象服务原本的运行效率,那咱们已经上线的系统不用图形化用什么?还有一个叫Jprofiler是最好用的图形界面,可是这个是收费的,因此通常用不到,

若是不用图形界面那咱们用什么,咱们能够用 cmdline、arthas这两个 图形界面用在什么地方呢?用在测试上,测试的时候进行监控~

若是已经上线的项目,咱们不用图形界面能够用什么呢?咱们能够用Jmap

jmap

[root@root ~]# jmap -histo 19086 | head -20 在这里插入图片描述 它就会把咱们的内存信息打印出来,虽然没有图形化界面方便,可是里面的信息也足够咱们去观察和定位问题了

线上系统,内存特别大,jmap执行期间会对进程产生很大影响,甚至卡顿(电商不适合)

  1. 设定了参数HeapDump,OOM的时候会自动产生堆转储文件(java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError FullGCTest)
  2. 不少服务器备份(高可用),停掉这台服务器对其余服务器不影响
  3. 下期讲解,哈哈哈

今天的JVM课程就到这里了,原创不易,你们记得一键三连~,点赞/收藏过百,我就是怀双胞胎也出下一篇。

我是牧小农,怕什么真理无穷,进一步有进一步的欢喜,你们加油!!!

相关文章
相关标签/搜索