mcpField
J
java-profiling

java-profiling

github.com/claude-dev-suiteDevelopment4644 installsUpdated 2d ago
Repository

About java-profiling

java-profiling is a reference skill for engineers diagnosing JVM performance. It covers JFR, jcmd, garbage collection, memory, CPU, and JIT analysis, with commands and troubleshooting guidance.

Key features

  1. 01JFR recording and analysis
  2. 02jcmd process and memory diagnostics
  3. 03GC selection, logging, and tuning
  4. 04CPU, allocation, and lock profiling
  5. 05JIT and memory troubleshooting

Use cases

  1. 01Investigating high CPU or thread contention
  2. 02Diagnosing heap or metaspace exhaustion
  3. 03Reviewing garbage-collection pauses
  4. 04Profiling allocations and lock behavior

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/claude-dev-suite/claude-dev-suite --skill java-profiling

After installing, type/java-profilingin Claude Code to confirm it loaded.

Details

From the project README

Java/JVM Performance Profiling

When NOT to Use This Skill

  • Node.js/JavaScript profiling - Use the nodejs-profiling skill for V8 profiler and heap analysis
  • Python profiling - Use the python-profiling skill for cProfile and tracemalloc
  • Application-level optimization - This is for JVM-level profiling, not algorithm optimization
  • Database query tuning - Use database-specific profiling tools
  • Frontend performance - Use browser DevTools for client-side profiling

Deep Knowledge: Use mcp__documentation__fetch_docs with technology: java for comprehensive JFR configuration, GC tuning, and JVM diagnostics.

Java Flight Recorder (JFR)

Starting JFR
# Start recording with application
java -XX:+FlightRecorder \
     -XX:StartFlightRecording=duration=60s,filename=recording.jfr \
     -jar app.jar

# Start recording on running JVM
jcmd <pid> JFR.start duration=60s filename=recording.jfr

# Continuous recording (always-on)
java -XX:+FlightRecorder \
     -XX:FlightRecorderOptions=stackdepth=256 \
     -XX:StartFlightRecording=disk=true,maxsize=500m,maxage=1d \
     -jar app.jar

# Dump current recording
jcmd <pid> JFR.dump filename=dump.jfr
JFR Configuration
# custom.jfc
<?xml version="1.0" encoding="UTF-8"?>
<configuration version="2.0">
  <event name="jdk.CPULoad">
    <setting name="enabled">true</setting>
    <setting name="period">1 s</setting>
  </event>
  <event name="jdk.GCHeapSummary">
    <setting name="enabled">true</setting>
  </event>
  <event name="jdk.ObjectAllocationInNewTLAB">
    <setting name="enabled">true</setting>
    <setting name="stackTrace">true</setting>
  </event>
</configuration>
Analyzing JFR Files
# Print JFR summary
jfr summary recording.jfr

# Print specific events
jfr print --events jdk.CPULoad recording.jfr
jfr print --events jdk.ExecutionSample --json recording.jfr

# Export to JSON
jfr print --json recording.jfr > recording.json

jcmd Diagnostics

Process Information
# List all Java processes
jcmd

# VM info
jcmd <pid> VM.version
jcmd <pid> VM.flags
jcmd <pid> VM.system_properties
jcmd <pid> VM.command_line

# Thread dump
jcmd <pid> Thread.print

# Heap info
jcmd <pid> GC.heap_info

# Class histogram
jcmd <pid> GC.class_histogram
Memory Analysis
# Native memory tracking (requires -XX:NativeMemoryTracking=summary)
jcmd <pid> VM.native_memory summary

# Heap dump
jcmd <pid> GC.heap_dump /path/to/dump.hprof

# Force GC
jcmd <pid> GC.run

GC Tuning

GC Selection
# G1GC (default in JDK 9+, recommended for heap > 4GB)
java -XX:+UseG1GC -jar app.jar

# ZGC (low latency, JDK 15+)
java -XX:+UseZGC -jar app.jar

