Linux排查java程序CPU占用过高问题

最新推荐文章于 2025-04-23 10:34:44 发布

菜鸟要成长zz

最新推荐文章于 2025-04-23 10:34:44 发布

阅读量577

点赞数

分类专栏： JVM 文章标签： jdk java jvm linux 多线程

本文链接：https://blog.youkuaiyun.com/weixin_44688581/article/details/116528413

版权

JVM 专栏收录该内容

2 篇文章

订阅专栏

博客内容讲述了在服务器上部署的Java项目出现CPU占用过高的情况，通过`top`命令定位到问题出在Druid线程池。使用`jstack`工具分析线程状态，发现多个Druid线程处于等待状态，如LogStatsThread、DestroyConnectionThread和CreateConnectionThread。这些线程可能因数据库连接问题导致资源占用异常。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

项目部署到服务器上之后，偶尔出现CPU被java程序占满的情况。
现在排查问题原因

top

首先查看系统资源占用信息，使用命令

top

发现正在运行的JAVA项目CPU占用率如果很高，那问题肯定出在这个程序中。

top -H -p[进程ID]

得到进程ID后，我们需要获取到具体的线程ID，然后用jstack分析。

top -H -p[进程ID]

需要将线程ID转换为十六进制，直接在Linux中即可转换。

printf “%x\n” [线程十进制数]

补充：\n只为换行显示，单纯的转换只需要%x 即可

printf "%x\n" [线程十进制数]

得到十六进制数之后可以使用JDK提供的jstack进行分析。

使用jstack分析

jstack是JDK自带的堆栈分析工具，如果是Java程序导致的服务器CPU占用异常，大家可以利用此工具进行排查。

jstack 【进程ID】 | grep 0x【线程ID十六进制】 -A 30(显示后30行)

如果提示 -bash: jstack: command not found，则可以找到jdk的目录，进入bin目录，

结果排查

如果是代码错误直接显示出来某个类那一行出现问题，可以根据代码排查。
现在排查到是因为德鲁伊线程池连接数据库出现问题，尚未解决。

"Druid-ConnectionPool-Log-443267826" #482142 daemon prio=5 os_prio=0 tid=0x00007f5aa85bb000 nid=0x29bb waiting on condition [0x00007f5a1b2c7000]

   java.lang.Thread.State: TIMED_WAITING (sleeping)

        at java.lang.Thread.sleep(Native Method)

        at com.alibaba.druid.pool.DruidDataSource$LogStatsThread.run(DruidDataSource.java:2219)



"Druid-ConnectionPool-Destroy-790650151" #482141 daemon prio=5 os_prio=0 tid=0x00007f5aa8b34000 nid=0x29ba sleeping[0x00007f5a1b3c8000]

   java.lang.Thread.State: TIMED_WAITING (sleeping)

        at java.lang.Thread.sleep(Native Method)

        at com.alibaba.druid.pool.DruidDataSource$DestroyConnectionThread.run(DruidDataSource.java:2172)



"Druid-ConnectionPool-Create-790650151" #482140 daemon prio=5 os_prio=0 tid=0x00007f5aa8b32800 nid=0x29b9 waiting on condition [0x00007f5a1b4c9000]

   java.lang.Thread.State: WAITING (parking)

        at sun.misc.Unsafe.park(Native Method)

        - parking to wait for  <0x00000006ebcbcd18> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)

        at com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread.run(DruidDataSource.java:2079)



"Druid-ConnectionPool-Log-790650151" #482139 daemon prio=5 os_prio=0 tid=0x00007f5aa97d8000 nid=0x29b8 waiting on condition [0x00007f5a1b5ca000]

   java.lang.Thread.State: TIMED_WAITING (sleeping)

        at java.lang.Thread.sleep(Native Method)

        at com.alibaba.druid.pool.DruidDataSource$LogStatsThread.run(DruidDataSource.java:2219)



"Druid-ConnectionPool-Destroy-504900470" #482138 daemon prio=5 os_prio=0 tid=0x00007f5aa97d6800 nid=0x29b7 sleeping[0x00007f5a1b6cb000]

--

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f5af0024000 nid=0x1a7b runnable 



"VM Periodic Task Thread" os_prio=0 tid=0x00007f5af0192800 nid=0x1a84 waiting on condition