Java for Beginner
779 subscribers
777 photos
220 videos
12 files
1.31K links
Канал от новичков для новичков!
Изучайте Java вместе с нами!
Здесь мы обмениваемся опытом и постоянно изучаем что-то новое!

Наш YouTube канал - https://www.youtube.com/@Java_Beginner-Dev

Наш канал на RUTube - https://rutube.ru/channel/37896292/
Download Telegram
Что выведет код?

import java.util.*;

public class Task201225 {
public static void main(String[] args) {
List<Number> list = new ArrayList<>();
list.add(10); // Integer
list.add(5.5); // Double
list.add(3); // Integer
list.add(2.0); // Double

Collections.sort(list);

System.out.println(list);
}
}


#Tasks
👍1
Пишите)
🔥4
Вопрос с собеседований

Зачем нужен StampedLock? 🤓

Ответ:

StampedLock предоставляет оптимистичные блокировки чтения, позволяющие читать данные без полного блокирования.

Он быстрее ReadWriteLock, но требует ручной проверки валидности.

Позволяет минимизировать contention при высоких нагрузках.


#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
История IT-технологий сегодня — 23 декабря


ℹ️ Кто родился в этот день

Ро́берт Э́ллиот (Боб) Кан (англ. Robert Elliot Kahn, Bob Kahn; род. 23 декабря 1938, Нью-Йорк)американский инженер-электрик, который вместе с Винтом Серфом впервые предложил протокол управления передачей (TCP) и интернет-протокол (IP) — основные протоколы связи, лежащие в основе Интернета. В 2004 году Кан вместе с Винтом Серфом получил премию Тьюринга за свою работу над TCP/IP.

Михаи́л Леони́дович Гро́мов (род. 23 декабря 1943, Бокситогорск, Ленинградская область) советский, французский и американский математик, доктор физико-математических наук, лауреат Абелевской премии.
Внёс большой вклад в развитие метрической геометрии, симплектической геометрии, римановой геометрии, геометрической теории групп. Большое влияние на многие области математики оказали его исследования в теории гиперболических групп, а также работы, связанные с h-принципом.


🌐 Знаковые события

1947 – Транзистор впервые продемонстрирован в лаборатории Bell Laboratories .


#Biography #Birth_Date #Events #23Декабря
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Мутация тела запроса и ответа в Spring Cloud Gateway: Реактивная работа с потоком данных

В Spring Cloud Gateway тело HTTP запроса или ответа представлено не как статический байтовый массив, а как реактивный поток Flux<DataBuffer>. Это фундаментальное отличие от традиционных синхронных фреймворков, где тело запроса полностью загружается в память перед обработкой.

DataBuffer — это абстракция над байтовым буфером, которая может быть основана на heap memory (byte[]) или direct memory (ByteBuffer). Поток Flux<DataBuffer> представляет собой последовательность таких буферов, которые поступают по мере чтения из сетевого соединения. Это позволяет обрабатывать большие тела запросов, не загружая их полностью в память, что критически важно для производительности при работе с файлами или стриминговыми данными.

Однако многие операции трансформации (JSON модификация, валидация, обогащение) требуют доступа ко всему телу целиком. Это создает фундаментальное противоречие между эффективностью использования памяти и возможностями трансформации. Spring Cloud Gateway предлагает несколько стратегий разрешения этого противоречия.


Архитектура фильтров модификации тела

Фильтры ModifyRequestBody и ModifyResponseBody реализуют паттерн "читай-трансформируй-пиши" (read-transform-write) в реактивном стиле.

Их архитектура включает несколько этапов:
Чтение и буферизация — тело потока собирается в единый DataBuffer с ограничением максимального размера для предотвращения исчерпания памяти.
Декодирование — байтовый буфер преобразуется в объект указанного типа (String, byte[], или кастомный POJO) с использованием configured HttpMessageReader.
Трансформация — применяется функция преобразования, которая получает декодированный объект и возвращает новый объект.
Кодирование — преобразованный объект сериализуется обратно в байты.
Замена тела — оригинальный поток тела заменяется новым потоком, содержащим трансформированные данные.


Критически важным аспектом является управление памятью: оригинальный DataBuffer должен быть освобожден после использования, иначе произойдет утечка памяти. В реактивном контексте это достигается через операторы doFinally или использование DataBufferUtils.release().


