🔼 Прокачай DevOps-скиллы на практике

Платформа с реальными DevOps-задачами. Кейсы по Linux, Docker и Kubernetes — всё как в бою, но с читами:

✔️ Автопроверка решений
✔️ Подсказки
✔️ Готовые решения

🔗 Попробовать

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

🔬 Правильный вопрос про AI

Все исследования AI-ассистентов меряют одно: насколько быстрее ты закрываешь задачу. Метрика удобная, но она игнорирует 70–80% реальных затрат — поддержку, рефакторинг, устранение дефектов.

Исследование «Echoes of AI» (arXiv, 2025) спросило другое:

«Что будет, когда другой разработчик возьмёт AI-код и попытается его развивать?»

151 участник, 95% практикующие разработчики (не студенты). Java/Spring Boot проект, две фазы, настоящее РКИ. Одна группа пишет с AI, другая без. Потом третья группа без AI поддерживает и тот, и другой код.

Результат оказался неожиданный.

👉 Читать

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

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

#DevLife

🧩 Просто о сложном: Saga Pattern

Когда пользователь оформляет заказ, нужно списать деньги, зарезервировать товар и уведомить склад. Всё в разных сервисах. Что делать, если один из них упал?

Обычная транзакция тут не поможет. Добро пожаловать в Saga.

Идея проста: разбиваем большую распределённую транзакцию на цепочку маленьких локальных. Каждый шаг — это своя транзакция в своём сервисе. Если что-то пошло не так, то запускаем компенсирующие транзакции в обратном порядке.

🔹 Два подхода

1. Choreography (хореография)

Сервисы общаются через события. Каждый сам знает, что делать дальше.

OrderService → [OrderCreated] → PaymentService
PaymentService → [PaymentDone] → InventoryService
InventoryService → [Reserved] → NotificationService

✔️ Просто, нет единой точки отказа
❌ Сложно отследить весь флоу, спагетти из событий

2. Orchestration (оркестрация)

Есть дирижёр — Saga Orchestrator. Он знает весь сценарий и командует сервисами.

public class OrderSagaOrchestrator {

    public void execute(Order order) {
        try {
            paymentService.charge(order);
            inventoryService.reserve(order);
            notificationService.notify(order);
        } catch (PaymentException e) {
            // компенсация не нужна — деньги не списаны
        } catch (InventoryException e) {
            paymentService.refund(order); // компенсируем
        }
    }
}

✔️ Флоу виден в одном месте, легко дебажить
❌ Оркестратор может стать узким местом

⚠️ Важно понимать: компенсирующая транзакция ≠ откат БД. Это бизнес-операция. Если деньги уже списаны, то мы не откатываем строку в БД, мы делаем возврат.

В Java-экосистеме Saga используют вместе с:

→ Apache Kafka / RabbitMQ — для событий между сервисами
→ Axon Framework — встроенная поддержка Saga из коробки
→ Spring State Machine — для управления состоянием оркестратора
→ Temporal / Conductor — оркестрация workflow на уровне инфраструктуры

🔹 Когда использовать

✔️ Микросервисная архитектура
✔️ Несколько БД, нет возможности использовать 2PC
✔️ Долгоживущие бизнес-транзакции
❌ Монолит с одной БД — просто используй @Transactional

Saga — это не серебряная пуля, это компромисс. Ты жертвуешь изоляцией ради масштабируемости. Данные могут быть временно не консистентны и это нормально, если бизнес с этим согласен.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

😮 Топ-вакансий для джавистов за неделю

Java-разработчик — Офис (Казань)

Java-разработчик — от 230 000 до 330 000 ₽ — удалёнка/гибрид (Москва)

Senior Java Developer (Kotlin) — от 400 000 ₽ — удалёнка

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

⌛ Сохраняйте шпаргалку по join'ам

Наглядная шпаргалка с примерами и визуализацией SQL JOIN.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

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

#DevLife

