Java Portal | Программирование

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГ ИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодня И те, кто научится вайбкодить сейчас, будут увереннее конкурировать на рынке и зарабатывать больше тех, кто по-прежнему делает всё вручную. Стартовать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы. Подписывайтесь, нас уже 30 тысяч: @vibecoding_tg

Spring Boot: с org.hibernate.SQL=DEBUG можно получить более детальный вывод Hibernate-запросов прямо в логах. #SpringBoot #Hibernate 👉 Java Portal

Микросервисы — плохой выбор по умолчанию для 94% команд. Зачем разбивать приложение на набор сервисов, которым нужно общаться через сеть. На бумаге это выглядит как «правильный» подход. Масштабирование звучит привлекательно. Но на практике я видел, как это ломается, шесть раз. Команды из 5 инженеров поднимали 11 сервисов с несколькими очередями сообщений. Всё становилось медленнее. Деплой, который занимал минуты, растягивался до 35 минут из-за зависимостей. Отладка превращалась в кошмар: один баг — и приходится трейсить запрос через несколько сервисов и кодовых баз. Сложность не уменьшилась. Она просто распределилась. Микросервисы — это решение под масштабирование, но большинство команд внедряют их слишком рано, когда проблемы масштаба ещё нет. Если ты всё ещё работаешь на localhost, основная проблема — не масштаб. Это стабильный релиз. Когда микросервисы имеют смысл: - команды блокируют работу друг друга - части системы требуют независимого масштабирования - есть нормальная трассировка в проде, и можно отлаживать без угадывания Если этого нет — платишь налог распределённых систем без реальной выгоды. Начинай с монолита и держи модульность. Делить стоит только тогда, когда связность начинает тормозить разработку. Большинство обсуждений «нам нужны микросервисы» на деле не про архитектуру. Они про грязную кодовую базу или болезненные деплои. Сначала решаются эти проблемы. Простые системы легче понимать. Перегруженные обычно разваливаются под собственным весом. 👉 Java Portal

Spring Boot: используйте @Async только для небольших задач на оффлоадинг и только с явно заданным исполнителем. #SpringBoot #SoftwareDevelopment 👉 Java Portal

Возможно, один из самых безумных репозиториев с Docker Он позволяет запускать полноценную macOS внутри Docker -контейнера и открывать её прямо из браузера. - Поднимается macOS одной командой Докера - Запуск полноценной macOS на Linux через QEMU/KVM - Открывается сразу в браузере - Поддержка нескольких версий macOS - Подходит для тестирования, CI и macOS-специфичных инструментов Такие проекты хорошо показывают, насколько далеко можно зайти с Docker и виртуализацией. Репозиторий: https://github.com/dockur/macos 👉 Java Portal

POST не идемпотентен. PUT — идемпотентен. PATCH — зависит от реализации. Ошибка в этих свойствах ломает ретраи. Идемпотентность означает: один и тот же запрос даёт один и тот же результат. Это важно, потому что сеть нестабильна, а клиенты делают повторные запросы. Неидемпотентные эндпоинты дублируют побочные эффекты. Два запроса могут означать две оплаты или два заказа. GET — идемпотентен. PUT — идемпотентен. DELETE — идемпотентен. POST — не идемпотентен. PATCH — зависит (инкремент vs установка значения). Для неидемпотентных эндпоинтов используют идемпотентные ключи: клиент отправляет уникальный ключ, сервер сохраняет ключ и ответ, повтор с тем же ключом возвращает тот же результат. Так устроены платёжные системы. Без этого ретраи превращаются в дублирование операций. 👉 Java Portal

Совет по Java Используйте осмысленные имена методов, которые отражают их назначение. #JavaDev #CleanCode 👉 Java Portal

JetBrains использует IDE-нативные возможности понимания кода, чтобы делать ИИ-агентов эффективнее на больших кодовых базах. Зачем тратить время и токены на grep, если в IDE уже есть семантический поиск, навигация по символам и рефакторинги? Интересный момент: Codex, судя по наблюдениям, заметно лучше использует такие инструменты, чем Claude Code. 👉 Java Portal

Java: начиная с Java 14 можно использовать records для создания коротких неизменяемых объектов, предназначенных для хранения данных. ✅ короче обычных POJO ✅ имеют встроенные equals(), hashCode(), toString() ✅ по умолчанию неизменяемые #JavaDev #Records 👉 Java Portal