Декодирование тела в реактивном контексте


Типы декодирования и их ограничения
Декодирование тела запроса или ответа — это процесс преобразования байтового потока в объект Java. Spring Cloud Gateway поддерживает несколько стратегий декодирования, каждая со своими характеристиками производительности и использования памяти.

Строковое декодирование наиболее простое, но и наиболее затратное по памяти. Весь буфер преобразуется в строку, что для больших тел (мегабайты и более) может привести к значительному потреблению памяти. Однако для типичных JSON API с телами в несколько килобайт это вполне приемлемый подход.


// Теоретический пример: строковое декодирование
Flux<DataBuffer> bodyFlux = exchange.getRequest().getBody();
Mono<String> bodyString = DataBufferUtils.join(bodyFlux, maxInMemorySize)
.map(buffer -> {
byte[] bytes = new byte[buffer.readableByteCount()];
buffer.read(bytes);
DataBufferUtils.release(buffer);
return new String(bytes, StandardCharsets.UTF_8);
});


Потоковое декодирование JSON использует парсеры, способные обрабатывать поток байтов инкрементально, без полной буферизации. Например, Jackson может парсить JSON по мере поступления данных, генерируя события (SAX-подобный подход) или строя объектную модель частично. Это значительно снижает потребление памяти, но ограничивает возможности трансформации — нельзя модифицировать то, что еще не прочитано, или то, что уже было записано.

Бинарное декодирование сохраняет тело как byte[] без попытки интерпретации. Это полезно для проксирования бинарных данных (изображения, файлы) или когда трансформация работает на байтовом уровне (шифрование, сжатие).


#Java #middle #Spring_Cloud_Gateway
👍1
Ограничение размера буфера и защита от переполнения

Критически важным аспектом безопасности при работе с телами запросов является защита от атак типа "отказ в обслуживании" через отправку чрезмерно больших тел. Spring Cloud Gateway предоставляет конфигурационный параметр maxInMemorySize, который ограничивает максимальный размер тела, которое будет полностью буферизовано в памяти.


Когда размер тела превышает этот лимит, применяется одна из двух стратегий:
Частичная буферизация с отказом — запрос отклоняется с ошибкой 413 (Payload Too Large) или 400 (Bad Request). Это безопасный, но не всегда желаемый подход.
Дисковая буферизация — данные временно записываются на диск, что позволяет обрабатывать большие тела, но с значительным снижением производительности и требованием к дисковому пространству.


Правильная настройка maxInMemorySize требует баланса между безопасностью и функциональностью. Типичные значения для JSON API — от 256KB до 10MB, в зависимости от специфики приложения. Для загрузки файлов могут потребоваться большие значения или специализированные обработчики, которые работают с потоком без полной буферизации.


Трансформация JSON → JSON: архитектурные подходы

Дерево против потоковой обработки
Трансформация JSON может быть реализована двумя принципиально разными подходами: построение полного дерева объектов (DOM-подобный подход) или потоковая обработка (SAX-подобный подход).

Подход на основе дерева объектов предполагает полное чтение JSON в память, построение объектной модели (например, Jackson JsonNode), модификацию этой модели и сериализацию обратно в JSON. Этот подход предоставляет максимальную гибкость — можно произвольно модифицировать любую часть документа, добавлять, удалять или изменять поля. Однако он требует значительного объема памяти и времени на построение и сериализацию дерева.

// Теоретический пример: трансформация через JsonNode
Function<JsonNode, JsonNode> transformer = root -> {
// Модификация дерева
if (root.has("user")) {
((ObjectNode) root.get("user")).put("processedBy", "gateway");
}
return root;
};


Потоковый подход обрабатывает JSON как последовательность токенов (начало объекта, имя поля, значение, конец объекта). Модификации ограничены — можно фильтровать поля, переименовывать их (если имя известно заранее), но нельзя произвольно изменять структуру или добавлять новые поля на основе значений других полей. Преимущество — минимальное использование памяти и высокая производительность.

В контексте Gateway выбор подхода зависит от требований к трансформации. Для простых операций (добавление стандартных полей, удаление чувствительных данных) потоковый подход предпочтительнее. Для сложных трансформаций, зависящих от значений полей, необходим подход на основе дерева.


