Git worktree — отличный способ поднять песочницу, куда можно запустить агентов искать решение, пока ты спокойно продолжаешь работу на master или другой ветке. На фото баш-скрипт, который : создаёт новый worktree/ветку под задачку с префиксом ga fix (типа fizzy--fix), а потом gd можно снести всё к чертям, когда закончил.

Если хочешь потыкать у себя — есть удобный gist для копипасты.

👉 Java Portal

Hidden классы в Java. Что скрывают Lambda выражения

С переходом Java на более безопасные и стандартизированные подходы к динамической генерации классов, скрытые (hidden) классы стали ключевым механизмом замены устаревшего Unsafe::defineAnonymousClass

Они решают проблемы доступности, управления жизненным циклом и контроля доступа, особенно актуальные для разработчиков фреймворков и языков на JVM. Хотя скрытые классы пока не полностью заменяют функциональность Unsafe, они лежат в основе ряда важных механизмов, такие как, например, реализация лямбд в JDK.

Подробнее

👉 Java Portal

Spring Boot совет

В тестах на Spring Boot можно без лишних настроек использовать RestTestClient через аннотацию @AutoConfigureRestTestClient

Для TestRestTemplate есть аналогичная аннотация — @AutoConfigureTestRestTemplate

@SpringBootTest
@AutoConfigureRestTestClient
public class PersonControllerTests {

    private static final String API_PATH = "/persons";

    @Test
    void add(@Autowired RestTestClient restTestClient) {
        restTestClient.post().uri(API_PATH)
                .body(Instancio.create(Person.class))
                .exchange()
                .expectStatus().is2xxSuccessful()
                .expectBody(Person.class)
                .value(person -> assertNotNull(person.getId()));
    }
}

👉 Java Portal

LATENCY VS THROUGHPUT

Когда пользователи говорят что приложение «тормозит», причина может быть в двух плоскостях:

* проблема latency (каждый запрос обрабатывается медленно)
* проблема throughput (система забита и не тянет нагрузку)

Иногда это вообще смесь обоих.

Latency — время, которое сервер тратит на выполнение одного запроса от начала до ответа.

Throughput — сколько запросов сервер способен обработать за единицу времени.

Представим, что ты инженер в сервисе доставки пиццы.

Сценарий 1:
Пользователь нажимает «Отправить заказ» и ответ долго крутится — значит высокий latency. Для пользователя это воспринимается как «всё лагает».
Низкий latency = быстрый отклик для каждого конкретного запроса.

Сценарий 2:
Ответы идут примерно по 100 мс — вроде норм. Но если система способна держать только 10 запросов в секунду, а одновременно приходит тысяча, всё разваливается. Это низкий throughput.
Высокий throughput = возможность обслуживать много пользователей одновременно.

Обе метрики критичны, особенно когда система растёт по нагрузке.

* Ответы быстрые, но при всплеске трафика сыпятся таймауты — проблема в throughput.
* Каждый запрос тормозит даже при маленьком трафике — проблема в latency.

» Как чинят проблемы с latency (ускоряем отдельные запросы)

Причины: медленные SQL-запросы, тяжёлые внешние API, прожорливая логика, геолокация сервера и так далее.
Обычно помогают индексы в БД, кэширование, оптимизация кода, CDN, профилирование узких мест.

» Как фиксят проблемы с throughput (увеличиваем пропускную способность)

Обычно упирается в ресурсы. Масштабирование: больше серверов, балансировка нагрузки, кэширование, горизонтальное расширение и т. п.

P.S. Для пользовательских API чаще гонятся за низким latency, а для фоновых задач типа batch-процессинга чаще важнее throughput, чем скорость каждого отдельного задания.

Всё упирается в то, под что именно ты оптимизируешься.

👉 Java Portal

Подсказка по Spring Boot: если нужно, чтобы DTO спокойно игнорировали лишние поля в JSON от клиента и не ломали API, можно повесить @JsonIgnoreProperties(ignoreUnknown = true)

Дано DTO:

public class UserDTO {
    private String name;
    private int age;

