一文理清JVM和GC（下）

时间  2020-04-11
标签 一文 理清 jvm 栏目 Java 繁體版
原文   原文链接

他来了他来了，他带着JVM下篇走来了。并承诺看完还理不清JVM，大家大胆骂他菜鸡（嘴下留情哥哥们）

本文主要介绍JVM和GC解析
本文较长，分为上下篇（可收藏，勿吃尘）
若有须要，能够参考
若有帮助，不忘 点赞 ❥java

一文理清JVM和GC上篇linux

1、上篇接入

1）OOM的认识

  • StackOverflowError
 public static void main(String[] args) {
       stackOverflowError();   //Exception in thread "main" java.lang.StackOverflowError
   }
    private static void stackOverflowError() {
       stackOverflowError();
    }
复制代码
  • OutOfMemeoryError：java heap space
public static void main(String[] args) {
        String str = "cbuc";
        for (; ; ) {
            str += str + UUID.randomUUID().toString().substring(0,5);   //+= 不断建立对象
        }
    }
复制代码
  • OutOfMemeoryError：GC overhead limit exceeded

程序在垃圾回收上花费了98%的时间，却收集不会2%的空间。
加入不抛出GC overhead limit ，会形成：
1. GC清理的一点点内存很快会再次填满，迫使GC再次执行，这样就造成了恶性循环。
2. CPU的使用率一直是100%，而GC却没有任何成果ios

-.-
-.-
  • OutOfMemeoryError：Direct buffer memory
  • 写NIO程序常用 ByteBuffer 来读取或者写入数据，这是一种基于通道（Channel）和缓冲区（Buffer）的 I/O 方式，它可使用 Native 函数库直接分配堆外内存，而后经过一个存储在Java 堆里面的DirectByteBuffer 对象做为这块内存的引用进行操做。这样能在一些场景中显著提升性能，由于避免了在Java堆和Native堆中来回复制数据。
  • ByteBuffer.allocate(capability) ：这一种方式是分配JVM堆内存，属于GC管辖范围，因为须要拷贝因此速度相对较慢。
  • ByteBuffer.allocateDirect(capability)：这一种方式是分配OS本地内存，不属于GC管辖范围，因为不须要内存拷贝，因此速度相对较快。
  • 可是若是不断分配本地内存，堆内存不多使用，那么JVM就不须要执行GC，DirectByteBuffer 对象就不会被回收，这时候堆内存充足，但本地内存可能就已经使用光了，再次尝试分配本地内存就会出现OutOfMemeoryError，那程序就直接奔溃了。
public static void main(String[] args) {
        /**
         * 虚拟机配置参数
         * -Xms10m -Xmx10m -XX:+PrintGCDetails  -XX:MaxDirectMemorySize=5m
         * */
        System.out.println("配置的maxDirectMemeory："+(sun.misc.VM.maxDirectMemory()/(double)1024/1024)+"MB");
        try {TimeUnit.SECONDS.sleep(3);} catch (InterruptedException e) {e.printStackTrace();}
        // -XX:MaxDerectMemorySize=5m  配置为5m, 这个时候咱们使用6m
        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(6*1024*1024);

    }
复制代码
  • OutOfMemeoryError：unable to create new native thread

高并发请求服务器是，常常会出现该异常
致使缘由web

  1. 你的应用建立了太多线程了，一个应用进程建立多个线程，超过系统承载权限。
  2. 你的服务器并不容许你的应用程序建立这么多线程，linux系统默认容许的那个进程能够建立的线程数时1024个，你的应用建立超过这个数量就会报OutOfMemeoryError：unable to create new native thread

解决办法算法

  1. 想方法减低你应用程序建立线程的数量，分析应用是否真的须要建立那么多线程，若是不是，改代码将线程数降到最低。
  2. 对于有点应用，确实须要建立不少线程，远超过linux系统默认1024个线程的限制，能够经过修改linux服务器配置，扩大linux默认限制
