Нити, застрявшие при 100% использовании процессора в HashMap во время сохранения JSF()

У нас есть проблема в нашей производственной среде, 4 Threads - на 100% использовании CPU из команды HTOP. Чтобы продолжить исследование проблемы, я создал дамп Thread, чтобы узнать, какой поток использует процессор.

Вот что я узнал. 4 потока имеют одну и ту же трассировку стека, все из которых находятся в состоянии RUNNABLE. К сожалению, я застрял в своем исследовании, так как трассировка стека не имеет ссылки на мой внутренний код, это больше на стороне Richfaces. Я думаю, что это та часть, где JSF создает страницу.

Трассировка стека.

"ajp-0.0.0.0-8009-47" daemon prio=10 tid=0x00007fb8040af000 nid=0x172c runnable [0x00007fb8b3bf8000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.hash(HashMap.java:351) at java.util.HashMap.putForCreate(HashMap.java:512) at java.util.HashMap.putAllForCreate(HashMap.java:534) at java.util.HashMap.<init>(HashMap.java:320) at org.ajax4jsf.component.UIDataAdaptorBase.createChildStateCopy(UIDataAdaptorBase.java:894) at org.ajax4jsf.component.UIDataAdaptorBase.saveState(UIDataAdaptorBase.java:1554) at org.richfaces.component.UIDataTable.saveState(UIDataTable.java:181) at org.richfaces.component.html.HtmlDataTable.saveState(HtmlDataTable.java:1361) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1103) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119) at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1119) at org.ajax4jsf.component.AjaxViewRoot.processSaveState(AjaxViewRoot.java:751) at org.ajax4jsf.application.AjaxStateManager.getComponentStateToSave(AjaxStateManager.java:179) at org.ajax4jsf.application.AjaxStateManager.buildViewState(AjaxStateManager.java:515) at org.ajax4jsf.application.AjaxStateManager$SeamStateManagerWrapper.saveView(AjaxStateManager.java:106) at org.jboss.seam.jsf.SeamStateManager.saveView(SeamStateManager.java:89) at org.ajax4jsf.application.AjaxStateManager.saveSerializedView(AjaxStateManager.java:470) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:615) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.josso.servlet.agent.GenericServletSSOAgentFilter.doFilter(GenericServletSSOAgentFilter.java:558) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436) at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:722)

Другое дело: есть ли какой-либо способ, который я могу использовать в трассировке стека, скажу, что я хотел создать журналы, чтобы я мог определить, какая страница в моем приложении создается эта трассировка стека? Или, может быть, я могу использовать фазовый прослушиватель?

Любая помощь будет оценена по достоинству. Спасибо.

Я использую Seam 2.2, Richfaces 3.3.3 final, JSF 1.2.

Ответы

Ответ 1

Это

java.lang.Thread.State: RUNNABLE
    at java.util.HashMap.hash(HashMap.java:351)
    at java.util.HashMap.putForCreate(HashMap.java:512)
    at java.util.HashMap.putAllForCreate(HashMap.java:534)
    at java.util.HashMap.<init>(HashMap.java:320)

и это,

java.lang.Thread.State: RUNNABLE
    at java.util.HashMap.getEntry(HashMap.java:446)
    at java.util.HashMap.get(HashMap.java:405)

известны проблемы с потоками, связанные с java.util.HashMap, когда один поток вызывает a get(), в то время как другой поток выполняет в то же время a put(). Поток будет во время вычисления хеша, а затем застрял в бесконечном цикле. Техническое решение этой проблемы использует вместо этого реализацию ConcurrentMap. См. Также a.o. эта статья dzone.

Однако в вашем конкретном случае

    at java.util.HashMap.<init>(HashMap.java:320)
    at org.ajax4jsf.component.UIDataAdaptorBase.createChildStateCopy(UIDataAdaptorBase.java:894)
    at org.ajax4jsf.component.UIDataAdaptorBase.saveState(UIDataAdaptorBase.java:1554)
    at org.richfaces.component.UIDataTable.saveState(UIDataTable.java:181)
    at org.richfaces.component.html.HtmlDataTable.saveState(HtmlDataTable.java:1361)
    at javax.faces.component.UIComponentBase.processSaveState(UIComponentBase.java:1103)

эта проблема проявляется, когда состояние вашего компонента <rich:dataTable> уже будет сохранено. Это, в свою очередь, предполагает, что к одному и тому же экземпляру компонента обращаются несколько потоков. Это неправильно, класс UIComponent на первом месте никогда не был предназначен для потокобезопасности. Это, в свою очередь, указывает на то, что рассматриваемый экземпляр компонента не является областью действия запроса, как того требует спецификация JSF. Например, это может произойти, если вы используете binding для привязки компонента к охвату сеанса или, возможно, даже к области приложения bean или, что еще хуже, к статическому полю.

<x:someComponent ... binding="#{nonRequestScopedBean.someComponent}">

Вы должны в своей кодовой базе искать такой компонент и исправить его соответствующим образом, убедившись, что bean является областью действия запроса или с помощью другого решения для требования/проблемы, для которого вы считали, что с помощью binding это путь был бы правильным решением.

См. также:

Как работает атрибут привязки в JSF? Когда и как его использовать?

Ответ 2

после длительного анализа моя проблема решена.

поскольку мы используем версию jsf 2.1.7, повтор UI реализован с использованием hashmap в версии 2.1.7. поэтому, когда мы используем вложенный ui, повторение cpu велико. я заменил ui повторить с JSTL для каждого, теперь приложение работает.

иначе вы также можете использовать, вам нужно изменить JSF 2.2.4 или LATER VERSION.