Investigate high CPU usage, memory problems, and slow Java applications with JDK diagnostic tools. Start from symptoms, collect suitable evidence, and narrow down causes while accounting for collection overhead and sensitive data.
Symptom-first runtime diagnostics for JVM applications using JDK tools: jcmd, jstack, jmap, jstat, JFR, GC logs, async-profiler, Native Memory Tracking, and Eclipse MAT. Use when a Java app has high CPU, memory leaks or OutOfMemoryError, slow startup, deadlocks or thread starvation, long GC pauses, native memory growth, or slow requests. Includes permission tiers for safe use.
Run score Not tested
See how to installThis skill investigates high CPU use, memory problems, slow startup, and slow responses in Java applications using tools suited to each symptom. It uses thread information from jcmd and jstack, checks memory collection with jstat and GC logs, and can proceed to JFR or async-profiler to record runtime behavior. It recommends combining repeated samples with another source of evidence to test a cause hypothesis.
Use it when a Java application is slow or under strain and you are unsure what evidence to collect. It also covers deadlocks and memory growth outside the Java heap. After a fix, it guides you to measure again using the same method and compare the results.
OutOfMemoryError.”Run diagnostic tools as the same OS user as the target JVM. Recording or attach operations require consent, and production diagnostics require explicit instruction. Heap dumps may contain sensitive information: analyze them locally, do not share them, and delete them afterward. Account for pauses during collection and available disk space.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 25, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Pick the lightest tool that answers the question, starting from the symptom.
| Tier | Tools | Rule |
|---|---|---|
| 1. Read-only | jps -l, jcmd <pid> help/VM.version/VM.flags/Thread.print, jstat, jstack, reading logs | May run after stating the exact command. Class histograms (jcmd <pid> GC.class_histogram, jmap -histo, jmap -histo:live) are NOT Tier 1: they run heap inspection at a safepoint and can pause application threads on a large heap, so treat them as Tier 2 (consent, stated overhead). The default forms and -histo:live additionally force a full GC; -all=true / jmap -histo skip the full GC but still pause during the scan (and count unreachable objects). |
| 2. Recording / attach | JFR (JFR.start, -XX:StartFlightRecording), async-profiler, NMT (-XX:NativeMemoryTracking), enabling GC logs | Requires user consent. State duration and expected overhead (JFR default profile is about 1-2%; async-profiler depends on mode; NMT summary roughly 5-10%, detail more) before running. |
| 3. Intrusive / sensitive | Heap dumps (GC.heap_dump, jmap -dump), jhsdb, commands that print JVM arguments or system properties (jps -v/-lv/-m, bare jcmd, VM.system_properties, VM.command_line, jinfo, ps aux on a Java process; they can expose secrets, redact output), JDWP with suspend, anything on production | Requires explicit consent, a stated target path, free-disk check (a dump is about the size of the used heap), and a stated pause. Heap dumps contain secrets (passwords, tokens, personal data). Never share or upload them; redaction is NOT a reliable safeguard. Analyze locally and delete afterwards. |
Never run Tier 2 or Tier 3 commands against production unless the user explicitly instructs it. Run diagnostic tools as the same OS user as the target JVM. Prefer reproducing on dev or staging.
| Symptom | First step | Then | Reference |
|---|---|---|---|
| High CPU | Thread dumps x3 (Tier 1) + top -H to map hot native thread ids to nid | JFR or async-profiler CPU flame graph (Tier 2) | threads, jfr, async-profiler |
| Memory leak / OOM | jstat -gcutil, GC.class_histogram -all=true twice, minutes apart (Tier 2: safepoint pause even with -all=true; without it a full GC too; get consent on production) | Heap dump + Eclipse MAT (Tier 3) or JFR OldObjectSample (Tier 2) | heap, gc |
| Slow startup | -Xlog:class+load, framework startup/condition reports, timestamped logs | JFR from start, async-profiler wall-clock | jfr, async-profiler |
| Deadlock / thread starvation | jcmd <pid> Thread.print (reports deadlocks), compare dumps over time | Virtual threads: Thread.dump_to_file | threads |
| GC pauses | GC log (-Xlog:gc*) and jstat -gc | JFR GC events; tune collector/heap | gc |
| Native memory growth (RSS grows, heap does not) | Compare RSS vs heap; enable NMT, jcmd VM.native_memory baseline / summary.diff (Tier 2) | async-profiler nativemem or allocator tools | nmt, containers |
| Slow requests | Tracing/metrics and logs first; Actuator or Dev UI (see below) | JFR (socket/file/lock events), async-profiler wall-clock | jfr, async-profiler |
| JVM crash / hang, no tools respond | hs_err_pid*.log, core dump | jhsdb (Tier 3) | basics |
Start with jps/jcmd basics to identify the target JVM and confirm which JDK version is running.
JDK tools see the JVM; some questions (which endpoint, which SQL query, which bean) are easier at the application level. Optional options, in order of preference:
metrics, health, loggers, httpexchanges) and Quarkus Dev UI / Micrometer metrics are built in and need no extra tool. Expose Actuator endpoints minimally; For heapdump and threaddump, follow the policy in the spring-observability skill: never expose them over public HTTP; the only exception is a temporary, user-consented window with authentication, TLS and network restriction, removed afterwards.gh skill install jdubois/boot-ui skills/bootui.If considering BootUI:
Follow the project's own documentation for usage; this skill does not reproduce it.
See containers for attaching tools inside containers, -XX:MaxRAMPercentage, and cgroup memory limits.
java-debugging skill.Official docs (prefer them over this skill for the JDK in use; change 21 to your version): jcmd https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html, jfr https://docs.oracle.com/en/java/javase/21/docs/specs/man/jfr.html, JFR guide https://docs.oracle.com/en/java/javase/21/jfr/introduction-jdk-flight-recorder.html, troubleshooting guide https://docs.oracle.com/en/java/javase/21/troubleshoot/, async-profiler releases https://github.com/async-profiler/async-profiler/releases.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Map an existing codebase into seven documents covering its technology, structure, architecture, conventions, integrations, tests, and concerns. Link findings to file evidence, mark unknowns, and highlight differences between stated plans and the actual implementation.
Assess a repository’s readiness for AI agents with AgentRC and generate a standalone HTML dashboard. Review scores across nine areas, see prioritized improvements, and optionally apply scoring policies tailored to an organization.
Generate coding agent instruction files from a project's actual code using AgentRC. Capture detected languages, frameworks, and conventions in one shared file or split rules by topic and project area, with a preview before writing.
Customize AgentRC readiness assessments to match team or organization standards. Choose or create policies that adjust check importance, disable irrelevant checks, set pass thresholds, and define requirements for automated checks in CI workflows.
Analyze supplied ad performance data to identify wasted spend, strong campaigns, and next tests. Compare channels, assess whether test differences are meaningful, and produce budget reallocation recommendations with a prioritized action plan.
Turn code files into learning resources by adding comments that explain syntax, programming concepts, and design choices. Adjust explanation depth and repetition to the reader’s knowledge while preserving file structure, encoding, and syntax.