The Performance Impact of java.lang.System.getProperty()
How to avoid blocked threads.
Join the DZone community and get the full member experience.
Join For Free‘java.lang.System.getProperty(
public static String getAppName() {
String app = System.getProperty("appName");
return app;
}
When the above method is invoked, ‘buggyApp’ will be returned. However, if ‘java.lang.System.getProperty(
What Is the Performance Impact of Using ‘java.lang.System.getProperty()’ API?
‘java.lang.System.
Real-World problem in Atlassian SDK
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’s stack trace will be reported in the tool.
All these threads entered into the BLOCKED state because of the ‘Camel Thread #6 – backboneThreadPool’ (i.e., Red color node in the graph). Here is the initial few lines of this thread’s stack trace:
Camel Thread #6 –
backboneThreadPool
Stack Trace is:
at
java.util.Hashtable.get(Hashta
ble.java:362)
- locked <0x0000000080f5e118> (a java.util.Properties)
at java.util.Properties.
getProperty(Properties.java: 969) at java.util.Properties.
getProperty(Properties.java: 988) at java.lang.System.getProperty(
System.java:756) at net.java.ao.atlassian.
ConverterUtils.enforceLength( ConverterUtils.java:16) at net.java.ao.atlassian.
ConverterUtils.checkLength( ConverterUtils.java:9) : :
Fig: Stack trace of the thread which acquired the LOCK
From the stack trace, you can notice that this thread was invoking the ‘java.lang.System.getProperty(
http-nio-8080-exec-293
Stack Trace is:
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.Hashtable.get(Hashtable.java:362)
- waiting to lock <0x0000000080f5e118> (a
java.util.Properties)
at java.util.Properties.
getProperty(Properties.java: 969) at java.util.Properties.
getProperty(Properties.java: 988) at java.lang.System.getProperty(
System.java:756) at net.java.ao.atlassian.
ConverterUtils.enforceLength( ConverterUtils.java:16) at net.java.ao.atlassian.
ConverterUtils.checkLength( ConverterUtils.java:9) : :
Fig: Stack trace of one of the BLOCKED threads waiting for the LOCK
http-nio-8080-exec-279
Stack Trace is:
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.Hashtable.get(Hashtable.java:362)
- waiting to lock <0x0000000080f5e118> (a
java.util.Properties)
at java.util.Properties.
getProperty(Properties.java: 969) at java.util.Properties.
getProperty(Properties.java: 988) at java.lang.System.getProperty(
System.java:756) at org.ofbiz.core.entity.
EntityFindOptions.<init>( EntityFindOptions.java:124) : :
Fig: Stack trace of another BLOCKED thread waiting for the LOCK
Since this ‘java.lang.System.getProperty(
What is the Solution?
Here are the potential solutions to address this problem:
1. Upgrade to JDK 11:
Starting from JDK 11, Synchronized ‘HashTable’ has been replaced with ‘ConcurrentHashMap’ in java.util.Properties. Thus when you upgrade to JDK11, you will not run into this problem.
2. Caching the values:
In a significant number of applications, System properties don’t change during runtime. In such circumstances, we don’t have to keep invoking ‘java.lang.System.getProperty(
private static String app = System.getProperty("appName");
public static String getAppName() {
return app;
}
If you notice the above code, ‘’java.lang.System.
Opinions expressed by DZone contributors are their own.
Comments