java内存、垃圾回收查看与分析

最新推荐文章于 2024-10-06 20:45:20 发布

wudiazu

最新推荐文章于 2024-10-06 20:45:20 发布

阅读量6.3k

点赞数 1

分类专栏： linux java

java 同时被 2 个专栏收录

32 篇文章 1 订阅

订阅专栏

linux

4 篇文章 1 订阅

订阅专栏

Java 内存查看与分析

首先使用 jps -l 查找当前所有的 Java 进程。

jstat 命令

jstat -gc pid 1000 或者 jstat -gc pid 1000 > out.txt：每隔1000号码打印一次或导出 GC 的状态。

S0C S0U：Survivor 0区的大小及使用情况
S1C S1U：Survivor 1区的大小及使用情况
EC EU：Eden 区的大小及使用情况
OC OU：Old 区的大小及使用情况
PC PU：Perm 区的大小及使用情况（Java 8 中取消）
MC MU：Metaspace 区的大小及使用情况（Java 8 中用户替代 Perm 区）
YGC YGCT：Young Generation Minor GC 的数目及时间
FGC FGCT：Old Generation Full GC 的数目及时间
GCT：GC 总时间 = YGCT + FGCT

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000

jmap -heap 命令

jmap -heap pid 或者 jmap -heap pid > out.txt：打印或导出堆内存使用情况。
例如：
可以查看：

Heap Configuration 堆的配置
Heap Usage 对的使用情况，包括 Eden 区, From 区，To 区，Old 区，Perm 区（Java 8 中取消）

Attaching to process ID 20128, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.92-b14

