LoadingCache refresh() appears to not update newValue to cache

[dyimo]

Hello.
I have found an issue (tested in 2.8.6), which is not necessarily a bug. I'd like to get your thoughts on what to do about it.
When the refresh loop execution interval is less than the execution time of cacheload.After the loop is executed several times. It is found that the data of cache get is no longer changed.

Here is the code:

    @Test
    public void testRefresh() throws InterruptedException {
        AtomicInteger atomicInteger = new AtomicInteger(0);
        AtomicInteger incr = new AtomicInteger(100000);
        LoadingCache<Key, String> dataCache = Caffeine.newBuilder()
                .expireAfterWrite(8, TimeUnit.SECONDS)
                .refreshAfterWrite(1, TimeUnit.SECONDS)
                .build(key -> {
                    Thread.sleep(4_000);
                    int i = atomicInteger.incrementAndGet();
                    String result = "key==:" + key.incr + ",value:" + i + "---------cache";
                    logger.info(result);
                    return result;
                });

        while (true) {
            Key key = new Key(incr.getAndIncrement());
            dataCache.refresh(key);
            logger.info(dataCache.get(key) + "..........get");
            Thread.sleep(1_000);
        }

    }
    static class Key {
        int code = 0;
        int incr;

        public Key(int incr) {
            this.incr = incr;
        }

        @Override
        public boolean equals(Object o) {
            if (this == o) return true;
            if (o == null || getClass() != o.getClass()) return false;
            Key key = (Key) o;
            return code == key.code;
        }

        @Override
        public int hashCode() {
            return Objects.hash(code);
        }
    }

[ben-manes]

For debugging, you can add a removalListener to observe the replacements in your output and override reload(key, oldValue) in the cache loader to see the possible replacement.

In Guava if the reload completes and observes that the entry's current value differs from the oldValue, then the reload's newValue is dropped and notified as REPLACED. This is to handle cases like a put or invalidate during the reload. If multiple refresh calls for the same key occur while the reload is in-flight, then the subsequent calls are ignored. This avoids redundant work but means only the first reload call was honored, perhaps having some stale state (hence assuming an invalidate to assert otherwise).

Caffeine follows Guava here but sadly lacks the ability to ignore redundant refresh calls. There are a few duplicate, open issues that refer to this such as #236 and #322. It has been on the backlog to clean up all of these refresh related improvements.

Thus in Guava your test will show a nice increment with only a few threads, whereas Caffeine suffers from the stampede as it launches a new task for each invocation. This creates a queue of reload tasks in the executor, causing it to be swamped and most of the reloads be dropped as they observe data inconsistencies.