    // геттеры и сеттеры
}

Если с клиента прилетает такой JSON:

{
    "name": "Alice",
    "age": 25,
    "extraField": "not expected"
}

Получим ошибку:

UnrecognizedPropertyException: Unrecognized field "extraField"

Эту ситуацию решаем через аннотацию @JsonIgnoreProperties:

@JsonIgnoreProperties(ignoreUnknown = true)
public class UserDTO {
    ...
}

👉 Java Portal

Spring Boot: дорогие по времени API-вызовы можно кешировать через @Cacheable и Redis.

Первый запрос с конкретным ключом идет в реальный API.
Все повторные — из Redis за миллисекунды.

<!-- Добавляем зависимости -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-b

# Базовая настройка в application.yml
spring:
  redis:
    host: localhost
    port: 6379

  cache:
    type: redis

server:
  port: 8080

// Конфигурация Redis (TTL 10 минут)
@Bean
public RedisCacheConfiguration cacheConfig() {
    return RedisCacheConfiguration.defaultCacheConfig()
        .entryTtl(Duration.ofMinutes(10))
        .disableCachingNullValues();
}

// Кэшируем метод сервиса
@Cacheable("users")
public User getUserById(Long id) {
    return userService.fetchUserFromRemoteApi(id);
}

Вот ссылка на демо-проект на Spring Boot (для работы нужен запущенный Redis на порту 6379)

👉 Java Portal

Spring Boot Istio 1.2.0 вышел

Что подтянули в обновлении:

🍃авто-генерация fault-ов
🍃 авто-создание и инжект gateway
🍃 авто-генерация HTTP matches

Детали тут : https://github.com/piomin/spring-boot-istio

👉 Java Portal

Принцип открытости/закрытости (OCP): это принцип из SOLID, который говорит, что классы должны быть открыты для расширения, но закрыты для модификации.

Вместо правки существующей реализации стоит добавлять новое поведение через интерфейсы и наследование в Java, не трогая уже написанный код.

// Плохой способ реализовать генератор отчётов
class ReportGenerator {
    public void generateReport(String type) {
        if (type.equals("PDF")) {
            System.out.println("Generating PDF Report...");
        } else if (type.equals("CSV")) {
            System.out.println("Generating CSV Report...");
        } else if (type.equals("EXCEL")) {
            System.out.println("Generating Excel Report...");
        }
    }
}

// Более правильный вариант

// Определяем интерфейс
interface Report {
    void generate();
}

// Реализации
class PdfReport implements Report {
    public void generate() {
        System.out.println("Generating PDF Report...");
    }
}

class CsvReport implements Report {
    public void generate() {
        System.out.println("Generating CSV Report...");
    }
}

// Используем конкретную реализацию
public class ReportApp {
    public static void main(String[] args) {
        Report report = new PdfReport();
        report.generate();
    }
}

👉 Java Portal

У платформенных потоков в Java есть 6 состояний. У виртуальных потоков их около 20, но они скрыты от нас.

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

Узнаем здесь! 🤭

👉 Java Portal

Java-совет : избегай преждевременной оптимизации.

Сначала сосредоточься на чистом, рабочем коде.

Пиши код, который корректно работает, и в первую очередь закрывает функциональные требования.

// Простейший пример
String helloThere = "Hello " + "there" + "!";
System.out.println(helloThere);

// Эта строка кода читаемая и работает как задумано

// Позже можно подумать об оптимизации через StringBuilder
StringBuilder sb = new StringBuilder();
sb.append("Hello ");
sb.append("there");
sb.append("!");
System.out.println(sb.toString());

👉 Java Portal

Arconia для Spring Boot Dev Services и Observability

В этом посте объясняется, как использовать фреймворк Arconia для улучшения опыта разработки со Spring Boot. Проект совсем свежий и активно развивается. Меня он зацепил одной фичей, которую я люблю в Quarkus, но которой не хватает в Spring Boot. Речь про Dev Services. Если вы работали с Quarkus, то наверняка знаете, о чём речь. Dev Services позволяют автоматически поднимать не сконфигуренные сервисы в dev-режиме и при тестировании. Как и в Quarkus, Arconia базируется на Testcontainers и использует поддержку Spring Boot Testcontainers.

