JUnit 5 lets you choose a parallel execution strategy of dynamic, fixed, or custom. What does each one mean, and how do you control the resulting degree of parallelism?

## What a strategy configures When parallel execution is enabled, the Jupiter engine runs the test tree on a `ForkJoinPool`. A `ParallelExecutionConfiguration` supplies that pool's numbers — chiefly the **parallelism** (the target number of actively running threads), plus a minimum runnable count, a maximum pool size, a keep-alive time, and whether the pool may saturate. The configuration parameter ``` junit.jupiter.execution.parallel.config.strategy = dynamic | fixed | custom ``` selects who produces that configuration. Note this is orthogonal to the execution *mode*: modes decide **which nodes may overlap**, the strategy decides **how many threads are available** to overlap them. Both are needed; neither substitutes for the other. ## dynamic The default. Parallelism is computed from the machine: ``` parallelism = ceil(Runtime.getRuntime().availableProcessors() × factor) ``` where the factor comes from `junit.jupiter.execution.parallel.config.dynamic.factor` and defaults to `1.0`. So on an 8-core machine you get 8 by default. The factor is the tuning dial. For **CPU-bound** unit tests, a factor around 1.0 is right — more threads than cores just adds context switching. For **I/O-bound** tests (HTTP calls, database round-trips, `Thread.sleep`-style waits) each thread is idle most of the time, so factors of 2–4 often cut wall-clock time substantially. Values below 1.0 are the polite choice on a developer laptop where the IDE and the browser also want CPU. The hazard of `dynamic` is that `availableProcessors()` reports what the JVM believes it has. In a container with a fractional or capped CPU quota, modern JVMs respect cgroup limits reasonably well, but on shared CI executors you can still end up sizing to the host's 64 cores while your job is allowed a fraction of that — producing heavy contention and *slower* runs than sequential. ## fixed ``` junit.jupiter.execution.parallel.config.strategy = fixed junit.jupiter.execution.parallel.config.fixed.parallelism = 4 ``` The `fixed.parallelism` parameter is mandatory for this strategy — omit it and configuration fails. The value is used verbatim regardless of the machine. This is the strategy to reach for when reproducibility matters: identical thread counts on every developer machine and every CI agent make timing-sensitive failures reproducible and stop a beefy workstation from hiding a race that a two-core CI box exposes (or vice versa). It is also the honest answer when your tests contend on one external resource — a single database — where more than N concurrent tests only queues on the far side. ## custom ``` junit.jupiter.execution.parallel.config.strategy = custom junit.jupiter.execution.parallel.config.custom.class = com.example.CiAwareStrategy ``` The named class implements `ParallelExecutionConfigurationStrategy`, a single method taking the `ConfigurationParameters` and returning a `ParallelExecutionConfiguration`. Use it when the number has to come from somewhere JUnit cannot see: a `CI_PARALLELISM` environment variable, the number of database schemas your test harness provisioned, a shard index, or a rule like "half the cores, but never more than six". ## Pool size, saturation and blocked tests Since JUnit 5.10 both built-in strategies expose two extra parameters — a maximum pool size (`…config.dynamic.max-pool-size-factor`, default 256, and `…config.fixed.max-pool-size`) and a saturate flag (`…config.dynamic.saturate` / `…config.fixed.saturate`, default `true`). They exist because the pool is a `ForkJoinPool`: when a test blocks — waiting on a lock, on I/O, on another test — the pool may compensate by starting an additional worker so that the *target* parallelism of running threads is maintained. Without headroom, a suite where many tests block can deadlock or crawl. Setting `saturate=false` makes the pool refuse to exceed its bounds, which is stricter but risks starvation. In practice you leave these alone until you observe a stall. The practical consequence to remember: **parallelism is a target for runnable threads, not a hard cap on threads**. If you must guarantee that no more than N tests touch an external system at once, enforce it with a semaphore or an exclusive-resource declaration, not by setting parallelism to N. ## Picking a number Start with `dynamic` and factor 1.0, measure, then adjust. Increase the factor while wall-clock time keeps dropping; stop when it plateaus or the failure rate rises. Switch to `fixed` once you want CI and local runs to behave identically or once the JVM's view of the CPU count is untrustworthy. Reach for `custom` only when the value must be derived at runtime from information outside JUnit.