How to Detect and Solve Java Application Performance Bottlenecks: A Practical Guide

1. Overview

Technical systems evolve through three stages: early (focus on business functionality, performance ignored), middle (performance problems emerge and affect growth), and late (performance and business must be balanced). Detecting and solving performance issues is the core goal of this article.

2. What Is Performance?

Performance can be described from four perspectives:

Speed (slow) – how long a page or API takes to respond.

Pressure (high load) – the system’s ability to handle many concurrent requests.

Qualitative – intuitive feeling of slowness.

Quantitative – measurable metrics such as response time (RT), queries per second (QPS), and concurrency.

3. Discovering Performance Problems

3.1 Qualitative + Speed

Examples: a page takes several seconds to load, a list loads slowly, or an API times out.

3.2 Quantitative + Speed

Example calculation for a company with 7,200 employees clocking in between 08:00‑08:30, each check‑in taking 5 seconds:

RT = 5 s

QPS = 7200 / (30 × 60) ≈ 4

Concurrency = QPS × RT = 4 × 5 = 20

Thus, Concurrency = QPS × RT.

3.3 QPS vs. TPS

QPS (Queries Per Second) counts requests, while TPS (Transactions Per Second) counts business transactions (receive request → process business → return result). The relationship can be expressed as:

QPS = N * TPS   // N ≥ 1, where N is the number of transactions per request

Examples of Java code with one transaction vs. multiple transactions are shown to illustrate the concept.

3.4 Diagnostic Tools

Logging – manually print timestamps before and after business logic.

Spring StopWatch – measure each method’s execution time and output a summary.

Arthas – an online Java diagnostic tool that can trace method execution, dump heap, and monitor GC.

trace java.front.optimize.FastTestService test03

Sample trace output shows the time spent in biz1() and biz2().

3.5 CPU & Memory Diagnosis

To reproduce a CPU spike, a simple loop calling a method repeatedly is used. Tools: dashboard – shows real‑time CPU usage per thread. thread -n 1 – lists the busiest thread and its stack trace. free -h – displays system memory usage. memory (Arthas) – shows JVM heap, metaspace, and other memory regions. jmap and jhsdb jmap – obtain heap dumps for offline analysis. jstat -gcutil <pid> <interval> – monitors GC activity and pauses.

3.6 Comprehensive Problem Discovery

Stress testing with tools like JMeter (ramp‑up threads 10‑30, 1‑minute duration) helps expose bottlenecks. Key metrics to watch are TPS, response time (especially the 95th percentile), and error rates. A monitoring system (custom or third‑party) should visualize these indicators.

4. Optimizing Performance Issues

Four generic methods are proposed:

Reduce requests.

Trade space for time (caching, indexing).

Parallelize tasks.

Asynchronize tasks.

These methods can be applied across five architectural layers:

Proxy layer

Frontend layer

Service layer

Cache layer

Data layer

Examples:

Frontend: add a captcha in flash‑sale scenarios to cut down abusive traffic.

Service: batch multiple RPC calls into a single request.

Service: use Future to run independent calls in parallel.

Cache: introduce multi‑level caching.

Data: add appropriate indexes.

Service: make non‑critical calls asynchronous.

5. Conclusion

The article covered the lifecycle of performance concerns, defined performance dimensions, presented practical ways to discover speed and pressure problems using logging, StopWatch, Arthas, and system commands, and finally offered a layered optimization framework that combines request reduction, caching, parallelism, and asynchrony.