Делаем простой rate limiter!

Иногда нужно ограничить частоту действий: отправку писем, запросы к API, попытки входа или запуск тяжёлой операции. Соберём простой limiter, который разрешает не больше N действий за небольшой промежуток времени.

Для хранения времени запросов подойдёт очередь:

import java.time.Duration;
import java.time.Instant;
import java.util.ArrayDeque;
import java.util.Deque;

Создадим класс:

public class RateLimiter {
    private final int limit;
    private final Duration window;
    private final Deque<Instant> calls = new ArrayDeque<>();

Конструктор:

    public RateLimiter(int limit, Duration window) {
        this.limit = limit;
        this.window = window;
    }

Главный метод будет возвращать true, если действие разрешено:

    public boolean allow() {
        Instant now = Instant.now();
        Instant border = now.minus(window);

        while (!calls.isEmpty() && calls.peekFirst().isBefore(border)) {
            calls.removeFirst();
        }

Если в окне уже слишком много вызовов, блокируем:

        if (calls.size() >= limit) {
            return false;
        }

        calls.addLast(now);
        return true;
    }
}

Теперь можно ограничить, например, 3 попытки за 10 секунд:

RateLimiter limiter = new RateLimiter(
    3,
    Duration.ofSeconds(10)
);

Использование:

if (limiter.allow()) {
    System.out.println("Запрос выполнен");
} else {
    System.out.println("Слишком много запросов");
}

Такой limiter хранит только актуальные вызовы внутри окна. Старые записи постепенно удаляются из очереди.

Для многопоточного кода метод allow() стоит синхронизировать:

public synchronized boolean allow() {
    // та же логика
}

Rate limiter это простой, но очень полезный паттерн для API, авторизации, фоновых задач и защиты от слишком частых действий.

👉 Java Ready | #практика

Чем полезен List.copyOf() в Java?

Иногда объект получает список извне и сохраняет его в поле:

public Order(List<String> items) {
    this.items = items;
}

На первый взгляд всё нормально. Но если внешний код потом изменит список, изменится и состояние Order:

List<String> source = new ArrayList<>();
source.add("book");

Order order = new Order(source);
source.add("phone");

Теперь внутри order тоже может оказаться новый элемент, хотя сам Order его не добавлял.

Чтобы защититься, можно сделать копию:

this.items = List.copyOf(items);

Теперь объект хранит собственный неизменяемый снимок списка:

public Order(List<String> items) {
    this.items = List.copyOf(items);
}

Если исходный список изменится позже, поле внутри Order уже не поменяется:

source.add("phone");

// order всё ещё хранит старый набор

И сам список внутри Order нельзя случайно изменить:

order.items().add("tablet"); // UnsupportedOperationException

Обычно такой список удобно возвращать наружу:

public List<String> items() {
    return items;
}

Потому что вызывающий код не сможет незаметно изменить внутреннее состояние объекта.

Важно: List.copyOf() не принимает null-элементы:

List.copyOf(List.of("a", null)); // NullPointerException

List.copyOf() полезен для защитного копирования. Он помогает не отдавать внутреннее состояние объекта под управление внешнего кода.

👉 Java Ready | #совет

📂 Напоминалка по структуре каталогов Linux!

Например, /bin содержит системные бинарные файлы, а /etc — конфигурации, управляющие поведением системы.

На картинке — директории Linux, их назначение и место в иерархии.

Сохрани, чтобы не забыть!

👉 Java Ready | #ресурс

Когда в Java стоит использовать Objects.requireNonNull()?

Иногда параметр метода не должен быть null вообще. Например, сервису нужен репозиторий, обработчику нужен клиент, а объекту доменной модели обязательное имя.

Часто это проверяют вручную:

public UserService(UserRepository repository) {
    if (repository == null) {
        throw new NullPointerException("repository");
    }

    this.repository = repository;
}

Работает, но код становится шумным.

В Java для такой проверки есть Objects.requireNonNull():

public UserService(UserRepository repository) {
    this.repository = Objects.requireNonNull(repository);
}

Если передать null, ошибка появится сразу в конструкторе, а не где-то позже при первом вызове метода.

Можно добавить понятное сообщение:

this.repository = Objects.requireNonNull(
    repository,
    "repository must not be null"
);

Это особенно полезно в конструкторах:

public Order(String id, BigDecimal amount) {
    this.id = Objects.requireNonNull(id, "id");
    this.amount = Objects.requireNonNull(amount, "amount");
}

И в методах, где null ломает смысл операции:

public void send(Message message) {
    Objects.requireNonNull(message, "message");

    transport.send(message);
}

Но не стоит ставить requireNonNull() везде подряд. Если null нормальный вариант состояния, лучше явно отразить это в логике:

String label = user.getNickname() != null
    ? user.getNickname()
    : user.getName();

Objects.requireNonNull() хорош там, где null является ошибкой. Он помогает падать раньше и ближе к месту неправильного вызова.

👉 Java Ready | #совет

Полезная статья о том, как использовать RabbitMQ вместе с Java Spring!

В этой статье:
• Как два микросервиса могут общаться через очередь сообщений
• Что делают producer, consumer, exchange и queue
• Как собрать простой пример на Spring и RabbitMQ без лишней теории

Продолжай читать на Habr!

👉 Java Ready | #статья