Spring Boot: использование Spring Cloud Config для централизованного управления конфигурацией — важная практика. Вместо того чтобы каждый сервис хранил свой application.yml, конфигурация подтягивается из единого источника. Сначала нужно сконфигурировать сервер конфигурации. Поднимается отдельное приложение сервера конфигурации с аннотацией @EnableConfigServer и Git-репозиторий, где лежат все .yml файлы. Сервер отдает конфигурацию по HTTP, клиенты подтягивают её при старте.

<!-- Setting Up the Config Server -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

// Enable it with @EnableConfigServer annotation

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

# Point it to your Git repository

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/your-org/config-repo
          default-label: main
          clone-on-start: true

server:
  port: 8888

Структура Git-репозитория следует соглашениям именования Spring Boot: {application-name}-{profile}.yml или {application-name}/{profile}.yml Клиентское приложение нужно настроить: добавить стартовую зависимость и минимальную конфигурацию.

<!-- Add the client dependency -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

# Configure the application to fetch config from the config server

spring:
  application:
    name: order-service

  config:
    import: "optional:configserver:http://localhost:8888"

  cloud:
    config:
      profile: dev

server:
  port: 8080

Динамическое обновление конфигурации без рестарта достигается через перезагружаемые бины с аннотацией @RefreshScope:

package ...;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

Конфиденциальные данные должны быть зашифрованы в файлах конфигурации:

@Service
@RefreshScope
public class PricingService {

    @Value("${pricing.discount.percentage:0}")
    private int discountPercentage;

    // This value updates when config changes, no restart needed

}

curl -X POST http://localhost:8080/actuator/refresh

👉 Java Portal

Значения области видимости финализированы в Java 25. Более чистая альтернатива переменным, привязанным к потоку, с ограниченным временем жизни и хорошей совместимостью с виртуальными потоками.

static final ScopedValue<User> USER = ScopedValue.newInstance();

ScopedValue.where(USER, user)
    .run(() -> UserService.updateUser());

👉 Java Portal

Java-совет : можно использовать List.of() и Set.of() для создания неизменяемых коллекций. ✅ Это быстрый способ создать немодифицируемые списки и множества без использования Collections.unmodifiableList(). #Java #Коллекции 👉 Java Portal

В Java лямбда-выражение создаёт экземпляр функционального интерфейса. Во время выполнения этот экземпляр создаётся с помощью класса LambdaMetaFactory Следующий код на Java создаёт объект Function<String, String>

Function<String, String> f = s -> s.toUpperCase();

Во время выполнения объект создаётся с помощью кода, аналогичного следующему:

@SuppressWarnings("unchecked")
void main() throws Throwable {
    MethodHandles.Lookup lookup;
    lookup = MethodHandles.lookup();

    CallSite callSite;
    callSite = LambdaMetafactory.metafactory(
        lookup,
        "apply",
        MethodType.methodType(Function.class),
        MethodType.methodType(Object.class, Object.class),
        lookup.findStatic(
            getClass(),
            "lambda",
            MethodType.methodType(String.class, String.class)
        ),
        MethodType.methodType(String.class, String.class)
    );

    MethodHandle target;
    target = callSite.getTarget();

    Function<String, String> f;
    f = (Function<String, String>) target.invokeExact();

    String msg;
    msg = f.apply("Hello, World!");

    IO.println(msg);
}

private static String lambda(String s) {
    return s.toUpperCase();
}

При выполнении этот код выведет в консоль HELLO, WORLD! ❤️ 👉 Java Portal

В Java можно ставить метку на выражение, которое уже промечено другой меткой. И так хоть до бесконечности. Полезно? Вряд ли. Стоит ли использовать? Точно нет. Но как факт — это работает Пример:

String question;
to: be: or: not: that: is: the: question = "What?";

out.println(question);

> Код компилируется > Метки (to:, be:, or: и т.д.) игнорируются, если не используются в break или continue Вывод:

What?

Иногда Java действительно говорит с нами стихами 🫢 👉 Java Portal

Этот Dockerfile для Spring Boot создаёт образ, который потребляет на 33% меньше памяти по сравнению с образом, собранным с помощью Buildpacks (рекомендуемый Spring способ сборки Docker-образов) 💪 👉 Java Portal

Spring Boot: можно добавить глобальные метаданные OpenAPI через аннотацию @OpenAPIDefinition. ✅ Её размещают на основном классе приложения Spring Boot или в отдельном конфигурационном классе. #SpringBoot #JavaDev 👉 Java Portal

