gc日志怎么看_今日不聊春秋不谈三国，聊聊GC中的各种时间

Java虚拟机的发展，为我们提供了各种垃圾回收器，同时也引发了各种措手不及的疑难杂症，下面这个问题，相信大家肯定碰到过。

从打印的日志来看，real time 比 user + sys 大，似乎有点问题，要查明这种问题，首先要了解user、sys和real分别是代表什么。

user | sys | real

user和sys指垃圾回收时所消耗的CPU时间

real更倾向于从开始到结束的时间

1、user time

这里需要知道一个概念：用户态。

在用户态中，代码不具备直接访问硬件或者访问内存的能力，必须借助操作系统提供的可靠的，底层的API进行操作，由于这种隔离带来的保护作用，用户态的代码崩溃，不会对系统造成什么影响，我们平时写的代码都运行在用户态。

user time指的是进行垃圾回收时，运行在用户态时花费的CPU时间，期间如果有线程阻塞或等待io的时间，不会被计入到该时间中。

2、sys time

这里需要知道一个概念：内核态。

在内核态中，代码可以不受任何限制的访问底层硬件、执行任意的CPU指令，访问任意的内存地址，内核态的代码崩溃将是灾难性的，会影响到整个系统。

和user time对应的，sys time是运行在内核态时花费的CPU时间。

因为很多事情在用户态无法实现的，比如在申请内存、访问硬件（硬盘、网络端口等），这些操作只能在内核态才能完成，比如代码中的一些操作（malloc分配内存、文件读和写）会调用内核中的函数，这些函数所执行的时间会被计入到sys time中。

如果调用了malloc方法，并不是所有时间花费都会算到sys time上，因为malloc方法中还有一部分代码是运行在用户态的，这部分时间会计入到use rtime，只有在内核态运行时，才会计入到sys time。

3、real time

从GC开始到结束，时钟走过的时间，期间任何时间消耗都要算上，比如线程sleep 、等待IO完成等待。

问题

user + sys表示一共花费了多少CPU时间，注意！这里统计的是所有的CPU，所以有下面的结论：

1、单核环境，real 比user + sys大一点，但不会大很多；

2、多核环境，user + sys 会比real大，如果各个线程任务分配均匀，差不多是GC线程的倍数；

但是，遇到real time 比 user+sys大很多的情况，应该怎么办？

real多出来的那部分时间到底去哪里了？

一般遇到这种问题，可以从两个方面分析：

1、在对应的时间点是否有内存swap，导致磁盘IO

Swap分区在系统的物理内存(这里应该是运行内存)不够用的时候，把物理内存中的一部分空间释放出来，以供当前运行的程序使用。那些被释放的空间可能来自一些很长时间没有什么操作的程序，这些被释放的空间被临时保存到Swap分区中，等到那些程序要运行时，再从Swap分区中恢复保存的数据到内存中。

如果在GC时发生Swap，real time可能变大。

2、gc的日志是否被阻塞

如果在GC时发生日志阻塞，那么real time可能变大。

你的赞和关注是我继续创作的动力~