作为一个已经有近4年经验的java程序员,实在不满足于每天的CURD操作,总是想给自己找点有意思的事研究研究,闲来无事,查看服务器java程序cpu占用情况,发现有个java进程cpu占用一直在80%左右,虽然还没有导致程序崩溃,但是看着总是不舒服的。
服务器运行 top 命令,然后按 c 就可以查看程序cpu占用情况
![9bf642abc8e2a6f8a42a0588cd90c6f0.png](https://img-blog.csdnimg.cn/img_convert/9bf642abc8e2a6f8a42a0588cd90c6f0.png)
排在第一位的这个占用了80%,还刚好就是我的程序,惭愧惭愧。不过也刚好让我来练手。
找到进程的 PID 16322
然后根据pid查出该进程中所有的线程 top -Hp 16322
找到cpu占用最高的线程的 PID 16388
![0d9a3e0adf4e44d7815fec9d155584ea.png](https://img-blog.csdnimg.cn/img_convert/0d9a3e0adf4e44d7815fec9d155584ea.png)
注意:我这里截得图是我优化之后的,之前的图忘了保存,意思是一样的,找到cpu占用最高的线程的pid即可,pid转为16进制--->4004
然后执行命令: jstack 16322|grep 4004 -A 30 查看该线程打印的堆栈,看看到底是哪里的代码有问题。
![2432e4b94a824e739ac99bd64cf13d76.png](https://img-blog.csdnimg.cn/img_convert/2432e4b94a824e739ac99bd64cf13d76.png)
由堆栈信息可以看出我代码中的69行可能有问题。打开代码
![8c2e8080523388da0ba9eaf7ea0afc52.png](https://img-blog.csdnimg.cn/img_convert/8c2e8080523388da0ba9eaf7ea0afc52.png)
这行代码其实完成的功能也简单,就是把字符串转为一个List对象,用的是 net.sf.json.JSONArray 这个包的方法。我猜测是这个效率太低导致的,于是main方法对比测试。
拿这个包和fastjson包对比:
![8d0599bf96fe6e9d69764485ba5e5671.png](https://img-blog.csdnimg.cn/img_convert/8d0599bf96fe6e9d69764485ba5e5671.png)
运行查看用时:
![352438b263a6f23c742e8efcdb8bc86e.png](https://img-blog.csdnimg.cn/img_convert/352438b263a6f23c742e8efcdb8bc86e.png)
多次运行发现,fastjson普遍比sf包快近1倍,然后修改代码,替换工具类为fastjson,提交代码,再次运行。
![86327e5128992e4f1fce531c6a095bcd.png](https://img-blog.csdnimg.cn/img_convert/86327e5128992e4f1fce531c6a095bcd.png)
可以看到,cpu占用从之前的80%左右立马降到了百分之十几,哈哈哈,真爽!