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

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

Наш канал на RUTube - https://rutube.ru/channel/37896292/
Download Telegram
Правильное применение

break
- Используйте, когда нужно досрочно выйти из цикла (например, поиск элемента в списке).
- Пример: Поиск числа в массиве.

int[] numbers = {1, 2, 3, 4, 5};
int target = 3;
boolean found = false;
for (int num : numbers) {
if (num == target) {
found = true;
break;
}
}
System.out.println("Найдено: " + found);


continue
- Используйте, чтобы пропустить ненужные случаи (например, игнорировать пустые строки).
- Пример: Суммирование только положительных чисел.

int sum = 0;
for (int i = -2; i <= 3; i++) {
if (i <= 0) {
continue;
}
sum += i;
}
System.out.println("Сумма: " + sum); // 1 + 2 + 3 = 6



Метки
- Используйте в вложенных циклах, когда нужно влиять на внешний цикл.
- Пример: Поиск в матрице.

int[][] matrix = {{1, 2}, {3, 4}};
outer: for (int row = 0; row < matrix.length; row++) {
for (int col = 0; col < matrix[row].length; col++) {
if (matrix[row][col] == 3) {
System.out.println("Найдено в строке " + row + ", столбце " + col);
break outer;
}
}
}


Рекомендации
- Избегайте меток, если возможно — используйте методы для упрощения кода.
- Документируйте метки комментариями, так как они делают код сложнее.
- Тестируйте циклы на бесконечность или пропуски.


Работа под капотом

Компиляция в байт-код
- break: Компилируется в инструкцию goto для перехода к концу цикла.
- continue: Компилируется в goto для возврата к началу цикла (проверке условия).
- Метки: Метка становится меткой в байт-коде, а break/continue с меткой — goto к этой метке.


Пример break в цикле:
while (true) {
if (condition) break;
}

Байт-код (упрощенно):
loop:
if condition goto end
goto loop
end:


Память и стек
- break и continue не влияют напрямую на память, но прерывают или пропускают код, экономя ресурсы.
- Вложенные циклы с метками используют стек вызовов для локальных переменных.


Оптимизация в JVM
- JIT-компилятор может встраивать циклы с break/continue, оптимизируя переходы.
- В бесконечных циклах с break JVM может оптимизировать, если видит частый выход.


Ошибки в памяти
- Бесконечные циклы без break могут переполнить стек или кучу.
- Неправильные метки могут привести к неожиданным переходам.

#Java #для_новичков #beginner #break #continue
👍5
Apache Kafka

Producer — гарантии, производительность, транзакции


Apache Kafka Producer — это клиентская компонента, ответственная за отправку сообщений в Kafka-кластер.

Основные конфиги: acks, linger.ms, batch.size, compression.type, buffer.memory
Продюсер настраивается через свойства в Properties объекте (в Java/Scala) или аналогичные в других клиентах. Эти конфиги определяют баланс между latency, throughput и durability.

- acks: Определяет уровень подтверждения от брокера. Возможные значения: 0 (fire-and-forget, нет подтверждения, минимальная latency, но возможна потеря данных при сбое), 1 (подтверждение от лидера, данные записаны на диск лидера, но не реплицированы), all (или -1, подтверждение после репликации на все ISR, максимальная durability). В памяти продюсера: при acks=all запрос блокируется до получения подтверждения от min.insync.replicas брокеров. Это влияет на throughput: acks=0 дает миллионы сообщений/сек, но без гарантий; acks=all снижает до сотен тысяч из-за ожидания репликации. Нюанс: при acks=all, если ISR сокращается (например, из-за лага фолловеров), продюсер может бросить MetadataException, требуя ручного вмешательства.

- linger.ms: Время ожидания перед отправкой батча (по умолчанию 0). Продюсер аккумулирует сообщения в памяти (в RecordAccumulator), группируя по партициям. Если батч не заполнен в течение linger.ms, он отправляется принудительно. Это trade-off: высокое значение (например, 5-10 мс) увеличивает размер батча, амортизируя network overhead, но повышает latency. В памяти: таймер на основе ScheduledExecutorService проверяет батчи; overhead — минимальный, но при высоком linger.ms память может заполняться, если трафик низкий.

- batch.size: Максимальный размер батча в байтах (по умолчанию 16 КБ). Когда батч достигает этого размера, он отправляется немедленно, игнорируя linger.ms. В памяти: каждый батч — это Deque<ProducerBatch> в RecordAccumulator, где ProducerBatch содержит ByteBuffer для сериализованных записей. Нюанс: слишком большой batch.size (например, 1 МБ) увеличивает память (buffer.memory), но снижает I/O на брокере; малый — приводит к частым мелким запросам, увеличивая CPU на serialization и network.

- compression.type: Тип сжатия (none, gzip, snappy, lz4, zstd). Сжатие происходит в памяти продюсера перед добавлением в батч: сериализованные записи компрессируются в ByteBuffer. Это снижает объем данных на сети/диске, но добавляет CPU overhead. Подробнее в senior-нюансах ниже.