💥 Разрушим частый миф

Мне НЕ нужно разбираться с управлением памятью в Java, так как за меня всё делает GC

Garbage Collector (GC) действительно очищает неиспользуемые объекты, которые больше не имеют активных ссылок. Благодаря этому в Java не нужно вручную освобождать память, как в C++.

Несколько предпосылок к исходному тезису:

🔹 В других языках, где ручное управление памятью (C, C++), утечки очевидны — если забыл free(), память навсегда потеряна.
🔹 В Java GC работает автоматически, поэтому кажется, что он решает все проблемы сам.
🔹 "Ну раз GC есть, значит, про память можно не думать!" — типичная ошибка.

GC удаляет только те объекты, которые больше не имеют активных ссылок. Если же объект остаётся доступным, но фактически не используется, он будет занимать память до завершения работы приложения.

🔽 Несколько случаев утечек памяти

1️⃣ Статические коллекции (заполняем, но не чистим)

Если создать static List и постоянно добавлять в него объекты, они никогда не будут удалены GC, потому что статические поля живут весь срок жизни приложения.

public class MemoryLeak {
    private static final List<byte[]> cache = new ArrayList<>();
    
    public static void main(String[] args) {
        while (true) {
            cache.add(new byte[10 * 1024 * 1024]); 
            System.out.println("Добавили 10MB в кеш. Используемая память: " +
                    (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / (1024 * 1024) + "MB");
        }
    }
}

Через пару минут — OutOfMemoryError

2️⃣ Потоковые переменные (ThreadLocal)

Объекты, хранящиеся в ThreadLocal, привязываются к потоку, а в пуле потоков они могут жить дольше, чем нужно.

public class ThreadLocalLeak {
    private static final ThreadLocal<byte[]> threadLocalData = new ThreadLocal<>();

    public static void main(String[] args) {
        ExecutorService executor = Executors.newFixedThreadPool(5);

        for (int i = 0; i < 10; i++) {
            executor.execute(() -> {
                threadLocalData.set(new byte[10 * 1024 * 1024]); // 10MB на поток
                System.out.println("Память занята потоком!");
            });
        }

        executor.shutdown();
    }
}

Поток завершится, а память останется занята, потому что ThreadLocal не очищается автоматически.

3️⃣ Внутренние классы и "утекшие" ссылки

Если анонимный класс или лямбда-ссылка ссылается на внешний объект, она может мешать GC очистить его.

public class InnerClassLeak {
    private String data = "Очень важные данные";

