Кофеин против кэша гуавы

Основное отличие заключается в том, что Caffeine использует кольцевые буферы для записи и воспроизведения событий, тогда как Guava использует ConcurrentLinkedQueue. Намерение всегда состояло в том, чтобы перенести Гуаву, и имело смысл начать с более простого, но, к сожалению, никогда не было заинтересованности в принятии этих изменений. Подход с кольцевым буфером позволяет избежать распределения, ограничен (с потерями) и дешевле в эксплуатации.

Остальные затраты связаны с несоответствием конструкции. Первоначальный автор MapMaker с энтузиазмом относился к мягким ссылкам как к решению проблем с кешированием, откладывая это до GC. К сожалению, несмотря на то, что в микротестах это может показаться быстрым, на практике он имеет ужасную производительность из-за остановки GC. Решение, основанное на размере, должно было быть адаптировано к этой работе, и это не идеально. Caffeine оптимизируется на основе размера, а также получает улучшенную хеш-таблицу, тогда как Guava более элегантно обрабатывает кэширование ссылок.

Caffeine не создает собственных потоков для обслуживания или истечения срока действия. Это откладывает затраты на commonPool, что немного улучшает задержки для пользователя, но не пропускную способность. Будущая версия может использовать CompletableFuture.delayedExecutor для планирования следующего события истечения срока действия без непосредственного создания потоков (для пользователей, у которых бизнес-логика зависит от уведомлений о быстром удалении).

ConcurrentLinkedHashMap и MapMaker были написаны одновременно, и CLHM по производительности похож на Caffeine. Я считаю, что разница связана с тем, какие сценарии предпочитали и оптимизировали дизайнеры, что повлияло на то, как будут реализованы другие функции. Есть низко висящие плоды, позволяющие Гуаве иметь аналогичный профиль производительности, но нет внутреннего чемпиона, который бы управлял этим (и тем более с кофеином в качестве предпочтительной альтернативы).