Sam Brannen bb7ea37f1b Drain pending writes before evicting in ConcurrentLruCache.clear() ...

Prior to this commit, clear() polled the eviction queue to remove
entries and only afterward drained the pending write operations queue.

Consequently, a put() whose AddTask had not yet been linked into the
eviction queue -- for example, because it lost the race to self-drain
while clear() held the eviction lock -- would only be applied by that
trailing drain, linking the entry into the eviction queue right after
clear() had already finished removing everything it could see.

The practical effect was that an entry already fully added to the cache
could still be present immediately after clear() returned, with no
further concurrent activity required at that point.

To address that, this commit revises clear() so that it drains the
pending write operations queue before polling the eviction queue, so
any write that was already queued gets cleaned up along with everything
else. However, a put() that is genuinely concurrent with an in-progress
clear() call can still survive, which is consistent with the cache's
weak-consistency design.

Thanks to @guanchengang for raising gh-37286, which prompted this fix.

Closes gh-37287

2026-09-17 12:45:42 +02:00

..

src

Drain pending writes before evicting in ConcurrentLruCache.clear()

2026-09-17 12:45:42 +02:00

spring-core.gradle

Consistently ignore non-loadable annotation types with ClassFile/ASM

2026-03-11 13:52:19 +01:00