⌛ Как устроен кеш в Spring Boot?

Spring Boot упрощает кеширование благодаря аннотациям и встроенной интеграции с разными кеш-провайдерами (EhCache, Caffeine, Redis и др.). Spring использует Spring Cache Abstraction, которая оборачивает кеширующую логику в аннотации:

▪️ @Cacheable — кладёт результат в кеш
▪️ @CachePut — обновляет кеш
▪️ @CacheEvict — удаляет из кеша

За кулисами используется прокси (через Spring AOP или CGLIB), который перехватывает вызовы методов, проверяет кеш и возвращает либо сохранённое значение, либо выполняет метод и кеширует результат.

🔍 Что под капотом

Если вызвать метод с @Cacheable, Spring выполняет несколько шагов:

1. Определяет ключ кеша

▪️ По умолчанию ключ формируется из параметров метода
▪️ Можно задать кастомный ключ через key = "#id"

2. Проверяет кеш-провайдер

▪️ Дефолтный провайдер — ConcurrentHashMap
▪️ Можно подключить Redis, Caffeine, EhCache и т. д.

3. Возвращает данные

▪️ Если значение есть в кеше — сразу отдаётся
▪️ Если нет – вызывается метод и результат сохраняется в кеше

⚠️ Нюансы

— Кеш работает только для Spring-управляемых бинов (если метод вызван внутри того же класса — кеш не сработает)
— Не кешируйте изменяемые объекты, иначе возможны неожиданные побочные эффекты
— Очищайте кеш, если данные меняются (@CacheEvict)

🎯 Как быстро настроить кеширование в Spring Boot

Писать кеш руками через HashMap или страдать с вручную настроенными TTL — скучно, долго и ненадёжно. В Spring Boot всё уже готово: включаем, настраиваем, и поехали!

1️⃣ Добавляем зависимость

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

ИЛИ

implementation 'org.springframework.boot:spring-boot-starter-cache'

2️⃣ Включаем кеширование

Добавляем простую аннотацию над главным классом приложения (или конфиг классом):

@SpringBootApplication
@EnableCaching 
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

3️⃣ Кешируем методы сервисов

Используем аннотацию @Cacheable на тех методах, которые часто выполняются и редко меняются:

@Service
public class UserService {

    @Cacheable(value = "users", key = "#id")
    public User getUserById(Long id) {
        simulateSlowService(); 
        return userRepository.findById(id).orElseThrow();
    }

    private void simulateSlowService() {
        Thread.sleep(3000);
    }
}

Теперь при повторном вызове метода с тем же параметром ответ прилетит мгновенно.

4️⃣ Настройка TTL и конфигурация кеша

В Spring Boot по умолчанию используется простой ConcurrentMap (без TTL). Если хочешь TTL и прочие плюшки, подключайте Caffeine:

spring:
  cache:
    type: caffeine
    caffeine:
      spec: maximumSize=500,expireAfterAccess=10m

Кеш будет жить максимум 10 минут и не разрастаться до бесконечности.

5️⃣ Очистка кеша

Если нужно принудительно почистить кеш после обновления данных, используем @CacheEvict:

@CacheEvict(value = "users", key = "#id")
public void updateUser(Long id, User updatedUser) {
    userRepository.save(updatedUser);
}

💬 Хранили когда-нибудь кеш в мапе?

🐸 Библиотека джависта #буст

🔥 Spring Security: как работает @PreAuthorize и зачем он нужен

В продакшн-коде часто возникает задача ограничить доступ к методам сервиса или контроллера. Делать это вручную — значит плодить дублирование и путать бизнес-логику с проверками. Для этого в Spring Security есть аннотация @PreAuthorize.

🔵 Как это работает

1. Аннотация вешается на метод (контроллер или сервис).

2. При вызове метода Spring Security перехватывает обращение и проверяет условие, указанное в аннотации.

3. Условие описывается на языке SpEL (Spring Expression Language), где доступно:

▪️ authentication — текущий объект аутентификации;
▪️ principal — данные текущего пользователя;
▪️ #id, #dto и т.д. — аргументы метода, к которым можно обратиться напрямую.

Пример:

@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long id) { ... }

→ метод вызовется только для пользователей с ролью ADMIN.

🔵 Что можно писать внутри

— Проверка ролей и прав

hasRole('USER'), hasAnyRole('ADMIN','MODERATOR')

hasAuthority('SCOPE_read') (актуально при работе с OAuth2)

— Собственные условия

@PreAuthorize("#id == authentication.principal.id")
public UserProfile getProfile(Long id) { ... }

→ Здесь доступ только к своему профилю.

— Комбинации условий

Логика пишется прямо в SpEL:

@PreAuthorize("hasRole('ADMIN') or @securityService.isOwner(#docId)")
public Document update(Long docId) { ... }

— Сервисы внутри выражений

В выражение можно подключать свои бины:

@PreAuthorize("@reviewSecurity.isOwner(#id, authentication)")
public Review update(Long id) { ... }

→ бин reviewSecurity должен быть в контексте Spring и возвращать true/false.

🔵 Зачем это нужно

— Не надо вручную писать проверки в каждом методе.

— Авторизация централизована и читается прямо на уровне API.

— Условия можно вынести в отдельный сервис, чтобы не захламлять аннотацию.

👉 В итоге @PreAuthorize — это не только про роли, а про гибкий DSL проверки доступа, который можно расширять под проект: от банальной проверки ролей до бизнес-логики уровня "пользователь может редактировать только свои документы, если они ещё не опубликованы".

🐸 Библиотека джависта

#Enterprise