- buffer.memory: Общий размер буфера в памяти для несент батчей (по умолчанию 32 МБ). Это off-heap память (DirectByteBuffer), чтобы избежать GC. Если буфер заполнен, send() блокируется (configurable via max.block.ms). Нюанс: при высоком трафике и медленной сети буфер может переполниться, вызывая ProducerFencedException в транзакционных режимах; мониторьте метрики bufferpool-usage.

В памяти продюсера: основной компонент — RecordAccumulator, который держит Map<TopicPartition, Deque<ProducerBatch>>. Каждое send() сериализует ProducerRecord, вычисляет партицию (via Partitioner), добавляет в батч. Отдельный Sender thread (в KafkaProducer) периодически проверяет батчи и отправляет ProduceRequest через NetworkClient (NIO-based).


#Java #middle #Kafka #Produser
👍3
Idempotence: enable.idempotence=true, гарантии без дублей

Idempotent producer обеспечивает exactly-once семантику без дубликатов при ретреях. Включается via enable.idempotence=true, что implicitly устанавливает acks=all, retries>0, max.in.flight.requests.per.connection=5 (или меньше).

Как работает: каждому продюсеру присваивается уникальный producer.id (PID) от брокера при init. Каждому батчу добавляется sequence number (начиная с 0 per partition). Брокер хранит last sequence per PID/partition и отвергает дубликаты (если sequence уже обработан). При ретрее продюсер переотправляет с тем же sequence.

В памяти: продюсер держит Map<TopicPartition, Integer> для sequences. Overhead: минимальный, но требует стабильного соединения (если connection drops, может потребоваться reinitialization). Гарантии: at-least-once becomes exactly-once для одной сессии; не покрывает множественные продюсеры или app restarts (для этого — transactions).

Нюанс: idempotence не влияет на ordering, если max.in.flight=1; но по умолчанию позволяет до 5 in-flight, что может нарушить order (см. senior-нюансы).


Transactions (EOS): transactional.id, initTransactions(), ограничения и caveats

Transactions предоставляют exactly-once semantics (EOS) через топики, включая atomicity: все или ничего для группы send(). Включается via transactional.id (уникальный ID, persistent across restarts).

Процесс: producer.initTransactions() регистрирует PID с брокером (via InitProducerIdRequest), устанавливая epoch. Затем beginTransaction(), send()..., commitTransaction() или abortTransaction(). В commit брокер пишет маркеры (commit/abort) в логи, делая транзакцию видимой для потребителей с isolation.level=read_committed.

В памяти: продюсер держит TransactionManager, который тракает открытые транзакции, pending batches. Batches помечаются transactionally; overhead — дополнительные метаданные в ProduceRequest.

Ограничения: только для idempotent producers; max.in.flight=1 (принудительно, чтобы сохранить ordering); нельзя смешивать transactional и non-transactional send в одном продюсере. Caveats: timeout via transaction.timeout.ms (по умолчанию 60 сек), после чего транзакция фенсится (ProducerFencedException). При restart с тем же transactional.id старый PID фенсится, позволяя продолжить. Нюанс: в кластере с downtime контроллера initTransactions() может блокироваться; для EOS в Streams используйте processing.guarantee=exactly_once.


Partitioner: кастомный и дефолтный


Partitioner определяет, в какую партицию идет запись. Дефолтный (DefaultPartitioner): если key=null, round-robin; если key не null, hash(key) % num_partitions (murmur2 hash для consistency).

Кастомный: implement Partitioner interface (partition() method). Полезно для affinity (например, все orders пользователя в одну партицию для ordering). В памяти: вызывается синхронно в send(), overhead — от hash computation.

Нюанс: плохой partitioner может привести к skew (горячие партиции), снижая throughput; всегда учитывайте num_partitions changes.


Retry/backoff политика

Retries (по умолчанию 2147483647) и retry.backoff.ms (100 мс) управляют повторными попытками при transient errors (например, NotLeaderForPartitionException).

Как работает: Sender thread ловит retriable exceptions, backoff (exponential с jitter), затем retry. В idempotence/transactions retry прозрачен, без дубликатов.

В памяти: pending requests в InFlightRequests Map, с timeout per request. Нюанс: высокие retries могут маскировать проблемы (например, network flaps), увеличивая latency; мониторьте retry-rate метрики.


#Java #middle #Kafka #Produser
Метрики: request-latency, batch-size-avg

Продюсер экспортирует JMX метрики via KafkaProducer.metrics().

Ключевые:
- request-latency-avg: Средняя latency ProduceRequest (от send до response). Включает network + broker processing. Высокая — указывает на bottleneck (медленная сеть, перегруженный брокер).
- batch-size-avg: Средний размер батча в байтах. Идеально близко к batch.size для efficiency; низкий — увеличьте linger.ms.

Другие: record-queue-time-avg (время в accumulator), buffer-bytes (используемая память). Нюанс: используйте MetricsReporter для интеграции с Prometheus; в production мониторьте per-partition метрики для detection skew.


Пример кода

Вот расширенный пример на Java, демонстрирующий idempotence и transactions:
import org.apache.kafka.clients.producer.*;
import java.util.Properties;

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all");
props.put("enable.idempotence", "true");
props.put("transactional.id", "order-tx-1");

