Spring 캐시 추상화 × Flyweight 패턴: 메모리 폭주 0% 만드는 공식

수십 만 개가 넘는 도메인 객체를 매번 new로 찍어 내다 보면 GC가 울음 버튼을 누른다. Flyweight 패턴은 “변하지 않는 속성(intrinsic)을 공유”해 객체 수를 획기적으로 줄이는 전략이고, Spring Cache 추상화는 이를 캐싱 한 줄로 구현하게 해 주는 비밀 무기다.

---

1️⃣ 왜 캐시 = Flyweight Factory인가?

@Cacheable 메서드는 이미 Flyweight Factory 역할을 한다.

• Key → 객체를 구분하는 extrinsic 상태
• Cache Value → 공유되는 intrinsic 객체
  같은 키로 호출되면 Spring이 이미 생성된 인스턴스를 돌려주므로, 손코딩 Factory·Map 관리가 필요 없다.

---

2️⃣ 세 줄로 끝내는 셋업

<!-- pom.xml -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-cache</artifactId>
</dependency>

// AppConfig.java
@EnableCaching   // 캐싱 기능 ON
@SpringBootApplication
public class App {…}

의존성 + @EnableCaching이면 기본 ConcurrentMapCacheManager가 뜨고, 필요하면 Caffeine·Redis로 교체만 하면 된다.

---

3️⃣ 코드 예시 – 국가 코드 객체를 Flyweight로

@Service
@RequiredArgsConstructor
public class CountryService {

    private final CountryRepository repo;   // DB 또는 외부 API

    @Cacheable(value = "country", key = "#code")
    public Country get(String code) {       // extrinsic: code
        return repo.findByCode(code)        // intrinsic: 이름·통화·언어 등
                   .orElseThrow();
    }
}

• Country 엔티티를 immutable(불변 필드, no setter)로 두면 스레드 안전한 Flyweight가 완성된다.
• 동일 코드로 요청이 들어오면 캐시가 객체를 반환하므로, 1만 번 호출해도 힙에는 딱 한 개만 존재.

---

4️⃣ 성능·안정성 꿀팁

1. 캐시 매니저 선택
   • 단일 인스턴스 앱 → Caffeine TTL 캐시
   • 다중 인스턴스·마이크로서비스 → Redis 분산 캐시
2. TTL·만료 정책 : Flyweight는 “변하지 않는” 전제가 중요. 변경 가능성이 있으면 TTL을 짧게 두거나 @CacheEvict로 무효화한다.
3. 모니터링 : Actuator /caches 엔드포인트나 Micrometer Metrics로 히트율·사이즈를 체크해 과도 캐싱을 예방.
4. 메모리↔CPU 트레이드오프 : 캐싱으로 객체는 줄지만 해시 계산 등 오버헤드가 증가할 수 있으니 JMH·VisualVM으로 프로파일링 후 적용.

---

5️⃣ 장·단점 스냅샷

• 👍 메모리 절감 : 객체 공유로 힙 사용량·GC 횟수 감소.
• 👍 구현 간소화 : 전통적 Flyweight Factory·Pool 클래스를 캐시 매니저 한 줄로 대체.
• ⚠️ 일관성 이슈 : 공유 객체가 실제로 “정적”인지 검증하지 않으면 구버전 데이터가 퍼질 위험.
• ⚠️ 키 설계 난이도 : key SpEL이 잘못되면 동일 객체가 캐시에 중복 저장될 수 있다.

---

한 줄 요약

@Cacheable 하나면 Spring이 “Flyweight Factory+Pool”을 자동 생성한다—이것이 캐시 추상화의 진정한 가치다.