javajmap

❶ 如何查看java虚拟机堆内存的参数值

请确保java_home/bin配置到path环境变量下，因为这些工具都在jdk的bin目录下

jps(JVM Process Status Tool)：JVM机进程状况工具

用来查看基于HotSpot JVM里面所有进程的具体状态, 包括进程ID，进程启动的路径等等。与unix上的ps类似，用来显示本地有权限的java进程，可以查看本地运行着几个java程序，并显示他们的进程号。使用jps时，不需要传递进程号做为参数。
Jps也可以显示远程系统上的JAVA进程，这需要远程服务上开启了jstat服务，以及RMI注及服务，不过常用都是对本对的JAVA进程的查看。
命令格式：jps [ options ] [ hostid ]
常用参数说明：
-m 输出传递给main方法的参数，如果是内嵌的JVM则输出为null。
-l 输出应用程序主类的完整包名，或者是应用程序JAR文件的完整路径。
-v 输出传给JVM的参数。
例如：
C:\Users\Administrator>jps -lmv
1796 -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx512m -XX:MaxPermSize=256m
7340 sun.tools.jps.Jps -lmv -Denv.class.path=.;D:\DevTools\VM\jdk1.6.0_31\\lib\dt.jar;D:\DevTools\VM\jdk1.6.0_31\\lib\tools.jar; -Dapplication.home=D:\DevTools\VM\jdk1.6.0_31 -Xms8m
其中pid为1796的是我的eclipse进程，pid为7340的是jps命令本身的进程

jinfo(Configuration Info for Java)：JVM配置信息工具

可以输出并修改运行时的java 进程的opts。用处比较简单，用于输出JAVA系统参数及命令行参数
命令格式：jinfo [ options ] [ pid ]
常用参数说明：
-flag 输出，修改，JVM命令行参数
例如：
C:\Users\Administrator>jinfo 1796
将会打印出很多jvm运行时参数信息，由于比较长这里不再打印出来，可以自己试试，内容一目了然

Jstack(Stack Trace for Java)：JVM堆栈跟踪工具
jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64“
命令格式：jstack [ option ] pid
常用参数说明：
-F 当’jstack [-l] pid’没有相应的时候强制打印栈信息
-l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表.
-m 打印java和native c/c++框架的所有栈信息.
-h | -help打印帮助信息
例如：
C:\Users\Administrator>jstack 1796
2013-05-22 11:42:38
Full thread mp Java HotSpot(TM) Client VM (20.6-b01 mixed mode):

"Worker-30" prio=6 tid=0x06514c00 nid=0x1018 in Object.wait() [0x056af000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188)
- locked <0x1ad84a90> (a org.eclipse.core.internal.jobs.WorkerPool)
at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50)
......
......
......
......

jstat(JVM statistics Monitoriing Tool)：JVM统计信息监视工具

对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控
命令格式：jstat [ option pid [interval [ s | ms ] [count] ] ]
常用参数说明：
-gcutil 输出已使用空间占总空间的百分比
-gccapacity 输出堆中各个区域使用到的最大和最小空间
例如：每隔1秒监控jvm内存一次，共监控5次
C:\Users\Administrator>jstat -gccapacity 1796 1s 5
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 97
C:\Users\Administrator>jstat -gcutil 1796 1s 5
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
一些术语的中文解释：
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
PC：Perm(持久代)的容量 (字节)
PU：Perm(持久代)目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
NGCMN：年轻代(young)中初始化(最小)的大小 (字节)
NGCMX：年轻代(young)的最大容量 (字节)
NGC：年轻代(young)中当前的容量 (字节)
OGCMN：old代中初始化(最小)的大小 (字节)
OGCMX：old代的最大容量 (字节)
OGC：old代当前新生成的容量 (字节)
PGCMN：perm代中初始化(最小)的大小 (字节)
PGCMX：perm代的最大容量 (字节)
PGC：perm代当前新生成的容量 (字节)
S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E：年轻代中Eden（伊甸园）已使用的占当前容量百分比
O：old代已使用的占当前容量百分比
P：perm代已使用的占当前容量百分比
S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)
S1CMX ：年轻代中第二个survivor（幸存区）的最大容量 (字节)
ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)
DSS：当前需要survivor（幸存区）的容量 (字节)（Eden区已满）
TT： 持有次数限制
MTT ： 最大持有次数限制