try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
producer.initTransactions();
producer.beginTransaction();
ProducerRecord<String, String> record = new ProducerRecord<>("orders", "key", "value");
producer.send(record);
producer.commitTransaction();
} catch (ProducerFencedException e) {
// Handle fencing, e.g., abort and reinitialize
} catch (KafkaException e) {
// Abort on error
producer.abortTransaction();
}


В production добавьте Callback в send() для async handling, и flush() перед close().

Нюансы: max.in.flight.requests.per.connection влияние на ordering, компрессия: zstd vs snappy vs lz4, когда idempotence недостаточно и нужна транзакция

- max.in.flight.requests.per.connection: По умолчанию 5, позволяет параллельные запросы по одному соединению для throughput. Но если >1 и retry происходит, ordering может нарушиться: failed batch retry после successful последующих. В idempotence это разрешено, но для strict ordering установите=1 (снижает throughput на 20-50%). В transactions forcibly=1.

- Компрессия: zstd — лучший ratio (до 5x), но высокий CPU (для высоких данных); snappy — быстрый, низкий CPU, средний ratio (2-3x), идеален для real-time; lz4 — баланс, faster than gzip. В памяти: compression в отдельном thread pool (если compression.type set), overhead — allocate temp buffers. Тестируйте: для text-heavy — zstd; binary — snappy.

- Когда idempotence недостаточно: Idempotence покрывает retries в одной сессии, но не atomicity across topics/partitions или app failures (дубликаты при restart). Транзакции нужны для EOS в multi-topic writes (например, order + inventory update) или с Kafka Streams. Caveat: transactions добавляют 10-20% overhead из-за маркеров и fencing. Используйте если SLA требует no duplicates/loss even on crashes; иначе idempotence достаточно для 99% случаев.


#Java #middle #Kafka #Produser
👍2
Основы ООП в Java

Глава 1. Классы и объекты

Состояние и поведение: поля и методы


Объектно-ориентированное программирование — это подход, где программа строится вокруг объектов, которые представляют реальные сущности (например, машину, человека или счет в банке).

Java — это чисто объектно-ориентированный язык, где всё (кроме примитивных типов) является объектом. ООП помогает писать масштабируемый код, который легко расширять и поддерживать.
Классы и объекты: Основные понятия


Класс: Это шаблон или "чертеж" для создания объектов. Класс определяет, какие данные (состояние) и действия (поведение) будут у объектов.
Объект: Это экземпляр класса — конкретная реализация шаблона. Например, класс Car может описывать автомобили в общем, а объект — конкретный автомобиль, такой как "красный Ford с номером ABC123".
Пример: Представьте класс Person (Человек). Он может иметь состояние (имя, возраст) и поведение (ходить, говорить). Объекты этого класса — конкретные люди, такие как "Алексей, 35 лет".



Состояние: Поля (Fields)

Состояние объекта определяется полями — переменными внутри класса, которые хранят данные. Поля описывают характеристики объекта.


Объявление полей: Поля объявляются в теле класса, вне методов. Они могут быть примитивными типами (int, double) или ссылочными (String, другие классы).

Модификаторы доступа: Чтобы защитить данные, используйте модификаторы:
private: Доступны только внутри класса (рекомендуется для полей).
public: Доступны везде (избегайте для полей, чтобы сохранить инкапсуляцию).
protected: Доступны в классе и подклассах.
Без модификатора (default): Доступны в пакете.


Пример класса с полями:

public class Person {
// Поля (состояние)
private String name; // Имя человека
private int age; // Возраст человека
}

Здесь name и age — поля, хранящие состояние объекта.
Они private, чтобы внешний код не мог напрямую изменять их (инкапсуляция).



Поведение: Методы (Methods)

Поведение объекта определяется методами — функциями внутри класса, которые выполняют действия с данными или изменяют состояние.

Объявление методов: Методы имеют сигнатуру: модификатор, тип возвращаемого значения, имя, параметры в скобках, тело в фигурных скобках.

Типы методов:
Конструкторы: Специальные методы для инициализации объектов. Имя совпадает с именем класса, нет типа возвращаемого значения.
Обычные методы: Выполняют действия, могут возвращать значение или нет (void).
Геттеры и сеттеры: Методы для чтения (get) и записи (set) полей, чтобы обеспечить контролируемый доступ.


Пример с методами:
public class Person {
private String name;
private int age;

// Конструктор (инициализирует состояние)
public Person(String name, int age) {
this.name = name; // this — ссылка на текущий объект
this.age = age;
}

// Метод (поведение): Вывод информации
public void introduce() {
System.out.println("Привет, меня зовут " + name + ", мне " + age + " лет.");
}

// Геттер для возраста
public int getAge() {
return age;
}

// Сеттер для возраста (с проверкой)
public void setAge(int age) {
if (age > 0) {
this.age = age;
} else {
System.out.println("Возраст не может быть отрицательным!");
}
}
}

