Deadlocks shouldn't be invisible.

DIXY helps Java developers detect, investigate, and understand application deadlocks with JVM-level diagnostics and developer-friendly tooling.

Get Started Explore GitHub

curl -fsSL https://raw.githubusercontent.com/roy-gunjan743/DIXY-CLI/main/install.sh | sh

macOS / Linux. Needs Java 21+. Windows and other options

~/orders-service — dixy detect

$ dixy detect --jar ./orders-service.jar
Agent Started Successfully
Reporting detected deadlocks to: http://localhost:8081/api/internal/deadlocks
[2026-10-30T09:14:00Z] threads=14 locks=6 waits=0 cycles=0
[2026-10-30T09:14:01Z] threads=14 locks=6 waits=1 cycles=0
[2026-10-30T09:14:02Z] threads=14 locks=6 waits=2 cycles=1
ALERT: DEADLOCK CYCLE 1
  worker-2 holds Monitor-2351897819504; worker-1 waits for it
  worker-1 holds Monitor-2351897820112; worker-2 waits for it
$ echo $?
1   # deadlock found

Representative output · format from cli/DetectApplicationRunner.java

Java 21JVMTI native agentJava Flight RecorderVirtual threadsSpring Boot + Spring ShellMIT licensed

The problem

One blocked thread can hide an entire system problem.

Deadlocks are relationships, not errors. Nothing throws, nothing logs — two threads simply wait for each other forever.

Hard to identify

A deadlocked service doesn't crash. It just stops answering, and from the outside it looks like a slow dependency.

BLOCKED "worker-1" waiting to lock <0x…504>

at OrderService.reserve(…)

BLOCKED "worker-2" waiting to lock <0x…112>

at Inventory.commit(…)

RUNNABLE "http-nio-8080-exec-3"

… 37 more threads

Hard to investigate

The evidence is a relationship between threads and locks, spread across dozens of stack traces.

1. find the pid
2. dump the threads
3. read every trace
4. map who holds what
5. repeat on the next host

Manual JVM diagnostics are costly

Capturing dumps at the right moment, on the right host, then reading them by hand takes time you don't have during an incident.

How it works

Discover. Analyze. Diagnose.

01
Discover
The Java agent attaches to your JVM and collects lock and thread events from JVMTI, JFR and a thread-state poller.
EventSender.java (opens source on GitHub)
02
Analyze
Each event updates a wait-for graph: which thread owns each lock, and which thread waits for which lock.
GraphGateway.java (opens source on GitHub)
03
Diagnose
Cycle detection finds threads waiting on each other and reports exactly who holds what — in the CLI and the REST API.
DeadlockDetector.java (opens source on GitHub)

Features

Built on the JVM's own signals.

Every badge below is backed by code in the repository. See the full feature matrix.

01Available

JVM-level diagnostics

A native C++ JVMTI agent subscribes to monitor-contention events, so DIXY sees the moment a thread blocks on a monitor and the moment it gets it.

agent.cpp JvmtiBridge.java

native/src/agent.cpp · excerpt

jvmti->SetEventNotificationMode(
    JVMTI_ENABLE,
    JVMTI_EVENT_MONITOR_CONTENDED_ENTER, nullptr);
jvmti->SetEventNotificationMode(
    JVMTI_ENABLE,
    JVMTI_EVENT_MONITOR_CONTENDED_ENTERED, nullptr);

02Available

Java agent integration

Attach to any Java 21 application with -javaagent, or let dixy detect launch or attach for you. Detected cycles are pushed to the backend; a network failure never breaks your app.

VirtualDeadlockAgent.java RemoteReportSink.java

bash

$ java -javaagent:dixy-agent.jar=serverUrl=http://localhost:8081,apiKey=…,appName=orders \
    -jar orders-service.jar

03Available

Thread and synchronization monitoring

JFR streams thread lifecycle, monitor and park events — including jdk.VirtualThreadPinned for virtual-thread pinning — while a poller fills in live wait states.

JfrEventListener.java ThreadStatePoller.java

jdk.ThreadStartjdk.ThreadEndjdk.JavaMonitorEnterjdk.JavaMonitorWaitjdk.ThreadParkjdk.VirtualThreadPinned

04Available

Wait-for graph analysis

Threads and locks become a graph. A cycle means every thread in it waits for the next — a deadlock. Cycles with a pinning edge are flagged as pinning deadlocks.

WaitForGraph.java DeadlockDetector.java PinningDetector.java

thread
lock
holds
waits
deadlock cycle

05Available

CLI experience

dixy opens an interactive shell with tab completion. dixy detect scans non-interactively with JSON output and exit codes for scripts.

dixy.sh DeadlockCommands.java CliConfig.java

dixy

$ dixy
dixy> status
dixy> threads list
dixy> deadlocks detect
dixy> detect --json

Commands from cli/*.java

06Available

Diagnostic event collection

Threads, locks, wait edges and deadlock reports are stored in PostgreSQL and served over a REST API with API-key auth, plus Prometheus metrics.

TelemetryController.java GraphPersistenceService.java

bash

$ curl -H "X-API-Key: dixy-local-dev-key-123" \
    http://localhost:8081/api/deadlocks

Architecture

From JVM event to deadlock report.

Hover or select a component to see its role and the source file behind it.

Full architecture

Target JVM

Collection

Processing

Detection

Output

Cycle detection

DeadlockDetectorAvailable

Depth-first search for cycles. PinningDetector keeps cycles containing a PINS edge.

DeadlockDetector.java PinningDetector.java

CLI

Every command here exists in the code.

Copied from the command definitions in the repository.

$ dixyterminal

Open the interactive dixy> shell.

$ dixy detect --pid <pid>terminal

Attach the agent to a running JVM and scan every second.

$ dixy detect --jar <path> --jsonterminal

Same scan, machine-readable {"cycles":[...]} snapshots.

$ dixy <app-directory>terminal

Pick a runnable jar in the folder, start it with the agent, open the shell.

dixy> statusshell

Diagnostic status: HEALTHY / WARNING / CRITICAL.

dixy> deadlocks listshell

List the latest stored deadlock reports.

dixy> events listshell

Recent raw JVMTI events (LockOwned / LockReleased).

dixy> helpshell

List every command and its options.

All 19 commands are in the CLI reference.

Why DIXY

Ad-hoc diagnosis vs. a dedicated workflow.

A qualitative comparison of how the work gets done. No benchmarks, no competitor claims.

Manual diagnosis compared with DIXY's workflow
Task	Ad-hoc manual	With DIXY
Finding the deadlock	Spot a hang, then take thread dumps at the right moment	Continuous scan every second; alert as soon as a cycle exists
Reading the evidence	Cross-reference lock addresses across many stack traces	Prints each edge: who holds which lock, who waits for it
Virtual threads	Look for pinning separately with JFR tooling	jdk.VirtualThreadPinned feeds the same graph
Automation	Ad-hoc scripts around dump tools	Exit code 1 on deadlock, --json output
History	Dumps saved wherever someone put them	Reports stored and queryable via CLI and REST

Make your Java applications easier to debug.

Open source, MIT licensed, and built on JVMTI and JFR.

Explore on GitHub Read Documentation