深入理解JVM性能调优

浅浅的花香味﹌ 2022-06-05 05:07 274阅读 0赞

在上文中我们分析了很多性能监控工具，介绍这些工具的目的只有一个，那就是找出对应的性能瓶颈。盲目的性能调优是没有效果的，只有充分知道了哪里出了问题，针对性的结果才是立竿见影的。解决了主要的性能问题，那些次要的性能问题也就不足为虑了！

我们知道，性能问题无非就这么几种：CPU、内存、磁盘IO、网络。那我们来逐一介绍以下相关的现象和一些可能出现的问题。

一、CPU过高。

查看CPU最简单的我们使用任务管理器查看，如下图所示，windows下使用任务管理器查看，Linux下使用top查看。

![深入理解JVM性能调优][JVM]

![深入理解JVM性能调优][JVM 1]

一般我们的服务器都采用Linux，因此我们重点关注一下Linux(注：windows模式下相信大家已经很熟悉了，并且前面我们已经提到，使用资源监视器可以很清楚的看到系统的各项参数，在这里我就不多做介绍了)

在top视图下，对于多核的CPU，显示的CPU资源有可能超过100%，因为这里显示的是所有CPU占用百分百的总和，如果你需要看单个CPU的占用情况，直接按键1就可以看到。如下图所示，我的一台测试机为8核16GB内存。

![深入理解JVM性能调优][JVM 2]

在

top  视图下，按键  shift+h  后，会显示各个线程的  CPU  资源消耗情况，如下图所示：

![深入理解JVM性能调优][JVM 3]

我们也可以通过

sysstat  工具集的  pidstat  来查看