    public void createAnonymousClass() {
        Runnable task = new Runnable() {
            @Override
            public void run() {
                System.out.println("Используем: " + data);
            }
        };
        new Thread(task).start();
    }
}

task ссылается на data, даже если InnerClassLeak больше не используется → GC не очистит объект.

👎 Миф разрушен. GC не всемогущий и даже с ним придётся изучать, как работать с памятью в Java.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

✔️ SQL-тест: Топ категорий Google Search

Задача из реального интервью в Google 👇

📦 Задание

Google хочет проанализировать самые популярные категории поиска для оптимизации результатов.

Таблицы на картинке. Напишите запрос для подсчета общего количества поисков в каждой категории по месяцам за 2024 год.

Ставьте → 🔥, если нравится формат. Если нет → 🤔

💬 Решения под спойлер. Сравним, какое будет лучше.

🐸 Библиотека собеса по Java

#practise

🖥 Визуализатор кода

Прямо в браузере можно посмотреть, что происходит под капотом кода: как создаются и взаимодействуют объекты, как данные перемещаются в памяти, и как работает стек вызовов. Всё это можно увидеть пошагово.

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

⛓ Ссылка на сервис

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

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

#DevLife

🐳 Магия Docker CLI

Забываете, сколько места занимают контейнеры, образы и тома Docker? Не хотите каждый раз лезть в df или гадать? Просто запустите docker system df, и у вас будет вся картина перед глазами.

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

— Показывает сколько места занимают образы, контейнеры, тома и билд-кэш.
— Видно реальный размер и сколько можно освободить прямо сейчас.
— Незаменимо, когда диск неожиданно кончается на проде или CI/CD агенте.

🔹 Как использовать

— Краткая сводка: docker system df
— Подробный разбор по каждому объекту: docker system df -v
— Можно комбинировать с docker system prune, чтобы сразу почистить лишнее.
— Удобно добавить в cron или мониторинг, чтобы отслеживать рост потребления.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

🖥 Параллельная обработка Kafka сообщений с гарантией at-least-once в условиях медленного внешнего сервиса

Если один запрос зависает, batch встаёт колом. Простое увеличение max.poll.records не решит проблему, если медленные ответы — это постоянное явление.

В статье описывается, как заменить пакетную синхронизацию на трёхэтапную модель: подготовка, обработка, постобработка – через специальный wait-топик. Коммит офсета происходит сразу, сохраняя гарантию at-least-once, и даже 8-часовая недоступность Postgres не сорвёт обработку.

В итоге получили 46 TPS против 170 TPS с теми же настройками. Код, конфиги Kafka Connect и результаты тестов прилагаются.

🔗 Подробнее в статье

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

📌 False Sharing и Object Memory Layout в Java

Если производительность внезапно падает, хотя два потока работают с разными частями одного объекта, скорее всего, проблема в так называемом false sharing.

Вот как это работает: процессор не берет данные из памяти побайтово. Он работает с cache line, обычно это 64 байта. Если два ядра процессора держат одну и ту же cache line в своих кэшах первого уровня (L1) и хотя бы одно ядро в нее пишет, запускается протокол когерентности (MESI). Этот протокол делает копию cache line недействительной в другом ядре. И это происходит, даже если ядра пишут в разные поля объекта, но эти поля физически находятся в одной cache line.

🔹 Как объекты лежат в памяти

JVM (HotSpot) раскладывает объект примерно так:
[mark word — 8 байт]
[klass pointer — 4/8 байт]
[поля по убыванию размера: long/double → int/float → short/char → byte/boolean → ссылки]
[padding до выравнивания на 8 байт]

Порядок полей в исходнике не соответствует порядку в памяти. JVM перегруппировывает их для минимизации выравнивания. Проверить реальный layout можно через JOL:

javaSystem.out.println(ClassLayout.parseClass(MyClass.class).toPrintable());

Для класса с `long`, `int` и `boolean` JOL покажет что-то вроде:

OFFSET  SIZE    TYPE
0       4       (object header: mark)
4       4       (object header: mark)
8       4       (object header: class)
12      4       int value
16      8       long counter
24      1       boolean flag
25      7       (alignment/padding)

Итого 32 байта — меньше cache line. Два таких объекта рядом в массиве легко попадут в одну линию.

🔹 Классический сценарий

class Counters {
    volatile long a;
    volatile long b;
}

Поля a и b занимают по 8 байт. Заголовок объекта – примерно 12-16 байт. Вероятно, оба поля попадают в одну 64-байтную строку кэша. Если два потока независимо увеличивают a и b, они постоянно будут делать строку недействительной друг для друга. На многоядерной системе это легко может привести к падению производительности в 5-10 раз по сравнению с независимыми счетчиками.

Решение – добавление отступов (padding). До Java 8 это делали руками, добавляя фиктивные поля:

class PaddedCounter {
    volatile long value;
    long p1, p2, p3, p4, p5, p6, p7; // 56 байт padding
}

Уродливо и ненадёжно. Плюс JIT мог выкинуть «мёртвые» поля.

С Java 8 появилась аннотация @Contended (пакет jdk.internal.vm.annotation):

@Contended
volatile long a;
@Contended
volatile long b;

В JVM автоматически добавляется padding в 128 байт вокруг помеченного поля. Это сделано для защиты от prefetcher'а (размер двойной cache line). Чтобы это работало вне классов JDK, нужно использовать опцию -XX:-RestrictContended.

Аннотация @Contended стоит на полях внутри Thread (например, для thread-local random), ForkJoinPool и Striped64, который является базовым классом для LongAdder и LongAccumulator.

🔹 LongAdder как способ решения проблемы

LongAdder показывает, как можно решить проблему не просто добавлением отступов, а с помощью особого подхода к проектированию. Вместо одного volatile long используется массив Cell[], где у каждой ячейки стоит @Contended. Каждый поток пишет в свою ячейку, итоговое значение получается через sum(). При большой нагрузке это работает намного быстрее, чем AtomicLong.

За это приходится платить: sum() не является атомарной операцией. Если нужна полная точность в момент чтения, LongAdder не подойдет.

🔹 О массивах примитивных типов

Тут есть свои нюансы с long[]. Элементы располагаются один за другим, без каких-либо дополнительных данных между ними. Восемь элементов long занимают ровно одну cache line. Если несколько потоков одновременно пишут в соседние ячейки, false sharing практически гарантирован. Именно поэтому в Striped64 используется массив объектов Cell[], а не long[]: каждый объект с @Contended изолирован от других.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

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

#DevLife

🖥 Как LeetCode только проще

Сайт с интерактивными задачами → CodingBat Java

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

🔧 Caffeine: локальный кеш когда Redis избыточен

Для кеширования результатов тяжёлых вычислений или редко меняющихся справочников Redis часто избыточен. Caffeine — высокопроизводительный in-process кеш с Window TinyLFU eviction policy.

🔹 Решение

▪️ Зависимость

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
</dependency>

▪️ Конфигурация через Spring Cache

spring:
  cache:
    type: caffeine
    caffeine:
      spec: maximumSize=1000,expireAfterWrite=10m
  cache:
    cache-names:
      - currencies
      - countryDictionary
      - featureFlags

▪️ Программная конфигурация с разными политиками

@Configuration
@EnableCaching
public class CaffeineConfig {

    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager manager = new CaffeineCacheManager();
        manager.setCacheLoader(caffeineCacheLoader());

