How to Diagnose and Optimize High CPU & Memory Usage in Java Applications on Linux

Why Java Performance Matters for Operations

IT operations staff frequently encounter performance bottlenecks in Java services running on Linux. When user load spikes or server capacity cannot be expanded, the ability to diagnose and optimise CPU and memory usage is essential to keep services responsive and to avoid unnecessary resource consumption.

Typical High‑Resource Issues

In production, a Java process may continuously consume a large share of CPU and RAM and rarely release them. This leads to system sluggishness, forced process termination or service restarts, and consequently business interruption. The most common root causes are tight loops, excessive I/O waits, or memory leaks.

Case Study: Character Gateway Server (jerrySsh)

The following example analyses a real‑world Java service named jerrySsh that failed to meet its design target of 500 concurrent users per machine.

2. Problem Analysis

2.1 CPU‑High Analysis

1. Use top to observe overall CPU and memory usage. The %id column shows idle CPU; a low value indicates high utilization.

2. Identify the Java process that dominates CPU consumption (e.g., PID 13033).

Preparation

export JAVA_HOME=/usr/apps/java/jdk1.6.0_20/

export PATH=$JAVA_HOME/bin:$PATH

export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

Step‑by‑step procedure

Run top and note that the Java process uses > 50 % CPU.

List its threads sorted by CPU time: ps -mp 13033 -o THREAD,tid,time | sort -rn The output shows thread 28358 consuming over eight minutes of CPU time.

Convert the thread ID to hexadecimal for jstack usage: printf "%x\n" 28358 # → 6ec6 Dump the stack of that thread: jstack -l -F -p 13033 The stack trace points to waiting and reading statements that are the primary CPU consumers.

2.2 Memory Usage Analysis

The service’s memory usage is generally balanced, but occasional CLOSE_WAIT sockets prevent buffers/cache from being released, reducing the amount of memory available for new allocations. Linux keeps data in physical memory as long as possible; swapping only occurs when the usable memory (excluding buffers/cache) is exhausted.

From a Java perspective, the focus is on avoiding java.lang.OutOfMemoryError: Java heap space by reducing unnecessary object creation and preventing leaks.

Diagnostic tools top – real‑time memory view. jmap -histo:live <pid> – list live objects and their memory footprints. jmap -dump:live,format=b,file=heap.bin <pid> – generate a heap dump for analysis with Eclipse MAT or similar tools.

Example command: jmap -histo:live 14978 The histogram highlights large allocations for constMethodKlass, methodKlass, symbolKlass, and especially large int[] arrays, indicating code sections that should be reviewed for excessive object creation.

3. Summary of Analysis Techniques

CPU Analysis Tools top – monitor live CPU usage. ps -ef or ps -mp – list processes and thread‑level CPU consumption. jstack – dump Java thread stacks to locate hot threads and potential deadlocks. pstack – Linux utility for native thread stack traces.

Memory Analysis Tools top – monitor live memory usage. jmap -histo:live <pid> – inspect object counts and memory usage. jmap -dump:live,format=b,file=heap.bin <pid> combined with MAT – detect memory leaks and analyse heap composition.

By combining these Linux and Java‑specific utilities, operations engineers can pinpoint resource‑intensive code paths, determine whether the cause is application logic or system constraints, and collaborate with developers to implement targeted optimisations.