Using the Locking perspective
The Locking perspective provides information in graph and table form that helps you understand any contention caused by locking.
Information is shown for two kinds of locks:
- Java™ monitors
- synchronized Objects in the Java application, provided as part of the Java Class Libraries, middleware, independent software packages, or application code.
- System monitors
- locks that are part of the Java runtime environment itself.
Java monitors are shown by default and are most useful in resolving application contention issues. To show the system monitors, use the Show... icon in the toolbar of the table or plot.
Garbage collection time is removed from hold times for all monitors held across a garbage collection cycle.
Understanding the bar chart
The bar chart gives an overview of how contended the application locks are.
The height of the bars represents the slow lock count and is relative to all the columns in the graph. A slow count occurs when the requested monitor is already owned by another thread and the requesting thread is blocked.
The color of each bar is based on the value of the % miss column in the table. The gradient moves from red (100%), through yellow (50%), to green (0%). A red bar indicates that the thread blocks every time that the monitor is requested. A green bar indicates a thread that never blocks.
Only the most contended monitors are shown.
Understanding the table
The Monitors table shows the data for each monitor listed:
Column heading | Description |
---|---|
% miss | The percentage of the total Gets, or acquires, for which the thread trying to enter the lock on the synchronized code had to block until it could take the lock. |
Gets: | The total number of times the lock has been taken while it was inflated. |
Slow: | The total number of non-recursive lock acquires for which the requesting thread had to wait for the lock because it was already owned by another thread. |
Recursive: | The total number of recursive acquires. A recursive acquire occurs when the requesting thread already owns the monitor. |
% util: | The amount of time the lock was held, divided by the amount of time the output was taken over. |
Average hold time: | The average amount of time the lock was held, or owned, by a thread. For example, the amount of time spent in the synchronized block, measured in processor clock ticks. |
Name: | The monitor name. This column is blank if the name is not known. |
The table lists every monitor that was ever inflated. The % miss column is of initial interest. A high % miss shows that frequent contention occurs on the synchronized resource protected by the lock. This contention might be preventing the Java application from scaling further.
If a lock has a high % miss value, look at the average hold time and % util. If % util and average hold time are both high, you might need to reduce the amount of work done while the lock is held. If % util is high but the average hold time is low, you might need to make the resource protected by the lock more granular to separate the lock into multiple locks.
Understanding lock names
The monitor names include an object address, shown in brackets, and the type of the lock. For example, when synchronizing on an object with class Object, the monitor name includes an address and java/lang/Object.
Locking on AIX
AIX® architecture means that locking works differently from other platforms. On AIX, more locks might be shown as badly performing, especially system monitor locks. This is expected behavior on AIX.