❓ В чем разница между map() и flatMap()?

Оба метода используются для трансформации данных в Stream, но с ключевыми отличиями:

▪️ map(Function<T, R>) применяет функцию к каждому элементу потока и возвращает поток с преобразованными элементами (Stream<R>).

▪️ flatMap(Function<T, Stream<R>>) делает то же самое, но ожидает, что функция вернет Stream<R>, а затем "выпрямляет" вложенные потоки в один Stream<R>.

📌 Пример:

List<String> words = List.of("Hello", "World");

// map(): превращает каждое слово в список символов
List<List<Character>> mapped = words.stream()
    .map(word -> word.chars()
                     .mapToObj(c -> (char) c)
                     .toList())
    .toList();

// flatMap(): превращает каждое слово в поток символов и "сплющивает" их в один поток
List<Character> flatMapped = words.stream()
    .flatMap(word -> word.chars()
                         .mapToObj(c -> (char) c))
    .toList();

System.out.println(mapped);      // [[H, e, l, l, o], [W, o, r, l, d]]
System.out.println(flatMapped);  // [H, e, l, l, o, W, o, r, l, d]

🔼 Улучшаем работу с Optional

Все используют Optional, но не все знают, как сделать это лучше. Нередко можно встретить такой код:

Optional<User> userOpt = findUserById(id);
if (userOpt.isPresent()) {
    User user = userOpt.get();
    processUser(user);
}

Такой код не только избыточен, но и может привести к NoSuchElementException, если забыть проверить isPresent(). Поэтому лучше использовать ifPresent(), чтобы оптимизировать код:

findUserById(id).ifPresent(this::processUser);

📌 Какие ещё варианты

— Для выполнения действия, если значение есть (ifPresent()).
— Для подстановки дефолтного значения (orElse() / orElseGet()).
— Для обработки исключений (orElseThrow()).

⚠️ Плохие практики

▪️ Использовать Optional в качестве аргументов методов — это ломает читаемость API.
▪️ Использовать Optional.get() без проверки — это сводит всю пользу Optional на нет.

📊 Почему увольнять программистов ради ИИ — путь к провалу

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

➡️ Что внутри статьи

▪️ Почему новые поколения программистов рискуют потерять ключевые навыки.

▪️ Как компании, заменившие инженеров ИИ, столкнутся с серьезными проблемами.

▪️ Почему опытные разработчики станут супердорогими и востребованными.

▪️ К чему приведет полная ставка на искусственный интеллект в IT.

🔵 Подтяните свои знания о машинном обучении вместе с нашим курсом «Базовые модели ML и приложения»

🔗 Читайте статью

❓ Какой AI-инструмент вы используете?

🔥 ChatGPT
👍🏼 DeepSeek
⚡️ GitHub Copilot
❤️ ЯндексГпт
👾 Я пишу код сам, без AI

⌛ WeakHashMap

WeakHashMap — это хеш-таблица, в которой ключи хранятся через слабые ссылки (WeakReference). Это значит, что если на ключ нет сильных ссылок, он становится кандидатом на удаление при следующем проходе GC.

🔹 Как работает GC с WeakHashMap

GC удаляет только ключи, на которые больше нет сильных ссылок. Значения же остаются в памяти, пока WeakHashMap не изменится (put(), remove()). Можно использовать ReferenceQueue, чтобы отслеживать удалённые ключи.

🔹 Когда используется

— Кеширование данных, которые можно безопасно сбрасывать.
— Хранение метаданных объектов без риска утечек памяти.
— Уменьшение давления на GC в высоконагруженных системах.

🔹 Отличие от HashMap

В HashMap ключ останется в памяти, пока его явно не удалят. В WeakHashMap ключ исчезнет автоматически, если на него нет ссылок.

⚠️ Когда НЕ стоит использовать

— Если кеш должен сохранять данные долго.
— Если ключи неизменяемые (String из пула строк, Integer), GC их не удалит.
— Если нужна предсказуемость хранения — WeakHashMap не гарантирует срок жизни ключей.

💬 Используете WeakHashMap в проде?

🧠 Твоя БД скоро станет умнее тебя: 5 трендов open-source баз данных 2025