Чтобы разобраться, как Spring Boot работает с Testcontainers, посмотрите статью на эту тему. Если интересуют Dev Services в Quarkus, то вот пост, который фокусируется на автоматизации тестирования в Quarkus.

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

👉 Java Portal

Spring Boot: чтобы сервисы возвращали пагинированный ответ, а не огромный список, можно использовать Page<T> и Pageable.

Без пагинации:

[
  { "id": 1, "name": "John" },
  { "id": 2, "name": "Lia" }
  ...
]

С пагинацией:

{
  "content": [
    { "id": 1, "name": "John" },
    { "id": 2, "name": "Lia" }
    ...
  ],
  "page": {
    "size": 20,
    "number": 0,
    "totalElements": 50213,
    "totalPages": 2511
  }
}

Вместо того чтобы напрямую возвращать Page<T>, можно вернуть кастомный paged response DTO, чтобы не светить типы фреймворка в API.

record PagedResponse<T>(
    List<T> items,
    int page,
    int size,
    long totalElements,
    int totalPages
) {}

И метод контроллера будет выглядеть примерно так:

@GetMapping
public PagedResponse<User> getUsers(Pageable pageable) {
    Page<User> page = repository.findAll(pageable);

    return new PagedResponse<>(
        page.getContent(),
        page.getNumber(),
        page.getSize(),
        page.getTotalElements(),
        page.getTotalPages()
    );
}

👉 Java Portal

Паттерны архитектуры приложений Spring Boot: здесь

Серебряной пули не существует. Когда речь заходит об архитектуре современного приложения, часто можно услышать, что Anemic Domain Model — это плохо, или что Transaction Script — это антипаттерн. Также многие советуют Clean Architecture или Hexagonal Architecture в связке с DDD как «лучшую» или «правильную» архитектуру.

Но бесплатных обедов не бывает. Любое решение всегда приходит со своим набором компромиссов. Важно понимать эти trade-offы и выбирать архитектуру, которая лучше всего подходит под конкретные требования приложения.

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

Может возникнуть вопрос: почему стоит довольствоваться «достаточно хорошей» архитектурой, а не сразу делать «лучшую»?

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

Лично я считаю, что исправлять недоинженеренную систему проще, чем переинженеренную. Добавлять всегда легче, чем убирать.

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

Поэтому лучше начинать с архитектуры «достаточно хорошего уровня» и эволюционировать её по мере развития системы.

Именно это и демонстрируется в данном репозитории: реализация примера приложения с использованием разных архитектурных подходов. Начиная с простой слоистой архитектуры и постепенно переходя к модульному монолиту с DDD и гексагональной архитектурой. В каждом модуле дизайн и архитектура улучшаются за счёт применения лучших практик и паттернов.

👉 Java Portal

Совет по Java: предпочитай инъекцию через конструктор, а не инъекцию в поля.

Инъекция в поле:

@Component
public class UserController {

    @Autowired
    private Logger logger;

    public void createUser(String username) {
        ...
    }
}

// Сложнее тестировать изолированно.

Инъекция через конструктор:

...
private final Logger logger;

@Autowired
public UserController(Logger logger) {
    this.logger = logger;
}

...
// Проще создавать экземпляр для unit-тестов

👉 Java Portal

Топ оконных функций, которые использует каждый data-инженер

1. ROW_NUMBER()
ROW_NUMBER() позволяет пронумеровать строки в рамках группы, что сильно упрощает дедупликацию. Нужно взять последнюю запись по клиенту или первое событие в сессии — решается чисто и без костылей.

2. DENSE_RANK()
Если делаешь лидерборды или бизнес-уровни, эта функция всплывает почти сразу. Она группирует одинаковые значения без пропусков в нумерации — рейтинги получаются понятными даже для нетехнических стейкхолдеров.

