Comprehensive Guide to Java Application Performance Optimization and Diagnosis

Java application performance optimization is a long‑standing topic, with typical issues such as slow page response, interface timeouts, high server load, low concurrency, and frequent database deadlocks.

In modern fast‑paced development, increasing traffic and code bloat bring many performance bottlenecks. The author classifies Java performance problems into four layers—application, database, framework, and JVM—as shown in Figure 1.

Performance Diagnosis Tools

Two main approaches exist: on‑site analysis (which may impact production) and post‑mortem analysis (collecting data for later replay). The article focuses on on‑site tools such as top, vmstat, iostat, jstack, jstat, jmap, and third‑party tools like JProfiler and MAT.

OS Diagnosis

Key OS metrics include CPU (load average, usage, context switches), memory (free‑m, swap usage), and I/O (disk and network). Sample commands and screenshots (Figures 2‑4) illustrate how to read top and vmstat output and interpret context‑switch counts.

Java Application Diagnosis

Common issues are identified via thread stacks, heap dumps, and GC logs. Example code causing excessive context switches:

for(Category c = this; c != null; c = c.parent) {<br/>    // Protected against simultaneous call to addAppender, removeAppender,…<br/>    synchronized(c) {<br/>        if (c.aai != null) {<br/>            write += c.aai.appendLoopAppenders(event);<br/>        }<br/>        ...<br/>    }<br/>}<br/>

GC analysis uses jstat, jmap, and MAT. Typical GC parameters are shown in Figure 10.

JVM Tuning

A case study describes periodic Full GC caused by RMI’s Distributed Garbage Collection daemon. The daemon code is:

private static class Daemon extends Thread {<br/>    public void run() {<br/>        for (;;) {<br/>            long d = maxObjectInspectionAge();<br/>            if (d >= l) {<br/>                System.gc();<br/>                d = 0;<br/>            }<br/>            // …<br/>        }<br/>    }<br/>}<br/>

Solutions include disabling explicit GC (‑XX:+DisableExplicitGC) or adjusting RMI GC intervals (‑Dsun.rmi.dgc.server.gcInterval, ‑Dsun.rmi.dgc.client.gcInterval) and enabling concurrent GC (‑XX:+ExplicitGCInvokesConcurrent), which reduced Full GC frequency (Figure 11).

Application‑Layer Tuning

Analyzing a high‑load advertising system revealed a HashMap concurrency bug caused by lazy loading. The problematic code is:

private static Map<Long, UnionDomain> domainMap = new HashMap<>();<br/>private boolean isResetDomains() {<br/>    if (CollectionUtils.isEmpty(domainMap)) {<br/>        List<UnionDomain> newDomains = unionDomainHttpClient.queryAllUnionDomain();<br/>        if (CollectionUtils.isEmpty(domainMap)) {<br/>            domainMap = new HashMap<>();<br/>            for (UnionDomain domain : newDomains) {<br/>                if (domain != null) {<br/>                    domainMap.put(domain.getSubdomainId(), domain);<br/>                }<br/>            }<br/>        }<br/>        return true;<br/>    }<br/>    return false;<br/>}<br/>

Fixes include replacing HashMap with ConcurrentHashMap, pre‑loading caches, or using distributed caches.

Database‑Layer Tuning

Deadlock cases in a MySQL InnoDB advertising system are examined. The root cause was many transactions locking the same secondary index ( idx_groupdomain_accountid) and then waiting for the primary key lock. Introducing a composite index on (accountid, groupid) reduced lock contention. index ‘idx_groupdomain_accountid’<br/> Additional lock‑wait logs show RECORDLOCK on the secondary index and waiting for RECORDLOCK on the PRIMARY index.

spaceid 5726 page no 8658 … RECORDLOCK (secondary index)<br/>spaceid 5726 page no 12990 … RECORDLOCK (primary index)<br/>

Summary & Recommendations

Performance tuning follows the 2‑8 principle: 80 % of issues stem from 20 % of code. Recommendations span hardware/OS upgrades, database optimizations (SQL, indexing, sharding, NoSQL), architectural improvements (new frameworks, distributed strategies), and business‑level adjustments.

Finally, a Q&A explains InnoDB’s secondary‑index locking behavior and how it leads to primary‑key lock acquisition.