Java | Фишки и трюки

String.format() 🆚 конкатенация vs StringBuilder — кто быстрее на самом деле? Каждый день ты склеиваешь строки. Но если это происходит в горячем цикле или в высоконагруженном микроссервисе — разница в подходах может стоить миллисекунд, а то и секунд процессорного времени. Давай расставим всё по местам с цифрами в руках. Вот бенчмарк-ликбез, после которого ты больше не будешь гадать 👇 🗂 Шаг 1: Подопытные (4 основных способа)

    
        // 1. Конкатенация (+)
String result1 = "Привет, " + name + "! Тебе " + age + " лет.";

// 2. StringBuilder
String result2 = new StringBuilder()
    .append("Привет, ")
    .append(name)
    .append("! Тебе ")
    .append(age)
    .append(" лет.")
    .toString();

// 3. String.format()
String result3 = String.format("Привет, %s! Тебе %d лет.", name, age);

// 4. String.concat() (редко, но бывает)
String result4 = "Привет, ".concat(name).concat("! Тебе ").concat(String.valueOf(age)).concat(" лет.");{}
    

➡️ Все они дают один результат. Но под капотом — абсолютно разная механика и производительность. 🗂 Шаг 2: Бенчмарк (условные замеры на 100_000 итераций) Представим результаты в наносекундах на операцию (меньше = лучше):

    
        Конкатенация (+) ........... ~50 нс
StringBuilder .............. ~15 нс
String.format() ............ ~1200 нс
String.concat() ............ ~70 нс{}
    

➡️ Главный вывод: String.format() проигрывает в скорости в десятки раз. Он делает парсинг шаблона, проверку типов — это дорого. StringBuilder — чемпион по скорости. 🗂 Шаг 3: Почему «+» иногда не хуже StringBuilder? Важный нюанс! Компилятор сам оптимизирует простую конкатенацию в StringBuilder.

    
        // Ты пишешь:
String s = a + b + c;

// Компилятор делает под капотом:
String s = new StringBuilder().append(a).append(b).append(c).toString();{}
    

➡️ Но! Это работает только для литералов и финальных выражений в одной строке кода. В циклах — оптимизации нет! 🗂 Шаг 4: Цикл — место, где «+» убивает производительность

    
        // ❌ ПЛОХО (создаётся новый StringBuilder на КАЖДОЙ итерации)
String result = "";
for (String part : parts) {
    result += part; // Скрытый new StringBuilder() каждый раз!
}

// ✅ ХОРОШО (один StringBuilder на весь цикл)
StringBuilder sb = new StringBuilder();
for (String part : parts) {
    sb.append(part);
}
String result = sb.toString();{}
    

➡️ В цикле на 1000 элементов разница будет в сотни раз. Это та самая ошибка, которая съедает CPU. 🗂 Шаг 5: А когда тогда использовать String.format()? Когда читаемость и поддержка важнее скорости: 1. Сложные шаблоны с числами, датами, округлением:

    
            // Читаемо vs Нечитаемо
    String.format("Сумма: %.2f руб., дата: %tD", sum, date); // ✅
    // vs ручное склеивание с DecimalFormat и SimpleDateFormat — кошмар
    {}
    

2. Логирование, где скорость не критична (но даже там лучше шаблонизатор). 3. Конфигурационные сообщения, выносимые в properties-файлы. ➡️ String.format() — это Rolls-Royce: удобно, красиво, но для поездки в магазин за хлебом — избыточно. 🗂 Шаг 6: StringJoiner — твой друг для списков

    
        // Когда нужно собрать строку через разделитель
StringJoiner joiner = new StringJoiner(", ", "[", "]");
joiner.add("Java");
joiner.add("Kotlin");
joiner.add("Scala");
String result = joiner.toString(); // [Java, Kotlin, Scala]{}
    

➡️ Под капотом использует StringBuilder, но даёт элегантный API для склейки с разделителями. Используй вместо ручных проверок «не первый ли элемент?». 🗣 Запомни: Выбирай инструмент не по привычке, а по делу.