Для кого-то неожиданно узнать, что Java не конкатенирует строки на этапе выполнения в таком кейсе: String c = "a" + "b"; Что важно: Строка в Java хранится как byte[] + флаг кодировки: 0 — LATIN1 (1 байт на символ, для ASCII экономия памяти) 1 — UTF-16 (2 байта на символ) Строки размещаются в двух областях: - куча - пул строковых констант (SCP) Пример:

String a = "hello", b = "hello";

a == b → true, обе переменные указывают на один объект из пула Пример:

String a = "hello", b = new String("hello");

a == b → false, разные объекты в куче При такой записи:

String c = "a" + "b";

компилятор Java выполняет константную свёртку и подставляет готовое значение:

String c = "ab";

Конкатенации на этапе выполнения нет — это вычисляется на этапе компиляции. но это не работает со строковыми переменными:

java id="xq7v2m"
String a = "a", b = "b", c = a + b;

здесь компилятор Java уже не может сделать константную свёртку, поэтому генерируется вызов через invokedynamic с StringConcatFactory На уровне байткода это реализуется через механизм динамической конкатенации строк (JEP 280 / JEP 357), который выбирает оптимальную стратегию выполнения во время запуска. В ранних версиях вместо этого использовался StringBuilder, где код фактически превращался в цепочку append() и финальный toString(). 👉 Java Portal

На собесе по Java понимание устройства JVM и управления памятью сильно влияет на оценку. Ниже — сжатое покрытие всех 25 тем без воды. 1. Heap vs Stack Heap — аллокация объектов, шарится между потоками. Stack — фреймы методов, локальные переменные, примитивы. Объекты в heap, ссылки — в stack. 2. Сборка мусора GC освобождает недостижимые объекты. Сборщики: Serial, Parallel, CMS (устаревший), G1. Объект попадает под GC при отсутствии достижимости по графу ссылок. 3. Области памяти JVM Heap (Young/Old), Stack, Metaspace (вместо Method Area), Native Stack. Metaspace хранит метаданные классов. 4. Алгоритмы GC Minor GC — Young, Major/Full GC — Old. Mark-and-Sweep, Copying, Mark-Compact. 5. Параметры JVM -Xms, -Xmx — размер heap. -XX:NewRatio — соотношение поколений. GC-логи анализируются для поиска пауз и аллокаций. 6. Утечки памяти Причины: статические коллекции, кеши без очистки, listener’ы. Инструменты: VisualVM, JConsole, Eclipse MAT. 7. OutOfMemoryError Heap overflow, Metaspace overflow, Direct memory. Решения: тюнинг heap, профилинг, оптимизация аллокаций. 8. Типы ссылок Soft — для кешей. Weak — сборка при следующем GC. Phantom — для пост-очистки. 9. ThreadLocal Утечки из-за хранения значений без remove(). Проблема усиливается в пуле потоков. 10. finalize() Непредсказуемый вызов, влияет на GC. Замена — Cleaner или try-with-resources. 11. Direct Memory Off-heap через ByteBuffer.allocateDirect. Контроль сложнее, GC не управляет напрямую. 12. JEP по GC ZGC (JEP 307) — низкие паузы. Shenandoah (JEP 189) — конкурентная очистка. 13. Архитектура JVM ClassLoader, Runtime Data Areas, Execution Engine, JNI. 14. Загрузка классов Loading → Linking → Initialization. Загрузчики: Bootstrap, Platform (бывш. Extension), System. 15. Байткод Инструкции JVM, стековая модель исполнения. Интерпретируется и оптимизируется JIT. 16. JIT-компилятор Горячий код компилируется в машинный. Оптимизации: инлайнинг, удаление мертвого кода. 17. Структура .class Magic number, constant pool, методы, атрибуты. 18. Жизненный цикл потоков NEW → RUNNABLE → BLOCKED/WAITING → TERMINATED. JVM управляет планированием через ОС. 19. JNI Связка с нативным кодом (C/C++). Используется для low-level операций. 20. Профилинг JVM CPU, память, потоки. Инструменты: VisualVM, JConsole. 21. HotSpot Основная реализация JVM. Использует адаптивную оптимизацию и JIT. 22. Манипуляция байткодом ASM, BCEL, Javassist. Применяется в прокси, AOP, фреймворках. 23. Инструменты диагностики jstack — дамп потоков. jmap — heap dump. jstat — статистика GC. 24. Безопасность классов Верификация байткода. Security Manager (устаревший, но концепт важен). 25. Java Memory Model (JMM) Правила видимости и happens-before. Ключевые примитивы: volatile, synchronized. 👉 Java Portal