Паттерны трансформации JSON

Существует несколько типовых паттернов трансформации JSON, которые часто применяются в API Gateway:
Обогащение (enrichment) — добавление новых полей в запрос или ответ. Например, Gateway может добавлять метаданные (время обработки, идентификатор запроса) или вычисленные значения (хеш тела для проверки целостности).
Санитизация (sanitization) — удаление или маскирование чувствительных данных. Это может включать маскирование паролей, токенов, персональных данных перед логированием или передачей downstream сервисам.
Нормализация (normalization) — приведение данных к стандартному формату. Например, преобразование различных форматов дат к единому стандарту, нормализация телефонных номеров или email адресов.
Агрегация (aggregation) — объединение данных из нескольких источников в единый ответ. Хотя полная агрегация обычно выходит за рамки Gateway, простые случаи (добавление заголовков в тело ответа) могут обрабатываться на этом уровне.
Валидация (validation) — проверка структуры и содержимого JSON согласно схеме. Gateway может отклонять некорректные запросы до их достижения бизнес-логики, уменьшая нагрузку на backend.



#Java #middle #Spring_Cloud_Gateway
👍1
Санитизация и обогащение данных

Принципы санитизации в Gateway
Санитизация (очистка) данных — это процесс удаления или маскирования чувствительной информации из запросов и ответов.

В контексте API Gateway санитизация выполняет несколько важных функций:

Защита конфиденциальных данных — предотвращение утечки паролей, токенов, персональных данных через логи или в downstream сервисы, которые не должны иметь к ним доступ.
Соответствие требованиям регуляторов — GDPR, HIPAA и другие регуляторы требуют минимализации сбора и обработки персональных данных.
Упрощение отладки — логи, содержащие маскированные данные, безопаснее для использования в разработке и поддержке.


Теоретически, санитизация должна быть идемпотентной — многократное применение не должно изменять уже санитизированные данные. Это важно в цепочках обработки, где данные могут проходить через несколько фильтров или сервисов.

Стратегии обогащения данных


Обогащение данных — противоположная санитизации операция: добавление информации к запросу или ответу.

Обогащение может быть основано на:
Статических данных — константы, версии API, идентификаторы окружения. Эти данные известны на этапе конфигурации Gateway.
Динамических данных, вычисляемых из запроса — хеши тела, размер содержимого, нормализованные заголовки. Эти данные вычисляются на основе содержимого запроса.
Данных из внешних источников — информация о пользователе из базы данных, геолокация по IP, рейтинги безопасности. Эти данные требуют внешних вызовов, что увеличивает задержку.
Данных из контекста выполнения — идентификаторы трассировки, временные метки, идентификаторы экземпляра Gateway. Эти данные генерируются в процессе обработки запроса.


Архитектурно важно различать обогащение, необходимое для downstream сервисов (например, добавление идентификатора пользователя), и обогащение для мониторинга и логирования (например, добавление времени обработки). Первое должно передаваться в запросе к backend, второе — только в метаданных Gateway.


Валидация схем и обработка ошибок

Валидация JSON против схемы — это проверка, что структура и типы данных в JSON соответствуют предопределенной спецификации.

В контексте Gateway валидация выполняет несколько функций:
Защита backend сервисов — отклонение некорректных запросов до их достижения бизнес-логики.
Улучшение качества API — предоставление клиентам детальных сообщений об ошибках при несоответствии схеме.
Документирование API — схемы служат формальной спецификацией ожидаемых данных.


Теоретически, валидация может быть строгой (отклонять любые дополнительные поля) или нестрогой (разрешать дополнительные поля). Выбор зависит от политики API: строгая валидация обеспечивает лучшую обратную совместимость и защиту от ошибок, но менее гибка для эволюции клиентов.

Реактивная реализация валидации сталкивается с проблемой: для валидации по схеме обычно требуется полный доступ к документу, что противоречит принципам потоковой обработки.


Решения включают:
Двухэтапная валидация — быстрая потоковая проверка синтаксиса и базовой структуры, затем (при необходимости) полная валидация по схеме.
Ленивая валидация — валидация только тех частей документа, которые фактически используются в трансформации.
Валидация в downstream сервисах — Gateway выполняет только базовую проверку, полная валидация делегируется backend.



