Thread dumps captured with the JDK tool called jstack will reveal that multiple threads are stuck in java.util.HashMap.getEntry() at the same point without synchronization locking being present.
Specific thread stack trace showing an example from the thread dump file:
Steps to Reproduce:
Expected Result: CPU utilization will not spike/thrash at 95% and higher, and threads will not appear stuck on the same line in java.util.HashMap.getEntry().
Actual Result: Intermittently, CPU can spike and threads will hang, and the condition will not typically resolve itself without a service restart.
Caused by CLRT-79908
This defect will not be fixed at this time. If the problem occurs for our customers on any currently supported version of Clarity, please raise a support ticket referencing this defect (CLRT-79908) or knowledge article, and the defect will be able to be reviewed again.
Restart the bg services when possible. It is unlikely that much else will run before the restart takes place anyway, as most CPU cycles are exhausted in an infinite loop spin.
In the stack traces, the top two lines contain the following in multiple threads as the indicator of this problem:
The line numbers for java.util.HashMap() correspond to the use of Oracle JDK 1.7.0_21 and other versions and possibly even other operating systems where the bg is running could reveal a different line number in use accordingly, but will still be for the same problem and cause.