jmap( Memory Map for Java)：JVM内存映像工具

打印出某个java进程（使用pid）内存内的所有‘对象’的情况（如：产生那些对象，及其数量）
命令格式：jmap [ option ] pid
常用参数说明：
-mp:[live,]format=b,file=<filename> 使用二进制形式输出jvm的heap内容到文件中， live子选项是可选的，假如指定live选项,那么只输出活的对象到文件.
-histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量.
-F 强迫.在pid没有相应的时候使用-mp或者-histo参数. 在这个模式下,live子参数无效.
例如：以二进制形式输入当前堆内存映像到文件data.hprof中
jmap -mp:live,format=b,file=data.hprof 1796
生成的文件可以使用jhat工具进行分析，在OOM（内存溢出）时，分析大对象，非常有用
通过使用如下参数启动JVM，也可以获取到mp文件：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./java_pid<pid>.hprof
在jvm发生内存溢出时生成内存映像文件

jhat(JVM Heap Analysis Tool)：JVM堆转储快照分析工具

用于对JAVA heap进行离线分析的工具，他可以对不同虚拟机中导出的heap信息文件进行分析，如linux上导出的文件可以拿到WINDOWS上进行分析，可以查找诸如内存方面的问题。
命令格式：jhat mpfile(jmap生成的文件)
例如：分析jmap导出的内存映像
jhat data.hprof
执行成功后，访问http://localhost:7000即可查看内存信息，

MAT(Memory Analyzer Tool)：一个基于Eclipse的内存分析工具

官网： http://www.eclipse.org/mat/
update：http://download.eclipse.org/mat/1.2/update-site/
这是eclipse的一个插件，安装后可以打开xxx.hprof文件，进行分析，比jhat更方便使用，有些时候由于线上xxx.hprof文件过大，直接使用jhat进行初步分析了，可以的话拷贝到本地分析效果更佳。

图形化监控工具：

在JDK安装目录bin下面有两个可视化监控工具
1. JConsole(Java Monitoring and Management Console) 基于JMX的可视化管理工具。
2. VisualVM(All-in-one Java Troubleshooting Tool)随JDK发布的最强大的运行监视和故障处理程序。
推荐使用VisualVM，他有很多插件，可以更方便的监控运行时JVM

❷ JDK命令介绍

命令jps用于列出java进程，直接运行jps不加任何参数，可以列出Java程序的进程ID以及Main函数等名称。
参数-q指定jps只输出进程ID，而不输出类的短名称
参数-m用于输出传递给Java进程（主函数）的参数
参数 -l用于输出主函数的完整路径
参数 -v可以显示传递给JVM的参数

jstat是一个可以用于观察Java应用程序运行时信息的工具。它的功能非常强大，可以通过它，查看堆信息的详细使用情况。主要用于监控虚拟机的各种运行状态信息，如类的装载、内存、垃圾回收、JIT编译器等，在没有GUI的服务器上，这款工具是首选的一款监控工具。
基本使用语法为：

选项option可以由以下值构成：

-class：显示ClassLoader的相关信息。
-compiler：显示JIT编译的相关信息。
-gc：显示与GC相关的堆信息。
-gccapacity：显示各个代的容量及使用情况。
-gccause：显示垃圾收集相关信息（同-gcutil），同时显示最后一次或当前正在发生的垃圾收集的诱发原因。
-gcnew：显示新生代信息。
-gcnewcapacity：显示新生代大小与使用情况。
-gcold：显示老年代与永久代的信息。
-gcoldcapacity：显示老年代的大小。
-gcmetacapacity：显示元空间的大小。（在java8之前是使用-gcpermcapacity显示永久代的大小）
-gcutil：显示垃圾收集信息。
-printcompilation：输出JIT编译的方法信息。
以上选项可以输入 jstat -options 查看。

-t 参数可以在输出信息前加一个 Timestamp 列，显示程序的运行时间。

-h 参数可以在周期性数据输出时，输出多少行数据后，跟着输出一个表头信息。

vmid 参数就是Java进程id。

interval 参数用于指定输出统计数据的周期，单位为毫秒。

count 用于指定一共输出多少次数据。