3. LAG() / LEAD()
Используются, чтобы посмотреть на предыдущее или следующее значение. Идеально подходит для сравнения сегодняшних продаж со вчерашними или поиска изменений между событиями.

4. SUM() OVER()
Так делаются накопительные суммы без развала запроса. SUM() OVER() позволяет сохранить детализацию по строкам и при этом добавить кумулятивные итоги. Очень удобно в финансовых и событийных пайплайнах.

5. FIRST_VALUE() / LAST_VALUE()
Нужны, когда важен контекст. Помогают взять первое или последнее значение внутри партиции — критично для временной аналитики, например при сравнении стартовых и финальных значений или расчёте метрик жизненного цикла.

👉 Java Portal

Spring Boot: если в коде используется RestTemplate, тесты можно писать, подменяя внешние HTTP-вызовы с помощью MockRestServiceServer.

✅MockRestServiceServer работает за счет перехвата HTTP-запросов.

Дан сервис, который дергает внешний API:

@Service
public class ProductService {

    private final RestTemplate restTemplate;

    public ProductService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String getProductName(long id) {
        Product product = restTemplate.getForObject(
            "https://remoteapi.com/products/{id}",
            Product.class,
            id
        );
        return product.getName();
    }
}

Тест можно реализовать так:

@SpringBootTest
class ProductServiceTest {

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    private ProductService productService;

    private MockRestServiceServer mockServer;

    @BeforeEach
    void setup() {
        mockServer = MockRestServiceServer.createServer(restTemplate);
    }

    @Test
    void shouldReturnProductWhenExternalApiCalled() {
        // Arrange
        mockServer.expect(requestTo("https://remoteapi.com/products/1"))
            .andExpect(method(HttpMethod.GET))
            .andRespond(withSuccess(
                "{\"id\":1,\"name\":\"USB stick\"}",
                MediaType.APPLICATION_JSON
            ));

        // Act
        ProductDto product = productService.getProduct(1L);

        // Assert
        assertThat(product.getName()).isEqualTo("USB stick");

        mockServer.verify();
    }
}

👉 Java Portal

Нашли офигенный способ выучить PostgreSQL в браузере : crunchydata

PostgreSQL-песочница с практическими уроками SQL, транзакциям, индексам, PostGIS и не только

🛌

👉 Java Portal

Java: не пихай бизнес-логику в Stream.peek(). Используй его только для отладки.

Смысл простой: peek() предназначен для легкого дебага и просмотра потока, а не для вычислений или побочных эффектов.

Используй только для легкой отладки

Пример: просмотр (инспекция) потока пайплайна

list.stream()
    .filter(x -> x > 10)
    .peek(x -> System.out.println("Filter: " + x))
    .map(x -> x * 2)
    .peek(x -> System.out.println("Map: " + x))
    .toList();

👉 Java Portal

📱 Держите 6 хороших каналов по искусственному интеллекту и программированию для любого уровня!

Выбирай направление:

📱 Нейросети — @neuro_prompt

🤖 AI-инструменты — @ai_prompt

📱 Python — @python_prompt

🤔 InfoSec & Хакинг — @infosec_prompt

👩‍💻 IT Новости — @it_news

😄 IT Мемы — @it_memes

Промпты, обучение, шпаргалки и полезные ресурсы на каждую тему!

Под капотом многопоточной синхронизации в Java: как потоки договариваются через Mark Word

Синхронизация в Java часто воспринимается как простая языковая конструкция — достаточно использовать ключевое слово synchronized, и код начинает «просто работать».

На практике же на уровне JVM происходит цепочка событий, которую можно проследить до Mark Word — восьмибайтового служебного поля заголовка каждого Java-объекта.

Современные JVM (HotSpot, OpenJ9, GraalVM) не используют фиксированную модель блокировок. Вместо этого они динамически выбирают стратегию синхронизации, исходя из реального поведения потоков и истории использования объекта.

Эта статья предназначена для Java‑разработчиков, которые уже знакомы с многопоточностью и synchronized, но хотят разобраться, как именно JVM управляет блокировками, какие состояния проходит объект и какую роль в этом играет Mark Word.

👉 Java Portal