+- **Deadlock (Part A).** On the first load, several **independently-locked process-global registry singletons** — `RegistryManifest.defaultLoaderRegistry()` (DEFAULT_LOCK), `MetaDataRegistry.getInstance()` (INSTANCE_LOCK, reached via `ConstraintEnforcer.getInstance()` on the first `addChild`), and `ServiceRegistryFactory.getDefault()`, plus the JVM class-init locks of the ~18 type providers — could be acquired by two loader threads in **different orders** (a classic lock-ordering deadlock). `MavenLoaderConfiguration` first-touches the sealed registry on the Maven worker thread with no timeout, so a deadlock there wedged the reactor forever. A new **`RegistryBootstrap.warmUpDefaults()`** deterministically initializes those singletons on a single thread under one lock **before** any parallel first-init can race them; it is called from `MetaDataLoader.initWithConcurrencyProtection` (covers every loader embedder — Spring, parallel test runners, servers — not just Maven) and the mojo `execute()`s (covers Maven's pre-`init()` eager registry touch).
0 commit comments