# Shenandoah (low latency, OpenJDK)
java -XX:+UseShenandoahGC -jar app.jar

# Parallel GC (throughput)
java -XX:+UseParallelGC -jar app.jar
GC Logging
# JDK 9+ unified logging
java -Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=5,filesize=10m \
     -jar app.jar

# Common GC flags
java -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps \
     -XX:+PrintTenuringDistribution \
     -Xloggc:gc.log \
     -jar app.jar
G1GC Tuning
java -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=200 \        # Target pause time
     -XX:G1HeapRegionSize=16m \        # Region size
     -XX:InitiatingHeapOccupancyPercent=45 \  # Start marking at 45%
     -XX:G1ReservePercent=10 \         # Reserve for promotions
     -XX:ConcGCThreads=4 \             # Concurrent GC threads
     -XX:ParallelGCThreads=8 \         # Parallel GC threads
     -jar app.jar

Memory Optimization

Heap Sizing
# Set heap size
java -Xms4g -Xmx4g -jar app.jar  # Fixed heap (recommended for production)

# Metaspace sizing
java -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -jar app.jar

# Direct memory
java -XX:MaxDirectMemorySize=256m -jar app.jar
Memory Leak Detection
// Common leak patterns

// ❌ Bad: Static collections that grow
private static List<Object> cache = new ArrayList<>();
public void process(Object obj) {
    cache.add(obj);  // Never removed
}

// ✅ Good: Bounded cache with eviction
private static final Cache<String, Object> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofMinutes(10))
    .build();

// ❌ Bad: Unclosed resources
public void readFile(String path) {
    InputStream is = new FileInputStream(path);
    // Missing is.close()
}

// ✅ Good: Try-with-resources
public void readFile(String path) {
    try (InputStream is = new FileInputStream(path)) {
        // Process
    }
}

// ❌ Bad: ThreadLocal not cleaned
private static ThreadLocal<Connection> connHolder = new ThreadLocal<>();
public void process() {
    connHolder.set(getConnection());
    // Missing connHolder.remove()
}

// ✅ Good: Always clean ThreadLocal
public void process() {
    try {
        connHolder.set(getConnection());
        // Process
    } finally {
        connHolder.remove();
    }
}

CPU Profiling

async-profiler (recommended)
# Profile CPU
./profiler.sh -d 30 -f profile.html <pid>

# Profile allocations
./profiler.sh -d 30 -e alloc -f alloc.html <pid>

# Profile locks
./profiler.sh -d 30 -e lock -f lock.html <pid>

# Flame graph output
./profiler.sh -d 30 -f flamegraph.html -o flamegraph <pid>
JMC (Java Mission Control)
# Open JFR recording in JMC
jmc recording.jfr

Common Bottleneck Patterns

Synchronization Issues
// ❌ Bad: Coarse-grained locking
public synchronized void process(String key, Object value) {
    cache.put(key, value);
    compute(value);
}

// ✅ Good: Fine-grained locking
private final ConcurrentHashMap<String, Object> cache = new ConcurrentHashMap<>();
public void process(String key, Object value) {
    cache.put(key, value);  // Lock-free for different keys
    compute(value);
}

// ✅ Good: Read-write lock
private final ReadWriteLock lock = new ReentrantReadWriteLock();
public Object get(String key) {
    lock.readLock().lock();
    try { return cache.get(key); }
    finally { lock.readLock().unlock(); }
}
String Operations
// ❌ Bad: String concatenation in loop
String result = "";
for (String s : list) {
    result += s;  // Creates new String each iteration
}

// ✅ Good: StringBuilder
StringBuilder sb = new StringBuilder();
for (String s : list) {
    sb.append(s);
}
String result = sb.toString();

// ✅ Good: String.join for simple cases
String result = String.join("", list);
Collection Optimization
// ❌ Bad: ArrayList when size known
List<String> list = new ArrayList<>();
for (int i = 0; i < 10000; i++) {
    list.add(getData(i));  // Multiple resizes
}

// ✅ Good: Pre-size collections
List<String> list = new ArrayList<>(10000);