Конструктор: Person(String name, int age) устанавливает начальное состояние.
Метод introduce(): Выводит информацию (поведение).
Геттер getAge(): Возвращает значение поля.
Сеттер setAge(int age): Изменяет поле с проверкой (инкапсуляция).



#Java #для_новичков #beginner #class #object
👍4
Создание и использование объектов

Объекты создаются с помощью оператора new.

Пример в методе main:

public class Main {
public static void main(String[] args) {
// Создание объекта
Person person1 = new Person("Алексей", 35);

// Вызов метода
person1.introduce(); // Вывод: Привет, меня зовут Алексей, мне 35 лет.

// Использование геттера и сеттера
System.out.println("Текущий возраст: " + person1.getAge());
person1.setAge(36);
System.out.println("Новый возраст: " + person1.getAge());
}
}

new Person("Алексей", 35): Создает объект и вызывает конструктор.
person1.introduce(): Вызывает метод объекта.



Как создать это в IntelliJ IDEA


Создайте класс:

В проекте щелкните правой кнопкой на src → New → Java Class.
Назовите Person и добавьте код выше.


Создайте класс Main:
Аналогично создайте Main с методом main.

Запустите:
Правой кнопкой на Main.java → Run 'Main.main()'.


Полезные советы для новичков

Используйте this: Для отличия полей класса от параметров методов (например, this.name = name;).
Конструкторы по умолчанию: Если конструктор не указан,
Java создает пустой конструктор public Person() {}.
Множественные конструкторы: Можно иметь несколько конструкторов (перегрузка), перегрузка, но об этом в следующем уроке.
Практика инкапсуляции: Всегда делайте поля private и предоставляйте доступ через геттеры/сеттеры.
Проверки в сеттерах: Добавляйте логику, чтобы избежать некорректных данных.



#Java #для_новичков #beginner #class #object
👍3
Apache Kafka

Consumer — группы, оффсеты, ребалансинг


Apache Kafka Consumer — это клиент, ответственный за чтение и обработку сообщений из топиков.


Group coordinator, heartbeat, session.timeout.ms

Consumer groups позволяют нескольким потребителям параллельно обрабатывать топик, распределяя партиции между ними для load balancing. Группа идентифицируется по group.id; каждый потребитель в группе — member с уникальным member.id (генерируется при join).

Group coordinator это брокер, выбранный для управления группой (hash(group.id) % num_brokers определяет координатора).

Координатор хранит состояние группы: members, assignments партиций, committed offsets (в внутренней теме __consumer_offsets).

В памяти брокера: состояние в GroupMetadataManager, с off-heap структурами для efficiency; offsets реплицированы как обычные записи.


Потребители поддерживают связь через heartbeat'ы: отдельный Heartbeat thread в KafkaConsumer посылает HeartbeatRequest каждые heartbeat.interval.ms (по умолчанию 3 сек) к координатору. Координатор отвечает, подтверждая membership. Если heartbeat не приходит в течение session.timeout.ms (по умолчанию 45 сек), member считается dead, триггеря rebalance.

В памяти потребителя: Coordinator хранит generation (epoch группы), member.id. Нюанс: высокое session.timeout.ms позволяет пережить GC-паузы или network glitches, но замедляет detection failures; низкое — приводит к frequent rebalances. При poll() heartbeat отправляется implicitly, если interval истек.


Offset management: авто-коммит vs ручной (commitSync, commitAsync)

Offsets тракают прогресс чтения: для каждой партиции — committed offset, с которого группа начнет после restart/rebalance.

Авто-коммит: Включается enable.auto.commit=true (default), с auto.commit.interval.ms (5 сек). При poll() потребитель аккумулирует processed offsets в памяти (OffsetAndMetadata), и каждые interval commit'ит их async. В памяти: Map<TopicPartition, OffsetAndMetadata> в KafkaConsumer, flushed periodically.

Trade-offs: удобно, но риск at-most-once (если crash после обработки, но до commit — потеря) или at-least-once (duplicates если commit после обработки, но перед full ack). Не используйте для critical processing.

Ручной коммит: enable.auto.commit=false. commitSync() — synchronous, блокирует до подтверждения от координатора (via OffsetCommitRequest), обеспечивает durability, но увеличивает latency. commitAsync() — asynchronous, с optional callback для error handling; faster, но требует manual retry на failures.

В памяти: offsets буферизуются до commit; при commitSync все in-flight commits ждут. Нюанс: commit только assigned партиций; при rebalance revoked offsets commit'ятся в onPartitionsRevoked. Для EOS используйте с transactions (read-process-write pattern).


#Java #middle #Kafka #Consumer
👍5
Rebalancing: Range, RoundRobin, Cooperative Sticky

Rebalancing — процесс перераспределения партиций при changes в группе (join/leave, failures). Триггерится coordinator'ом: все members посылают JoinGroupRequest, coordinator выбирает leader (первый joiner), который вычисляет assignments via assignor.

