首先，我是一个.NET人，所以我在这里有点不合时宜。
我的客户的供应商为他们的产品提供了一个在Tomcat中托管的API。该服务似乎“坚持”了几天前的请求。
我的信念是，他们的API代码中没有正确的错误处理，只是陷入无休止的循环中，一遍又一遍地重试请求。他们不会说出问题所在，而只是告诉我的客户重启Tomcat。
这已经成为一个问题，供应商现在建议安排一项任务来每天重启Tomcat。但是，有些服务可以按需调用API（来自零售消费者）。
那里的专家可以支持我吗？我不相信Tomcat有任何本质错误需要重启。构建在它之上的“严重”应用程序太多，永远不会容忍这种错误。它 是来自它们（供应商）的错误编码。或者是否存在可能导致这些“死线程”的已知配置/平台问题？
非常感谢任何见解。
答案 0 :(得分：1)
要分析卡住的线程，您需要进行线程转储并将其传递给供应商（或编写代码的人）进行分析。如果您不知道如何进行线程转储，您可以谷歌找出适合您环境的程序 坚持线程可能是因为一个线程持有网络资源而不放手。错误的编码也是一个问题 定期重新启动不是最佳选择，但在找到永久性解决方案之前，它可能是一种临时解决方法。