Multithreading & Concurrency

The JVM executes bytecode, the JRE = JVM + core libraries, and the JDK = JRE + developer tools (javac, jar, jlink, jshell).

• JVM: class loading, bytecode verification, interpretation + JIT compilation, garbage collection.
• Since Java 11 there is no separate JRE download; use the JDK, or build a trimmed runtime with jlink.

Always pass-by-value. For objects, the value copied is the reference, so a method can mutate the object but cannot make the caller's variable point elsewhere.

static void change(StringBuilder sb, String s) {
    sb.append("!");   // visible to caller
    sb = new StringBuilder("new"); // not visible
    s = s + "?";      // not visible, Strings are immutable
}

Class loader subsystem, runtime data areas, execution engine, and native interface.

• Class loader subsystem: loads, links and initializes classes.
• Runtime data areas: heap, per-thread stacks, program counter registers, native method stacks, metaspace (method area).
• Execution engine: bytecode interpreter, JIT compilers, garbage collector.
• JNI connects Java code to native libraries.

Loading, linking (verification, preparation, resolution) and initialization.

• Loading: read the .class bytes and create a Class object.
• Verification: check bytecode structure and type safety.
• Preparation: allocate static fields and set them to default values (0, null, false).
• Resolution: replace symbolic references with direct ones (may be lazy).
• Initialization: run static initializers and assign static field initializer values, in textual order.

Loaders delegate to their parent first; a child loads a class only if every ancestor failed. This prevents user code from replacing core classes like java.lang.String.

• Bootstrap loader: core java.base classes, written in native code (getClassLoader() returns null).
• Platform loader (extension loader before Java 9): other JDK modules.
• Application (system) loader: classpath/module path.

Heap (objects), thread stacks (frames with locals and operand stack), metaspace (class metadata), PC registers, native stacks, plus off-heap memory such as direct buffers and the code cache.

• Heap and metaspace are shared; stacks are per-thread.
• Total process memory = heap + metaspace + thread stacks + code cache + direct memory + GC overhead.

Young generation (Eden + two survivor spaces) and old generation. New objects go to Eden; survivors of minor GCs are copied between survivor spaces and promoted to old after reaching a tenuring threshold.

• Based on the weak generational hypothesis: most objects die young.
• G1 uses equal-sized regions that play the eden/survivor/old roles dynamically.

Each method call pushes a frame holding local variables, an operand stack and a reference to the constant pool. The frame is popped on return or exception unwinding.

• Size is set with -Xss (default typically 1 MB on 64-bit Linux).
• Too-deep recursion causes StackOverflowError.

Metaspace stores class metadata in native memory and replaced PermGen in Java 8. It grows dynamically instead of having a fixed size inside the Java heap.

• Limit it with -XX:MaxMetaspaceSize; unlimited by default.
• Metadata is freed when the defining class loader becomes unreachable.
• Interned strings and static field values moved to the heap (Java 7/8).

byte 8-bit, short 16, int 32, long 64, float 32, double 64, char 16 (unsigned), boolean (JVM-dependent size, one bit of information).

• Fields default to 0, 0.0, '\u0000', false; references default to null.
• Local variables have no default and must be definitely assigned before use.

The compiler inserts Integer.valueOf(int) for boxing and intValue() for unboxing. No magic at runtime, just generated calls.

• Integer, Long, Short, Byte, Character (0..127) cache small values; Boolean has two constants.
• Float and Double have no cache.

Widening (int to long) is implicit and safe in range; narrowing (long to int) needs an explicit cast and can lose data via truncation of high bits.

• int to float and long to double are widening but can lose precision.
• Compound assignment (+=) includes an implicit narrowing cast.

Binary floating point cannot represent most decimal fractions exactly (0.1), so errors accumulate. Use BigDecimal (constructed from a String) or integer minor units.

• IEEE 754: 1 sign bit, exponent, mantissa.
• BigDecimal needs an explicit RoundingMode for non-terminating divisions.

char is a 16-bit UTF-16 code unit, and arithmetic on it promotes to int. Characters outside the BMP take two chars (a surrogate pair).

• Use String.codePoints() or codePointAt for real characters.
• 'a' + 1 is the int 98; (char) ('a' + 1) is 'b'.

String is final with a private final value array, which makes it thread-safe, cacheable by hash and safe as a map key. Literals are interned into a pool on the heap so identical literals share one instance.

