我正在尝试分析从我的 tomcat 服务器获取的线程转储。其中一个线程转储是在正常运行几分钟后获取的,显示线程池大约有 70 个,其中有几个处于 WAITING 状态。我留下了一个脚本在一夜之间命中服务器,然后在早上进行了另一个线程转储。比较两个转储时,我可以看到线程池已从 70 个线程增加到 90 个线程。我还可以看到相同的线程在一个转储和另一个转储之间处于 WAITING 状态,同时添加了 20 个新线程。这是否表明我的应用程序中存在一些错误或者这是标准行为?我想知道为什么不重新使用等待中的线程,而是创建新线程。我假设线程从一个转储到另一个转储根本没有被重新使用,因为在转储文件中它将它们报告为“正在等待”,其中 <> 中的数字从一个转储到另一个转储是相同的,这是这个假设对吗?
例如,从我最初的线程转储中我看到了这个:
"http-8000-40" - Thread t@74
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <4fd24389> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at java.lang.Object.wait(Object.java:485)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:458)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:484)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
然后我可以在第二天早上的转储中看到相同的线程处于相同的状态并等待相同的对象:(我根据“<>”中的数字假设这一点)
"http-8000-40" - Thread t@74
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <4fd24389> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
at java.lang.Object.wait(Object.java:485)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:458)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:484)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
最佳答案
Tomcat 需要花费一些时间来管理线程和其他资源,即使在您的 Web 应用程序代码完成请求处理之后也是如此。为了跟上负载,Tomcat 将在没有足够线程可用时分配新线程。
如果您总共有 70 个线程和 70 个并发请求,一切都应该没问题。如果一个请求(共 70 个)完成(即客户端已接收到所有数据)并且在 Tomcat 完全完成请求处理器线程之前发出另一个请求,则将分配另一个线程来处理在大小为 71 的线程池。
这可能会发生很多次,因为上下文切换、GC 暂停等可能会干扰服务器上发生的所有事情的准确时间,因此它不是确定性的。
关于线程池增加时 Apache Tomcat 线程处于等待状态,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16960957/