#Java #middle #Spring_Cloud_Gateway
👍1
Архитектура обработки ошибок валидации

Когда валидация или трансформация завершается ошибкой, Gateway должен предоставить клиенту информативный, но безопасный ответ.


Архитектура обработки ошибок включает несколько компонентов:
Классификация ошибок — различение синтаксических ошибок (невалидный JSON), структурных ошибок (несоответствие схеме) и семантических ошибок (значения вне допустимого диапазона).
Форматирование ответов об ошибках — структурированные ответы (например, JSON с полями error, message, details) предпочтительнее простого текста.
Контекстуализация ошибок — включение в ответ информации о том, какая часть запроса вызвала ошибку (путь в JSON, имя поля).
Логирование для отладки — сохранение полной информации об ошибке (включая оригинальный запрос) в логах для последующего анализа, но не раскрытие её клиенту.



Подмешивание дополнительных данных в ответы

Архитектурные паттерны обогащения ответов

Подмешивание (инжекция) дополнительных данных в ответы backend сервисов — это мощный паттерн, который позволяет Gateway добавлять информацию без модификации самих сервисов.

Теоретически, существует несколько подходов к реализации этого паттерна:
Инкрементальное обогащение — Gateway добавляет новые поля в существующий JSON ответ. Этот подход требует полного парсинга и ресериализации ответа, но предоставляет максимальную гибкость.
// Теоретический пример: добавление поля в ответ
Function<String, String> responseTransformer = originalJson -> {
// Парсинг JSON, добавление поля, сериализация обратно
JsonNode root = objectMapper.readTree(originalJson);
((ObjectNode) root).put("gatewayProcessed", true);
return objectMapper.writeValueAsString(root);
};


Обёртывание (wrapping) — Gateway помещает оригинальный ответ в новый объект с дополнительными полями.

Например:
{
"data": { /* оригинальный ответ */ },
"metadata": { "processedBy": "gateway", "timestamp": "..." }
}


Этот подход проще в реализации (не требует модификации оригинального JSON), но меняет структуру ответа, что может нарушить контракты с клиентами.

Заголовочное обогащение — данные добавляются в заголовки HTTP, а не в тело. Это самый эффективный подход (не требует модификации тела), но ограничен типом данных (строковые значения) и может не поддерживаться всеми клиентами.

Согласованность и атомарность обогащения

При обогащении ответов важно обеспечить согласованность данных. Например, если Gateway добавляет поле с хешем тела, этот хеш должен вычисляться на основе уже обогащенного тела, что создает циклическую зависимость.

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

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

Оптимизация производительности обогащения

Обогащение ответов, особенно для больших тел, может существенно влиять на производительность Gateway.

Оптимизационные стратегии включают:
Ленивое обогащение — вычисление дополнительных данных только при необходимости (например, только для определенных маршрутов или типов контента).
Кэширование промежуточных результатов — если обогащение использует внешние данные (информация о пользователе), эти данные могут быть кэшированы.
Параллельная обработка — если обогащение требует нескольких независимых операций (вычисление хеша, добавление метаданных, нормализация), они могут выполняться параллельно.
Потоковое обогащение — для определенных типов обогащения (добавление префикса/суффикса, простые замены) можно использовать потоковую обработку без полной буферизации.



#Java #middle #Spring_Cloud_Gateway
👍1
Что выведет код?

import java.util.*;
import java.util.stream.*;

public class Task231225 {
public static void main(String[] args) {
LinkedList<Integer> list = new LinkedList<>();
list.add(1);
list.add(2);
list.add(3);

Stream<Integer> stream = list.stream();
list.add(4);

System.out.println(stream.count());
}
}


#Tasks
👍1
Варианты ответа:
Anonymous Quiz
7%
0
14%
3
29%
4
50%
Исключение
👍1
Вопрос с собеседований

Что такое CAS-операция? 🤓

Ответ:

Compare-And-Swap
— атомарная операция на уровне процессора.

Сравнивает текущее значение с ожидаемым и обновляет только при совпадении. Лежит в основе атомарных классов Java.

Позволяет создавать неблокирующие алгоритмы.


#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1