• Immutability enables the pool, hash caching and security (class names, paths).
• Since Java 9 strings use compact Latin-1/UTF-16 byte arrays.

String is immutable; StringBuilder is a mutable, unsynchronized builder; StringBuffer is the synchronized legacy version.

• Use StringBuilder for loops that append; + in a loop creates a builder per iteration.
• Java 9+ compiles + using invokedynamic (StringConcatFactory).

== compares primitives by value and references by identity; equals compares logical content if overridden. The default Object.equals is identity.

&& and || skip evaluating the right operand when the left already decides the result. & and | on booleans always evaluate both sides.

if (s != null && s.length() > 3) { /* safe */ }

++i increments then yields the new value; i++ yields the old value then increments. As standalone statements they are equivalent.

It wraps silently in two's complement; no exception. Integer.MAX_VALUE + 1 equals Integer.MIN_VALUE.

• Use Math.addExact, multiplyExact, toIntExact to throw ArithmeticException.
• Floating point overflows to Infinity instead.

<< shifts left filling zeros, >> is an arithmetic shift that preserves the sign bit, and >>> is a logical shift that fills with zeros.

• The shift distance is masked: int uses the low 5 bits, long the low 6 bits.
• x >> 1 equals floor division by 2; -7 >> 1 is -4, while -7 / 2 is -3.

If both operands are numeric, binary numeric promotion applies; if one is a boxed type and the other a primitive, the result is unboxed. So true ? 1 : 2.0 yields 1.0.

• Mixed Integer/int with a null operand can cause an unboxing NPE.
• With two references the result is the lub (least upper bound) type.

Execution jumps to the matching case and continues through subsequent cases until a break or the end. default can appear anywhere.

• Supported selector types: byte, short, char, int, their wrappers, enum, String (Java 7), and patterns (Java 21).

Since Java 14 switch can be an expression that produces a value, uses -> arms without fall-through, and must be exhaustive.

int days = switch (month) {
    case FEB -> 28;
    case APR, JUN, SEP, NOV -> 30;
    default -> { int d = 31; yield d; }
};

• Over an enum or sealed type exhaustiveness is checked without default.
• Java 21 adds pattern matching and case null.

For arrays it compiles to an index loop; for Iterable it uses iterator(). You cannot see the index or remove elements safely.

A label names an enclosing statement; break label exits it and continue label jumps to the next iteration of that labeled loop. It is structured, not a goto.

outer:
for (int i = 0; i < 3; i++)
    for (int j = 0; j < 3; j++) {
        if (j == 1) continue outer;
        if (i == 2) break outer;
    }

static members belong to the class, not to instances; they exist once per class loader and are initialized when the class is initialized.

• Static methods cannot access instance members directly and have no this.
• A static nested class has no implicit reference to an outer instance, unlike an inner class.

A static {} block runs once during class initialization; an instance {} block runs on every construction, before the constructor body (after super()).

• Both run in textual order together with field initializers.
• Instance initializers are rarely useful; constructors or field initializers are clearer.

A final variable can be assigned once, a final method cannot be overridden, and a final class cannot be extended.

• A blank final field must be assigned in every constructor or initializer.
• Final fields get special safe-publication guarantees in the Java Memory Model.

No. final fixes the reference, not the object's state; final List<String> l can still have elements added.

• True immutability: final class, private final fields, no setters, defensive copies in and out.
• List.of, Map.of and records (shallowly) support this style.

transient excludes a field from default Java serialization; on deserialization it gets the type default (null, 0, false).

• Used for derived data, caches, and secrets such as passwords.
• Does not apply to static fields, which are never serialized anyway.
• JSON libraries such as Jackson ignore transient unless configured; JPA treats it as non-persistent.

Visibility and ordering: a write to a volatile variable happens-before every subsequent read of it, and reads/writes are not reordered across it. It does not provide atomicity for compound actions.

• Good for flags and safe publication of immutable objects.
• long and double volatile reads/writes are atomic (non-volatile may tear on 32-bit JVMs per spec).

A local variable is effectively final if it is never reassigned after initialization. Lambdas and inner classes capture the value, so captured locals must not change.

Class init: superclass static initializers, then subclass static, once. For each instance: superclass instance initializers and constructor body, then subclass instance initializers and constructor body.

