java程序启动时cpu和负载高探索

最新推荐文章于 2024-07-21 22:13:41 发布

原创最新推荐文章于 2024-07-21 22:13:41 发布 · 1.2w 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#java #虚拟机 #类加载

编程语言专栏收录该内容

27 篇文章

订阅专栏

本文讲述了作者在定位一个简单Java监控程序CPU占用率高达150%的问题过程中，发现类加载可能是导致CPU高的原因。Java虚拟机在启动时会加载所有依赖类，即使在main函数中未直接使用，也会触发类加载，导致CPU消耗。建议频繁启动的监控程序避免使用Java或采用非Java语言编写，以减少CPU负载。

这两天协助运维定位1个监控程序CPU占用率达到150%的问题，过程曲折，结论简单，很有意思：）

首先我们来看一下cpu高时候截图：

可以看到红色框中的监控程序CPU占用率都很高，但其实这些监控程序的实现很简单：发送1个http请求，收到响应后简单判断一下响应码，然后打印监控结果，打印完成就退出了。每次监控都会重新由daemon程序拉起运行。

这么简单的业务占用这么高的cpu，怎么感觉都不太可能，于是拿到监控程序的源码开始定位。

第一个想到的是VisualVm、JConsole等工具，但由于程序很快就运行完成了，这两个工具都还没有连接上就结束了，而且拿到的数据也没法看出具体是什么原因导致cpu高，尝试了一下就放弃了。

第二个尝试是用strace去跟踪程序的调用，结果摘录如下（省略很多）：

17572 14:08:43.552199 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9949000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.562857 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.563029 clock_gettime(CLOCK_REALTIME, {1423721323, 563056000}) = 0
17572 14:08:43.563119 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9936000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.573913 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.574159 clock_gettime(CLOCK_REALTIME, {1423721323, 574214000}) = 0
17572 14:08:43.574253 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9925000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.584885 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.585055 clock_gettime(CLOCK_REALTIME, {1423721323, 585081000}) = 0
17572 14:08:43.585147 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9936000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.595900 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.596170 clock_gettime(CLOCK_REALTIME, {1423721323, 596206000}) = 0
17572 14:08:43.596245 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9947000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.606960 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.607139 clock_gettime(CLOCK_REALTIME, {1423721323, 607167000}) = 0
17572 14:08:43.607232 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9935000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.617875 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.618119 clock_gettime(CLOCK_REALTIME, {1423721323, 618209000}) = 0
17572 14:08:43.618249 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9890000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.628960 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.629140 clock_gettime(CLOCK_REALTIME, {1423721323, 629168000}) = 0
17572 14:08:43.629231 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9935000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.639865 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.640134 clock_gettime(CLOCK_REALTIME, {1423721323, 640167000}) = 0
17572 14:08:43.640206 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9946000}) = -1 ETIMEDOUT (Connection timed out)
17572 14:08:43.650868 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0
17572 14:08:43.651139 unlink("/tmp/hsperfdata_gamedata/17559") = 0
17572 14:08:43.651324 exit_group(0)     = ?

怎么那么多futex，google一查“futex connection time out”，嘿，还真有很多结果，最典型的就是leap second,中文翻译为“闰秒”，但仔细一看，上一次闰秒发生是2012年06月份，现在都2015年了，而且天天cpu都高，应该不是这个问题

工具指望不上，只好看代码，代码看了后怀疑几个地方：

1）CountDownLatch：因为这个最有可能用到futex了，但实际想了想和验证了一下，这个东东不可能导致cpu这么高，真有这个问题，这东东完全就没法用了

2）多线程：看了代码，没有几个线程，而且业务就是一发一收，不可能多线程导致的

问题陷入僵局，怎么办呢？只好用终极大招了：分段注释！

1）注释响应处理的代码 —— 不行，cpu占用100%

2）注释发送请求的代码 —— 还是不行，，cpu占用100%

这不坑爹嘛，请求都不发，响应也没有了，你咋还这么慢？

3）干脆注释所有代码，只在main里面打印Hello world —— 还是不行，，cpu占用100%

这下就蛋疼了，没有任何业务，你cpu还高，这不坑我嘛

4）自己写个Hello world —— 咦，这次可以了，cpu占用1%左右

咋回事，同样都是打印Hello world，为啥cpu差别那么大？

左思右想，突然灵光一闪：难道是和jvm加载类文件有关？

