# 使用OQL分析虚拟机内存 本章作为书第一章的补充，较为详细说明了如何进行内存分析以解决因为内存使用过多导致的性能降低以及内存溢出现象。有些非内存故障问题，页可以通过OQL来分析对象在内存中使用情况，查看对象运行时刻的属性值。 ## 获取内存镜像文件 当应用系统性能不佳的时候，我们在第一章介通过 jvisualvm的抽样器定位性能瓶颈外，系统性能不佳还可能是虚拟机频繁的全局垃圾回收导致。 导入本节附带工程OQL后，可以直接运行OutMemoryCase1方法，该方法会不断的向Map里添加User实例，直到内存用满为止 ~~~java public class OutMemoryCase1 { static Map<Long,User> map = new HashMap<>(); static long idBase = 0; static Config config = new Config(); static public void test() { config.setMax(1000); config.setSleep(100); for(int i=0;i<config.getMax();i++){ User user = new User(); user.setId((long)idBase); user.setName("user"+idBase); user.setDepartId((long)idBase); map.put(user.getId(),user); idBase++; } } public static void main(String[] ags) throws InterruptedException { while(true){ test(); Thread.sleep(config.getSleep()); System.out.println(config.getMessage()+idBase); } } } ~~~ test方法会循环运行1万次，像类变量map添加User实例，main方法则不断循环运行test，每循环一次，会打印idBase变量。 User对象是一个POJO，包含了id，departId，和name属性，定义如下 ~~~java public class User { private Long id ; private Long departId ; private String name; //忽略getter和setter } ~~~ Config对象如下定义，包含了循环，休眠等配置信息 ~~~java public class Config { private int max =100; private int sleep = 10; private String message = ">"; //忽略getter和setter } ~~~ 运行OutMemoryCase1方法后，我们可以使用jdk命令jps 获取进程编号 ~~~ >jps -ml 914 com.ibeetl.code.OutMemoryCase1 957 sun.tools.jps.Jps -ml ~~~ 然后我们使用jdk的jstat命令观察内存使用情况 ~~~ jstat -gcutil -h 20 914 2000 0 ~~~ - -gcutil 表示输出内存使用汇总信息。 - -h 表示没输出20行，再打印一次表头 - 914是我们需要监控的虚拟机进程ID，使用需要用实际进程id代替 - 2000表示每2000毫秒输出一行信息 - 最后一个参数 0 表示一直输出，如果填写其他数字n，则最多输出n行  上图显示了虚拟机各个代的使用情况,描述了堆内存的各个占比和垃圾回收次数以及占用时间 * S0,第一个幸存区使用比率 * S1，第二个幸存区的使用率 * E，伊甸园区的使用比率 * O 老年代 * M 方法区，元空间使用率 * CCS,压缩使用比率 * YGC 年轻代垃圾回收次数 * YGCT 年纪带垃圾回收占用时间 * FGC 全局垃圾回收次数，这对性能影响至关重要 * FGCT 全局垃圾回收的消耗时间 * GCT 总得垃圾回收时间 关于虚拟机的内部结构和垃圾回收机制，超出了本书的范畴，这里做一些简要描述，我们只需要关注一些异常情况。 Java虚拟机中，对象的生命周期有长有短，大部分对象的生命周期很短，只有少部分的对象才会在内存中存留较长时间，因此可以依据对象生命周期的长短将它们放在不同的区域。在采用分代收集算法的Java虚拟机堆中，一般分为三个区域，用来分别储存这三类对象： 新生代 - 刚创建的对象，在代码运行时一般都会持续不断地创建新的对象，这些新创建的对象有很多是局部变量，很快就会变成垃圾对象。这些对象被放在一块称为新生代的内存区域。新生代的特点是垃圾对象多，存活对象少。 在新生代区域中，按照8:1:1的比例分为了Eden、SurvivorA、SurvivorB三个区域。其中Eden意为伊甸园，形容有很多新生对象在里面创建；Survivor区则为幸存者，即经历GC后仍然存活下来的对象。 Eden区对外提供堆内存。当Eden区快要满了，则进行Minor GC(新生代GC)，把存活对象放入SurvivorA区，清空Eden区； Eden区被清空后，继续对外提供堆内存； 当Eden区再次被填满，此时对Eden区和SurvivorA区同时进行Minor GC(新生代GC)，把存活对象放入SurvivorB区，此时同时清空Eden区和SurvivorA区； Eden区继续对外提供堆内存，并重复上述过程，即在 Eden 区填满后，把Eden区和某个Survivor区的存活对象放到另一个Survivor区； 当某个Survivor区被填满，且仍有对象未被复制完毕时，或者某些对象在反复Survive 15次左右时，则把这部分剩余对象放到老年代区域；当老年区也被填满时，进行Major GC（老年代GC），对老年代区域进行垃圾回收。 老年代 - 一些对象很早被创建了，经历了多次GC也没有被回收，而是一直存活下来。这些对象被放在一块称为老年代的区域。老年代的特点是存活对象多，垃圾对象少。 永久代 - 一些伴随虚拟机生命周期永久存在的对象，比如一些静态对象，常量等。这些对象被放在一块称为永久代的区域。永久代的特点是这些对象一般不需要垃圾回收，会在虚拟机运行过程中一直存活。（在Java1.7之前，方法区中存储的是永久代对象，Java1.7方法区的永久代对象移到了堆中，而在Java1.8永久代已经从堆中移除了，这块内存给了元空间。 从jstat的输出可以看到，老年代已经使用了99.9%，FGC一直在不停的增长，说明内存几乎已经占满，正常情况应该很难观察到一次FGC发生。从控制台的打印输出来看 ~~~ ....... 9320000 9330000 9340000 ~~~ 系统输出已经停滞在9340000值（在此是作者本人机器上运行结果，实际结果不一定是这个值），这代表此时系统执行已经非常缓慢了，这就是因为虚拟机频繁的全局垃圾回收导致的。 如果你不了解oql工程，没有看过代码OutMemoryCase1 如何诊断此时系统是哪一处代码出问题了呢，思路实获取内存的dump文件，然后通过OQL，一种类似SQL的分析语句分析内存dump文件，定位问题代码。 有多种方式获取到内存dump文件： 通过jmap 命令主动获取到 ~~~ jmap -dump:format=b,file=filename.hprof pid ~~~ 实际系统会有2G到8G内存，此命令会导致虚拟机暂停1-3秒时间，并生成指定filename的dump文件 还有一种是被动获取方式，当虚拟机出现内存溢出的时候，会主动dump内存文件。添加虚拟机启动参数 ~~~ -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof ~~~ 会有如下输出 ~~~ >9454000 >9455000 java.lang.OutOfMemoryError: Java heap space Dumping heap to heapdump.hprof ... ~~~ 通过打开jvisualvm也可以获取到堆dump文件，在左侧进程列表里找到该进程，右键，点击选项“堆 dump”，保存内存镜像文件 无论那种方式，我们都会获取到内存dump文件，我们下一节，将使用jvisualvm分析，主要使用OQL功能分析内存使用情况，定位系统问题 ## OQL 查询语言 打开jvisualvm工具，选择菜单File，点击装入，选择我们保存过的dump文件，这时候jvisualvm面板会打开内存镜像文件。打开较大的内存镜像文件需要较长的时间，需要耐心等候  有一个“类按钮”可以进入类实例使用汇总页面，一个OQL控制台会进入OQL功能，我们点击OQL直接进入OQL控制台  如面板所示，左下角的查询编辑器可以输入OQL语句，从内存中查询，我们输入 ~~~ select x from java.util.HashMap x where x.size>1000 ~~~ 这个OQL语句查询出所有HashMap实例，且其属性size大于1000的，查询结果显示在面板上方。可以点击每个实例进入详情面板，如下图  右上面板是字段面板，包含了选中实例的的所有属性，可以看到，size属性为2百万，是个非常大的数，这代表此时HashMap包含了2百万个对象，如果熟悉HashMap代码，我们知道table属性保存了所有的元素，我们可以点击table属性,向下钻取，可以看到存放的正是User对象。 右下面板是引用面板，根节点为this，表示了我们查询出来的这个HashMap实例，该面板节点每个子节点表示了所属关系，我们可以看到这个HashMap实例的名字是map，属于OutMemoryCase1类。 截至到目前为止，我们已经使用一条OQL语句找到了内存的溢出的原因，且定位到代码位置为OutMemoryCase1。我们下面学习更多的OQL语法，这有助于帮助我们分析内存 OQL语法类似SQL和Javascript结合体，javascript用于表达式和方法调用，格式如下 ~~~ select <JavaScript expression to select> [ from [instanceof] <class name> <identifier> [ where <JavaScript boolean expression to filter> ] ] ~~~ * class name是java类的完全限定名，如：java.lang.String, java.util.ArrayList, [C是char数组, [Ljava.io.File是java.io.File[]，依此类推，insatnceof 关键字用上，表示将查询其子类 * from和where子句都是可选的 * 可以使用identifier.fieldName语法访问Java字段，并且可以使用array [index]语法形式访问数组元素。 * OQL使用的是JS表达式，因此使用&&和||，不要使用and or 比如查找超长的字符串，这里的10000是一个任意指定的值，如下OQL语句查找字符串长度超过1万的。 ~~~java select s from java.lang.String s where s.value.length >= 10000 ~~~ 这里s表示String,查看java.lang.String有个名字为value的char[] 类型的数组，因此filter是s.value.length >= 10000 针对OutMemoryCase1，比如我们要查找user对象中departId为15的User对象，并输出其name属性 ~~~java select u.name from com.ibeetl.code.User u where u.departId.value==15 ~~~ 需要注意的事，User对象的departId类型Long，并非原始类型，因此需要使用Long对象的value属性来比较。另外在OQL里任意实例的都有属性id，是在OQL分配的对象唯一标识，因此，如下OQL语句在jvisualvm执行得不到期望的结果 ~~~ //错误的OQL语句,id属性是内存分配的唯一id，并非用户的id属性 select u.name from com.ibeetl.code.User u where u.id.value==15 ~~~ 如下查询包含key为"abc"的Map,value为"edf"，注意需要使用toString才能比较字符串 ```sql select m from java.util.Map$Entry m where m.key.toString()='abc'&&m.value.toString()='edf' ``` 通过size函数获取实例本身占用的空间，rsize函数获取实例占用的shallow空间，实际使用空间 ~~~ select sizeof(x) from java.util.HashMap x where x.size>1000 select rsizeof(x) from java.util.HashMap x where x.size>1000 ~~~ rsizeof 会计算对象下每一个对象占用空间，因此执行该语句需要较长时间，sizeof仅仅计算此对象属性占用空间。查询出来的对象可以通过objectid函数得到一个16进制编号，可以记住这个唯一编号，在用函数heap.findObject直接定位到该实例 ~~~sql select objectid(x) from com.ibeetl.code.Config //查询返回"31150212072",可以记住下次再分析的时候直接查询该Config对象 select heap.findObject(31150212072) ~~~ OQL提供了一系列的heap方法,用于查找实例,由于附录并非专门讲解OQL，因此列出重要的方法并还是以OutMemoryCase1为例子，说明如何使用 * heap.forEachClass - 为每个Java类调用一个回调函数 ~~~ heap.forEachClass(callback); ~~~ * heap.forEachObject - 为每个Java对象调用回调函数 ~~~ heap.forEachObject(callback, clazz, includeSubtypes); ~~~ 如果clazz未指定，则是默认的java.lang.Object，includeSubtypes表示查找子类，如果未指定，默认是true,callback是一个类似JS的回掉函数. * heap.findClass - 查找给定名称的Java类 * heap.findObject 根据对象标识查询对象 * heap.objects 返回Java对象的枚举 ~~~ heap.objects(clazz, [includeSubtypes], [filter]) ~~~ 比如，我们需要查找某个User对象，其name属性的值是“user1“结尾,我们可以使用js正则表达式查询 ~~~ heap.objects("com.ibeetl.code.User", false, "/user1$/.test(it.name)") //或者 heap.objects ("com.ibeetl.code.User",false,"it.name.toString()=='user1'") ~~~ * heap.livepaths 返回给定对象存活的路径数组。此方法接受可选的第二个参数，它是一个布尔标志。此标志指示是否包含弱引用的路径。默认情况下，不包括具有弱引用的路径。 ~~~ select heap.livepaths(config) from com.ibeetl.code.Config config ~~~ 会有如下输出，我们可以看到Config对象被OutMemoryCase1引用 ~~~ com.ibeetl.code.Config#1->com.ibeetl.code.OutMemoryCase1->sun.launcher.LauncherHelper ~~~ OQL提供了一些对集合操作的方法，允许查询出来的结果集，进行过滤和加工，一些常用的函数如下 * filter filter函数返回一个数组/枚举，其中包含满足给定布尔表达式的输入数组/枚举的元素。布尔表达式代码可以引用以下内置变量。it - >目前访问过的元,index - >当前元素的索,array - >正在迭代的数组/枚举,result - > result array / enumeration 如查询User对象，name属性为“user1” ~~~ select filter(heap.objects ("com.ibeetl.code.User"), "it.name.toString()=='user1'") ~~~ 或者使用回调函数 ~~~javascript select filter(heap.objects ("com.ibeetl.code.User"), function(it){ if(it.name.toString()=='user1'){ return true; }else{ return false; } }) ~~~ * map 通过评估每个元素上的给定代码来转换给定的数组/枚举。评估的代码可以引用以下内置变量。it - >目前访问过的元,index - >当前元素的索,array - >正在迭代的数组/枚举,result - > result array / enumeration map函数返回通过在输入数组/枚举的每个元素上重复调用代码而创建的值的数组/枚举。 ~~~javascript select map(heap.objects('com.ibeetl.code.User'), function (it) { var res = objectid(it); res+=">"+toHtml(it); return res ; }) ~~~ 此例子通过heap.objects查询所有的User实例，返回数组，并传入map方法，map将每个User实例 转化为一个字符串，包含了User实例的唯一编号，toHtml方法是OQL自带的一个方法，接受一个对象实例，输出带有类名和顺序号的字符串。运行语句，有如下输出 ~~~ 31138521288>com.ibeetl.code.User#1 31138521456>com.ibeetl.code.User#2 31138521624>com.ibeetl.code.User#3 ........ ~~~ * max函数,返回给定数组/枚举的最大元素。接受表达式以比较数组的元素。默认情况下使用数字比较。比较表达式可以使用以下内置变量：lhs - >左侧元素进行比较,rhs - >右侧元素进行比较 如查询容量最大的Map，这有可能是内存溢出发生的地方。 ~~~ select max(map(heap.objects('java.util.HashMap'), 'it.size')) // 或者 select max(heap.objects('java.util.HashMap'), 'lhs.size> rhs.size') ~~~ * min函数，同max，返回给定数组/枚举的最小元素 * sort函数，给出数组/枚举的排序。（可选）接受代码表达式以比较数组的元素。默认情况下使用数字比较。比较表达式可以使用以下内置变量：lhs 代表左侧元素，rhs - >代表右侧元素 ~~~ select sort(heap.objects('[C'), 'sizeof(lhs) - sizeof(rhs)') ~~~ 查询所有字符串数组，并按照大小升序排序。 附录A介绍了JDK自带的OQL，许多商业的内存分析器提供了更多的内置的分析功能以及OQL功能扩展，如果有条件，建议使用这些商业内存分析器和参考他们的OQL使用文档介绍。在我的内存故障解决里，基本上使用自带的OQL就能找到问题所在了，需要耐心的分析和查找问题。