Spring Boot 4 Complete Guide · 강의

Caffeine 조정을 활용한 메모리 내 캐싱

처리량이 높은 로컬 캐시를 위해 Caffeine의 제거, 만료 및 크기 정책을 구성합니다.

레슨 2/413개 단계

Caffeine 조정을 활용한 메모리 내 캐싱은(는) CoddyKit의 무료 Spring Boot 4 Complete Guide 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Spring Boot 4 Complete Guide 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Caffeine for Local Caches

Caffeine is a high-performance, near-optimal Java caching library and the default in-memory cache for Spring Boot when it is on the classpath.

It uses the Window TinyLFU eviction policy, which beats plain LRU on real-world hit rates.
It supports size-based, time-based, and reference-based eviction.
It is fully concurrent and lock-free on the read path, ideal for high-throughput services.

In this lesson you will tune Caffeine's eviction, expiry, and size policies so a local cache stays fast without exhausting heap.

Adding Caffeine to a Spring Boot 4 App

Spring Boot auto-configures Caffeine when both spring-boot-starter-cache and the caffeine dependency are present.

Then enable caching with @EnableCaching on a configuration class. Methods annotated with @Cacheable will use the Caffeine-backed CacheManager.

import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Configuration;

@Configuration
@EnableCaching
public class CacheConfig {
    // CaffeineCacheManager is auto-configured
    // when com.github.ben-manes.caffeine:caffeine is on the classpath
}

Maximum Size Eviction

The most common policy for a local cache is bounded size. Use maximumSize to cap the number of entries; Caffeine evicts the least valuable entries (Window TinyLFU) once the bound is exceeded.

Pick a size that fits comfortably in heap given your value object footprint.
Eviction is not immediate at the boundary; it happens promptly but asynchronously.

import com.github.benmanes.caffeine.cache.Caffeine;
import org.springframework.cache.caffeine.CaffeineCacheManager;
import org.springframework.context.annotation.Bean;

@Bean
public CaffeineCacheManager cacheManager() {
    CaffeineCacheManager manager = new CaffeineCacheManager("products");
    manager.setCaffeine(Caffeine.newBuilder()
            .maximumSize(10_000)
            .recordStats());
    return manager;
}

Weight-Based Eviction

When entries vary wildly in size, bound the cache by weight instead of count. Provide a maximumWeight and a Weigher that returns each entry's cost.

You cannot combine maximumSize and maximumWeight on the same cache.
Weights are computed once at insertion and are not updated afterward.

import com.github.benmanes.caffeine.cache.Caffeine;

Caffeine.newBuilder()
        .maximumWeight(50_000_000) // ~50MB budget
        .weigher((String key, byte[] value) -> value.length)
        .build();

expireAfterWrite vs expireAfterAccess

Time-based expiry comes in two flavors:

expireAfterWrite: entry expires a fixed duration after it was created or last replaced. Best for data with a known freshness window (e.g. a price valid for 5 minutes).
expireAfterAccess: entry expires a duration after its last read or write. Best for keeping hot data alive and dropping idle entries.

You may combine both; the entry expires when either condition fires first.

import com.github.benmanes.caffeine.cache.Caffeine;
import java.time.Duration;

Caffeine.newBuilder()
        .maximumSize(10_000)
        .expireAfterWrite(Duration.ofMinutes(5))
        .expireAfterAccess(Duration.ofMinutes(2))
        .build();

Configuring via application.properties

For a single shared spec, Spring Boot lets you skip Java config and use the spring.cache.caffeine.spec property. It accepts the comma-separated Caffeine spec string.

This is convenient but applies the same spec to every cache name; per-cache tuning still requires a programmatic CaffeineCacheManager or a custom CacheLoader.

spring.cache.type=caffeine
spring.cache.cache-names=products,prices
spring.cache.caffeine.spec=maximumSize=10000,expireAfterWrite=5m,recordStats

refreshAfterWrite for Stale-While-Revalidate

refreshAfterWrite differs from expiry: instead of removing the entry, it asynchronously reloads it after the duration while still serving the old value. This avoids a latency spike on the first request after staleness.

It requires a LoadingCache (a cache built with a CacheLoader).
Only one thread triggers the refresh; others keep reading the existing value.
Combine with a longer expireAfterWrite as a hard ceiling.

import com.github.benmanes.caffeine.cache.Caffeine;
import com.github.benmanes.caffeine.cache.LoadingCache;
import java.time.Duration;

LoadingCache<String, String> cache = Caffeine.newBuilder()
        .refreshAfterWrite(Duration.ofMinutes(1))
        .expireAfterWrite(Duration.ofMinutes(10))
        .build(key -> loadFromDatabase(key));

A Standalone Caffeine Demo