Assignors (partition.assignor.class):
- Range: Дефолт до 2.4. Партиции сортируются, делятся по range (например, для 10 partitions, 3 consumers: 0-3,4-6,7-9). Skew если num_partitions не делится evenly.
- RoundRobin: Распределяет round-robin для fairness, минимизируя skew.
- Cooperative Sticky (default с 2.4): Эволюция Sticky (минимизирует перемещения партиций). Cooperative — incremental: вместо full revoke-assign, использует несколько раундов (Eager vs Cooperative protocol). В первом раунде revoke только conflicting partitions, затем assign. Снижает downtime: consumers продолжают process revoked-later.

В памяти coordinator'а: хранит previous assignments для sticky. Нюанс: custom assignor implement ConsumerPartitionAssignor; для large groups (>100) rebalance может занять секунды из-за sync.


Static membership


Static membership избегает rebalance при restarts: group.instance.id (уникальный static ID per instance). При join с тем же ID, coordinator распознает как restart, не триггеря rebalance (если assignments unchanged).

В памяти: coordinator тракает instances в GroupMetadata. Нюанс: полезно для stateful consumers (с local state); но если instance меняет host, rebalance все равно. Комбинируйте с cooperative для minimal disruption.


Pause/Resume и backpressure

Для контроля flow: consumer.pause(Collection<TopicPartition>) останавливает fetch для партиций, но poll() продолжает heartbeat. resume() возобновляет. Используйте для backpressure: если downstream slow, pause до обработки backlog.

В памяти: paused partitions в Set<TopicPartition> в Fetcher; fetch requests skip them. Нюанс: paused не влияет на rebalance; при длительном pause lag растет, рискуя eviction из группы если max.poll.interval.ms истекает.

Backpressure: мониторьте lag, dynamically pause если queue full. В Streams это built-in via task pausing.


Метрики: lag, rebalance-latency

Consumer экспортирует метрики via KafkaConsumer.metrics():
- consumer-lag: Records-lag-max — максимальный lag (LEO - committed offset) по партициям. Вычисляется via FetchRequest с metadata. Высокий lag указывает на slow processing; мониторьте per-partition.
- rebalance-latency-avg: Среднее время rebalance (от trigger до completion). Включает join, sync, assign. Высокое — из-за large groups или slow assignors.

Другие: poll-time, commit-latency. Нюанс: используйте ConsumerMetrics для JMX; в production alert на lag > threshold или frequent rebalances.


#Java #middle #Kafka #Consumer
👍5
Пример кода

Пример на Java с subscribe и RebalanceListener для handling revoke/assign:
import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.TopicPartition;
import java.util.*;

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "my-group");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("enable.auto.commit", "false"); // Manual commit

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("topic"), new ConsumerRebalanceListener() {
@Override
public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
// Commit offsets before losing partitions
commitOffsets(); // Custom method to commit processed offsets
}

@Override
public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
// Restore state or seek to offsets
/* warm-up: e.g., load local state for partitions */
}
});

try {
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
// Process records
consumer.commitAsync(); // Or commitSync for sync
}
} finally {
consumer.close();
}


В production: implement commitOffsets() с Map<TopicPartition, OffsetAndMetadata>; handle exceptions в listener.


Нюансы

- Избегание frequent rebalancing: Frequent rebalances (от scaling, GC, network) приводят к downtime (poll blocks во время). Static membership стабилизирует группу при restarts. CooperativeStickyAssignor минимизирует перемещения (до 80% меньше чем Range). Увеличьте session.timeout.ms до 300 сек для tolerance; heartbeat.interval.ms= session/3. Мониторьте rebalance-rate; если high — investigate app stability.

- max.poll.interval.ms и долгие операции: По умолчанию 5 мин — максимальное время между poll(). Если processing в poll() превышает (например, heavy computation), coordinator считает dead, триггеря rebalance. Решение: разбейте работу на chunks, poll() frequently; используйте pause() для long ops, но resume timely. Для очень долгих — offload в separate thread, но sync с poll(). Нюанс: в Streams это processing.guarantee=at_least_once handles.

- Обработка с сохранением ordering: Consumer гарантирует order только внутри партиции, но rebalance может нарушить если state не сохранен. В onPartitionsRevoked commit offsets и persist state (например, в external store). В onPartitionsAssigned seek(committed offset) и restore state. Для strict ordering: single-threaded per partition, или assign manually (без subscribe, используйте assign()). Нюанс: в groups с multiple consumers ordering cross-partition не гарантировано; для global order — single partition или external sorting.


#Java #middle #Kafka #Consumer
👍3🤯2
Основы ООП в Java

Глава 1. Классы и объекты


Конструкторы. Перегрузка. Ключевое слово this


Конструктор — это специальный метод класса, который вызывается автоматически при создании объекта с помощью new. Он используется для инициализации полей объекта, установки начального состояния.

Сигнатура конструктора:
Имя совпадает с именем класса.
Нет типа возвращаемого значения (даже void не пишется).
Может иметь параметры для передачи значений.


Если вы не определяете конструктор, Java создает пустой конструктор автоматически:
public Person() {
// Пусто, поля инициализируются значениями по умолчанию (null для объектов, 0 для чисел)
}


Пример простого конструктора:
public class Person {
private String name;
private int age;

// Конструктор с параметрами
public Person(String name, int age) {
this.name = name;
this.age = age;
}
}

