Блог

Раньше мы использовали кэш guava, и мы хотим изменить его на caffeine.

Мы хотим установить для каждой сущности свое собственное «время истечения», что-то вроде — put(K key, V value, long expiration_time).

Я видел 3 функции выше, и мне интересно, что именно они делают, если вы можете объяснить мне значение операций каждого из них, это будет здорово.

Например, возвращаемое значение expireAfterCreate должно быть продолжительностью, которую мы хотим для этого объекта с момента его создания до истечения срока его действия? или что-то еще?

Мне также интересно, почему у нас есть параметр «currentTime» как в expireAfterRead, так и в expireAfterUpdate, если мы не используем его в функции?

Когда мы использовали кэш guava, мы использовали expireAfterAccess, какова его замена в caffeine?

Мой последний вопрос: как я могу установить значение по умолчанию для объектов без уникального времени истечения срока действия.

Спасибо,

Май

Когда мы использовали кэш guava, мы использовали expireAfterAccess, какова его замена в caffeine?

Мы зеркально отображаем API Guava, поэтому это также доступно в построителе кэша.

Мой последний вопрос: как я могу установить значение по умолчанию для объектов без уникального времени истечения срока действия.

Используйте expireAfterAccess , expireAfterWrite , или возвращайте постоянную продолжительность с expireAfter(Expiry) помощью .

Я видел 3 функции выше, и мне интересно, что именно они делают, если вы можете объяснить мне значение операций каждого из них, это будет здорово.

Expiry это интерфейс обратного вызова, в котором обновляется одно значение метки времени. Вызванный метод соответствует операции, выполняемой над записью кэша (создан, обновлен, прочитан). Обновление или чтение, которые не должны иметь никакого эффекта, могут вернуться currentDuration в режим no-op.

Например, возвращаемое значение expireAfterCreate должно быть продолжительностью, которую мы хотим для этого объекта с момента его создания до истечения срока его действия? или что-то еще?

ДА. Однако, если expireAfterUpdate возвращает пользовательское значение (что-то другое, чем currentDuration ), то это переопределяет предыдущую продолжительность истечения срока действия.

Мне также интересно, почему у нас есть параметр «currentTime» как в expireAfterRead, так и в expireAfterUpdate, если мы не используем его в функции?

Чаще всего это можно игнорировать, но предоставляется, если это как-то полезно. Это текущая временная метка nano из Ticker (не время настенных часов).

Мы хотим установить для каждой сущности свое собственное «время истечения», что-то вроде — put(K key, V value, long expiration_time).

Обратный вызов Expiry необходим и обычно рекомендуется, потому что в идеале записи загружаются через кеш, чтобы избежать давки (например LoadingCache ). Давка — это когда несколько потоков просматривают одну и ту же запись, пропускают, загружают ее и перезаписывают друг друга, вводя ее. Это потраченная впустую работа вместо того, чтобы загружать только один поток, а другие ждут результатов.

Тем не менее, этот метод доступен в разделе Cache.policy().expiresVariably() . Эти методы, зависящие от конфигурации, спрятаны в этой области, чтобы обеспечить большую мощность, когда это будет сочтено необходимым.

Спасибо,

Добро пожаловать.