• Within one class, static fields/blocks and instance fields/blocks run in textual order.
• Fields not yet initialized hold defaults, which is why calling an overridable method from a constructor is dangerous.

Every constructor starts with this(...) or super(...), explicit or implicit (super()). The call must be the first statement (Java 22 preview relaxes this for code that does not reference this).

• If a class declares any constructor, the compiler does not add the default one.
• If the superclass lacks a no-arg constructor, the subclass must call another explicitly.

var lets the compiler infer the type of a local variable from its initializer (Java 10). The type is still static and fixed; var is not dynamic typing.

• Allowed: locals, for-loop variables, lambda parameters (Java 11).
• Not allowed: fields, method parameters/returns, no initializer, null initializer, array initializer {1,2}.
• var is a reserved type name, not a keyword; var var = 1; compiles.

A record is a transparent, shallowly immutable data carrier (Java 16). The compiler generates private final fields, a canonical constructor, accessors (name(), not getName()), equals, hashCode and toString.

record Point(int x, int y) {
    Point {                       // compact constructor
        if (x < 0) throw new IllegalArgumentException();
    }
}

• Records are implicitly final, cannot extend classes, but can implement interfaces and have static members.
• No instance fields beyond the components.

Multi-line string literals delimited by """ (Java 15). Incidental indentation is stripped based on the least-indented line (including the closing delimiter), and trailing spaces are removed.

String json = """
    {"name": "A"}
    """;

• Line endings are normalized to \n.
• \ at line end suppresses the newline; \s keeps a trailing space.

When it is no longer reachable from any GC root (thread stacks, static fields, JNI references, active class loaders). The GC traces reachability; it does not count references.

• Cyclic references among unreachable objects are collected.
• System.gc() is only a hint.

Serial (single thread), Parallel (throughput), G1 (balanced, default since Java 9 on server-class machines), ZGC and Shenandoah (low pause, concurrent compaction).

• Select with -XX:+UseSerialGC, -XX:+UseParallelGC, -XX:+UseG1GC, -XX:+UseZGC.
• Generational ZGC arrived in Java 21 (-XX:+ZGenerational, default in 23).
• Java 8 default is Parallel GC.

A stop-the-world pause halts all application threads at a safepoint so the GC can work with a consistent heap. GC roots are the starting points for tracing: local variables on thread stacks, static fields, JNI handles, and live class loaders.

• Concurrent collectors shrink pauses but still need short pauses for root scanning.
• Time-to-safepoint can be long when a thread is in a counted loop.

Strong references block collection. Soft references are cleared under memory pressure (caches), weak ones at the next GC when only weakly reachable (WeakHashMap), phantom ones are enqueued after finalization and used for cleanup via Cleaner.

The JVM starts by interpreting bytecode, profiles invocation and loop counts, and compiles hot methods to native code. Tiered compilation uses C1 (fast, light optimization) first and C2 (aggressive, profile-guided) for the hottest code.

• Compiled code lives in the code cache.
• Deoptimization falls back to the interpreter when an assumption (e.g., a monomorphic call site) breaks.
• -XX:+PrintCompilation shows compile events.

Method inlining, escape analysis (scalar replacement, lock elision), loop unrolling, dead code elimination, range-check elimination and devirtualization.

• Inlining is limited by bytecode size (MaxInlineSize, FreqInlineSize).
• Escape analysis can avoid heap allocation for objects that do not leave a method.

-Xms initial heap, -Xmx max heap, -Xss thread stack size, -XX:MaxMetaspaceSize metaspace cap, -XX:MaxDirectMemorySize direct buffers.

• Setting -Xms equal to -Xmx avoids resize pauses.
• In containers use -XX:MaxRAMPercentage (default 25%).

Overloads are chosen at compile time using the static argument types; overrides are dispatched at runtime using the object's actual class.

• Overload phases: exact/widening, then boxing, then varargs.
• Overriding requires the same signature, a compatible return type (covariant) and no weaker access.

private (class), package-private (default, same package), protected (package plus subclasses), public (everywhere). With modules (Java 9) a package must also be exportsed.

void f(String... a) is compiled to String[] a; the compiler packs the arguments into an array. It must be the last parameter, and only one is allowed.

Default methods (Java 8) let interfaces evolve without breaking implementors; static methods hold utilities; private methods (Java 9) share code between defaults. Interfaces still cannot hold instance state.

• If two interfaces supply the same default, the class must override and may pick one via A.super.m().
• A class method always wins over an interface default.

Equal objects must have equal hash codes; equals must be reflexive, symmetric, transitive, consistent and false for null. Unequal objects may share a hash code.

• Override both together; hash collections break otherwise.
• Do not use mutable fields in hashCode for objects stored in hash sets/maps.

if (o instanceof String s) tests and binds in one step (Java 16). sealed classes/interfaces (Java 17) restrict permitted subtypes, which enables exhaustive switch without default.

sealed interface Shape permits Circle, Square {}
record Circle(double r) implements Shape {}
record Square(double a) implements Shape {}
double area(Shape s) {
    return switch (s) {
        case Circle c -> Math.PI * c.r() * c.r();
        case Square q -> q.a() * q.a();
    };
}

(The switch pattern form is final in Java 21.)

equals, hashCode, toString, getClass, clone, finalize (deprecated), wait, notify, notifyAll. Typically equals, hashCode and toString are overridden.

• getClass, wait, notify and notifyAll are final.
• wait/notify require holding the object's monitor.

Usually less than 1,000,000 and different on each run. counter++ is read, add, write; concurrent threads overwrite each other's updates. Fix with AtomicInteger/LongAdder or synchronized.

The worker may never exit: with no happens-before edge the JIT can hoist the read of stop out of the loop. Declare stop volatile (or use interruption).

Thread 1 holds a waits for b; thread 2 holds b waits for a: deadlock. Always acquire in a consistent global order, e.g. by account id.

Account first = a.id < b.id ? a : b, second = first == a ? b : a;
synchronized (first) { synchronized (second) { move(a, b, amt); } }

Take a thread dump with jstack <pid> (or jcmd <pid> Thread.print, or kill -3). The dump ends with Found one Java-level deadlock: and lists the cycle. Programmatically use ThreadMXBean.findDeadlockedThreads().

Take 3 dumps 5-10 s apart and compare. Look for:

• Many threads BLOCKED on the same monitor (waiting to lock <0x...>) and who owns it.
• Threads in WAITING on a pool/queue or connection pool (HikariPool.getConnection).
• A thread RUNNABLE in the same frame across dumps (spinning/infinite loop).
• Pool threads all stuck in one remote call.

Run top -H -p <pid> to find the hottest thread id, convert to hex, then jstack <pid> | grep -A20 nid=0x<hex>. Check for tight loops, regex backtracking, a spinning CAS loop, or GC threads (name GC Thread). Confirm with a profiler (async-profiler/JFR).

Thread-starvation deadlock: all 10 workers can be occupied by parents blocking on child futures, while the children sit in the queue forever. Use separate pools, async composition, or ForkJoinPool.

Tasks 1-2 start core threads, 3-4 go to the queue, 5-6 create extra threads (max 4), task 7 is rejected (AbortPolicy throws RejectedExecutionException).

CallerRunsPolicy: the submitting thread executes the task itself, so it cannot submit more until done, throttling intake naturally. Pair with a bounded queue. For HTTP, prefer returning 429/503 via AbortPolicy if the caller thread is a request thread you cannot afford to block.

ScheduledExecutorService suppresses subsequent executions if any run throws, and the exception is stored in the Future unseen. Wrap the task body in try/catch and log.

Blocking tasks occupy the small common pool (cores - 1 threads), starving parallel streams and other async stages. Supply a dedicated bounded executor, or use virtual threads for blocking calls.

CompletionException:java.lang.RuntimeException: x. The failure passes through thenApply and arrives at exceptionally wrapped in CompletionException because it came from an upstream stage. If exceptionally were attached directly to the failing stage, you would see the raw RuntimeException ("x").

Start all three, then combine and apply orTimeout (Java 9+).

var a = CompletableFuture.supplyAsync(this::callA, pool);
var b = CompletableFuture.supplyAsync(this::callB, pool);
var c = CompletableFuture.supplyAsync(this::callC, pool);
CompletableFuture.allOf(a, b, c).orTimeout(2, TimeUnit.SECONDS).join();

completeOnTimeout(default, ...) supplies a fallback instead of failing.

Check-then-act race: both can see absence and both compute/put, the last write wins, and compute runs twice. Use computeIfAbsent(k, this::compute), which runs the function at most once per absent key.

In Java 8 it can livelock/hang (infinite loop on a reserved bin); since Java 9 it throws IllegalStateException: Recursive update when detected. HashMap throws ConcurrentModificationException (Java 9+). Compute outside the lambda or use a loop with get then putIfAbsent.

Lost updates, wrong size, null for present keys, and in Java 7 an infinite loop during resize (circular bucket list). Java 8 removed the cycle risk, but the map is still unsafe. Use ConcurrentHashMap.

ConcurrentModificationException (best-effort) because iteration is not atomic. Wrap iteration in synchronized (list) { ... }, or use CopyOnWriteArrayList (snapshot iteration).

Each add copies the array: O(n) allocation and GC churn, and writes block each other. Choose ConcurrentLinkedQueue, a ConcurrentHashMap.newKeySet(), or batch the changes.

The consumer is parked forever on an empty queue (non-daemon thread). Interrupt it (shutdownNow() or thread.interrupt()) and treat InterruptedException as the exit signal, or enqueue poison pills.

Use offer(e, timeout, unit) to wait a limited time and handle failure (retry, drop, spill to disk, return an error), or offer(e) for non-blocking. Choose based on whether data loss or latency is worse.

CountDownLatch(5); each service calls countDown() in finally, main calls await() (ideally with timeout).

CyclicBarrier(parties, mergeAction): all wait at await(), the barrier action merges round results, then the barrier resets for the next round. If one worker dies, others get BrokenBarrierException, so handle that.

Semaphore(5); acquire() before the call and release() in finally. This limits concurrency, not rate per second; for rate use a token bucket (e.g. Guava RateLimiter).

Pool threads outlive the webapp; their ThreadLocalMap values reference classes loaded by the old classloader, pinning it and all its static data (Metaspace growth). Call remove() in finally, avoid thread locals for such objects (use immutable DateTimeFormatter), and clean up in a context-destroy hook.

The new pool thread has no (or stale) value from the previous request. Capture the context and pass it explicitly or decorate the executor (Spring TaskDecorator, MDC copy, Micrometer context-propagation). Always clear in finally so pooled threads do not leak a previous user's data.

Two threads can both load; another can see a partially built object when unsafely published. Fix with a holder class, synchronized accessor, volatile DCL, or Supplier memoization with AtomicReference.

validate(stamp) returns false if any write lock was acquired since tryOptimisticRead(); values read in between may be inconsistent (e.g. new x, old y) and must be discarded. The reader falls back to readLock() and rereads. Never act on optimistic values before validating.

It deadlocks: the write lock waits for all readers (including itself) to release. Release the read lock, acquire the write lock, and recheck the condition. Downgrading (write then read then release write) is permitted.

The lock stays held forever, so other threads block indefinitely (unlike synchronized, which auto-releases). Always use try/finally. Place lock() before try, so a failed acquire does not trigger unlock().

Possible livelock: both keep acquiring one lock, failing the second, releasing and retrying in lockstep. Add randomized back-off, a timeout, or a consistent lock order.

Isolate with separate pools (bulkheads) per workload, or use a PriorityBlockingQueue with bounded size, and reserve capacity for critical tasks. Add queue-length and wait-time metrics.

It works without deadlock: monitors are reentrant, and the owning thread's hold count increments. The monitor is released only when the hold count returns to zero.

No. The static method locks Foo.class, the instance method locks this; they are different monitors, so they can run concurrently and do not protect shared state with each other.

A private final lock object. this is publicly lockable, so outside code (or a subclass) can interfere or cause deadlocks. Never lock on a String literal, boxed Integer, or a reassigned field either.

If the class is correctly constructed (no this escape), the reader sees the final fields correctly initialized. Non-final fields might be seen as defaults. If the object is a mutable one with non-final state, publish it safely: volatile field, synchronized, concurrent collection, or static initializer.

If thread 2 sees a == 2, it prints 1. The volatile write happens-before the read, and b = 1 precedes it in program order, so by transitivity b = 1 is visible (piggybacking). If a is not volatile, it may print 0.

get then set is two operations, so updates interleave and are lost. incrementAndGet is one atomic CAS loop. For custom updates use updateAndGet/accumulateAndGet with a side-effect-free function (it may be retried).

Push/pop via CAS on the head.

class Stack<T> {
    private record Node<T>(T v, Node<T> next) {}
    private final AtomicReference<Node<T>> head = new AtomicReference<>();
    void push(T v) {
        Node<T> h, n;
        do { h = head.get(); n = new Node<>(v, h); } while (!head.compareAndSet(h, n));
    }
    T pop() {
        Node<T> h;
        do { h = head.get(); if (h == null) return null; } while (!head.compareAndSet(h, h.next()));
        return h.v();
    }
}

In Java, ABA is mostly neutralized by garbage collection since nodes are freshly allocated and not reused, but reusing nodes (pooling) reintroduces it.

No. sum() is not an atomic snapshot, and you cannot get exact point-in-time totals. For exact figures, use AtomicLong or a lock, or accept approximate values for metrics only (sumThenReset is also racy).

IllegalMonitorStateException. wait/notify must be invoked inside synchronized on the same object. Same result when synchronizing on a different object than the one you call wait on.

Lost notification: the signal is not remembered and the waiter blocks forever. The fix is to guard with a state variable checked in a while loop under the same lock, so the waiter sees the condition already true and never waits.

Both producers and consumers wait on the same monitor, so notify() can wake the wrong kind (a producer waking a producer) and everyone sleeps. Use notifyAll(), or ReentrantLock with notFull/notEmpty conditions and signal().

lock.lock();
try {
    while (count == items.length) notFull.await();
    items[put] = x; put = (put + 1) % items.length; count++;
    notEmpty.signal();
} finally { lock.unlock(); }

More threads than 20 gain nothing, since they wait for connections. Size the worker pool at about 20 (or slightly above with a short connection timeout) and bound the queue. CPU count (8) is irrelevant for IO waits, but too many threads add contention and memory. Verify with load tests and queue-wait metrics.

About 16 (or 17). More threads add context switches and cache thrash with no extra throughput for CPU-bound work. For parallel stream or fork/join, the common pool defaults to cores - 1 workers plus the caller.

Stop accepting input first, then shutdown(), awaitTermination(timeout), and only on timeout shutdownNow(), followed by another await.

pool.shutdown();
if (!pool.awaitTermination(30, TimeUnit.SECONDS)) {
    pool.shutdownNow();
    pool.awaitTermination(10, TimeUnit.SECONDS);
}

Use get(timeout, unit) and on TimeoutException call future.cancel(true). Ensure the task responds to interruption. Add timeouts to the underlying I/O too.

With 200 platform threads only 200 calls are in flight, the rest queue, so total time is about 50 x latency. With virtual threads, all 10,000 blocking calls proceed concurrently with a few carrier threads, giving much higher throughput for I/O-bound work. Remaining limits: downstream capacity, connection pools, memory; use a Semaphore to cap concurrency to protected resources.

Common causes on Java 21: pinning from blocking inside synchronized (JDBC drivers, legacy libs), blocking native calls, a fixed-size pool of connections or a semaphore throttling everything, and ThreadLocal heavy caching (millions of copies). Diagnose with JFR event jdk.VirtualThreadPinned and -Djdk.tracePinnedThreads=full. Fixes: use ReentrantLock, upgrade the library, or Java 24+.

The scope shuts down: the sibling is interrupted/cancelled, join() returns, and throwIfFailed() rethrows the first failure wrapped in ExecutionException. Accessing get() on an unfinished or failed subtask throws IllegalStateException. The try-with-resources guarantees no subtask outlives the block. Preview API in Java 21, so it requires --enable-preview.

Data race on the unsynchronized ArrayList: lost elements, ArrayIndexOutOfBoundsException, or nulls. Use collect(Collectors.toList()) (or toList()), which merges per-thread containers safely.

Workers block instead of stealing, the pool (sized by cores) starves, and throughput drops, especially in the shared common pool, affecting unrelated stream and CompletableFuture users. Use a dedicated pool, ForkJoinPool.managedBlock, or non-fork/join executors for I/O.

Shrink the critical section (format outside the lock), use asynchronous appenders (queue plus one consumer, e.g. Log4j2 with Disruptor / Logback AsyncAppender), stripe locks, or use lock-free structures. Decide the policy on overflow (block, drop, or discard low levels). Confirm with a profiler and lock-contention metrics before and after.