Threads stuck at 100% CPU utilization in HashMap during JSF saveState()

Question

We have an issue in our production environment, 4 Threads is at 100% CPU Usage from the HTOP command. To further investigate the issue I generated a Thread dump in order to

Answer 1

This,

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)

and this,

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

are known threadsafety problems with java.util.HashMap when one thread invokes a get() while another thread does at the same time a put(). The thread will during calculating the hash then stuck in an infinite loop . The technical solution to this problem is using a ConcurrentMap implementation instead. See also a.o. this dzone article.

However, in your specific case,

    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)

this problem appears to manifest when the state of your <rich:dataTable> component is about to be saved. This in turn suggests that the very same instance of the component is being accessed by multiple threads. This is not right, the UIComponent class is in first place never designed to be threadsafe. This in turn indicates that the component instance in question is not request scoped as required by the JSF specification. This can for example happen when you're using binding to bind the component to a session scoped or perhaps even an application scoped bean or, worse, a static field.

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

You should in your codebase look for such a component and fix it accordingly by making sure that the bean is request scoped, or by using a different solution for the requirement/problem for which you thought that using binding this way would be the right solution.

See also:

• How does the 'binding' attribute work in JSF? When and how should it be used?

Answer 2

after long analysis my issue is resolved.

as we are using jsf 2.1.7 version , UI repeat implemented using hashmap in 2.1.7 version. hence when we use the nested ui repeat cpu is high. i have replaced ui repeat with JSTL for each now the application is working.

other way also you can use, you need to change the JSF 2.2.4 OR LATER VERSION.