太多停车等待线程

Posted 2023-03-23

【中文标题】太多停车等待线程

【英文标题】：Too many parking to wait threads

【发布时间】：2018-05-29 18:23:00

【问题描述】：

我正在分析一个应用程序挂起，通过线程转储，我有 90% 的工作线程处于这种状态：

"pool-3-thread-352" #13082 prio=5 os_prio=0 tid=0x00007ff6407fc800 nid=0x1e94 等待条件 [0x00007ff5a53b4000] java.lang.Thread.State：TIMED_WAITING（停车）在 sun.misc.Unsafe.park（本机方法） - 停车等待 (a java.util.concurrent.SynchronousQueue$TransferStack) 在 java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 在 java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460) 在 java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362) 在 java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 在 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 在 java.lang.Thread.run(Thread.java:748)

"pool-21-thread-214" #13081 prio=5 os_prio=0 tid=0x0000000002e6a800 nid=0x1e92 等待条件 [0x00007ff5a54b5000] java.lang.Thread.State：TIMED_WAITING（停车）在 sun.misc.Unsafe.park（本机方法） - 停车等待 (a java.util.concurrent.SynchronousQueue$TransferStack) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 在 java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460) 在 java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362) 在 java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 在 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 在 java.lang.Thread.run(Thread.java:748)

据我了解，这些基本上是 tomcat 服务器上的请求工作线程，在阻塞队列上等待直到请求到来。当请求到来时，一个线程将获得许可并运行以执行请求。

因此，如果没有可用的任务，这些线程将在队列中等待（停放）。当任务可用时，一个工作线程将获得许可并成为运行线程。它将执行任务。

但是如果线程池中创建的线程过多并且它们会占用资源，这些线程仍然会导致问题。

发现零死锁，但应用仍然挂起，几乎所有类型的异常：

javax.ws.rs.ProcessingException: RESTEASY004655: Unable to invoke request
    at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
    at com.agfa.orbis.core.client.service.rest.ClientHttpEngineWrapper.invoke(ClientHttpEngineWrapper.java:59)
    at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:436)
    at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.get(ClientInvocationBuilder.java:159)
    at com.agfa.hap.crs.commons.client.rest.RestClient.getResponse(RestClient.java:238)
    at com.agfa.hap.crs.commons.client.rest.RestClient.get(RestClient.java:70)
    at com.agfa.hap.crs.alertsystem.client.orbis.ForwardedUserAlertsMonitor.getSharedAlertState(ForwardedUserAlertsMonitor.java:88)
    at com.agfa.hap.crs.alertsystem.client.orbis.ForwardedUserAlertsMonitor.getCurrentAlertState(ForwardedUserAlertsMonitor.java:79)
    at com.agfa.hap.crs.alertsystem.client.orbis.AbstractAlertMonitor.requestMonitorUpdate(AbstractAlertMonitor.java:275)
    at com.agfa.hap.crs.alertsystem.client.orbis.AbstractAlertMonitor$10.execute(AbstractAlertMonitor.java:823)
    at com.agfa.hap.crs.alertsystem.client.orbis.AbstractAlertMonitor$Task.call(AbstractAlertMonitor.java:952)
    at com.agfa.hap.crs.alertsystem.client.orbis.AbstractAlertMonitor$Task.call(AbstractAlertMonitor.java:942)
    at com.agfa.hap.crs.alertsystem.client.orbis.AbstractAlertMonitor$TaskWrapper.call(AbstractAlertMonitor.java:925)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:992)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
    at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
    at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
    at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
    at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:283)
    ... 16 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
    at sun.security.ssl.InputRecord.read(InputRecord.java:505)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
    ... 29 more

我希望通过线程活动来链接这些异常！！！ 知道为什么连接关闭不正确吗？！！！！

【问题讨论】：

死锁？ SpotBugs 应该能够找到两个线程，其中两个条件导致死锁。

发现零死锁！！应用仍然挂了很长时间，异常在日志中到处都是。

等待中的空闲线程不会导致应用程序挂起。应用程序代码如何从异常中恢复（例如上面的 SSL 异常）？发生异常时是否正确关闭所有资源？究竟是什么症状让您认为应用程序挂起？

应用程序接口挂起，每次发送请求都会返回500个http响应！！！另一方面，数据库已启动且可访问，一旦启动 jstack，一切都被解除阻塞，应用程序再次运行！！！记忆明智，几乎没有什么可担心的。它是纯函数式的，此类异常大量随机出现！！！

【参考方案1】：

这些线程正在等待某事发生。正如你所写：

这些基本上是 tomcat 服务器上的请求工作线程，在阻塞队列上等待直到请求到来

据我了解，这发生在低负载下。所以太大的ThreadPool不会有问题。如果你真的很担心，可以为 ThreadPools 配置一个maxIdleTime。所以 Tomcat 将杀死旧的空闲线程 - 直到 ThreadPool 到达minSpareThreads。

This 是 Tomcat 8 的线程池文档。

This 是 Tomcat 7 的线程池文档。

This 是 Tomcat 6 的线程池文档。