jinfo 可以用来查看正在运行的Java运行程序的扩展参数，甚至支持在运行时修改部分参数。可以用来查看正在运行的 java 应用程序的扩展参数，包括Java System属性和JVM命令行参数；也可以动态的修改正在运行的 JVM 一些参数。当系统崩溃时，jinfo可以从core文件里面知道崩溃的Java应用程序的配置信息。

jmap 可以生成Java应用程序的堆快照和对象的统计信息。基本语法为：

option 选项如下：
-mp 生成java堆转储快照。格式为： -mp:[live,]format=b,file=,其中live子参数说明是否只mp出存活的对象
-finalizerinfo 显示在F-Queue中等待Finalizer线程执行finalize方法的对象。只在Linux/Solaris平台下有效
-heap 显示java堆详细信息，如使用哪种收集器、参数配置、分代情况等，在Linux/Solaris平台下有效
-histo 显示堆中对象统计信息，包含类、实例对象、合集容量
-permstat 以ClassLoader为统计口径显示永久代内存状态。只在Linux/Solaris平台下有效
-F 当虚拟机进程对-mp选项没有相应时。可使用这个选项强制生成mp快照。只在Linux/Solaris平台下有效

使用 jhat 工具可以用于分析Java应用程序的堆快照内容。jhat 在分析完成后，使用HTTP服务器展示其分析结果。在浏览器中访问 http://localhost:7000/

jstack 可用于导出Java应用程序的线程堆栈。语法为：

-l选项用于打印锁的附加信息。
jstack 工具会在控制台输出程序中所有的锁信息，可以使用重定向将输出保存到文件。
通过 jstack 工具不仅可以得到线程堆栈，它还能自动进行死锁检查，输出找到的死锁信息。

之前所述的工具中，只涉及到监控本机的Java应用程序。而在这些工具中，一些监控工具也支持对远程计算机的监控（如：jps、jstat）。为了启用远程监控，则需要配合使用jstatd工具。
命令jstatd是一个RMI服务端程序，它的作用相当于代理服务器，建立本地计算机与远程监控工具的通信。jstatd服务器将本机的Java应用程序信息传递到远程计算机。

JConsole（Java Monitoring and ManagementConsole）工具时JDK自带的图形化性能监控工具。通过JConsole工具，可以查看Java应用程序的运行概况，监控堆信息、永久区使用情况、类加载情况等。

❸ java内存查看与分析

