Java-совет: ты можешь использовать LinkedHashMap, чтобы легко реализовать LRU-кеш (Least Recently Used).

Тебе просто нужно заинстанцировать это вот так:

int capacity = 3;
Map<Integer, String> cache = new LinkedHashMap<>(capacity, 0.75f, true) {
    protected boolean removeEldestEntry(Map.Entry eldest) {
        return size() > capacity;
    }
};

cache.put(1, "one");
cache.put(2, "two");
cache.put(3, "three");
cache.get(1);
cache.put(4, "four"); // 2 удаляется (наименее недавно использованный)

System.out.println(cache);

👉 Java Portal

freeCodeCamp выкатили бесплатный курс по Git и GitHub для новичков. За 1 час разберёшь базу: ветки, слияния, pull request’ы и базовую командную работу. Отличный быстрый вход для тех, кто откладывал Git «на потом».

Git-курс тут

👉 Java Portal

Одна идея, на которой я люблю делать акцент, это автобоксинг и анбоксинг в Java.

Java фактически дает нам два параллельных мира:

Примитивы: int, long, double = быстрые, компактные, живут на стеке.

Обертки: Integer, Long, Double = полноценные объекты в heap.

Между этими мирами Java делает одно автоматическое преобразование:

Автобоксинг - превращение примитива в объект
Анбоксинг - обратное преобразование

Работает удобно, пока в какой-то момент не начинает мешать.

Почему это может быть проблемой?

Потому что при каждой конверсии у Java появляется лишняя работа:

Создаются новые объекты
Увеличивается нагрузка на GC
CPU делает больше операций
Срываются JIT-оптимизации
В циклах с высокой нагрузкой появляются скрытые задержки

В большинстве приложений это незаметно, но если проявится, то обычно довольно резко.

Типичный пример - коллекции:

List<Integer> numeros = new ArrayList<>();
for (int i = 0; i < 1_000_000; i++) {
numeros.add(i);
}

Очевидно, что пример синтетический, но суть в том, что в этом цикле i упаковывается в Integer миллион раз.

Перенеси этот сценарий на реальные участки твоего кода.

Каждая конверсия создает объект, нагружает GC и сбивает процессорный кеш.
Из-за этого приложение начинает подвисать, когда GC активируется.

Коллекции - не единственный источник проблем. Есть и сравнения:

Integer a = 1000;
Integer b = 1000;

if (a == b) { ... }

При работе с обертками оператор == сравнивает ссылки, а не значения.
Если происходит неявный анбоксинг, оба значения сначала превращаются в int и только потом сравниваются.
Такое смешение поведения местами непредсказуемо и приводит к трудноуловимым багам.

Есть еще и лямбды:

Stream<Integer> s = IntStream.range(0, 1_000_000)
.boxed(); // миллион автобоксингов

Если работаете с числами, лучше брать примитивные стримы:

IntStream
LongStream
DoubleStream

Они экономят память, убирают боксинг и работают быстрее.

Худший сценарий - структуры подсчета:

Map<String, Integer> counter = new HashMap<>();
counter.put(key, counter.getOrDefault(key, 0) + 1);

Каждая операция делает:

Анбоксинг существующего значения
Сложение как примитива
Обратный автобоксинг результата

Масштабируется это плохо и убивает производительность при высокой конкуренции.

Хорошие варианты:

- AtomicInteger
- LongAdder
- Хранить счетчик как примитив и конвертировать только при выдаче наружу

Значит ли это, что обертки плохие? Нет.
Проблема не в них, а в случайном использовании.

Обертки используют, когда:

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

Примитивы используют, когда:

Есть большие циклы
Много повторных вычислений
Важно избегать лишнего GC
Нужна стабильная производительность

Автобоксинг удобен, но у него есть подводные камни.
Обычно он не мешает, но когда все-таки мешает, его эффекты сложно отследить.

Хорошая новость: исправляется это просто.

Используй примитивы в вычислениях
Используй примитивные стримы
Не применяй обертки в счетчиках
Проверь циклы, создающие лишние объекты

Пара мелких правок может убрать тысячи лишних объектов и заметно снизить нагрузку на приложение.

👉 Java Portal

Похоже, это претендент на TUI года ⭐️

