A Simple Custom Wait Method for Java/Groovy Multithreaded Tests

Background

When measuring the performance of multithreaded utilities or frameworks, the usual workflow consists of preparing input data, writing a test method, launching a set of threads that execute the method, waiting for all threads to finish, and finally aggregating the results.

Earlier synchronization with java.util.concurrent.Phaser

In previous experiments a Phaser instance was created with the expected number of parties and each worker thread called phaser.arriveAndAwaitAdvance() (or similar) to signal completion. While functional, passing the Phaser object around makes the code harder to read, especially when the core work is expressed as a Groovy closure.

Groovy‑based asynchronous task

public static void main(String[] args) {
    // custom asynchronous task expressed as a closure
    def funtester = {
        fun {
            // syncDoSomething()
        }
    }
    // launch 10 threads executing the closure
    10.times { funtester() }
}

Encapsulating the task body in a closure improves readability, but the need to supply a Phaser as a second argument quickly becomes cumbersome:

public static void main(String[] args) {
    def phaser = new Phaser(10)
    def funtester = {
        fun({
            // syncDoSomething()
        }, phaser)
    }
    10.times { funtester() }
}

Custom waiting utility

To avoid explicit synchronization objects, a generic waiting method was created. The method repeatedly evaluates a supplied boolean‑returning Supplier until it becomes true, sleeping 0.5 seconds between checks.

/**
 * Wait until the supplied condition returns true.
 * The check interval is 0.5 seconds.
 */
public static void waitFor(Supplier<Boolean> condition) {
    while (!condition.get()) {
        sleep(0.5);
    }
}

Example usage

Assume ten threads each compute a result and store it in a thread‑safe list ts (e.g., Collections.synchronizedList(new ArrayList<>())). The main thread can block until the list size exceeds the expected count:

// Groovy closure syntax
waitFor { ts.size() > 10 }

// Equivalent Java‑style lambda
waitFor(() -> ts.size() > 10);

This approach eliminates the need to pass a Phaser or other coordination primitive to each worker. It is especially useful for quick stress‑testing scripts where the only requirement is “wait until all workers have produced their output”.

Notes and caveats

The waiting loop uses sleep(0.5), which in Groovy translates to a half‑second pause; adjust the interval for tighter latency requirements.

The condition must be side‑effect‑free and thread‑safe; reading the size of a concurrent collection is safe, but mutating state inside the condition can lead to race conditions.

Because the method blocks the calling thread, it should be used only in test or benchmarking harnesses, not in production code where non‑blocking coordination is preferred.