public static void main(String[] args) {
        for (int i = 1;  ; i++) {
            System.out.println("输出 i： " + i);
             new Thread(()->{
                 try {TimeUnit.SECONDS.sleep(Integer.MAX_VALUE);} catch (InterruptedException e) {e.printStackTrace();}
             },"线程"+i).start();
        }
    }
复制代码
  • OutOfMemeoryError：Metaspace

Java 8以后的版本使用Metaspace来替代永久代
Metaspace是方法区在HotSpot中的实现，它与持久带最大的区别在于：Metespace并不在虚拟机内存中而是使用本地内存
永久代（java8 后被原空间Metaspace取代了）存放了如下信息：服务器

  • 虚拟机加载的类信息
  • 常量池
  • 静态常量
  • 即时编译后的代码

2）4种垃圾收集器

  • GC算法（引用计数/复制/标清/标整）是内存回收的方法，垃圾收集器就是算法的实现
  • 目前为止尚未完美的收集器出现，更加没有万能的收集器，只是针对具体应用最合适的收集器，进行分代收集
  • 串行垃圾回收器（Serial）
    它为单线程环境设计而且只是用一个线程进行垃圾回收，会暂停全部的用户线程。因此不适合服务器环境。
  • 并行垃圾回收器（parallel）
    多个垃圾回收线程并行工做，此时用户线程是暂停的，适用于科学计算/大数据处理等弱交互场景
  • 并发垃圾回收器（CMS）
    用户线程和垃圾收集线程同时执行（不必定是并行，可能交替执行），不须要停顿用户线程，适用于对响应时间有要求的场景
  • G1垃圾回收器
    G1垃圾回收器将堆内存分割成不一样的区域而后并发的对其进行垃圾回收

