Use a concurrent cache in CraftRegistry

[electronicboy]

Problem

CraftRegistry#get lazily populates its backing cache, reading and then writing a plain HashMap with no synchronization.

This cache is reached off the main thread while building ItemMeta:

• CraftItemStack#getItemMeta resolves the item's CraftItemType via CraftRegistry#get (to select the meta subclass), and
• CraftMetaItem resolves the item's enchantments through CraftRegistry#get.

Plugins routinely build ItemMeta from other threads, so this map is read and written concurrently, which is unsafe for a HashMap.

Change

• Switch cache to a ConcurrentHashMap.
• Collapse the get()-then-put() sequence into a single atomic computeIfAbsent.
• Make lockReferenceHolders volatile, since it is now read from the concurrent get() path and flipped once during startup.

Why this is safe for computeIfAbsent

ConcurrentHashMap#computeIfAbsent forbids the mapping function from updating the same map (recursive update → IllegalStateException/bin live-lock). The registry wrapper constructors registered in PaperRegistries uniformly just store their Holder and defer derived work via Suppliers.memoize(...); the mapping function only touches the NMS registry and Holder.Reference#createStandAlone, never this cache. So it never re-enters the map. Any cross-registry resolution a wrapper may perform later targets a different CraftRegistry instance (different map) and is lazy regardless.

[Copilot]

Pull request overview

This PR hardens CraftRegistry#get for off-main-thread access by making its lazy cache population thread-safe, addressing unsafe concurrent reads/writes to a plain HashMap when plugins build ItemMeta asynchronously.

Changes:

• Replace the backing cache with a ConcurrentHashMap.
• Use computeIfAbsent to atomically load and cache registry entries.
• Make lockReferenceHolders volatile to ensure cross-thread visibility from the get() path.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.