注：sysstat下载地址：[http://sebastien.godard.pagesperso-orange.fr/download.html][http_sebastien.godard.pagesperso-orange.fr_download.html]

安装方法:

1、chmod +x configure

2、./configure

3、make

4、make install

如输入pidstat 1 2就会隔一秒在控制台输出一次当然CPU的情况，共输出2次

![深入理解JVM性能调优][JVM 4]

除了

top  、  pidstat  以外，  vmstat  也可以进行采样分析

![深入理解JVM性能调优][JVM 5]

相关

top  、  pidstat  、  mstat  的用法大家可以去网上查找。

下面我们主要来介绍以下当出现CPU过高的时候，或者CPU不正常的时候，我们该如何去处理？

CPU消耗过高主要分为用户进程占用CPU过高和内核进程占用CPU过高（在Linux下top视图下us指的是用户进程，而sy是指内核进程），我们来看一个案例：

![深入理解JVM性能调优][JVM 6]

程序运行前，系统运行平稳，其中蓝色的线表示总的

CPU  利用率，而红色的线条表示内核使用率。部署  war  测试程序，运行如下图所示：

![深入理解JVM性能调优][JVM 7]

对于一个

web  程序，还没有任何请求就占用这么多  CPU  资源，显然是不正常的。并且我们看到，不是系统内核占用的大量  CPU  ，而是系统进程，那是哪一个进程的呢？我们来看一下。

![深入理解JVM性能调优][JVM 8]

很明显是我们的

java  进程，那是那个地方导致的呢？这就需要用到我们之前提到的性能监控工具。在此我们使用可视化监控工具  VisualVM 。

![深入理解JVM性能调优][JVM 9]

首先我们排除了是

GC  过于频繁而导致大  CPU  过高，因为很明显监控视图上没有  GC  的活动。然后我们打开  profilter  去查看以下，是那个线程导致了  CPU  的过高？

![深入理解JVM性能调优][JVM 10]

前面一些线程都是容器使用的，而下面一个线程也一直在执行，那是什么地方调用的呢？查找代码中使用

ThredPoolExecutor  的地方。终于发现以下代码。

private BlockingQueue queue;

private Executor executor;

//……

public void run() \{

while(true)\{

try \{

SendMsg sendMsg = queue.poll();//从队列中取出

if(null != sendMsg) \{

sendForQueue(sendMsg);

\} catch (Exception e) \{

e.printStackTrace();

问题很显然了，我们看一下对应BlockingQueue的poll方法的API文档。

![深入理解JVM性能调优][JVM 11]

不难理解了，虽然使用了阻塞的队列，但是使用了非阻塞的取法，当数据为空时直接返回

null  ，那这个语句就等价于下面的语句。

@Override

public void run() \{

while(true)\{

相当于死循环么，很显然是非常耗费CPU资源的，并且我们还可以发现这样的死循环是耗费的单颗CPU资源，因此可以解释上图为啥有一颗CPU占用特别高。我们来看一下部署在Linux下的top视图。

![深入理解JVM性能调优][JVM 12]

猛一看，不是很高么？我们按键

1  来看每个单独  CPU  的情况！

![深入理解JVM性能调优][JVM 13]

这下看的很清楚了吧！明显一颗

CPU  被跑满了。（因为一个单独的死循环只能用到一颗  CPU  ，都是单线程运行的）。

问题找到，马上修复代码为阻塞时存取，如下所示：

@Override

public void run() \{

while(true)\{

try \{

SendMsg sendMsg = queue.take();//从队列中取出

sendForQueue(sendMsg);

\} catch (Exception e) \{

e.printStackTrace();

![深入理解JVM性能调优][JVM 14]

再来监控

CPU  的变换，我们可以看到，基本上不消耗  CPU  资源（是我没做任何的访问哦，有用户建立线程就会消耗）。

![深入理解JVM性能调优][JVM 15]

再来看

java  进程的消耗，基本上不消耗  CPU  资源

![深入理解JVM性能调优][JVM 16]

![深入理解JVM性能调优][JVM 17]

再来看VisualVM的监控，我们就可以看到基本上都是容器的一些线程了

![深入理解JVM性能调优][JVM 18]

以上示例展示了

CPU  消耗过高情况下用户线程占用特别高的情况。也就是  Linux  下  top  视图中  us  比较高的情况。发生这种情况的原因主要有以下几种：程序不停的在执行无阻塞的循环、正则或者纯粹的数学运算、  GC  特别频繁。

CPU过高还有一种情况是内核占用CPU很高。我们来看另外一个示例。

package com.yhj.jvm.monitor.cpu.sy;

import java.util.Random;

import java.util.concurrent.ExecutorService;

import java.util.concurrent.Executors;

/\*\*

\* @Described：系统内核占用CPU过高测试用例

\* @author YHJ create at 2012\-3\-28 下午05:27:33

\* @FileNmae com.yhj.jvm.monitor.cpu.sy.SY\_Hign\_TestCase.java

\*/

public class SY\_Hign\_TestCase \{

private final static int LOCK\_COUNT = 1000;

//默认初始化LOCK\_COUNT个锁对象

private Object \[\] locks = new Object\[LOCK\_COUNT\];

private Random random = new Random();

//构造时初始化对应的锁对象

public SY\_Hign\_TestCase() \{

for(int i=0;i<LOCK\_COUNT;++i)

locks\[i\]=new Object();

abstract class Task implements Runnable\{

protected Object lock;

public Task(int index) \{

this.lock= locks\[index\];

@Override

public void run() \{

while(true)\{   //循环执行自己要做的事情

doSth();

//做类自己要做的事情

public abstract void doSth();

//任务A 休眠自己的锁

class TaskA extends Task\{

public TaskA(int index) \{

super(index);

@Override

public void doSth() \{

synchronized (lock) \{

try \{

lock.wait(random.nextInt(10));

\} catch (InterruptedException e) \{

e.printStackTrace();

//任务B 唤醒所有锁

class TaskB extends Task\{

public TaskB(int index) \{

super(index);

@Override

public void doSth() \{

try \{

synchronized (lock) \{

lock.notifyAll();

Thread.sleep(random.nextInt(10));

\} catch (InterruptedException e) \{

e.printStackTrace();

//启动函数

public void start()\{

ExecutorService service = Executors.newCachedThreadPool();

for(int i=0;i<LOCK\_COUNT;++i)\{

service.execute(new TaskA(i));

service.execute(new TaskB(i));

//主函数入口

public static void main(String\[\] args) \{

new SY\_Hign\_TestCase().start();

代码很简单，就是创建了2000个线程，让一定的线程去等待，另外一个线程去释放这些资源，这样就会有大量的线程切换，我们来看下效果。

![深入理解JVM性能调优][JVM 19]

很明显，

CPU  的内核占用率很高，我们拿具体的资源监视器看一下：

![深入理解JVM性能调优][JVM 20]

很明显可以看出有很多线程切换占用了大量的

CPU  资源。

同样的程序部署在Linux下，top视图如下图所示：

![深入理解JVM性能调优][JVM 21]

展开对应的

CPU  资源，我们可以清晰的看到如下情形：

![深入理解JVM性能调优][JVM 22]

大家可以看到有大量的

sy  内核占用，但是也有不少的  us  ，  us  是因为我们启用了大量的循环，而  sy  是因为大量线程切换导致的。

我们也可以使用vmstat来查看，如下图所示：

![深入理解JVM性能调优][JVM 23]

二、文件

IO  消耗过大，磁盘队列高。

在windows环境下，我们可以使用资源监视器查看对应的IO消耗，如下图所示：

![深入理解JVM性能调优][JVM 24]

这里不但可以看到当前磁盘的负载信息，队列详情，还能看到每个单独的进程的资源消耗情况。

Linux下主要使用pidstat、iostat等进行分析。如下图所示

Pidstat –d –t –p \[pid\] \{time\} \{count\}

如：pidstat -d -t -p 18720 1 1

![深入理解JVM性能调优][JVM 25]

![深入理解JVM性能调优][JVM 26]

Iostat

![深入理解JVM性能调优][JVM 27]

Iostat –x xvda 1 10做定时采样

![深入理解JVM性能调优][JVM 28]

废话不多说，直接来示例，上干货！

package com.yhj.jvm.monitor.io;

import java.io.BufferedWriter;

import java.io.FileWriter;

import java.io.IOException;

import java.util.concurrent.ExecutorService;

import java.util.concurrent.Executors;

/\*\*

\* @Described：IO测试用例

\* @author YHJ create at 2012\-3\-29 上午09:56:06

\* @FileNmae com.yhj.jvm.monitor.io.IO\_TestCase.java

\*/

public class IO\_TestCase \{

private String fileNmae = "monitor.log";

private String context ;

// 和CPU处理器个数相同，既充分利用CPU资源，又导致线程频繁切换

private final static int THRED\_COUNT = Runtime.getRuntime().availableProcessors();

public IO\_TestCase() \{ //加长写文件的内容，拉长每次写入的时间

StringBuilder sb = new StringBuilder();

for(int i=0;i<1000;++i)\{

sb.append("context index :")

.append(i)

.append("\\n");

this.context= new String(sb);

//写文件任务

class Task implements Runnable\{

@Override

public void run() \{

while(true)\{

BufferedWriter writer = null;

try \{

writer = new BufferedWriter(new FileWriter(fileNmae,true));//追加模式

writer.write(context);

\} catch (Exception e) \{

e.printStackTrace();

\}finally\{

try \{

writer.close();

\} catch (IOException e) \{

e.printStackTrace();

//启动函数

public void start()\{

ExecutorService service = Executors.newCachedThreadPool();

for(int i=0;i<THRED\_COUNT;++i)

service.execute(new Task());

//主函数入口

public static void main(String\[\] args) \{

new IO\_TestCase().start();

这段示例很简单，通过创建一个和CPU个数相同的线程池，然后开启这么多线程一起读写同一个文件，这样就会因IO资源的竞争而导致IO的队列很高，如下图所示：

![深入理解JVM性能调优][JVM 29]

关掉之后马上就下来了

![深入理解JVM性能调优][JVM 30]

我们把这个部署到

Linux  上观看。

![深入理解JVM性能调优][JVM 31]

这里的

%idle  指的是系统没有完成写入的数量占用  IO  总量的百分百，为什么这么高我们的系统还能承受？因为我这台机器的内存为 16GB  的，我们来查看以下  top  视图就可以清晰的看到。

![深入理解JVM性能调优][JVM 32]

占用了大量的内存资源。

三、内存消耗

对于JVM的内存模型大家已经很清楚了，前面我们讲了JVM的性能监控工具。对于Java应用来说，出现问题主要消耗在于JVM的内存上，而JVM的内存，JDK已经给我们提供了很多的工具。在实际的生成环境，大部分应用会将\-Xms和\-Xmx设置为相同的，避免运行期间不断开辟内存。

对于内存消耗，还有一部分是直接物理内存的，不在堆空间，前面我们也写过对应的示例。之前一个系统就是因为有大量的NIO操作，而NIO是使用物理内存的，并且开辟的物理内存是在触发FULL GC的时候才进行回收的，但是当时的机器总内存为16GB 给堆的内存是14GB Edon为1.5GB，也就是实际剩下给物理呢哦村的只有0.5GB，最终导致总是发生内存溢出，但监控堆、栈的内存消耗都不大。在这里我就不多写了！

四、网络消耗过大

Windows下使用本地网络视图可以监控当前的网络流量大小

![深入理解JVM性能调优][JVM 33]

更详细的资料可以打开资源监视器，如下图所示

![深入理解JVM性能调优][JVM 34]

Linux

平台可以使用以下  sar  命令查看

sar -n DEV 1 2

![深入理解JVM性能调优][JVM 35]

字段说明：

rxpck/s：每秒钟接收的数据包

txpck/s：每秒钟发送的数据包

rxbyt/s：每秒钟接收的字节数

txbyt/s：每秒钟发送的字节数

rxcmp/s：每秒钟接收的压缩数据包

txcmp/s：每秒钟发送的压缩数据包

rxmcst/s：每秒钟接收的多播数据包

Java程序一般不会出现网络IO导致问题，因此在这里也不过的的阐述。

五、程序执行缓慢

当CPU、内存、磁盘、网络都不高，程序还是执行缓慢的话，可能引发的原因大致有以下几种：

1程序锁竞争过于激烈，比如你只有2颗CPU，但是你启用了200个线程，就会导致大量的线程等待和切换，而这不会导致CPU很高，但是很多线程等待意味着你的程序运行很慢。

2未充分利用硬件资源。比如你的机器是16个核心的，但是你的程序是单线程运行的，即使你的程序优化的很好，当需要处理的资源比较多的时候，程序还会很慢，因此现在都在提倡分布式，通过大量廉价的PC机来提升程序的执行速度！

3其他服务器反应缓慢，如数据库、缓存等。当大量做了分布式，程序CPU负载都很低，但是提交给数据库的sql无法很快执行，也会特别慢。

总结一下，当出现性能问题的时候我们该怎么做？

一、CPU过高

1、  us过高

使用监控工具快读定位哪里有死循环，大计算，对于死循环通过阻塞式队列解决，对于大计算，建议分配单独的机器做后台计算，尽量不要影响用户交互，如果一定要的话（如框计算、云计算），只能通过大量分布式来实现

2、  sy过高

最有效的方法就是减少进程，不是进程越多效率越高，一般来说线程数和CPU的核心数相同，这样既不会造成线程切换，又不会浪费CPU资源

二、内存消耗过高

1、  及时释放不必要的对象

2、  使用对象缓存池缓冲

3、  采用合理的缓存失效算法（还记得我们之前提到的弱引用、幽灵引用么？）

三、磁盘IO过高

1、  异步读写文件

2、  批量读写文件

3、  使用缓存技术

4、  采用合理的文件读写规则

四、网络

1、增加宽带流量

五、资源消耗不多但程序运行缓慢

1、使用并发包，减少锁竞争

2、对于必须单线程执行的使用队列处理

3、大量分布式处理

六、未充分利用硬件资源

1、  修改程序代码，使用多线程处理

2、  修正外部资源瓶颈，做业务拆分

3、  使用缓存

转自：http://yhjhappy234.blog.163.com/blog/static/3163283220122298232721/?suggestedreading&wumii

[JVM]: /images/20220605/12ffe922118c4ac68d26c11afb995a3c.png
[JVM 1]: /images/20220605/33a1e84346484fc093158fd281d37532.png
[JVM 2]: /images/20220605/26657b5befeb4be5a7f9b847c34032f1.png
[JVM 3]: /images/20220605/1f4b8304e3344c0a88baa639158903cc.png
[http_sebastien.godard.pagesperso-orange.fr_download.html]: http://sebastien.godard.pagesperso-orange.fr/download.html
[JVM 4]: /images/20220605/78029942b5da48f1aa494d1c2315e8ae.png
[JVM 5]: /images/20220605/fc26d058bc084efc8e71cff6c9dba942.png
[JVM 6]: /images/20220605/1dc525e5839f4961bdc735de6d817a66.png
[JVM 7]: /images/20220605/696d65eaadb34194a60d41992b831243.png
[JVM 8]: /images/20220605/a8b41f69be0946f086f13d619f0c2210.png
[JVM 9]: /images/20220605/9cd79f18c3e74e5aab72545fb2515177.png
[JVM 10]: /images/20220605/51f72496846140819dbc43a696779d2d.png
[JVM 11]: /images/20220605/354d470853df441e826416442d816931.png
[JVM 12]: /images/20220605/fb8c409995714edb84529b3ce3653b10.png
[JVM 13]: /images/20220605/ba18df27f56d4b8ba40ff72d577f5207.png
[JVM 14]: /images/20220605/50f02728e95f4c0fb378ad689b36d945.png
[JVM 15]: /images/20220605/4f10781144c34fe78134d0953f65dd1b.png
[JVM 16]: /images/20220605/f1d2e29d11834d3ca7d1342a74c0ad29.png
[JVM 17]: /images/20220605/b52926bf215c40e9b502a7a85cfdd6aa.png
[JVM 18]: /images/20220605/0b4cd64500104571b852e88e760d4116.png
[JVM 19]: /images/20220605/eb1efc9d9f90410aa14213dc0748e4b3.png
[JVM 20]: /images/20220605/c724a1bd3dde496a8ddf1cd1cd6af36a.png
[JVM 21]: /images/20220605/98f1a9e2d5414a9f89ffbde8acc0f619.png
[JVM 22]: /images/20220605/1748d544c39b46d58d11ab3a14db95a0.png
[JVM 23]: /images/20220605/b68b8627de634c27a81a19a661bb335c.png
[JVM 24]: /images/20220605/f6c6355853a548608e2f1078323bc833.png
[JVM 25]: /images/20220605/0e072f9842f84e5b949d8f90a5c1c679.png
[JVM 26]: /images/20220605/8f82cd41801845c89423791b7c00f4b8.png
[JVM 27]: /images/20220605/1de248bd25c140a1b409ef9b26bd7adb.png
[JVM 28]: /images/20220605/b104359a546b4d279de06eda46a337d8.png
[JVM 29]: /images/20220605/35357485bff54c9da3d18ff0752ad459.png
[JVM 30]: /images/20220605/cf5aeaa83aff4da786749aeabadcbad0.png
[JVM 31]: /images/20220605/e84fc1197c0642339d29ebcfe454e6ca.png
[JVM 32]: /images/20220605/f2cbf56b9eff4a0798e10bb7216ce2cb.png
[JVM 33]: /images/20220605/c3767119b99d44b2af25368486469498.png
[JVM 34]: /images/20220605/5cac682c80e446ec9b9752341cfe833c.png
[JVM 35]: /images/20220605/d8b03cf8303f427e86ac4dd279994c8f.png