3）垃圾收集器解析

  • 查看默认的垃圾收集器
    java -XX:+PrintCommandLineFlags -version
    网络

    -.-
    -.-

  • 默认的垃圾收集器多线程

    • UseSerialGC
    • UseParallelGC
    • UseConcMarkSweepGC
    • UseParNewGC
    • UseParallelOldGC
    • UseG1GC

  • 新生代并发

    • 串行GC（Serial）/（Serial Coping）
      一个单线程的收集器，在进行垃圾收集的时候，必须暂停其余全部的工做线程知道它收集结束
      -.-
      -.-

      最稳定以及效率高的收集器，只使用一个线程去回收但其在进行垃圾手机过程当中可能会产生较长的停顿（“Stop-The-World”状态）。虽然在收集垃圾过程当中须要暂停全部其余的工做线程，可是它简单高效，对于限定单个CPU环境来讲，没有线程交互的开销能够得到更高的单线程垃圾收集效率， 所以Serial垃圾收集器依然是Java虚拟机运行在Client 模式下默认的新生代垃圾收集器。

    JVM设置参数
    -XX:+UseSerialGC开启后会使用：Serial（Young区用）+Serial Old（Old区用的）收集器组合，
    表示：新生代、老年代都会使用串行回收收集器，新生代使用复制算法，老年代使用标记-整理算法app

    • 并行GC（ParNew）
      使用多线程进行垃圾回收，在垃圾收集时，会Stop-The-World暂停其余全部工做的线程知道它收集结束

      -.-
      -.-

      ParNew收集器其实就是Serial收集器新生代的并行多线程版本，最多见的应用场景是配合老年代的CMS GC工做，其他的行为和Serial收集器彻底同样，ParNew垃圾收集器在垃圾收集过程当中一样也要暂停全部的工做线程。它是不少java虚拟机运行在Server模式下新生代的默认垃圾收集器。

      JVM设置参数
      XX:+UseParNewGC 启用 ParNew收集器，只影响新生代的收集，不影响老年代。开启上述参数后，会使用：ParNew （新生代区用）+Serial Old（老年代区用）策略，新生代使用复制算法，老年代使用标记-整理算法。

    • 并行回收GC（Parallel）/（Parallel Scavenge）

      -.-
      -.-

      Parallel Scavenge收集器相似ParNew 也是新生代垃圾收集器，使用复制算法，也是一个并行的多线程的垃圾收集器，俗称吞吐量优先收集器。串行收集器在新生代和老年代的并行化
      关注点：

    1. 可控制的吞吐量
    2. 自适应调节策略也是ParallelScavenge收集器与ParallelNew收集器的一个重要区别

    JVM设置参数
    -XX:UseParallelGC 或 -XX:UseParallelOldGC（可互相激活），开启后：新生代使用复制算法，老年代使用标记-整理算法。

  • 老年代

    • 串行GC（Serial Old）/（Serial MSC） Serial Old 是Serial 垃圾收集器老年代版本，它一样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在Client默认的java虚拟机默认的年老代垃圾收集器。 用途：
      1. 在JDK1.5以前版本中与新生代的Parallel Scavenge收集器搭配使用。（Parallel Scavenge+Serial Old）
      2. 做为老年代版中使用CMS收集器的后备垃圾收集方案。
    • 并行GC（Parallel Old）/（Parallel MSC）
      Parallel Old收集器是Parallel Scavenge的老年代版本，使用多线程的标记-整理算法，Parallel Old在JDK 1.6以前，新生代使用 ParallelScavenge 收集器,只能保证新生代的吞吐量优先，没法保证总体的吞吐量。在JDK1.6以前（Parallel Scavenge+Serial Old）
      Parallel Old 正是为了在年老代一样提供吞吐量优先的垃圾收集器，若是系统对吞吐量要求比较高，JDK1.8 后能够优先考虑新生代Parallel Scavenge和年老代 Parallel Old收集器的搭配策略。

    JVM设置参数
    -XX:+UseParallelOldGC 开启 Parallel Old收集器，设置该参数后，使用 新生代Parallel + 老年代Parallel Old 策略

    • 并发标记清除GC（CMS）

      优势： 并发收集低停顿
      缺点：

      • 并发执行，对CPU资源压力大：
        因为并发进行，CMS在收集与应用线程会同时会增长对堆内存的占用，也就是说，CMS必需要在老年代堆内存用尽以前完成垃圾回收，不然CMS回收失败时，将触发担保机制，串行老年代收集器将会以STW的方式进行一次GC，从而形成较大停顿时间。
      • 采用的标记清除算法会致使大量碎片：
        标记清除算法没法整理空间碎片，老年代空间会随着应用时长被逐步耗尽，随后将不得不经过担保机制对堆内存进行压缩。CMS也提供了参数-XX:CMSFulllGCsBeForeCompaction（默认0，即每次都进行内存整理）来指定多少次CMS收集以后，进行一次压缩的Full GC。

      关键4步：

      1.Initial Mark （初始标记）： 标记GC Root能够直达的对象，耗时短。

      1. Concurrent Mark（并行标记）： 从第一步标记的对象出发，并发地标记可达对象。
      2. Remark（从新标记）： 从新进行标记，修正Concurrent Mark期间因为用户程序运行而致使对象间的变化及新建立的对象，耗时短。
      3. Concurrent Sweep（并行回收）： 并行地进行无用对象的回收。
        -.-
        -.-

  • 如何选择垃圾收集器

    • 单CPU或小内存，单机程序
      -XX:+UseSerialGC
    • 多CPU，须要最大吞吐量，如后台计算型应用
      -XX:+UseParallelGC
      -XX:+UseParallelOldGC
    • 多CPU，追求低停顿时间，需快速响应如互联网应用
      -XX:+UseConcMarkSweepGC
      -XX:+ParNewGC
      -.-
      -.-

