Learn what problems the java.lang.System.getProperty() API can cause and what you can do to fix blocked threads.<\/b>
\nJoin the DZone community and get the full member experience. \u2018java.lang. System.getProperty()\u2019 is a common API used by Java developers to read the System properties that are configured during application startup time. i.e. when you pass \u201c-DappName=buggyApp\u201d as your application\u2019s startup JVM argument, the value of the \u2018appName\u2019 system property can be read by invoking the \u2018java.lang. System.getProperty()\u2019. Example: When the above method is invoked, \u2018buggyApp\u2019 will be returned. However, if \u2018java.lang. System.getProperty()\u2019 is used in a critical code path, it has the potential to degrade the application\u2019s performance. In this post let\u2019s discuss what is the performance impact of invoking \u2018java.lang. System.getProperty()\u2019, how to mitigate it, and a real-world production problem triggered by this API. \u2018java.lang. System. getProperty()\u2019 API underlyingly uses \u2018java.util. Hashtable.get()\u2019 API. Please be advised that \u2018java.util. Hashtable.get()\u2019 is a synchronized API. It means only one thread can invoke the \u2018java.util. Hashtable.get()\u2019 method at any given time. If a new thread tries to invoke \u2018java.util. Hashtable.get()\u2019 API when the first thread is still executing it, the new thread will be put in a BLOCKED state. When a thread is in the BLOCKED state, it won\u2019t be able to progress forward. Only when the first thread completes executing the \u2018java.util. Hashtable.get()\u2019 API, new thread will be able to progress forward. Thus if \u2018java.lang. System.getProperty()\u2019 or \u2018java.util. Hashtable.get()\u2019 is invoked in critical code paths, it will impact the response time of the transaction. Recently this type of degradation was observed in Atlassian SDK. The thread dump was captured from this application and analyzed using the thread dump analysis tool fastThread. According to the thread dump analysis report,189 threads were in the BLOCKED state. Below is the transitive dependency graph from the thread dump report showing the names of the threads that are in the BLOCKED state. When you click on the thread name in the graph, that particular thread\u2019s stack trace will be reported in the tool. All these threads entered into the BLOCKED state because of the \u2018Camel Thread #6 \u2013 backboneThreadPool\u2019 (i.e., Red color node in the graph). Here is the initial few lines of this thread\u2019s stack trace: Fig: Stack trace of the thread which acquired the LOCK From the stack trace, you can notice that this thread was invoking the \u2018java.lang. System.getProperty()\u2019 API. Since \u2018java.lang. System.getProperty()\u2019 API underlyingly uses \u2018java.util. Hashtable.get()\u2019 API (which is a synchronized API call). Thus \u2018Camel Thread #6 \u2013 backboneThreadPool\u2019 will be the only thread allowed to enter this method. Below are the initial few lines of couple of threads (out of 189 threads) who are in BLOCKED state because they are waiting to enter the \u2018java.util. Hashtable.get()\u2019 API. Fig: Stack trace of one of the BLOCKED threads waiting for the LOCK Fig: Stack trace of another BLOCKED thread waiting for the LOCK Since this \u2018java.lang. System.getProperty()\u2019 API was present in the critical code path, multiple threads were trying to invoke it. Thus, all those 189 threads which were trying to invoke this API were put into the BLOCKED state. Ultimately, the overall application response time was degraded. Since System properties don\u2019t change during runtime, we don\u2019t have to keep invoking \u2018java.lang. System.getProperty()\u2019 API on every single transaction. Rather, we can invoke \u2018java.lang. System.getProperty()\u2019 API once, cache its value, and return the cached value on all future calls, as shown in the below code snippet. If you notice the above code, \u2018\u2019java.lang. System. getProperty()\u2019 is now assigned to a static member variable. It means this API will be called during application startup time, that too only once. From that point, if anyone invokes the getAppName() API, he will be returned the cached value. Thus, application threads will not be put into the BLOCKED state at runtime. This simple change can improve the application\u2019s overall response time. Opinions expressed by DZone contributors are their own.<\/p>\n