При создании объекта new Person("Алексей", 35) конструктор присваивает значения полям.



Ключевое слово this

this — это ссылка на текущий объект.


Оно используется внутри класса для:
Отличия полей класса от параметров методов (если имена совпадают).
Вызова других конструкторов или методов текущего объекта.


Пример использования this:
public class Person {
private String name;
private int age;

public Person(String name, int age) {
this.name = name; // this.name — поле класса, name — параметр
this.age = age;
}
}

Без this Java бы подумал, что name = name; — это присваивание параметра самому себе, что бесполезно.



Перегрузка конструкторов

Перегрузка — это создание нескольких методов с одним именем, но разными параметрами. Для конструкторов это позволяет создавать объекты разными способами.

Правила перегрузки:
Разные сигнатуры (количество, типы или порядок параметров).
Конструкторы могут вызывать друг друга с помощью this() для избежания дублирования кода.


Пример перегрузки:

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

// Конструктор по умолчанию (без параметров)
public Person() {
this.name = "Неизвестный";
this.age = 0;
}

// Конструктор с одним параметром
public Person(String name) {
this.name = name;
this.age = 0; // Возраст по умолчанию
}

// Конструктор с двумя параметрами
public Person(String name, int age) {
this.name = name;
this.age = age;
}

// Вызов другого конструктора с помощью this()
public Person(int age) {
this("Неизвестный", age); // Вызывает конструктор с двумя параметрами
}
}

Теперь объекты можно создавать по-разному:Person p1 = new Person(); // Неизвестный, 0
Person p2 = new Person("Алексей"); // Алексей, 0
Person p3 = new Person("Алексей", 35); // Алексей, 35
Person p4 = new Person(35); // Неизвестный, 35



Как создать это в IntelliJ IDEA

Добавьте конструкторы в класс:
Откройте класс Person.
Вставьте код с перегрузкой.
IntelliJ IDEA может генерировать конструкторы: Правой кнопкой → Generate → Constructor, выберите поля.



Тестируйте в Main:
Создайте класс Main и добавьте код для создания объектов.
Запустите: Правой кнопкой на
Main.java → Run.


Полезные советы для новичков

Избегайте дублирования:
Используйте this() для вызова одного конструктора из другого. Вызов должен быть первой строкой.
Параметры vs поля: Всегда используйте this при совпадении имен — это хорошая практика.
Конструктор без параметров: Полезен для создания объектов с значениями по умолчанию.
Ошибки: Если конструктор с параметрами есть, дефолтный не создается автоматически — добавьте его вручную, если нужен.
Практика: Перегружайте конструкторы, чтобы класс был гибким.



#Java #для_новичков #beginner #constructor
👍5🔥1
Apache Kafka

Схемы, сериализация и эволюция контрактов

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


Форматы: Avro, Protobuf, JSON-Schema

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

- Avro: Бинарный формат от Apache, ориентированный на экосистему Hadoop. Схема описывается в формате, похожем на JSON, и определяет записи с полями (простые типы, сложные: массивы, карты, объединения). Avro поддерживает эволюцию: добавление необязательных полей с значениями по умолчанию, удаление с defaults. В памяти сериализатора схема разбирается в общую запись (GenericRecord) или конкретную (SpecificRecord с генерированным кодом), где данные хранятся как древовидная структура (например, карта строк на объекты). Сериализация — рекурсивный обход, кодирование в буфер байтов с переменной длиной для эффективности. Затраты: схема может не включаться полностью, в Kafka обычно используется идентификатор схемы вместо полной версии. Преимущества: быстро (быстрее JSON), компактно, встроенная поддержка эволюции.

- Protobuf (Protocol Buffers): Бинарный формат от Google, с файлами .proto (сообщения с полями: обязательными, необязательными, повторяющимися). Поддерживает эволюцию: добавление полей с новыми номерами тегов (совместимо назад), но удаление или изменение типов рискованно. В памяти: Protobuf использует сгенерированные классы (через компилятор protoc), где сообщение — неизменяемый объект с методами доступа; сериализация в поток с переменными числами и длинами. Нет встроенных значений по умолчанию для новых полей (неизвестные поля игнорируются). Затраты: очень компактно (компактнее Avro за счёт тегов), быстрое разбор. Нюанс: в Kafka требуется внешний реестр для версионности, поскольку формат передачи не включает схему.

- JSON-Schema: Стандарт для описания структур JSON (версия draft-07 и выше). Не бинарный, но подходит для JSON-данных. Схема — объект JSON с свойствами, обязательными полями и типами. Эволюция: добавление свойств (если не обязательные), но JSON раздувается. В памяти: десериализация в карту или объект через библиотеки (например, Jackson с JsonSchema). Затраты: slowest и largest payloads, но читаемо человеком. Используйте для прототипов; в производстве предпочитайте бинарные для высокой пропускной способности.

Компромиссы: Avro и Protobuf для реальных систем (компактные, быстрые), JSON-Schema для простоты. В памяти все форматы используют временные буферы (буферы байтов в Java) для кодирования и декодирования; нагрузка на сборку мусора выше для сложных схем (много объектов).


