- System requirements
- Profiler architecture
- Profiler installation
- Uninstall profiler
- Running the profiler
- Profiler activation
- Welcome screen
- Start profiling
- Profiling overhead
- Snapshots
- Solving performance problems
- CPU profiling
- Thread profiling
- Threads tab
- Thread states
- Deadlock detector
- Frozen threads
- Virtual threads support
- Memory profiling
- Object allocation profiling
- Garbage collection
- Monitor profiling
- Exception profiling
- Telemetry
- Probes: monitor events of various kinds
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Automatic deobfuscation
- Summary
- Filters
- Profiler command line
- Export of profiling results to external formats
- Profiler Java API
- Profiler HTTP API
- Settings
- Troubleshooting and FAQ
Frozen threads
The profiler can detect deadlocks which are not otherwise reported by standard Java mechanism which detects only Java-level deadlocks, but does not detect deadlocks of Java threads caused by JVM internal locks (e.g. class loader) or native methods which explicitly use low-level synchronization primitives.
An heuristics detects threads whose stack does not change for some period of time, which is a sign of potential deadlock or hung thread.
Well-known cases when thread can legally stay in same state for a long time are excluded. In particular, it can be threads that are waiting for incoming connection in ServerSocket.accept(), some JVM internal threads etc.
Important: the frozen thread detection depends on thread profiling. If thread profiling is stopped, the detection is not possible.
Potential deadlocks are not necessarily actual deadlocks. It is possible that the reported threads are performing the same operation for a long time, and will eventually finish. Use Refresh button to check if detected threads are still considered frozen.
For each potentially deadlocked or hanged thread there is a link to ignore it. Once ignored, the stack will no longer be reported as a potential deadlock.
