![050f5decf8eeccebbd4e006db448d244.png](https://i-blog.csdnimg.cn/blog_migrate/d300ec957a9b00ea9143b301c3585935.jpeg)
Java虚拟机的发展,为我们提供了各种垃圾回收器,同时也引发了各种措手不及的疑难杂症,下面这个问题,相信大家肯定碰到过。
![c9af555f71eec9faceaedfbe1227b143.png](https://i-blog.csdnimg.cn/blog_migrate/1734d093cb1ee5f3f5fb35caf80b803d.png)
从打印的日志来看,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。
![72541f92a8be91ff56c81826a570bbc1.png](https://i-blog.csdnimg.cn/blog_migrate/6e1301142a290b4aab83cc7766823bf0.jpeg)
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可能变大。
你的赞和关注是我继续创作的动力~