• JVM--心得 OOM时的堆信息获取与分析


    JVM的框架知识了解之后,实际的项目里发生了OOM异常的话,怎么获取以及分析异常信息后怎么分析呢。
    这里稍微做一下归纳。
    第一步,首先通过下面两个方法的任何一种,把发生OOM时的heap信息dump下来。
    有两个方法,通过设置可以把OOM时的dump信息获取到:
    1)方法1:在JVM的启动参数里添加如下命令
    -XX:+HeapDumpOnOutOfMemoryError

    2)方法2:在JDK的安装目录下,找到bin目录,然后双击执行"jvisualvm.exe"
    执行程序之后,在视图里可以看到正在执行的java程序和Java线程ID(PID:xxx)。
    右键选中"在OOM时生成dump"。

    第二步,执行如下代码(本例使用方法1。如果使用方法2时需要先执行代码,再在JvirtualVM中选中java程序设置OOM时生成dump):
    代码的意义是每一次创建一个1*1024*1024大小的int数组。在While中循环,引起Heap的OutOfMemory异常发生。
    有一个小知识点共享下,map进行containsKey的处理时,key如果是javabean对象,判断时使用的是对象的引用。所以每次判断都是新的对象。
    最好key的数据类型定义为值类型等(String作为key时使用常量字符串对String赋值如String key ="key",不要用String key = new String(“key”)的形式,这样又变成了一个引用对象了)。
    ---------------------------------------------------
    package com.chong.studyparalell.jvm.heap;

    import java.util.HashMap;
    import java.util.Map;

    public class HeapLeakage {

    static class MapKey{
    Integer key;
    MapKey(Integer key){
    this.key = key;
    }
    }

    public static void main(String []args){

    Map<MapKey,Integer[]> localMap = new HashMap();
    while(true){
    for(int i = 0;i<10;i++){
    try{
    Thread.sleep(100);
    }catch(Exception e){
    e.printStackTrace();
    }
    MapKey mapKey = new MapKey(new Integer(i));
    if(!localMap.containsKey(mapKey)){
    localMap.put(mapKey, new Integer[1*1024*1024]);
    }
    }
    }
    }
    }
    -------------------------------------------------
    日志如下:
    JAVAGENT: call premain instrumentation for class SizeOf
    java.lang.OutOfMemoryError: Java heap space
    Dumping heap to java_pid31512.hprof ...
    Heap dump file created [491663234 bytes in 0.930 secs]
    Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at com.chong.studyparalell.jvm.heap.HeapLeakage.main(HeapLeakage.java:38)
    -------------------------------------------------
    第三步,在项目的classpath目录下确认"java_pidXXX.hprof"文件是否存在,正常情况下应该存在的。
    在jvirtualvm中,点击"文件"->"装入"->选中上述hprof文件。
    点击“类”tab页,通过"大小"排序,可以看出java.lang.Integer占用了99%以上的空间。
    双击这一行,可以进入进去看到,各个Integer的具体内容。这里的目的是发生OOM,所以Integer的内容没有设值,进去可以发现值都是null。

    那么实际的项目里,可以观看发生问题线程里哪些对象的一直是活着的,并且size远远超出预期,重点分析这些可疑对象。推测的方向:是否在循环里大量的实例化对象,加载DB数据时一次加载了大量的数据,以及是否发生了内存泄露(如长生命周期的Map和Set,List中一直保存在大量的不再使用的对象引用。),以及静态变量的使用等。

    后记:
    通过这几天的JVM复习,以及OOM发生时的dump分析,再次做项目时,头脑会更清晰一些。^-^
    JVM告一段落了,接下来会发一些跟SpringBoot和Redis相关的学习心得。

  • 相关阅读:
    sqlalchemy
    tornado-模板继承extend,函数和类的导入
    vi规范
    Spark 分布式SQL引擎
    Spark SQL 编程
    Spark SQL 基本原理
    spark SQL概述
    spark 多语言编程
    hadoop YARN
    spark 存储管理机制
  • 原文地址:https://www.cnblogs.com/chongpf/p/7677973.html
Copyright © 2020-2023  润新知