// ✅ Good: Use primitive collections for performance
// Use Eclipse Collections, Trove, or fastutil
IntList list = new IntArrayList(10000);
Boxing/Unboxing
// ❌ Bad: Autoboxing in hot path
public long sum(List<Long> numbers) {
    long sum = 0;
    for (Long n : numbers) {
        sum += n;  // Unboxing each iteration
    }
    return sum;
}

// ✅ Good: Use primitive streams
public long sum(List<Long> numbers) {
    return numbers.stream().mapToLong(Long::longValue).sum();
}

// ✅ Good: Primitive arrays when possible
public long sum(long[] numbers) {
    return Arrays.stream(numbers).sum();
}

JIT Optimization

Warm-up
// Warm-up critical paths before measuring
public static void main(String[] args) {
    // Warm-up phase
    for (int i = 0; i < 10_000; i++) {
        criticalMethod(i);
    }

    // Measurement phase
    long start = System.nanoTime();
    for (int i = 0; i < 100_000; i++) {
        criticalMethod(i);
    }
    long duration = System.nanoTime() - start;
}
JIT Logging
# Print JIT compilation
java -XX:+PrintCompilation -jar app.jar

# Print inlining decisions
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -jar app.jar

# Disable specific optimizations for debugging
java -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_hashCode -jar app.jar

Profiling Checklist

CheckToolCommand
CPU hotspotsJFRjcmd <pid> JFR.start
Memory usagejcmdjcmd <pid> GC.heap_info
GC behaviorGC logs-Xlog:gc*
Thread contentionJFRjdk.JavaMonitorWait events
Memory leaksHeap dumpjcmd <pid> GC.heap_dump
Class loadingjcmdjcmd <pid> VM.classloaders

Production Flags

java \
  -server \
  -Xms4g -Xmx4g \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UseStringDeduplication \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/heap.hprof \
  -Xlog:gc*:file=/var/log/gc.log:time,uptime:filecount=5,filesize=10m \
  -jar app.jar

Anti-Patterns

Anti-PatternWhy It's WrongCorrect Approach
System.out.println() in hot pathsExtremely slow, synchronous I/OUse SLF4J with async appenders
Creating many short-lived objectsGC pressure, allocation overheadReuse objects, use object pools
synchronized on hot pathsThread contention, poor scalabilityUse ConcurrentHashMap, ReentrantLock, or lock-free structures
String concatenation with + in loopsCreates many intermediate stringsUse StringBuilder
Autoboxing in loopsCreates wrapper objectsUse primitive types
Not sizing collectionsFrequent resizing, memory churnPre-size with new ArrayList<>(expectedSize)
finalize() for cleanupUnpredictable, deprecatedUse try-with-resources or explicit cleanup
Ignoring GC logsMiss performance degradationAlways enable GC logging in production
One-size-fits-all heapWrong GC pauses for workloadTune heap based on app behavior
Not using connection poolingConnection creation overheadUse HikariCP or similar

Quick Troubleshooting

IssueDiagnosisSolution
Long GC pausesHeap too large or wrong GCUse ZGC/Shenandoah or tune G1GC pause targets
OutOfMemoryError: Java heap spaceMemory leak or undersized heapAnalyze heap dump, increase -Xmx if needed
OutOfMemoryError: MetaspaceToo many classes loadedIncrease -XX:MaxMetaspaceSize or fix classloader leak
High CPU usageHot loop, inefficient algorithmCPU profile with JFR or async-profiler
Thread contentionLock competitionThread dump analysis, reduce lock scope
Slow startupClass loading, initializationUse AppCDS, lazy initialization
Memory leakUnclosed resources, static collectionsHeap dump comparison, find growing objects
GC overhead limit exceededGC taking > 98% of timeFix memory leak or increase heap
Full GC too frequentOld gen filling upTune heap ratio, fix object tenure issues
Application unresponsiveDeadlock or long GCThread dump to find deadlock, GC logs

Related Skills

Comments

Markdown supported