IBM Support

High CPU / Hang on java.util.HashMap.findNonNullKeyEntry() due to non-thread-safe usage of HashMap

Technote (troubleshooting)


High CPU or hang symptoms may be observed on java.util.HashMap.findNonNullKeyEntry when a HashMap is utilized in a non-thread-safe manner. This is an unsafe coding practice that can occur at any level of development when using the HashMap API: application, application server, third party module, etc. The following will outline how to identify the problematic code and some possible methods to resolve the issue.


High CPU or hung threads with an executing stack similar to the following:

    at java.util.HashMap.findNonNullKeyEntry()
    at java.util.HashMap.getEntry()
    at java.util.HashMap.get()
    at java.util.HashMap.findNonNullKeyEntry()
    at java.util.HashMap.putImpl()
    at java.util.HashMap.put()

The specific stack may vary.

As a more general symptom of this issue, the executing stack will show the problematic code calling a method within the HashMap API which will in turn call the findNonNullKeyEntry() method.

Resolving the problem

In order to resolve these type of issues, the problematic code must first be identified.

In the examples above, the problematic code is This is determined by looking at the code that is making the call to the HashMap API. In both cases we see that is calling the HashMap API, and therefore it is the problematic code. In the first example is calling the get() method, and in the second example is calling the put() method.

Once the problematic code has been identified, the developers of that code will need to review their usage of the HashMap API (Java 5, Java 6, Java 7). The discovery of high CPU or hung threads in states such as those described above is compelling evidence that the usage of the HashMap API has not been done in a thread-safe manner.

To correct the issue, the usage of HashMap objects should be done in a thread-safe (synchronized) manner as the API mandates. Alternatively, an object that is similar to a HashMap but intrinsically thread-safe could be used instead, a Hashtable or a ConcurrentHashMap for example.

To understand this further, please see the HashMap API document:

HashMaps and WebSphere Application Server

As noted previously, this is not an issue that is unique to applications or third party modules. This is an issue that can occur at any level of development where the HashMap API is used, including WebSphere Application Server itself. There are a number of WebSphere Application Server APARs which address such issues. If one of these specific issues is encountered, it is recommended that the referenced Fix Pack (or greater) be applied to correct the issue.

       APAR     Affected Versions        Released in Fix Pack      
    PK74719                    7.0           
    PK97665                    7.0           
    PM00692               6.1, 7.0 ,
    PM02318                    7.0          
    PM48600               7.0, 8.0 ,
    PM44032               7.0, 8.0 ,
    PM53640               7.0, 8.0 ,
      Note: This list contains the most common WebSphere Application Server APARs related to these type of issues; this list is by no means comprehensive or exhaustive.

    A Final Note: IBM Java 6 SDK Enhancements

    There have been some enhancements to the IBM Java 6 SDK to mitigate the likelihood of problems due to non-thread-safe usage of HashMap objects:

         APAR              Released       Shipped with Fix Pack
      IZ51855             Java 6 SR6           
      IZ73767             Java 6 SR9          

    However, it is still the responsibility of the code using the HashMap objects to ensure that it is done in a thread-safe (synchronized) manner as the API requires. These enhancements cannot and will not protect against all improper usage of HashMap objects.

    Document information

    More support for: WebSphere Application Server

    Software version: 6.1, 7.0, 8.0, 8.5

    Operating system(s): AIX, HP-UX, Linux, Solaris, Windows

    Software edition: Base, Express, Network Deployment

    Reference #: 1597581

    Modified date: 04 October 2016