🕰️ Java Time API: Почему java.util.Date должен умереть В старых версиях Java работа со временем была настоящим квестом. Класс java.util.Date — это, пожалуй, самый неудачный дизайн в истории JDK. 🤦‍♂️ Зал славы проблем Date и Calendar: 1️⃣ Они изменяемые (Mutable): Вы передаете дату в метод, а он может тихо поменять ей год. Это ад для многопоточности. 2️⃣ Нумерация месяцев: Январь — это 0. Декабрь — 11. Сколько багов было написано из-за этого! 3️⃣ Годы: new Date(2023, ...) создаст дату в 3923 году (потому что отсчет идет с 1900). 4️⃣ Нейминг: java.sql.Date наследуется от java.util.Date, но не содержит времени. Путаница неизбежна. ✅ Спасение в Java 8+ (java.time) Java переняла опыт библиотеки Joda-Time и внедрила JSR 310. Теперь у нас есть строгие, неизменяемые и понятные типы. Шпаргалка, что выбрать: 1️⃣ Instant — Точка на временной шкале (Unix Timestamp). Для кого: Для машин, логов и баз данных. Внутри это просто количество секунд с 1970 года (UTC). Пример: Instant.now() 2️⃣ LocalDate / LocalTime — "Дата в календаре" и "Время на часах". Без часового пояса. Для кого: Дни рождения, праздники ("Новый год всегда 1 января", неважно, где вы). Пример: LocalDate.of(2023, Month.JANUARY, 1) 3️⃣ ZonedDateTime — Полный фарш: дата + время + часовой пояс. Для кого: Для организации встреч звонков между странами. Учитывает переход на летнее время! 💎 Неизменяемость (Immutability): Больше никаких сюрпризов. Методы изменения времени всегда возвращают новый объект.

    
        
LocalDate today = LocalDate.now();
LocalDate tomorrow = today.plusDays(1); // today остался прежним!
{}
    

💡 Лайфхак: Если вам нужно посчитать разницу между датами, используйте Period (для дней/месяцев) или Duration (для секунд/наносекунд).

    
        
long days = ChronoUnit.DAYS.between(date1, date2);{}
    

🕰️ Java Time API: Почему java.util.Date должен умереть В старых версиях Java работа со временем была настоящим квестом. Класс java.util.Date — это, пожалуй, самый неудачный дизайн в истории JDK. 🤦‍♂️ Зал славы проблем Date и Calendar: 1️⃣ Они изменяемые (Mutable): Вы передаете дату в метод, а он может тихо поменять ей год. Это ад для многопоточности. 2️⃣ Нумерация месяцев: Январь — это 0. Декабрь — 11. Сколько багов было написано из-за этого! 3️⃣ Годы: new Date(2023, ...) создаст дату в 3923 году (потому что отсчет идет с 1900). 4️⃣ Нейминг: java.sql.Date наследуется от java.util.Date, но не содержит времени. Путаница неизбежна. ✅ Спасение в Java 8+ (java.time) Java переняла опыт библиотеки Joda-Time и внедрила JSR 310. Теперь у нас есть строгие, неизменяемые и понятные типы. Шпаргалка, что выбрать: 1️⃣ Instant — Точка на временной шкале (Unix Timestamp). Для кого: Для машин, логов и баз данных. Внутри это просто количество секунд с 1970 года (UTC). Пример: Instant.now() 2️⃣ LocalDate / LocalTime — "Дата в календаре" и "Время на часах". Без часового пояса. Для кого: Дни рождения, праздники ("Новый год всегда 1 января", неважно, где вы). Пример: LocalDate.of(2023, Month.JANUARY, 1) 3️⃣ ZonedDateTime — Полный фарш: дата + время + часовой пояс. Для кого: Для организации встреч звонков между странами. Учитывает переход на летнее время! 💎 Неизменяемость (Immutability): Больше никаких сюрпризов. Методы изменения времени всегда возвращают новый объект.

    
        