4）G1垃圾收集器

  • 之前垃圾收集器的特色
    1.年轻代和老年代是各自独立且连续的内存块
    2.年轻代中Eden+S0+S1使用复制算法进行收集
    3.老年代收集必须扫描整个老年代区域
    4.都是以尽量少而快速地执行GC为设计原则

  • G1概念

    Garbage-First 收集器，是一款面向服务端应用的收集器

    1. 整理空闲空间更快
    2. 须要更多的时间来预测GC停顿时间
    3. 不但愿牺牲大量的吞吐性能
    4. 不须要更大的Java Heap

    G1收集器的设计目标是取代CMS收集器
    优点：

    1. G1是一个有整理内存过程的垃圾收集器，不会产生不少内存碎片
    2. G1的Stop-The-World (STW)更可控，G1在停顿时间上添加了预测机制，用户能够指按期望停顿时间

    主要改变是Eden，Survivor和Tenured等内存区域再也不是连续的了，而是变成了一个个大小同样的region，每一个region从1M到32M不等。一个region有可能属于Eden，Survivor或者Tenured内存区域。

  • G1特色

    • G1能充分利用多CPU，多核环境硬件优点，尽可能缩短STW。
    • G1总体上采用标记-整理算法，局部是经过复制算法，不会产生内存碎片
    • 宏观上看G1之中再也不区分年轻代和老年代。把内存划分红多个独立的子区域（Region）
    • G1收集器里面讲整个的内存区都混合在一块儿了，但其自己依然在小范围内要进行年轻代和老年代的区分，保留了新生代和老年代。
    • G1虽然也是分代收集器，但整个内存分区不存在物理上的年轻代与老年代的区别，也不须要彻底独立的survivor（to space）堆作复制准备。G1只有逻辑上的分代概念，或者说每一个分区均可能随G1的运行在不一样代之间先后切换。

  • G1底层原理

（1）Region区域化垃圾收集器

区域化内存划片Region，总体编为了一下列不连续的内存区域，避免了全内存区的GC操做。
核心思想： 将整个堆内存区域分红大小相同的子区域（Region），在JVM启动时会自动配置这些子区域的大小。
在堆的使用上，G1并不要求对象的存储必定是物理上连续的只要逻辑上连续便可，每一个分区也不会固定地为某个代服务，能够按需在年轻代和老年代之间切换。启动时能够经过参数 -XX:G1HeapRegionSize=n 可指定分区大小（1MB~32MB，且必须是2的幂），默认将整堆划分为2048个分区。
大小范围在1MB~32MB，最多能设置2048个区域，也即可以支持的最大内存为：32MB*2048=65536MV=64G内存
最大好处就是化整为零，避免全内存扫描，只须要按照区域来进行扫描便可

-.-
-.-

（2）回收步骤

针对Eden区进行收集，Eden区耗尽后会被触发，主要是小区域收集+造成连续的内存块，避免内存碎片

  • Eden区的数据移动到新的Survivor区，部分数据晋升到Old区。
  • Survivor区的数据移动到新的Survivor区，部分数据晋升到Old区。
  • 最后Eden区收拾干净了，GC结束，用户的应用程序继续执行。
    -.-
    -.-

（3）4步过程

  • 初始标记： 只标记GC Roots能直接关联到的对象
  • 并发标记： 进行GC Roots Tracing的过程
  • 最终标记：修正并发标记期间，因程序运行致使标记发生变化的那一部分对象
  • 筛选回收： 根据时间来进行价值最大化的回收
    -.-
    -.-

（4）经常使用配置参数

  • -XX:+UseG1GC
    开启G1垃圾收集器
  • -XX:G1HeapRegionSize=n
    设置G1区域的大小。值是2的幂，范围是1M到32M。目标是根据最小的Java堆大小划分出约2048个区域
  • -XX:MaxGCPauseMillis=n
    最大停顿时间，这是个软目标，JVM将尽量（但不保证）停顿时间小于这个时间
  • -XX:InitiatingHeapOccupancyPercent=n
    堆占用了多少的时候就触发GC，默认是45
  • -XX:ConcGCThreads=n
    并发GC使用的线程数
  • -XX:G1ReservePercent=n
    设置做为空闲时间的预留内存百分比，以下降目标空间溢出的风险，默认值是10%

