Типы классов в Java:

1. Concrete Class — обычный класс с полной реализацией методов.
2. Abstract Class — нельзя создать напрямую через new; может содержать абстрактные методы.
3. Final Class — нельзя наследовать.
4. Static Nested Class — статический вложенный класс внутри другого класса.
5. Inner Class — нестатический класс внутри другого класса.
6. Local Class — класс, объявленный внутри метода или другого блока.
7. Anonymous Class — класс без имени, обычно используется для одноразовой реализации.
8. Singleton Class — класс, спроектированный так, чтобы существовал только один его экземпляр.
9. POJO — простой Java-класс без специальных требований к наследованию или фреймворкам.
10. Record Class — компактная форма класса для хранения данных; появилась как предварительная возможность в Java 14.
11. Enum Class — класс, представляющий фиксированный набор констант.

👉 Java Portal

90% PostgreSQL в 2026 году сводится к этим 10 вещам. Всё остальное — в основном споры об расширениях.

1. MVCC + VACUUM
Обновления создают мёртвые строки. Если autovacuum настроен плохо, таблицы и индексы раздуваются, а задержки постепенно растут неделями.

2. Индексы под реальные сценарии запросов
Порядок колонок в составных индексах важен. Нужно понимать частичные и покрывающие индексы, а также почему ORM иногда незаметно приводит к полному сканированию таблицы.

3. Блокировки и DDL
ALTER TABLE может заблокировать запись. Важно понимать режимы блокировок, очереди и безопасные приёмы вроде CREATE INDEX CONCURRENTLY и обновления данных небольшими партиями.

4. Уровни изоляции и аномалии
Read Committed, Repeatable Read, Serializable. Пропавшие или дублирующиеся строки часто нужно разбирать через конкурентные транзакции, а не искать проблему только в коде.

5. Управление соединениями
Слишком много соединений убивает CPU и память. Нужны PgBouncer, адекватные размеры пулов и контроль долгих транзакций в состоянии idle in transaction.

6. WAL, checkpoints и репликация
Объём WAL напрямую влияет на ввод-вывод. Плохие настройки checkpoints вызывают скачки задержек, а отставание реплик ломает чтение с реплик и делает переключение при сбое рискованным.

7. Основы планировщика запросов
EXPLAIN (ANALYZE, BUFFERS) — ваш отладчик. Нужно понимать оценки количества строк, типы JOIN и когда требуется ANALYZE или расширенная статистика.

8. Наблюдаемость, привязанная к реальным сбоям
Следите за p95 задержкой, ожиданием блокировок, временными файлами, попаданиями в кэш, отставанием autovacuum и реплик. Добавьте журнал медленных запросов с нормальными порогами.

9. Резервные копии и проверка восстановления
Базовые бэкапы плюс архивирование WAL — минимум. Главная ошибка — никогда не проверять восстановление и уже во время аварии выяснить, что не хватает ролей, расширений или восстановление занимает слишком долго.

10. Безопасность и права
Минимально необходимые права, отдельные владельцы объектов, никакого superuser у приложения, регулярная смена учётных данных, ограничение сетевого доступа и закрытая на запись схема public в production.

👉 Java Portal

Ещё один отличный плейлист по структурам данных и алгоритмам от pmavrin.

https://youtube.com/playlist?list=PLrS21S1jm43igE57Ye_edwds_iL7ZOAG4&si=4mS5lXn3uxI-V2LM

👉 Java Portal

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

У BitLemonSw как раз вышло новое видео о том, как работает предсказание ветвлений в современных процессорах.

Суть простая. В коде постоянно встречаются ветвления: циклы, if, switch/case, вызовы функций и возвраты.

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

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

https://youtu.be/UbDIoNY9E0w

👉 Java Portal

Сопоставление с образцом для instanceof: переменную можно объявить прямо в проверке.

Старый подход: сначала instanceof, затем отдельное приведение типа.

Новый подход: if (obj instanceof Dog d) — переменная d сразу готова к использованию.

При этом d существует только там, где условие проверки истинно.

#Java #PatternMatching

👉 Java Portal

Интеграционное тестирование базы данных с помощью Testcontainers

https://vladmihalcea.com/testcontainers-database-integration-testing/

👉 Java Portal

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

Любое изменение API попадает в одну из двух категорий, и от этого зависит всё.

Если изменение ломающее, нужно поднимать версию: удаление или переименование полей, добавление обязательных параметров или фундаментальное изменение поведения эндпоинта.

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

Большая часть боли появляется из-за двух противоположных ошибок. Не версионировать вообще — и каждый релиз превращается для пользователей в лотерею. Версионировать всё подряд — и в итоге вы поддерживаете пять версий, а разработчики уже не понимают, какую использовать.

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

— Показывайте версию явно, например /v1/ в URL, как это делают Stripe и GitHub.
— Используйте семантическое версионирование, чтобы смена мажорной версии сразу означала необходимость изменений в клиентском коде.
— Если версия выводится из эксплуатации, говорите об этом прямо в ответе через заголовок Sunset и давайте 6–12 месяцев на миграцию.

Версия API — это обещание о том, что не изменится.

Нарушать его нужно редко и громко. Никогда — молча.

Какую ошибку вы встречали чаще?

👉 Java Portal