LocalDate today = LocalDate.now();
LocalDate tomorrow = today.plusDays(1); // today остался прежним!
{}
    

💡 Лайфхак: Если вам нужно посчитать разницу между датами, используйте Period (для дней/месяцев) или Duration (для секунд/наносекунд).

    
        
long days = ChronoUnit.DAYS.between(date1, date2);{}
    

🤖Уведомления в Android — это важный инструмент взаимодействия с пользователем, который напрямую влияет на вовлечённость, retention и пользовательский опыт. Ошибки в работе с уведомлениями — частая проблема у начинающих Android-разработчиков. 📆На открытом вебинаре OTUS разберём все виды уведомлений в Android: от базовых до более продвинутых сценариев. Покажем, какие типы уведомлений существуют, чем они отличаются и в каких случаях используются. Все примеры — с разбором кода и практической реализацией. За один вебинар вы получите системное понимание уведомлений в Android и научитесь внедрять их в свои проекты осознанно, а не методом проб и ошибок. Это базовый навык, без которого невозможно двигаться дальше в Android-разработке. 💥Встречаемся 27 января в 20:00 МСК в преддверии старта курса «Android Developer». Регистрация открыта: https://otus.pw/8KD0/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

⌨️ Java CompletableFuture: Прокачанный Future Помните интерфейс Future из Java 5? Он был похож на чемодан без ручки. Вы могли отправить задачу в другой поток, но чтобы получить результат, приходилось делать future.get() и блокировать текущий поток, ожидая ответа. Смысл асинхронности терялся. В Java 8 появился `CompletableFuture`. Это Future, который можно "программировать". 🔗 Цепочки вызовов (Pipelining) Вместо того чтобы ждать результат, вы говорите Java: *"Когда результат будет готов, сделай с ним вот это, а потом вот это"*.

    
        
CompletableFuture.supplyAsync(() -> {
    return fetchUser(123); // 1. Идем в базу (в другом потоке)
}).thenApply(user -> {
    return user.getEmail(); // 2. Преобразуем (когда данные пришли)
}).thenAccept(email -> {
    sendEmail(email);       // 3. Отправляем письмо
});

System.out.println("Я не заблокирован!"); // Эта строка выполнится мгновенно
{}
    

💪 Суперсила: Комбинация задач Представьте, что вам нужно получить данные пользователя И его последние заказы из разных сервисов одновременно.

    
        
var userFuture = CompletableFuture.supplyAsync(() -> getUser());
var ordersFuture = CompletableFuture.supplyAsync(() -> getOrders());

// Ждем оба, комбинируем результаты и возвращаем отчет
userFuture.thenCombine(ordersFuture, (user, orders) -> {
    return new Report(user, orders);
}).thenAccept(report -> show(report));
{}
    

Оба запроса выполняются параллельно. Время выполнения равно времени самого медленного запроса, а не их сумме. ⚠️ Опасная ловушка По умолчанию CompletableFuture использует общий пул потоков ForkJoinPool.commonPool(). Если вы запустите там "тяжелую" блокирующую задачу (например, долгий запрос к БД без асинхронного драйвера), вы можете забить все потоки и "повесить" всё приложение. Совет: Всегда передавайте свой собственный Executor вторым аргументом:

    
        
CompletableFuture.supplyAsync(() -> heavyTask(), myCustomExecutor);{}
    

