ben-manes / caffeine / #5528 / 1

100%

master: 100%

push

github

avoid over-aggressive refresh discard (fixes #1970)

The low bit of an entry's write time is the refresh soft-lock marker.
A reader probing for a refresh sets it transiently (and starts no
load), but the completion's `getWriteTime() == writeTime` ABA check
mistook that marker for a concurrent write and discarded the freshly
completed reload.

Compare the base write time (masking the marker bit) in the completion,
and keep the refresh token registered across the value swap so the
compute machinery's discardRefresh clears it only after setWriteTime,
closing the remove-then-refresh stampede window. Re-validate the
soft-lock inside the entry's computeIfAbsent so a delayed reader aborts
instead of submitting a duplicate, stale reload. Apply the same
hold-token change to the explicit LocalLoadingCache.refresh and
LocalAsyncLoadingCache.tryComputeRefresh completions.

Cover the discard and the stampede with deterministic Fray and Lincheck
(runConcurrentTest) regressions and @CacheSpec token-cleared tests,
alongside the reporter's stress test.

4046 of 4054 branches covered (99.8%)

8238 of 8239 relevant lines covered (99.99%)

1.0 hits per line