        // разные настройки для разных кешей
        manager.registerCustomCache("currencies",
            buildCache(500, Duration.ofHours(1)));

        manager.registerCustomCache("featureFlags",
            buildCache(100, Duration.ofMinutes(5)));

        // дефолт для остальных
        manager.setCaffeine(Caffeine.newBuilder()
            .maximumSize(1000)
            .expireAfterWrite(10, TimeUnit.MINUTES)
            .recordStats()); // метрики

        return manager;
    }

    private Cache<Object, Object> buildCache(int size, Duration ttl) {
        return Caffeine.newBuilder()
            .maximumSize(size)
            .expireAfterWrite(ttl)
            .refreshAfterWrite(ttl.dividedBy(2)) // фоновое обновление
            .recordStats()
            .build();
    }
}

▪️ Метрики через Micrometer

@Bean
public CacheMetricsRegistrar cacheMetricsRegistrar(MeterRegistry registry,
                                                     CacheManager cacheManager) {
    return new CacheMetricsRegistrar(registry, List.of(cacheManager));
}

Даёт метрики: cache.gets, cache.puts, cache.evictions, cache.hits, hit rate.

refreshAfterWrite — ключевая настройка для production. В отличие от expireAfterWrite, он не удаляет запись по истечении TTL, а помечает её для фонового обновления. Следующий запрос получит устаревшее значение мгновенно, пока фоновый поток обновляет кеш. Латентность не растёт при рефреше.

⚠️ Caffeine — in-process кеш. При горизонтальном масштабировании каждый инстанс имеет свой кеш. Инвалидация при изменении данных требует либо короткого TTL, либо внешнего механизма (Redis pub/sub, Kafka event). Для справочников с редкими изменениями короткого TTL обычно достаточно.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise