tomcat cpu占用过高的问题

妈了个鸡腿 2019-06-28 10:56:08

确定是以下两个Thread占用过高，求问如何解决？

"ajp-nio-8009-ClientPoller-0" #53 daemon prio=5 os_prio=0 tid=0x000000001af75800 nid=0x3f6c runnable [0x000000001f38e000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:296)
at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:278)
at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:159)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x000000008045c548> (a sun.nio.ch.Util$3)
- locked <0x000000008045c538> (a java.util.Collections$UnmodifiableSet)
- locked <0x000000008045c3c8> (a sun.nio.ch.WindowsSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:825)
at java.lang.Thread.run(Thread.java:748)

Locked ownable synchronizers:
- None

"NioBlockingSelector.BlockPoller-2" #25 daemon prio=5 os_prio=0 tid=0x000000001a6a6000 nid=0x2c2c runnable [0x000000001c7bf000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:296)
at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:278)
at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:159)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x0000000080473840> (a sun.nio.ch.Util$3)
- locked <0x0000000080473830> (a java.util.Collections$UnmodifiableSet)
- locked <0x0000000080469600> (a sun.nio.ch.WindowsSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at org.apache.tomcat.util.net.NioBlockingSelector$BlockPoller.run(NioBlockingSelector.java:298)

Locked ownable synchronizers:
- None

...全文

537 5 打赏收藏转发到动态举报

写回复

5 条回复

切换为时间正序

请发表友善的回复…

发表回复

妈了个鸡腿 2019-07-10

打赏
举报

回复

回复一下，我是在虚拟机里调试的时候重新部署就很容易出现cpu很高的问题，但是在使用时暂时还没有出现这种情况。

K G 2019-07-08

打赏
举报

回复

你是不是设置成主线程了

「已注销」 2019-07-02

打赏
举报

回复

优化下代码

Blue_Shen_SH 2019-06-28

打赏
举报

回复

windows下可以试试性能查看

妈了个鸡腿 2019-06-28

打赏
举报

回复

引用 1 楼 Abel_Shen_G 的回复:

windows下可以试试性能查看

可以说具体点么？

本文主要记录一次tomcat进程，因TCP连接过多导致CPU占用过高的问题排查记录。问题描述 linux系统下，一个tomcat web服务的cpu占用率非常高，top显示结果超过200%。请求无法响应。反复重启依然同一个现象。问题排查 1、获取进程信息通过jdk提供的jps命令可以快速查出jvm进程， jps pid 2、查看jstack信息 jstack pid 发现存在大量log4j线程block，处于waiting lock状态 org.apache.log4j.Category.callAppenders(org.apache.log4j.spi.LoggingE

分析tomcat占用cpu高的原因

tomcat cpu hightomcat cpu high

资源下载链接为： https://pan.quark.cn/s/abbae039bf2a 在 Java 应用开发中，CPU 使用率过高是一个常见且棘手的问题，它会严重影响服务器性能，甚至导致系统不稳定。本文将分享一次 Java 应用导致 CPU 占用过高的排查实践。当发现应用 CPU 使用率异常时，首先需确认是否因计算密集型任务所致。但多数情况下，CPU 高负荷是程序逻辑错误导致的，如死循环，使得 CPU 资源无法释放。文中案例就是一个典型例子：服务器上一个运行在 Tomcat 容器中的 Java 应用，重新部署时因未正确终止 Tomcat 进程，导致数据库连接池锁未正常释放，进而引发死循环。排查时，可借助 Linux 系统工具初步诊断。top 命令能监控系统资源使用情况，可快速定位占用 CPU 资源最多的进程。案例中，top 显示进程 ID 为 31737 的进程 CPU 使用率极高。进一步使用 top -Hp 31737 查看该进程内部线程 CPU 使用情况，发现线程 ID 为 5322（十六进制为 14ca）的线程 CPU 使用异常。为定位问题具体位置，可使用 JDK 自带的 jstack 工具。jstack 可打印 Java 进程线程堆栈信息，通过 jstack 31737 | grep -10 14ca，找到线程 14ca 相关堆栈信息，发现线程状态为 TIMED_WAITING，即等待特定条件满足，推测可能是锁或其他同步机制导致的阻塞。结合问题现象和 jstack 输出，推断问题可能出在数据库连接池管理上。Stack Overflow 上有答案指出，在 Tomcat 下重新部署应用时，若旧的 Tomcat 进程未被杀死，可能导致数据库连接池锁无法释放。原因可能是旧的 Tomcat 实例仍持有某些数据库连接，而新部署尝试获取这些连接，从而产生死锁或长时间等待

一个应用占用CPU很高，除了确实是计算密集型应用之外，通常原因都是出现了死循环。下面这篇文章主要给大家介绍了一次因Java应用造成CPU过高的排查实践过程，文中通过示例代码介绍的非常详细，需要的朋友可以参考下

81,117

社区成员

341,739

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章