Audit exception safety and failure atomicity across all throw sites
Audit the cache for exception safety defects. For every code path where exceptions can be thrown, determine whether the cache is left consistent.
Assume at least one exception safety bug exists. If your analysis yields zero findings, re-examine catch-commit-rethrow paths — explain specifically why no exception scenario leaves inconsistent state.
Priority #1: catch-commit-rethrow in doComputeIfAbsent and remap. This is the most commonly misunderstood pattern and historically the most fragile. Trace the EXACT sequence of committed mutations, notification delivery, and exception propagation for every exception type.
User-provided code that can throw:
Runtime exceptions: 6. OutOfMemoryError during node/reference allocation 7. StackOverflowError from deep re-entrancy 8. RejectedExecutionException from executor
For each throw site:
List every mutation already committed before the throw point.
Determine whether the catch block rolls back or commits.
Check for:
For catch-commit-rethrow (doComputeIfAbsent, remap), verify:
For OutOfMemoryError specifically:
For each defect: state the throw site, mutations committed, inconsistent state, and a concrete triggering scenario.