Here is a complete, framework-free program demonstrating maximumSize eviction. Insert more entries than the bound and observe that the cache never exceeds its size after cleanup.

This is the kind of micro-benchmark you can run to validate a tuning choice before wiring it into Spring.

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;

public class CaffeineDemo {
    public static void main(String[] args) {
        Cache<Integer, String> cache = Caffeine.newBuilder()
                .maximumSize(3)
                .build();

        for (int i = 0; i < 10; i++) {
            cache.put(i, "value-" + i);
        }
        cache.cleanUp(); // force pending eviction work

        System.out.println("Estimated size: " + cache.estimatedSize());
        System.out.println("Get key 9: " + cache.getIfPresent(9));
    }
}

Per-Cache Tuning with Custom Specs

Real services need different policies per cache: a tiny hot lookup table vs a large warm dataset. Subclass or configure CaffeineCacheManager so each name gets its own builder.

One clean approach is registering individual native caches by name on the manager.

import com.github.benmanes.caffeine.cache.Caffeine;
import org.springframework.cache.caffeine.CaffeineCacheManager;
import java.time.Duration;

@Bean
public CaffeineCacheManager cacheManager() {
    CaffeineCacheManager manager = new CaffeineCacheManager();
    manager.registerCustomCache("prices", Caffeine.newBuilder()
            .maximumSize(1_000)
            .expireAfterWrite(Duration.ofSeconds(30))
            .build());
    manager.registerCustomCache("catalog", Caffeine.newBuilder()
            .maximumSize(100_000)
            .expireAfterAccess(Duration.ofHours(1))
            .build());
    return manager;
}

Measuring Hit Rate with recordStats

You cannot tune what you do not measure. Enable recordStats() to expose CacheStats: hit count, miss count, eviction count, and average load penalty.

A low hit rate suggests the cache is too small or the keys too cardinal.
High eviction with high miss rate means maximumSize is starving the working set.
Spring Boot's Micrometer integration publishes these as metrics when stats are on.

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import com.github.benmanes.caffeine.cache.stats.CacheStats;

public class StatsDemo {
    public static void main(String[] args) {
        Cache<String, Integer> cache = Caffeine.newBuilder()
                .maximumSize(2)
                .recordStats()
                .build();

        cache.put("a", 1);
        cache.getIfPresent("a"); // hit
        cache.getIfPresent("b"); // miss

        CacheStats stats = cache.stats();
        System.out.printf("hits=%d misses=%d rate=%.2f%n",
                stats.hitCount(), stats.missCount(), stats.hitRate());
    }
}

Avoiding Common Tuning Pitfalls

A few traps to watch for under high throughput:

Unbounded caches: never build a cache without a size or expiry bound, or you risk an OutOfMemoryError.
initialCapacity: set it near the expected steady-state size to avoid resize churn on the read-heavy path.
Soft/weak references: softValues() ties eviction to GC pressure, which is unpredictable; prefer explicit size/time bounds for latency-sensitive caches.
refreshAfterWrite without a loader: it silently has no effect on a manual cache.

Quick Check: Choosing an Expiry Policy

You cache product prices that the upstream system guarantees are valid for exactly 5 minutes after publication. Reads are frequent but you must never serve a price older than 5 minutes. Which Caffeine policy fits best?

인터랙티브 레슨에서 답해보세요

Recap

You tuned Caffeine for high-throughput local caching in Spring Boot 4:

Size: maximumSize for uniform entries, maximumWeight + Weigher for variable cost.
Time: expireAfterWrite for freshness contracts, expireAfterAccess to keep hot data, combine for both ceilings.
Refresh: refreshAfterWrite on a LoadingCache for stale-while-revalidate without latency spikes.
Config: spring.cache.caffeine.spec for one shared spec, or registerCustomCache for per-cache tuning.
Measure: always enable recordStats() and watch hit rate and eviction count to guide further tuning.

무료로 시작

AI 튜터와 함께 Java을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 21
레슨: 84

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“Caffeine 조정을 활용한 메모리 내 캐싱” 강의는 무료인가요?

네 — “Caffeine 조정을 활용한 메모리 내 캐싱” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Spring Boot 4 Complete Guide 강의 전체를 잠금 해제할 수 있습니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

“Caffeine 조정을 활용한 메모리 내 캐싱”에서 뭘 배우나요?

처리량이 높은 로컬 캐시를 위해 Caffeine의 제거, 만료 및 크기 정책을 구성합니다. 브라우저에서 직접 실행하는 실습 코드로 Spring Boot 4 Complete Guide을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Spring Boot 4 Complete Guide을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Spring Boot 4 Complete Guide은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“Caffeine 조정을 활용한 메모리 내 캐싱” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Spring Boot 4 Complete Guide 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Spring Boot 4 Complete Guide 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Spring Boot 4 Complete Guide(으)로 돌아가기