Analysis of Java.util.concurrent Locks

1. Introduction

Performance analysis of a program is an important aspect of the application development process. This work is typically done by professionals who aim to improve the performance of the code on a specific platform. When programs are multithreaded or parallel programs running on multi-core platforms, the problem of improving performance becomes more difficult. Because in such cases, you need to consider not only the performance of the code, but also the scalability of the code.

With the introduction of the Java.util.concurrent (JUC) package in Java 5, a new lock appears in the Java language. JUC packages are increasingly used because more applications need to be developed or carefully tuned for multicore systems. Although JLM can find the detailed competitive information of traditional Java locks, there is no similar tool to find the lock competition information for java.util.concurrent.locks packets. Sun/oracle, IBM, and other Java vendors do not have such a tool. The lack of profiling tools for JUC locks is the motivation for us to develop this lock tool, Jucprofiler (part of the Multicore SDK).

2. Jucprofiler Overview

When a JUC lock is used in a program, the thread "stops" execution in the following two situations:

When thread a attempts to acquire a JUC lock, but the lock is already obtained by another thread, thread A has to "stop" until the lock is released or timed out.

When thread A calls any "Wait" API for Java.util.concurrent.locks.Condition, thread a stops execution until another thread notifies it or times out.

We call these two situations "lock competition Time" and "Wait Time" respectively.

Jucprofiler is designed and implemented to capture the time overhead of both of these situations.

2.1. Code modification (instruments)

In order to obtain run-time data for Juc locks, some JUC classes need to be modified in advance, and then the corresponding classes in the JRE are replaced. Before using Jucprofiler for the first time, users need to run commands to generate Preinstrument.jar. If the JRE doesn't change, this step needs to be done only once. (If the user changes the JRE, the user needs to delete the Preinstrument.jar himself, and then rerun the command to generate Preinstrument.jar again).

2.1.1. Lock competition Time overhead

For the lock competition time overhead, Jucprofiler records the application class Java.util.concurrent.locks.AbstractQueuedSynchronizer and class Java.util.concurrent.locks.abstractqueuedsynchronizer$conditionobject, and assigns unique identities to these instances.

Class	Method	Call location
Java.util.concurrent.locks.LockSupport	Park (Object);	Methods in class Abstractqueuedsynchronizer Parkandcheckinterrupt ()
	Parknanos (Object blocker, long Nanos)	Method Doacquirenanos in class Abstractqueuedsynchronizer (int arg, long nanostimeout) and Doacquiresharednanos (int arg, long Nanostimeout)

2.1.2. Lock wait Time overhead

For lock wait time overhead, Jucprofiler gets the method to invoke class Java.util.concurrent.locks.LockSupport at different Locations Park (blocker) and Parknanos (blocker, Nanos) Time Cost:

Class	Method	Call location
Java.util.concurrent.locks.LockSupport	Park (Object);	Class Abstractqueuedsynchronizer methods other than Parkandcheckinterrupt ()
	Parknanos (Object blocker, long Nanos)	Class Abstractqueuedsynchronizer except Doacquirenanos (int arg, long nanostimeout) and Doacquiresharednanos (int arg, long Nanostimeout) methods outside the