How to Diagnose and Fix High CPU & Memory Issues in Java Applications

Java Application

1 CPU Load Too High

1.1 Problem Analysis

Use top to identify the Java process ID that consumes the most CPU.

After obtaining the PID, run top -Hp <pid> to find the thread IDs that use the most CPU within that process.

Dump the Java stack of the process with jstack -l <pid> > /tmp/java_pid.log.

Convert the identified thread IDs to hexadecimal. printf "%X" thread_id Search the hexadecimal thread ID in the stack log file to locate the corresponding stack trace. Sometimes excessive thread creation in the code can cause the problem:

# 查看该进程有多少线程
ps p 9534 -L -o pcpu,pmem,pid,tid,time,tname,cmd | wc -l

1.2 Solution

Provide the relevant thread logs to developers for pinpointing the error. Common thread states that indicate issues are:

WAITING

BLOCKED

Developers can then examine the indicated code locations for potential problems.

2 Memory Usage Too High

The Java Virtual Machine divides the memory it manages into several distinct regions. Some parts are thread‑private, while others are shared among threads.

Thread‑private: Program Counter, JVM Stack, Native Method Stack

Thread‑shared: Heap, Method Area, Direct Memory

2.1 From Garbage‑Collection Perspective

The Java heap is the main area managed by the garbage collector, often called the GC heap. Modern collectors use generational algorithms, dividing the heap into Young Generation (Eden, From Survivor, To Survivor) and Old Generation.

Since JDK 1.8 the permanent generation has been removed and replaced by Metaspace, which resides in native memory and is limited only by the physical memory of the host.

Typical allocation flow: objects are first allocated in Eden; when Eden fills, a Minor GC moves surviving objects to Survivor spaces; if Survivor spaces cannot hold them, they are promoted to the Old Generation, which triggers a Full GC when it becomes full.

To inspect heap distribution, use jmap -heap <pid>:

[root@iz23nb5ujp69 ~]# jmap -heap 11764
Attaching to process ID 11764, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.73-b02
using thread‑local object allocation.
Parallel GC with 2 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 2147483648 (2048.0MB)
   NewSize                  = 715653120 (682.5MB)
   MaxNewSize               = 715653120 (682.5MB)
   OldSize                  = 1431830528 (1365.5MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 372768768 (355.5MB)
   used     = 185979712 (177.36MB)
   free     = 186789056 (178.14MB)
   49.89% used
From Space:
   capacity = 175112192 (167.0MB)
   used     = 47983120 (45.76MB)
   free     = 127129072 (121.24MB)
   27.40% used
To Space:
   capacity = 167772160 (160.0MB)
   used     = 0 (0.0MB)
   free     = 167772160 (160.0MB)
   0.0% used
PS Old Generation
   capacity = 1431830528 (1365.5MB)
   used     = 257274632 (245.36MB)
   free     = 1174555896 (1120.14MB)
   17.97% used

Excessive Young GC can lead to Full GC, which consumes significant CPU and reduces throughput. Monitoring GC activity can be done with jstat:

jstat -gcutil <pid> 2000 10
S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
56.01   0.00   8.21  88.19  98.44  96.92  27350  353.229    41   32.416  385.645

Common causes of frequent GC:

Young generation size too small, causing many Young GCs that eventually promote many objects to the Old Generation.

Old Generation size too small, leading to frequent Full GCs.

Explicit calls to System.gc() – avoid manual GC triggers.

Insufficient Metaspace size.

2.2 From Code Perspective

Analyze heap dumps with Eclipse MAT:

jmap -dump:live,format=b,file=/tmp/dump1628.dat <pid>

Download MAT from http://www.eclipse.org/mat/ and import the dump for analysis. MAT provides views such as Histogram, Dominator Tree, Top Consumers, Duplicate Classes, Leak Suspects, and Top Components.

Additional tools for memory analysis include JConsole and Java VisualVM.

2.3 JVM Tuning Parameters (adjust per project)

-Xms2048m -Xmx2048m
-XX:MaxHeapFreeRatio=100
-XX:MinHeapFreeRatio=0
-Xmn900m
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=256m
-XX:MinMetaspaceFreeRatio=0
-XX:MaxMetaspaceFreeRatio=100
-XX:SurvivorRatio=7
-XX:MaxTenuringThreshold=14
-XX:ParallelGCThreads=2
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-XX:+PrintGCDetails

After tuning, the desired state is moderate Young GC frequency (e.g., one Minor GC every 20‑30 minutes) with minimal pause time and no Full GC or Metaspace‑induced GC.

2.4 Case Study

Sample GC logs show a Metadata GC triggering both a normal GC and a Full GC. The Full GC occurs because Metaspace reached its limit, not because the Young or Old generations were full.

[GC (Metadata GC Threshold) [PSYoungGen: 282234K->101389K(523264K)] 589068K->410894K(1921536K), 0.1611903 secs] [Times: user=0.18 sys=0.00, real=0.16 secs]
[Full GC (Metadata GC Threshold) [PSYoungGen: 101389K->0K(523264K)] [ParOldGen: 309505K->258194K(1398272K)] 410894K->258194K(1921536K), [Metaspace: 268611K->268101K(1294336K)], 1.8562117 secs] [Times: user=1.80 sys=0.08, real=1.86 secs]

Increasing Metaspace size resolves this issue.

2.5 Additional Resources

For default JVM flags, run java -XX:+PrintFlagsInitial and filter for Metaspace settings.

Original article reference: https://www.cnblogs.com/operationhome/p/10537018.html