using thread-local object allocation.
Parallel GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 4271898624 (4074.0MB)
   NewSize                  = 89128960 (85.0MB)
   MaxNewSize               = 1423966208 (1358.0MB)
   OldSize                  = 179306496 (171.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 67108864 (64.0MB)
   used     = 4026592 (3.840057373046875MB)
   free     = 63082272 (60.159942626953125MB)
   6.000089645385742% used
From Space:
   capacity = 11010048 (10.5MB)
   used     = 0 (0.0MB)
   free     = 11010048 (10.5MB)
   0.0% used
To Space:
   capacity = 11010048 (10.5MB)
   used     = 0 (0.0MB)
   free     = 11010048 (10.5MB)
   0.0% used
PS Old Generation
   capacity = 179306496 (171.0MB)
   used     = 0 (0.0MB)
   free     = 179306496 (171.0MB)
   0.0% used

873 interned Strings occupying 59320 bytes.

jmap -histo 命令

jmap -histo pid 或者 jmap -histo pid > out.txt：打印或导出堆内存中对象的数量及大小。
例如：
可以查看：

class name 类的名称
instances 类对应的对象的数目
bytes 类对应的对象的大小

 num     #instances         #bytes  class name
----------------------------------------------
   1:           522        3248552  [I
   2:          3282         416008  [C
   3:           217          78016  [B
   4:           581          66208  java.lang.Class
   5:          2292          55008  java.lang.String
   6:           618          32144  [Ljava.lang.Object;
   7:           152          10944  java.lang.reflect.Field
   8:           262           6288  java.lang.StringBuilder
   9:           178           5696  java.io.File
  10:           173           5536  java.util.HashMap$Node
  11:            61           5368  java.lang.reflect.Method
  12:            82           5248  java.net.URL
  13:           110           4400  java.lang.ref.SoftReference
  14:            26           4256  [Ljava.util.HashMap$Node;
  15:           259           4144  java.lang.Integer
  16:           101           4040  java.util.TreeMap$Entry

以上转载自简书
作者：专职跑龙套
链接：https://www.jianshu.com/p/4462f81e0789

主要分析工具和命令有如下几种：

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实时诊断，还有手动dump出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 -dump:<dump-options> <pid>

（to connect to running process and dump java heap）

dump-options:

format=b binary default

file=<file> dump heap to <file>

Example: jmap -dump: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的dump选项，这个选项是将jvm的堆中内存信息输出到一个文件中，在我本机执行

jmap -dump:file=c:dump.txt 340

注意340是我本机的java进程pid，dump出来的文件比较大有10几M，而且我只是开了tomcat，跑了一个很简单的应用，且没有任何访问，可以想象，大型繁忙的服务器上，dump出来的文件该有多大。需要知道的是，dump出来的文件信息是很原始的，绝不适合人直接观看，而jmap -histo显示的内容又太简单，例如只显示某些类型的对象占用多大内存，以及这些对象的数量，但是没有更详细的信息，例如这些对象分别是由谁创建的。那这么说，dump出来的文件有什么用呢？当然有用，因为有专门分析jvm的内存dump文件的工具。

5：jhat

上面说了，有很多工具都能分析jvm的内存dump文件，jhat就是sun jdk6及以上版本自带的工具，位于jdk的bin目录，执行 jhat -J -Xmx512m [file] ，file就是dump文件路径。jhat内置一个简单的web服务器，此命令执行后，jhat在命令行里显示分析结果的访问地址，可以用-port选项指定端口，具体用法可以执行jhat -heap查看帮助信息。访问指定地址后，就能看到页面上显示的信息，比jmap -histo命令显示的丰富得多，更为详细。

6：eclipse内存分析器

上面说了jhat，它能分析jvm的dump文件，但是全部是文字显示，eclipse memory analyzer，是一个eclipse提供用于分析jvm 堆dump的插件，它的分析速度比jhat快，分析结果是图形界面显示，比jhat的可读性更高。其实jvisualvm也可以分析dump文件，也是有图形界面显示的。

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毫秒

当然也可以配合linux自带的命令进行排查：

1. ps命令

ps -aux | sort -k4nr | head -N

*命令详解：
1. head：-N可以指定显示的行数，默认显示10行。
2. ps：参数a指代all——所有的进程，u指代userid——执行该进程的用户id，x指代显示所有程序，不以终端机来区分。ps -aux的输出格式如下：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  19352  1308 ?        Ss   Jul29   0:00 /sbin/init
root         2  0.0  0.0      0     0 ?        S    Jul29   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Jul29   0:11 [migration/0]

3. sort -k4nr中（k代表从根据哪一个关键词排序，后面的数字4表示按照第四列排序；n指代numberic sort，根据其数值排序；r指代reverse，这里是指反向比较结果，输出时默认从小到大，反向后从大到小。）。本例中，可以看到%MEM在第4个位置，根据%MEM的数值进行由大到小的排序。-k3表示按照cpu占用率排序。

2. top工具

命令行输入top回车，然后按下大写M按照memory排序，按下大写P按照CPU排序。

怎样选择工具

上面列举的一些工具，各有利弊，其实如果在开发环境，使用什么样的工具是无所谓的，只要能得到结果就好。但是在生产环境里，却不能乱选择，因为这些工具本身就会耗费大量的系统资源，如果在一个生产服务器压力很大的时候，贸然执行这些工具，可能会造成很意外的情况。最好不要在服务器本机监控，远程监控会比较好一些，但是如果要远程监控，服务器端的启动脚本要加入一些jvm参数，例如用jconsloe远程监控tomcat或jboss等，都需要设置jvm的jmx参数，如果仅仅只是分析服务器的内存分配和gc信息，强烈推荐，先用jmap导出服务器端的jvm的堆dump文件，然后再用jhat，或者jvisualvm，或者eclipse内存分析器来分析内存状况。

以下摘自简书

作者：占小狼
链接：https://www.jianshu.com/p/6690f7e92f27
來源：简书

记得前段时间，同事说他们测试环境的服务器cpu使用率一直处于100%，本地又没有什么接口调用，为什么会这样？cpu使用率居高不下，自然是有某些线程一直占用着cpu资源，那又如何查看占用cpu较高的线程？

当然一个正常的程序员不会写出上述代码，这里只是为了让一个线程占用较高的cpu资源。

top命令

在linux环境下，可以通过top命令查看各个进程的cpu使用情况，默认按cpu使用率排序

1、上图中可以看出pid为23344的java进程占用了较多的cpu资源；
2、通过top -Hp 23344可以查看该进程下各个线程的cpu使用情况；

上图中可以看出pid为25077的线程占了较多的cpu资源，利用jstack命令可以继续查看该线程当前的堆栈状态。

jstack命令

通过top命令定位到cpu占用率较高的线程之后，继续使用jstack pid命令查看当前java进程的堆栈状态

jstack命令生成的thread dump信息包含了JVM中所有存活的线程，为了分析指定线程，必须找出对应线程的调用栈，应该如何找？

在top命令中，已经获取到了占用cpu资源较高的线程pid，将该pid转成16进制的值，在thread dump中每个线程都有一个nid，找到对应的nid即可；隔段时间再执行一次stack命令获取thread dump，区分两份dump是否有差别，在nid=0x246c的线程调用栈中，发现该线程一直在执行JstackCase类第33行的calculate方法，得到这个信息，就可以检查对应的代码是否有问题。

通过thread dump分析线程状态

除了上述的分析，大多数情况下会基于thead dump分析当前各个线程的运行情况，如是否存在死锁、是否存在一个线程长时间持有锁不放等等。

在dump中，线程一般存在如下几种状态：
1、RUNNABLE，线程处于执行中
2、BLOCKED，线程被阻塞
3、WAITING，线程正在等待

实例1：多线程竞争synchronized锁

很明显：线程1获取到锁，处于RUNNABLE状态，线程2处于BLOCK状态
1、locked <0x000000076bf62208>说明线程1对地址为0x000000076bf62208对象进行了加锁；
2、waiting to lock <0x000000076bf62208> 说明线程2在等待地址为0x000000076bf62208对象上的锁；
3、waiting for monitor entry [0x000000001e21f000]说明线程1是通过synchronized关键字进入了监视器的临界区，并处于"Entry Set"队列，等待monitor，具体实现可以参考深入分析synchronized的JVM实现；

实例2：通过wait挂起线程

static class Task implements Runnable {
    @Override
    public void run() {
        synchronized (lock) {
            try {
                lock.wait();
                //TimeUnit.SECONDS.sleep(100000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

dump结果

线程1和2都处于WAITING状态
1、线程1和2都是先locked <0x000000076bf62500>，再waiting on <0x000000076bf62500>，之所以先锁再等同一个对象，是因为wait方法需要先通过synchronized获得该地址对象的monitor；
2、waiting on <0x000000076bf62500>说明线程执行了wait方法之后，释放了monitor，进入到"Wait Set"队列，等待其它线程执行地址为0x000000076bf62500对象的notify方法，并唤醒自己，具体实现可以参考深入分析Object.wait/notify实现机制；