（5）与CMS相比的优点

1）G1不会产生内存碎片。
2）是能够精确控制停顿，该收集器是把整个堆（新生代、老年代）划分红多个固定大小的区域，每次根据容许停顿的时间去收集垃圾最多的区域。

（6）总结

-.-
-.-

5）诊断生产环境服务器变慢

`（1）整机相关`

  • top
    -.-
    -.-

    前五行是统计信息
    第一行是任务队列信息，同uptime命令的执行结果同样
    17:16:47：当前时间
    up 23:47：系统运行时间
    2 users：当前登陆用户数
    load average:0.21,0.27,0.19：系统负载，既任务队列的平均长度，三个数值分别为1分钟、5分钟、15分钟前到如今的平均值

`（2）CPU相关`

  • vmstat
    -.-
    -.-

    vmstat -n 2 3
    第一个参数是采样的时间间隔数（单位:秒），第二个参数是采样的次数
    主要参数
  • procs
    r： 运行和等待CPU时间片的进程数，原则上1核的CPU的运行队列不要超过2，整个系统的运行队列不能超过总核数的2倍，不然表明系统压力过大。
    b： 等待资源的进程数，好比正在等待磁盘I/O,网络I/O等。
  • cpu
    us： 用户进程消耗CPU时间百分比，us值高，用户进程消耗CPU时间多，若是长期大于50%，须要优化程序
    sy： 内核进程消耗的CPU时间百分比
    us + sy 参考值为80%，若是us + sy 大于80%，说明可能存在CPU不足
    id： 处于空闲CPU百分比
    wa： 系统等待IO的CPU时间百分比
    sy： 来自于一个虚拟机偷取的CPU时间的百分比
  • mpstat
    mpstat -P ALL 2
    查看CPU核信息
    -.-
    -.-
  • pidstat
    pidstat -u 1 -p 进程号
    每一个进程使用cpu的用量分解信息

`（3）内存相关`

  • free
    应用程序中可用内存/系统物理内存>70%内存充足
    应用程序可用内存/系统物理内存<20% 内存不足须要增长内存
    20%<应用程序可用内存/系统物理内存<70% 内存基本够用
    -.-
    -.-

`（4）硬盘相关`

  • df
    查看磁盘剩余空闲数
    -.-
    -.-

`（5）硬盘IO相关`

  • iostat -xdk 2 3
    -.-
    -.-

6）分析生产环境CPU占用太高

  • 步骤1：
    先用top命令找出CPU占比最高的
  • 步骤2：
    ps -ef 或者 jps 进一步定位，得知是一个怎样的后台程序
  • 步骤3：
    定位到具体线程或者代码
    ps -mp 进程 -o THREAD,tid,time

-o：该参数是用户自定义格式
-p：pid进程使用cpu的时间
-m : 显示全部线程

  • 步骤4：
    将须要的线程ID转换为16进制格式（英文小写格式）
    再使用：printf "%x/\n" 有问题的线程ID
  • 步骤5：
    jstat 进程ID | grep tid（16进制线程ID小写英文）

7）经常使用的JVM监控和性能分析工具

  • jps（虚拟机进程情况工具）
  • jinfo（Java配置信息工具）
  • jmap（内存映像工具）
  • jstat（统计信息监控工具）
看完不赞，都是坏蛋
看完不赞，都是坏蛋

本文较长，能看到这里的都是好样的，成长之路学无止境
今天的你多努力一点，明天的你就能少说一句求人的话！
好久好久以前，有个传说，听说：
看完不赞，都是坏蛋

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程