БД перестают быть просто хранилищем — теперь они оптимизируют запросы, автоматически анализируют данные и даже используют AI для прогнозов.
Какие фичи перевернут мир open-source БД в 2025? Узнайте в статье👇

🫢 Прочитать статью

🐸Библиотека devops'a

💥 Разрушители мифов

Мне НЕ нужно разбираться с управлением памятью в 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.

⌛ Как устроен кеш в 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)

🧮🔠 Математика в действии: решаем хитрые задачи по прогнозированию, оптимизации и логике

Статья, которая поможет развить навыки решения задач с помощью математики.

➡️ Вот что вас ждет

1️⃣ Прогнозирование численности населения — используем цепи Маркова для предсказания миграций между городом и пригородами.

2️⃣ Минимизация затрат — находим минимальное скалярное произведение векторов для оптимального распределения задач между работниками.

3️⃣ Машина времени — решаем задачу максимального числа пересекающихся временных интервалов с помощью заметающей прямой.

4️⃣ Алгоритм Целлера — вычисляем день недели по дате. Проверка на практике.

🔵 Хочешь прокачаться в математике для ML? Тогда разбирайся с этими задачами и не упусти вебинар: «Математика для ML: от теории к практике».

👉 Читать статью

⚙️ Ускоряем анализ SQL-запросов с помощью AI

Часто пишете SQL-запросы и хотите быстро оптимизировать их или проверить на ошибки? Используйте этот промпт:

📝 Промпт:

Analyze the following SQL query used in Java. Explain its purpose, optimize it for performance, and suggest alternative approaches. If applicable, discuss indexing strategies and transaction handling.

String sql = "[вставьте ваш SQL-запрос сюда]";

💡 Дополнительные возможности:

— Добавьте Explain how to use PreparedStatement to prevent SQL injection и получите безопасную версию кода.
— Добавьте Suggest a Hibernate or JPA equivalent, если хотите уйти от ручного SQL.
— Добавьте Optimize this for large datasets, если у вас миллионы записей в таблице.

💬 Используете AI для помощи в написании sql-запросов?

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

🤝 💼 IT-конференции: как сходить на мероприятие и извлечь из него максимум пользы

🚀 IT-конференции — это не только про кофе-брейки и бесплатные стикеры. Это шанс завести полезные знакомства, узнать инсайдерскую информацию и найти новые карьерные возможности. Но для этого нужно не просто прийти, а правильно подготовиться и ловить важные моменты.

Как извлечь из мероприятия максимум пользы? Как сделать так, чтобы оно дало не только эмоции, но и реальные бонусы для вашей карьеры?

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

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

🔼 Оптимизация работы с JDBC в высоконагруженных приложениях

Неэффективное использование JDBC может легко стать узким местом и убить производительность. Вот пошаговый разбор, как сделать работу с JDBC быстрее и стабильнее.

1️⃣ Настраиваем connection pool

Используйте HikariCP, Apache DBCP или C3P0 вместо стандартного DriverManager. Это позволит переиспользовать соединения, а не открывать новое на каждый запрос.

2️⃣ Используем подготовленные запросы (PreparedStatement)

Во-первых, это снижает нагрузку на базу за счёт кеширования плана запроса. Во-вторых, убирает SQL-инъекции на уровне JDBC.

3️⃣ Выбираем правильный тип курсора ResultSet

— TYPE_FORWARD_ONLY, если нужно просто пробежать по данным.
— TYPE_SCROLL_INSENSITIVE позволяет скроллить данные, но требует больше памяти.
— TYPE_SCROLL_SENSITIVE редко нужен, но обновляет данные в реальном времени.

4️⃣ Ограничиваем выборку данных (LIMIT / FETCH FIRST)

Не забирайте сразу всю таблицу – старайтесь выбирать только нужные поля и ограничивать количество строк.

5️⃣ Выключаем автокоммиты

По умолчанию, каждый запрос в JDBC – это отдельная транзакция. Включите setAutoCommit(false) и коммитите изменения пачками, чтобы уменьшить нагрузку.

6️⃣ Логируем медленные запросы

Если какие-то SQL-запросы выполняются слишком долго – используйте SLF4J + P6Spy или встроенные средства логирования в пуле соединений, чтобы их отлавливать.

💬 Какие техники считаете самыми полезными?

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