业界有很多强大的java profile的工具，比如Jporfiler，yourkit，这些收费的东西我就不想说了，想说的是，其实java自己就提供了很多内存监控的小工具，下面列举的工具只是一小部分，仔细研究下扒陵jdk的工具，还是蛮有意思的呢：）
1：gc日志输出
在jvm启动参数中加入 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimestamps -XX:+PrintGCApplicationStopedTime，jvm将会按照这些参数顺序输出gc概要信息，详细信息，gc时间信息，gc造成的应用暂停时间。如果在刚才的参数后面加入参数 -Xloggc:文件路径，gc信息将会输出到指定的文件中。其他参数还有
-verbose:gc和-XX:+PrintTenuringDistribution等。
2：jconsole
jconsole是jdk自带的一个内存分析工具，它提供了图形界面。可以查看到被监控的jvm的内存信息，线程信息，类加载信息，MBean信息。
jconsole位于jdk目录下的bin目录，在windows下是jconsole.exe，在unix和linux下是jconsole.sh，jconsole可以监控本地应用，也可以监控远程应用。 要监控本地应用，执行jconsole pid，pid就是运行的java进程id，如果不带上pid参数，则执行jconsole命令后，会看到一个对话框弹出，上面列出了本地的java进程，可以选择一个进行监控。如果要远程监控，则要在远程服务器的jvm参数里加入一些东西，因为jconsole的远程监控基于jmx的，关于jconsole详细用法，请见专门介绍jconsle的文章，我也会在博客里专门详细介绍jconsole。
3:jviusalvm
在JDK6 update 7之后，jdk推出了另外一个工具：jvisualvm,java可视化虚拟机，它不但提供了jconsole类似的功能，还提供了jvm内存和cpu实时诊断，还有手动mp出jvm内存情况，手动执行gc。
和jconsole一样，运行jviusalvm，在jdk的bin目录下执行jviusalvm，windows下是jviusalvm.exe,linux和unix下是jviusalvm.sh。渗此租
4：jmap
jmap是jdk自带的jvm内存分析的工具，丛兆位于jdk的bin目录。jdk1.6中jmap命令用法：
Usage:
jmap -histo pid
（to connect to running process and print histogram of java object heap
jmap -mp:mp-options pid
（to connect to running process and mp java heap）
mp-options:
format=b binary default
file=file mp heap to file
Example: jmap -mp:format=b,file=heap.bin pid
jmap -histo pid在屏幕上显示出指定pid的jvm内存状况。以我本机为例，执行该命令，屏幕显示：
num #instances #bytes class name
----------------------------------------------
1: 24206 2791864 constMethodKlass
2: 22371 2145216 [C
3: 24206 1940648 methodKlass
4: 1951 1364496 constantPoolKlass
5: 26543 1282560 symbolKlass
6: 6377 1081744 [B
7: 1793 909688 constantPoolCacheKlass
8: 1471 614624 instanceKlassKlass
9: 14581 548336 [Ljava.lang.Object;
10: 3863 513640 [I
11: 20677 496248 java.lang.String
12: 3621 312776 [Ljava.util.HashMap$Entry;
13: 3335 266800 java.lang.reflect.Method
14: 8256 264192 java.io.ObjectStreamClass$WeakClassKey
15: 7066 226112 java.util.TreeMap$Entry
16: 2355 173304 [S
17: 1687 161952 java.lang.Class
18: 2769 150112 [[I
19: 3563 142520 java.util.HashMap
20: 5562 133488 java.util.HashMap$Entry
Total 239019 17140408
为了方便查看，我删掉了一些行。从上面的信息很容易看出，#instance指的是对象数量，#bytes指的是这些对象占用的内存大小，class name指的是对象类型。
再看jmap的mp选项，这个选项是将jvm的堆中内存信息输出到一个文件中，在我本机执行
jmap -mp:file=c:mp.txt 340
注意340是我本机的java进程pid，mp出来的文件比较大有10几M，而且我只是开了tomcat，跑了一个很简单的应用，且没有任何访问，可以想象，大型繁忙的服务器上，mp出来的文件该有多大。需要知道的是，mp出来的文件信息是很原始的，绝不适合人直接观看，而jmap -histo显示的内容又太简单，例如只显示某些类型的对象占用多大内存，以及这些对象的数量，但是没有更详细的信息，例如这些对象分别是由谁创建的。那这么说，mp出来的文件有什么用呢？当然有用，因为有专门分析jvm的内存mp文件的工具。
5：jhat
上面说了，有很多工具都能分析jvm的内存mp文件，jhat就是sun jdk6及以上版本自带的工具，位于jdk的bin目录，执行 jhat -J -Xmx512m [file] ，file就是mp文件路径。jhat内置一个简单的web服务器，此命令执行后，jhat在命令行里显示分析结果的访问地址，可以用-port选项指定端口，具体用法可以执行jhat -heap查看帮助信息。访问指定地址后，就能看到页面上显示的信息，比jmap -histo命令显示的丰富得多，更为详细。
6：eclipse内存分析器
上面说了jhat，它能分析jvm的mp文件，但是全部是文字显示，eclipse memory analyzer，是一个eclipse提供用于分析jvm 堆mp的插件，它的分析速度比jhat快，分析结果是图形界面显示，比jhat的可读性更高。其实jvisualvm也可以分析mp文件，也是有图形界面显示的。
7：jstat
如果说jmap倾向于分析jvm内存中对象信息的话，那么jsta就是倾向于分析jvm内存的gc情况。都是jvm内存分析工具，但显然，它们是从不同维度来分析的。jsat常用的参数有很多，如 -gc,-gcutil,-gccause，这些选项具体作用可查看jsat帮助信息，我经常用-gcutil，这个参数的作用不断的显示当前指定的jvm内存的垃圾收集的信息。
我在本机执行 jstat -gcutil 340 10000，这个命令是每个10秒钟输出一次jvm的gc信息，10000指的是间隔时间为10000毫秒。屏幕上显示如下信息（我只取了第一行，因为是按的一定频率显示，所以实际执行的时候，会有很多行）：
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
额怎么说呢，要看懂这些信息代表什么意思，还必须对jvm的gc机制有一定的了解才行啊。其实如果对sun的 hot spot jvm的gc比较了解的人，应该很容易看懂这些信息，但是不清楚gc机制的人，有点莫名其妙，所以在这里我还是先讲讲sun的jvm的gc机制吧。说到gc，其实不仅仅只是java的概念，其实在java之前，就有很多语言有gc的概念了，gc嘛就是垃圾收集的意思，更多的是一种算法性的东西，而跟具体语言没太大关系，所以关于gc的历史，gc的主流算法我就不讲了，那扯得太远了，扯得太远了就是扯淡。sun现在的jvm，内存的管理模型是分代模型，所以gc当然是分代收集了。分代是什么意思呢？就是将对象按照生命周期分成三个层次，分别是：新生代，旧生代，持久代。对象刚开始分配的时候，大部分都在新生代，当新生代gc提交被触发后了，执行一次新生代范围内的gc，这叫minor gc，如果执行了几次minor gc后，还有对象存活，将这些对象转入旧生代，因为这些对象已经经过了组织的重重考验了哇。旧生代的gc频率会更低一些，如果旧生代执行了gc，那就是full gc，因为不是局部gc，而是全内存范围的gc，这会造成应用停顿，因为全内存收集，必须封锁内存，不许有新的对象分配到内存，持久代就是一些jvm期间，基本不会消失的对象，例如class的定义，jvm方法区信息，例如静态块。需要主要的是，新生代里又分了三个空间：eden，susvivor0，susvivor1，按字面上来理解，就是伊甸园区，幸存1区，幸存2区。新对象分配在eden区中，eden区满时，采用标记-复制算法，即检查出eden区存活 的对象，并将这些对象复制到是s0或s1中，然后清空eden区。jvm的gc说开来，不只是这么简单，例如还有串行收集，并行收集，并发收集，还有着名的火车算法，不过那说得太远了，现在对这个有大致了解就好。说到这里，再来看一下上面输出的信息：
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
S0:新生代的susvivor0区，空间使用率为5462%
S1:新生代的susvivor1区，空间使用率为0.00%（因为还没有执行第二次minor收集）
E:eden区，空间使用率42.87%
O:旧生代，空间使用率43.52%
P:持久带，空间使用率86.24%
YGC:minor gc执行次数1792次
YGCT:minor gc耗费的时间5.093毫秒
FGC:full gc执行次数33
FGCT:full gc耗费的时间7.670毫秒
GCT:gc耗费的总时间12.763毫秒
怎样选择工具
上面列举的一些工具，各有利弊，其实如果在开发环境，使用什么样的工具是无所谓的，只要能得到结果就好。但是在生产环境里，却不能乱选择，因为这些工具本身就会耗费大量的系统资源，如果在一个生产服务器压力很大的时候，贸然执行这些工具，可能会造成很意外的情况。最好不要在服务器本机监控，远程监控会比较好一些，但是如果要远程监控，服务器端的启动脚本要加入一些jvm参数，例如用jconsloe远程监控tomcat或jboss等，都需要设置jvm的jmx参数，如果仅仅只是分析服务器的内存分配和gc信息，强烈推荐，先用jmap导出服务器端的jvm的堆mp文件，然后再用jhat，或者jvisualvm，或者eclipse内存分析器来分析内存状况。

❹ jmap 和mat分析java的内存远小于实际占用内存

当然是，其他的也是一样。

❺ Linux下如何定位JAVA进程直接内存的泄漏及top和jmap查看内存的关系

问题1：top的RES值和JAVA堆内存之间到底是一个什么关系？
——大概1、2个月有个帖子讨论过，挺长的，不过一下子找不到了；总的来说，两者很难找到非常精确匹配的计算关系，因为两者统计的口径是不同的；操作系统关心的是被应用程序所占用的，而JVM则只是关心堆中被分配出去的；这里面有JVM自己开销的、有碎片内存无法使用的、还有已使用完毕待回收的 等等问题。
——总的来说，我觉得如果不是为了底层开发之类的问题，不值得在此问题进行深入研究。

问题2：桥卖如何定位JAVA进程直接内存的泄档答漏？
——很遗憾，并没有什么招数来直接定位，否则内存泄露就不会是一个让大家闻风丧胆的问题了；各类工具都只行消慧是提供给你一定的手段去发现征兆、缩小怀疑范围，没有说直接帮你定位，那听起来就不是IT而是神话了。
——常规招数就是：范围 与 层次，两个方向不断通过测试和监控来缩小 怀疑范围，从而最终定位内存泄漏点。