jvm在启动的时候会装载并连接所有除反射以外的类，而class文件是二进制的文件，需要从磁盘加载到内存然后解析，这种解析是很耗费cpu的，那么class文件越多，cpu耗费就越高，这正好解释了为什么同样输出Hello world，不同程序cpu占用率差别很大。

这个推论正好也解释了之前遇到的另外一个线上项目的现象：每次启动后有大约1分钟左右系统的cpu和负载很高，过了1分钟后就恢复正常了。

【建议】

需要重复运行的监控类程序，如果用java写，最好不要做成每次都要重新启动，而是在程序里面循环或者定时运行；

如果一定要每次都要重新启动，频率又很频繁的话，建议用shell、python之类的来写，否则一台机器运行太多java类的工具程序，会导致cpu和负载飙升

===============2015.02.13补充====================================

昨晚完成博客后，脑海中梳理整个流程发现还是有一点疑问：java虚拟机都是按需加载类的，那么我的main函数里面完全没有用到任何其它类，为何还是会加载呢？

今天针对这个问题继续查阅相关资料，发现原来所谓的“使用”，并不单单指我们通常编码所说看到的new、方法调用，而且还包括“依赖”。

举个简单例子：

package common;

import java.util.*;

public class CommonTester {

    public static void main(String[] args) {
        System.out.println("Hello, world......");
    }

    /**
     * 这个函数在main里面并没有调用，但jvm还是会加载ArrayList类，因为CommonTester内依赖了ArrayList类
     * @return
     */
    public List<String> createStringList(){
        return new ArrayList<String>(100);
    }
}

以上这个例子中，CommonTester类在main函数中并没有调用crateStringList方法，但因为CommonTester类依赖ArrayList类，那么在加载CommonTester的时候发现其依赖ArrayList类，就会先加载ArrayList类。

所以，jvm最开始启动的时候肯定是先加载main函数所在的类，但是在加载这个类的时候发现依赖其它类，就会先加载其它类；加载其它类的时候也是这样处理，就像一个链式反应一样，所以基本上除了反射的类外，大部分类在jvm启动后，运行main函数前就已经加载完毕了。

为了验证这个推论，重新做了验证：

1）main函数所在的类注释所有其它代码，只保留main函数里面的打印语句

验证结果：cpu占用和自己写的简单的hello world程序一样，占用率大约1%左右

2）main函数所在的类注释所有其它代码，但保留import语句和main函数里面的打印语句

验证结果：和上面的一样，这个也很好理解，只保留import语句，因为这些语句并没有用，编译的时候这些语句都被优化掉了

==============2015.02.13第二次补充===========================

组内分享后，有同学又提出了一个疑问：jvm加载类的时候是多线程还是单线程？

为了回答这个问题，先后看了一些电子书和java官方的jvm规范，但都没有找到答案，于是决定自己来验证一下。

经过一番探索，终于找到1个很好的方法来判断类加载是单线程还是多线程。方法具体如下：

1）使用java -verbose启动程序，这样程序运行时就会打印加载的类

2）使用strace跟踪，就可以知道哪些线程加载了类

具体的命令为：strace -T -f -q -s 1024 -o strace.txt java -verbose .............（省略号代表具体的程序运行相关参数）

通过查看strace输出的结果，发现如下现象：

1）多个线程都会去加载类

2）同一线程需要用到的类如果还没有加载，则自己会去加载，不会再委托给其它线程加载

注：验证环境的jvm信息如下，不同的虚拟机可能有不同的实现：

java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

=============2015.07.13补充==================================

对于java6，有一个选项可以加快启动过程：-XX:CICompilerCount，对于线上业务，如果没有预热，启动后立刻有大量请求涌入，此时会出现cpu负载高，原因在于刚开始运行时Java都是解释执行，速度较慢，然后才逐渐用JIT将代码编译为本机二进制代码，JIT默认线程数只有2个，处理较慢。通过这个选项可以加快JIT的执行速度，降低启动后CPU负载高的时间。

但这个选项对于工具类java程序不能这样配置，同一台机器运行太多工具类，如果同时启动的话，因为线程数太多，负载会非常高

java7有一个自适应的选项：-XX:+TieredCompilation，能够根据CPU核数自动调整，有兴趣的同学可以研究一下

=======================================================

转载请注明出处：http://blog.youkuaiyun.com/yunhua_lee/article/details/43765371