gitlogue — инструмент для «кинематографичного» воспроизведения Git-коммитов прямо в терминале.

Смотри, как коммиты развертываются с анимацией ввода, подсветкой синтаксиса и живым обновлением дерева файлов.

Буквально наблюдай, как твой репозиторий пишет себя сам.

Написан на Rust

GitHub: https://github.com/unhappychoice/gitlogue

👉 Java Portal

Часто мы пишем public static void main и просто предполагаем, что Java сама «делает свою работу».

Но за этим стоит довольно сложная и интересная система , а именно ClassLoader’ы.

Именно они отвечают за то, чтобы находить, проверять и загружать каждый класс, который использует твоё приложение.

Без ClassLoader’ов нет JVM, нет Spring, нет плагинов, вообще ничего нет.

Что такое ClassLoader?

Это компонент JVM, который отвечает за:

- Поиск определения класса (файлы .class, JAR’ы, модули).
- Загрузку его в память.
- Проверку байткода на валидность и безопасность.
- Определение класса в изолированном пространстве.

Проще говоря, он превращает байткод в то, что JVM может исполнять.

Иерархия держит хаос под контролем

В Java используется модель делегирования вверх {parent delegation}

Это защищает от конфликтов, дублирования и неожиданных подмен классов.

Основные загрузчики:

- Bootstrap ClassLoader
Написан на C++, загружает базовые классы языка (java.lang.*, java.util.* и так далее).
Живёт прямо внутри JVM.

- Platform / Extension ClassLoader
Загружает библиотеки самого JDK и системные модули.

- Application ClassLoader
Загружает твои классы, зависимости и весь прикладной код.

Типичный поток загрузки выглядит так:

Когда ClassLoader пытается загрузить класс, он сначала делегирует запрос родителю.
Если родитель не находит класс, тогда уже текущий загрузчик пытается загрузить его сам.

Это не даёт тебе случайно переопределить String, List, Object и другие базовые классы.

Как загружается твой код?

Когда ты запускаешь JAR:

java -jar app.jar

Твой код загружает Application ClassLoader. Процесс простой:

- Проходит по classpath
- Открывает JAR’ы
- Находит .class
- Загружает их по мере необходимости

Загрузка классов происходит по требованию.

Если у тебя 200 классов, а реально используются только 10, будут загружены только эти 10.

Почему это реально важно?

Потому что всё, что мы используем поверх Java, строит свою работу на ClassLoader’ах:

Spring Boot создаёт собственный ClassLoader для загрузки fat JAR’ов.
Модульные приложения используют загрузчики для изоляции компонентов.
Веб-контейнеры вроде Tomcat создают отдельный ClassLoader на каждое приложение.
Плагины (IDEA, Jenkins, Minecraft, OSGi) работают через отдельные загрузчики.
Инструменты hot reload (Spring DevTools, JRebel) зависят от динамической перезагрузки классов.

Зачем это понимать на практике?

Рано или поздно ты столкнёшься с ошибками вида ClassNotFoundException. Понимание ClassLoader’ов даёт отличную точку старта для отладки.

Самые частые проблемы:

ClassNotFoundException — класс отсутствует в classpath текущего загрузчика.
NoClassDefFoundError — класс был доступен, но возникла ошибка при загрузке или верификации.
“Невозможный” ClassCastException — объект вроде бы нужного типа, но Java считает иначе. Обычно это означает, что один и тот же класс был загружен разными ClassLoader’ами.
Memory leak в веб-приложениях — Tomcat некорректно выгружает ClassLoader при redeploy.

Последнее происходит значительно чаще, чем кажется.

ClassLoader’ы это как кровеносная система Java ( их не видно, но без них ничего не работает. )

Понимание того, как Java загружает классы это не пустая теория. Это делает тебя сильнее в отладке, увереннее при разборе сложных багов и даёт чёткое понимание среды, в которой реально работает твоё приложение.

И когда в продакшене что-то падает с ClassNotFoundException, ты точно будешь рад, что разобрался в этом заранее.

👉 Java Portal

Учись разрабатывать API с нуля! 🤓

Этот ресурс бесплатный и включает:

✓ Пошаговый курс по REST API и GraphQL
✓ Как добавить безопасность в свои API
✓ Как монетизировать API

→ http://rapidapi.com/learn

👉 Java Portal