🔴 Завтра тестовое собеседование с Java-разработчиком 21 января(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика. Как это будет: 📂 Сергей Чамкин, старший разработчик из Uzum, ex-WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Cергей будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Сергею Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot Реклама. О рекламодателе.

👻 Java `volatile`: Призрак в памяти Спросите на собеседовании: «Зачем нужен volatile?», и 80% ответят: «Чтобы потоки не конфликтовали». Это не совсем так. volatile не спасает от конфликтов (race conditions). Он решает проблему видимости. Давайте разберемся, почему ваш код может зависнуть навечно без этого слова. 🛑 Ситуация: Бесконечный цикл Представьте простой код:

    
        
public class Worker {
    private boolean running = true; // ❌ Забыли volatile

    public void run() {
        while (running) {
            // Крутимся в цикле и ждем команды стоп
        }
        System.out.println("Stopped!");
    }

    public void stop() {
        running = false;
    }
}
{}
    

Вы запускаете run() в Потоке А, а через секунду вызываете stop() из Потока Б. Ожидание: Цикл остановится. Реальность: Программа может работать вечно. Почему? (Кэши процессора) Современные процессоры супер-быстрые, а оперативная память (RAM) — медленная. Чтобы не ждать память, каждое ядро процессора имеет свой локальный кэш (L1/L2 Cache). 1. Поток А (Ядро 1) скачал переменную running = true в свой кэш. Он проверяет её там. 2. Поток Б (Ядро 2) меняет значение на false в *своем* кэше и даже записывает в RAM. 3. Но Поток А этого не видит! Он продолжает читать true из своего изолированного кэша. Это называется проблема видимости. ✨ Магия `volatile` Если мы напишем:

    
        
private volatile boolean running = true;
{}
    

Мы говорим JVM и процессору: «Эту переменную нельзя кэшировать локально». 1. Любая запись в volatile переменную сразу пробрасывается (flush) в общую память (RAM). 2. Любое чтение volatile переменной идет напрямую из общей памяти. Поток А сразу увидит изменение, и цикл остановится. ⚠️ Главная ловушка: Атомарность Многие новички думают: «О, volatile синхронизирует данные! Значит можно делать счетчик».

    
        
volatile int count = 0;
count++; // ⛔️ ОПАСНО!
{}
    

НЕТ! Операция count++ — это три действия: считать, прибавить, записать. volatile гарантирует, что вы считаете свежее значение, но он не блокирует других от изменения этой переменной в тот же момент. Два потока могут одновременно считать 5, оба добавят 1 и запишут 6. Мы потеряем данные. Итог: 👉 Используйте volatile только для флагов состояния (вкл/выкл) или когда запись делает только один поток. 👉 Для счетчиков используйте AtomicInteger или synchronized.

Твой английский тормозит карьеру в IT? Привет! Меня зовут Диана, я основатель Fluent Biz — школы делового английского. Знакомо, когда: • Теряешь нить на митинге с foreign colleagues? • Не можешь уверенно представить свой проект на английском? • Заказчики просят «уточнить детали», а ты не знаешь, как объяснить? Мы решаем эти проблемы — быстро, без воды и скучных учебников! 🔥 Дарим тебе БЕСПЛАТНЫЙ пробный урок, на котором: ✅ Определим твой уровень английского ✅ Разберём твои слабые места в речи и переписке ✅ Расскажу о том, каким образом и за какое время ты сможешь выйти на новый уровень языка ✅ Докажу, что говорить на английском с самого первого урока — реально 🎁 + Бонус для первых 5 записавшихся: консультация по подготовке к собеседованию на английском. Что делать? 1️⃣ Подпишись на наш канал: @fluent_biz 2️⃣ Напиши @blhdiair cо словом «JAVA» — и мы согласуем удобное время для урока. Промокод на бесплатный урок сгорит ровно через неделю, успей написать до 25.07📑 Не дай незнанию английского стать твоим потолком в карьере!

⌨️ Java ClassLoader: Серый кардинал JVM Когда вы нажимаете "Run", вы, возможно, думаете, что Java загружает все ваши классы в память и начинает работу. Вовсе нет. Java — ленивая. Она грузит классы только тогда, когда они реально понадобятся. И отвечает за этот процесс ClassLoader. Это именно тот механизм, который позволяет серверам приложений (Tomcat, Jetty) перезапускать веб-приложения без остановки сервера, а Spring'у — творить свою магию. 🏗 Иерархия загрузчиков (Три кита) В Java существует строгая иерархия. Когда нужно найти класс, работает принцип Delegation Model (Модель делегирования): «Сначала спроси у родителя». 1️⃣ Bootstrap ClassLoader (Первородный) Это самый главный загрузчик. Он написан на C++ (поэтому, если вызвать String.class.getClassLoader(), вы получите null - Java его просто не видит как объект). Что грузит: Ядро Java (java.lang.*, java.util.* - всё из rt.jar или модулей java.base). 2️⃣ Platform ClassLoader (ранее Extension) Наследник Bootstrap'а. Что грузит: Расширения JDK (SQL, XML парсеры и прочие системные модули). 3️⃣ Application (System) ClassLoader Тот самый, с которым мы работаем 99% времени. Что грузит: Всё, что лежит в вашем CLASSPATH (`-cp`). Ваш код и ваши библиотеки. 🔄 Как работает поиск класса? Допустим, в коде встретилось new User(). 1. AppClassLoader не бросается искать файл User.class сам. Он звонит родителю: «Слушай, Platform, у тебя есть User?» 2. PlatformClassLoader тоже ленив и звонит своему родителю: «Bootstrap, у тебя есть User?» 3. Bootstrap смотрит в ядре Java. «Нет, это не стандартный класс». 4. Только тогда управление возвращается вниз. Platform смотрит у себя — нет. 5. И только в конце AppClassLoader ищет класс в ваших jar-файлах. Если не найдет и он — привет, ClassNotFoundException. 👹 Ад зависимостей (Jar Hell) и Custom ClassLoaders Зачем знать про ClassLoaders? Чтобы понимать сложные баги и архитектуру. Представьте, что ваше приложение использует библиотеку Lib A версии 1.0, а другая ваша библиотека требует Lib A версии 2.0. Стандартный загрузчик сломается: он не может загрузить два класса с одинаковым именем (`com.example.Lib`). Выиграет тот, кто первый попался в classpath, а второй упадет с ошибкой NoSuchMethodError. Как это решают Tomcat или Maven? Они пишут свои собственные ClassLoader'ы, нарушая стандартную иерархию. В Tomcat каждое веб-приложение (`war`) имеет свой изолированный загрузчик. Поэтому два разных приложения могут использовать разные версии Spring на одном сервере, и они не подерутся. Итог: ClassLoader — это мост между файловой системой и памятью JVM. Понимание модели делегирования спасает часы при отладке странных ошибок, когда класс вроде бы есть, но Java его «не видит».

🗑Внутренности JVM — кто убирает мусор и как JVM — это не просто виртуальная машина. Это механика управления памятью, где каждый сборщик мусора решает свои задачи и влияет на производительность. Разберёмся👇 ❌ Антипаттерн: полагаться на default GC без понимания

    
        // просто запускаем JVM и забываем{}
    

⚠️ Разные приложения — разные потребности: latency vs throughput. ➡️ Выбор GC = контроль над паузами и скоростью. ✅ Мини-примеры для понимания GC 👍 Создание большого массива объектов

    
        public class GCDemo {
    public static void main(String[] args) {
        for (int i = 0; i < 1_000_000; i++) {
            byte[] block = new byte[1024 * 1024]; // 1MB
        }
        System.out.println("Создано много объектов");
    }
}{}
    

➡️Позволяет увидеть работу сборщика мусора, если включить лог GC:

    
        -XX:+PrintGCDetails{}
    

👍Проверка поведения G1

    
        public class G1Demo {
    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 100; i++) {
            int[] arr = new int[10_000_000]; // ~40MB
            Thread.sleep(50); // медленная генерация объектов
        }
        System.out.println("Демонстрация работы G1");
    }
}{}
    

➡️ JVM с G1 будет постепенно очищать регионы, минимизируя паузы. 👍 Принудительный вызов GC (для экспериментов, не для продакшена)

    
        System.gc();{}
    

⚠️Позволяет проверить, как JVM реагирует, но не гарантирует моментальный сбор. 🗣 Запомни: Сборщик мусора — это механика JVM, а не магия. Выбор GC, размер heap и режим работы напрямую влияют на паузы и производительность. Этот код поможет увидеть GC в действии и понять разницу между Serial, Parallel и G1.