深入理解JVM性能调优

最新推荐文章于 2022-04-19 17:16:09 发布

曾燕辉

最新推荐文章于 2022-04-19 17:16:09 发布

阅读量156

点赞数

分类专栏： Java 性能优化

Java 同时被 2 个专栏收录

112 篇文章 1 订阅

订阅专栏

性能优化

12 篇文章 0 订阅

订阅专栏

转载自：https://blog.csdn.net/elvis_lfc/article/details/52313400

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

一、CPU过高。

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

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

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

在

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

我们也可以通过

sysstat 工具集的 pidstat 来查看

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

安装方法:

1、chmod +x configure

2、./configure

3、make

4、make install

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

除了

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

相关

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

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

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

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

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

对于一个

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

很明显是我们的

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

首先我们排除了是

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

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

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

private BlockingQueue queue;

private Executor executor;

//……

publicvoid run() {

while(true){

try {

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

if(null != sendMsg) {

sendForQueue(sendMsg);

}

} catch (Exception e) {

e.printStackTrace();

}

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

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

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

@Override

publicvoid run() {

while(true){

}

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

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

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

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

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

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

@Override

publicvoid run() {

while(true){

try {

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

sendForQueue(sendMsg);

} catch (Exception e) {

e.printStackTrace();

}

再来监控

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

再来看

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

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

以上示例展示了

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

publicclass SY_Hign_TestCase {

privatefinalstaticintLOCK_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();

}

abstractclass Task implements Runnable{

protected Object lock;

public Task(int index) {

this.lock= locks[index];

}

@Override

publicvoid run() {

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

doSth();

}

//做类自己要做的事情

publicabstractvoid doSth();

}

//任务A 休眠自己的锁

class TaskA extends Task{

public TaskA(int index) {

super(index);

}

@Override

publicvoid 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

publicvoid doSth() {

try {

synchronized (lock) {

lock.notifyAll();

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

}

} catch (InterruptedException e) {

e.printStackTrace();

}

//启动函数

publicvoid start(){

ExecutorService service = Executors.newCachedThreadPool();

for(int i=0;i<LOCK_COUNT;++i){

service.execute(new TaskA(i));

service.execute(new TaskB(i));

}

//主函数入口

publicstaticvoid main(String[] args) {

new SY_Hign_TestCase().start();

}

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

很明显，

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

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

CPU 资源。

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

展开对应的

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

大家可以看到有大量的

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

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

二、文件

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

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

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

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

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

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

Iostat

Iostat –x xvda 1 10做定时采样

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

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

publicclass IO_TestCase {

private String fileNmae = "monitor.log";

private String context ;

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

privatefinalstaticintTHRED_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

publicvoid 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();

}

//启动函数

publicvoid start(){

ExecutorService service = Executors.newCachedThreadPool();

for(int i=0;i<THRED_COUNT;++i)

service.execute(new Task());

}

//主函数入口

publicstaticvoid main(String[] args) {

new IO_TestCase().start();

}

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

关掉之后马上就下来了

我们把这个部署到

Linux 上观看。

这里的

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

占用了大量的内存资源。

三、内存消耗

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

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

四、网络消耗过大

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