我们已经在Tomcat 6.0.20上部署了Remedy中间层,但Tomcat几乎每天都频繁出现故障,并出现以下错误:
为地址null和端口8080创建的最大线程数(400)
我们已经尝试过增加线程数,但这还不够。两次后续崩溃之间的时间差异只会增加,但这也是同样的问题。
我们已经获得了线程转储,并且它显示大多数线程处于“等待”状态。请参考下面从线程日志中获得的内容如下:
*"http-8080-670" - Thread t@8479
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <775f1471> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
at com.bmc.arsys.apitransport.connection.a.get(Unknown Source)
at com.bmc.arsys.apitransport.connection.c.getProxy(Unknown Source)
at com.bmc.arsys.api.PoolingProxyManager.getProxy(Unknown Source)
at com.bmc.arsys.apitransport.connection.c.getProxy(Unknown Source)
at com.bmc.arsys.api.ARServerUser.getListEntryObjects(Unknown Source)
at com.remedy.arsys.goat.savesearches.ARUserSearches.loadFromServer(Unknown Source)
- locked <32e7e815> (a com.remedy.arsys.goat.savesearches.ARUserSearches)
at com.remedy.arsys.goat.aspects.IARUserSearchesServiceCacheAspect.ajc$around$com_remedy_arsys_goat_aspects_IARUserSearchesServiceCacheAspect$1$181ba497(IARUserSearchesServiceCacheAspect.aj:44)
- locked <794bbdbc> (a java.lang.String)
at com.remedy.arsys.goat.savesearches.ARUserSearches.getUserSearches(Unknown Source)
at com.remedy.arsys.goat.UserDataEmitter.<init>(Unknown Source)
at com.remedy.arsys.goat.service.DHTMLRequestService.requestDispatch(Unknown Source)
at com.remedy.arsys.stubs.FormServlet.doRequest(Unknown Source)
at com.remedy.arsys.stubs.GoatServlet.postInternal(Unknown Source)
at com.remedy.arsys.stubs.GoatHttpServlet.doGet(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Unknown Source)
Locked ownable synchronizers:
- locked <5b95bfda> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)*
线程处于'等待'的原因有很多,任何人都可以帮助缩小范围。
答案 0 :(得分:2)
当线程没有给出执行机会(即池中的线程数)时,线程进入park
状态。池指的是当前处于RUN
状态的线程。当池被填满时,线程进入队列,该队列将处于WAIT
状态,并且当它有机会进入池执行时有机会进入RUN
状态。
当pool
和queue
的阈值超过线程进入park WAIT
状态时,他们会等到以下任何事情发生,
i)超过配置的停车时间时
或
ii)permit
或pool
即{}进入queue
;调用RUN
时,该线程将有机会进入WAIT
或Thread.interrupt()
状态。
答案 1 :(得分:0)
线程似乎在等待,但实际上它们在工作队列中被阻塞。看起来他们使用ThreadPoolExecutor来安排任务,但工作队列中没有足够的线程来处理所有任务,或者每个任务花费的时间太长。
请查看:Deadlock in ThreadPoolExecutor。
另外,检查PoolingProxyManager
,他getProxy
应该做什么,看起来它正在尝试获取连接或其他资源。