#Java #middle #Kafka #Kafka_serializers #Kafka_deserializers
👍3
Реестр схем: именование субъектов, версионность, режимы совместимости (назад, вперёд, полная), формат передачи: магический байт + идентификатор схемы

Реестр схем (Schema Registry от Confluent, с открытым кодом) — централизованный сервис для хранения и проверки схем, интегрированный с Kafka. Он обеспечивает контракт: отправители регистрируют схемы, получатели загружают по идентификатору.

- Именование субъектов: Субъект — ключ для схемы, обычно имя темы с суффиксом -value или -key (стратегия именования: по умолчанию, по теме, по имени записи). Например, "orders-value" для значения в теме orders. Версионность: каждая схема под субъектом имеет версии (1, 2, ...), автоматически увеличивающиеся при регистрации, если совместима.

- Режимы совместимости: Правила проверки новой схемы по отношению к существующим.
- Назад (BACKWARD): Новая схема может читать старые данные (добавление необязательных полей нормально, удаление — нет). Для развёртки сначала потребителей.
- Вперёд (FORWARD): Старые схемы могут читать новые данные (добавление обязательных — нет, удаление необязательных — нормально). Для развёртки сначала отправителей.
- Полная (FULL): И назад, и вперёд (транзитивно: проверка со всеми предыдущими).
Режим настраивается по субъекту (по умолчанию назад с транзитивностью). В реестре: при отправке на /subjects/{subject}/versions сервер разбирает схему и проверяет совместимость через библиотеки (для Avro — валидатор схем, для Protobuf — аналогично).


- Формат передачи: Сообщение = магический байт (0 для Confluent) + идентификатор схемы (4-байтовое целое) + полезная нагрузка. В памяти сериализатора: идентификатор загружается из реестра (кэшируется локально в клиенте реестра: карта субъектов на версии и схемы), затем кодируется нагрузка. Десериализатор: читает магический байт и идентификатор, загружает схему (из кэша), декодирует. Кэш снижает задержку (срок жизни настраивается), но устаревший кэш может вызвать ошибку несовместимой схемы.

В памяти реестра (REST-сервис на Java): схемы хранятся в бэкенде (тема Kafka _schemas или база данных), с кэшем в памяти для быстрого доступа. Нюанс: высокая доступность через несколько экземпляров с выбором лидера.


Сериализаторы в Java: Avro (от Confluent), сериализатор/десериализатор Protobuf

В клиентах Kafka сериализаторы — реализации интерфейсов для сериализации и десериализации.

- Avro (от Confluent): io.confluent.kafka.serializers.KafkaAvroSerializer. Интегрирован с реестром: в методе сериализации загружает или регистрирует схему, пишет магический байт, идентификатор и данные. Для общих данных — общая запись; для конкретных — классы с генерированным кодом через плагин avro-maven. Десериализатор: KafkaAvroDeserializer, с настройкой автоматической регистрации схем false для производства. В памяти: использует писатели и читатели данных, пул буферов байтов для повторного использования.

- Protobuf: io.confluent.kafka.serializers.protobuf.KafkaProtobufSerializer. Аналогично: сообщения Protobuf генерируются из .proto, сериализатор регистрирует схему (Protobuf преобразуется во внутреннюю JSON-схему). В памяти: динамическое сообщение Protobuf, но предпочтительны сгенерированные для безопасности типов. Десериализатор разбирает с загруженной схемой.

Нюанс: кастомные сериализаторы расширяют абстрактный класс; затраты — загрузка схемы при инициализации (блокирующая), потом асинхронная.


#Java #middle #Kafka #Kafka_serializers #Kafka_deserializers
👍3
Пример producer с Avro

Вот базовый пример отправителя с сериализацией Avro, интегрированным с реестром схем:
import org.apache.kafka.clients.producer.*;
import io.confluent.kafka.serializers.KafkaAvroSerializer;
import org.apache.avro.generic.GenericRecord;
import org.apache.avro.Schema;
import org.apache.avro.generic.GenericData;
import java.util.Properties;

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092"); // Адреса серверов Kafka
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); // Сериализатор для ключей
props.put("value.serializer", KafkaAvroSerializer.class.getName()); // Сериализатор для значений Avro
props.put("schema.registry.url", "http://schema-registry:8081"); // URL реестра схем

KafkaProducer<String, GenericRecord> producer = new KafkaProducer<>(props);

// Пример схемы и записи
String schemaStr = "{\"type\":\"record\",\"name\":\"Order\",\"fields\":[{\"name\":\"id\",\"type\":\"int\"},{\"name\":\"amount\",\"type\":\"double\"}]}";
Schema schema = new Schema.Parser().parse(schemaStr); // Разбор схемы
GenericRecord record = new GenericData.Record(schema); // Создание записи
record.put("id", 1); // Заполнение поля id
record.put("amount", 100.5); // Заполнение поля amount

ProducerRecord<String, GenericRecord> producerRecord = new ProducerRecord<>("orders", "key", record); // Создание записи для отправки
producer.send(producerRecord); // Отправка
producer.close(); // Закрытие отправителя


