首页 文章

太多停车等待线程

提问于
浏览
2

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

“pool-3-thread-352”#13082 prio = 5 os_prio = 0 tid = 0x00007ff6407fc800 nid = 0x1e94等待条件[0x00007ff5a53b4000] java.lang.Thread.State:TIMED_WAITING(停车)at sun.misc.Unsafe.park (本机方法) - 在java.util.concurrent的java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)中停止等待<0x000000044af6bcd0>(java.util.concurrent.SynchronousQueue $ TransferStack) . 来自java的java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)的java.util.concurrent.SynchronousQueue $ TransferStack.transfer(SynchronousQueue.java:362)中的SynchronousQueue $ TransferStack.awaitFulfill(SynchronousQueue.java:460) .util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)at 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(停车)at sun.misc.Unsafe.park(Native Method) - 停车等待<0x00000004ad95fba8>(java.util.concurrent.SynchronousQueue $ TransferStack)java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)at java.util.concurrent.SynchronousQueue $ TransferStack.awaitFulfill(SynchronousQueue.java:460)at java.util.concurrent.SynchronousQueue $ TransferStack .transfer(SynchronousQueue.java:362)位于java.util.concurrent上的java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)中的java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) . ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)at java.util.concurrent.ThreadPoolExecutor $ Worker.run(ThreadPoolExecutor.java:624)at 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

我希望通过线程活动链接这些异常!知道连接错误的原因吗?!!!!

1 回答

  • 1

    这些线程正在等待发生的事情 . 正如你写的:

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

    据我了解,这是在低负荷下发生的 . 所以太大的ThreadPool不会成为问题 . 如果您真的担心它,可以为ThreadPools配置 maxIdleTime . 所以Tomcat将杀死旧的空闲线程 - 直到ThreadPool到达 minSpareThreads .

    This是Tomcat 8的线程池文档 .

    This是Tomcat 7的线程池文档 .

    This是Tomcat 6的线程池文档 .

相关问题