В реальных системах: используйте конкретные классы с генерированным кодом, добавьте обработку ошибок для исключений реестра схем.


Нюансы

- Тестирование эволюции схем: Создайте интеграционные тесты с имитацией реестра (встроенный Kafka плюс mock-клиент реестра). Шаги: зарегистрируйте первую версию схемы, отправьте данные; эволюционируйте ко второй (добавьте поле), проверьте режим совместимости; получите данные с десериализатором первой версии на данных второй (совместимость вперёд) и наоборот (назад). Используйте инструменты: avro-tools для сравнения, или тесты JUnit с проверкой совместимости схем. Нюанс: тестируйте транзитивную совместимость (третья версия с первой); имитируйте сброс кэша. В непрерывной интеграции: автоматизируйте с плагинами Gradle или Maven для валидации схем.

- Управление схемами (процесс одобрения): В крупных организациях внедрите рабочий процесс: схемы в репозитории Git, запросы на слияние с проверками совместимости (через плагин schema-registry-maven). Одобрение: ревью коллег плюс автоматические тесты; развёртка только после слияния. Используйте политику совместимости реестра по субъекту; для строгого контроля — полная транзитивная. Нюанс: семантика версионности (семантическое версионирование: мажорная для breaking changes), журнал аудита в реестре. Интегрируйте с процессами непрерывной интеграции и доставки: блокируйте развёртку при несовместимости.

- Сложности миграции с одного формата на другой: Миграция (например, с JSON на Avro) требует фазы двойной записи и чтения: отправители пишут в новую тему с новым форматом, получатели мигрируют постепенно. Сложности: преобразование данных (кастомный трансформер в Streams), обеспечение согласованности (атомарный переключатель невозможен из-за смещений). Затраты: двойное хранение во время перехода; конфликты схем при смешанных данных. Нюанс: для миграции в реальном времени используйте MirrorMaker с кастомными сериализаторами; риски — ошибки десериализации при коллизиях идентификаторов. Тестируйте с канареечными развёртками; время миграции — недели или месяцы для больших наборов данных.


#Java #middle #Kafka #Kafka_serializers #Kafka_deserializers
👍3
Основы ООП в Java

Глава 2. Инкапсуляция

Принцип инкапсуляции: скрытие внутреннего состояния


Инкапсуляция — это фундаментальный принцип ООП, который подразумевает объединение данных (состояния) и методов (поведения) в единый модуль — класс — с одновременным скрытием внутренних деталей от внешнего мира. Слово "инкапсуляция" происходит от "капсулы", где важное спрятано внутри, а снаружи виден только необходимый интерфейс.

В ООП инкапсуляция помогает моделировать реальные объекты: например, в автомобиле вы видите руль и педали (интерфейс), но не знаете, как именно работает двигатель внутри (скрытое состояние). Это делает систему более надежной и управляемой.

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

Вот ключевые аспекты, почему скрытие состояния критично в ООП:
Защита данных от несанкционированных изменений: В реальном мире вы не можете просто открыть капот машины и переставить детали — это может сломать всё. Аналогично, скрытие состояния предотвращает случайные или вредоносные изменения данных, обеспечивая целостность объекта. Например, если поле "возраст" в классе Person скрыто, внешний код не сможет установить отрицательное значение напрямую, что сохранит логическую consistency.

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

Снижение сложности: Внешний код видит только "черный ящик" — что объект может делать, но не как. Это уменьшает когнитивную нагрузку: разработчику не нужно знать все детали, чтобы использовать класс. Например, в библиотеке вы вызываете метод, не вникая в его внутреннюю логику.

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

Поддержка принципа "информационного скрытия": Это концепция из ООП, где класс раскрывает только необходимую информацию. Скрытие помогает избежать "спагетти-кода", где всё связано со всем, и способствует созданию чистых, самодокументируемых систем.


Без скрытия состояния ООП теряет силу: объекты становятся просто контейнерами данных, как в процедурном программировании, что приводит к хаосу в сложных системах.


Концептуальный пример

Представьте класс BankAccount (Банковский счет).
Внутреннее состояние — это баланс и номер счета.
Без скрытия любой код мог бы напрямую изменить баланс, что привело бы к ошибкам (например, отрицательный баланс). С инкапсуляцией состояние скрыто, и внешний код может только вносить/снимать деньги через контролируемые операции, обеспечивая валидацию и логику.


Это демонстрирует, как инкапсуляция делает объекты надежными "капсулами" с защищенным содержимым.


Полезные советы для новичков

Думайте как дизайнер: При создании класса спрашивайте: "Что внешний код должен знать о состоянии? Что можно скрыть?"
Преимущества в практике: В реальных проектах скрытие состояния упрощает отладку — ошибки локализуются внутри класса.
Связь с другими принципами ООП: Инкапсуляция закладывает основу для наследования и полиморфизма, где подклассы могут переопределять поведение без нарушения скрытия.
Ресурсы: Почитайте "Clean Code" Роберта Мартина — там много о принципах ООП, включая инкапсуляцию.



#Java #для_новичков #beginner #incapsulation
👍1