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

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

Наш канал на RUTube - https://rutube.ru/channel/37896292/
Download Telegram
Вопрос с собеседований

Что такое marker interface? 🤓


Ответ:

Marker-интерфейс
не содержит методов, а лишь помечает класс, предоставляя JVM или фреймворкам дополнительную информацию.

Примеры — Serializable и Cloneable.

Хотя современный подход — аннотации, такие интерфейсы всё ещё встречаются в старом коде.



#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from ChatRoom (Java for Beginner) (Первожрец Java)
Чет я основы забывать начал🤦🏼‍♂️😆
Короче могу взять несколько человек в падаваны и обучить Java с нуля))
🔥2
История IT-технологий сегодня — 27 ноября


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

Алан Эмтадж (родился 27 ноября 1964 года) — барбадосско-канадский программист и исследователь, создатель первой поисковой системы «Archie», одного из ранних инструментов навигации по FTP‐архивам в интернете.


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

1980 — стартовал пилотируемый космический аппарат «Союз Т-3»; экипаж — Леонид Кизим, Олег Макаров, Геннадий Стрекалов, при этом Макаров первым из советских космонавтов совершает четвёртый космический полёт.


#Biography #Birth_Date #Events #27Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
https://t.me/Java_for_beginner_dev/3765

А если реально то меня несколько раз в комментариях на Ютубе спрашивали о менторстве.

Думаю нужно попробовать)


Пишите, возьму всего несколько человек! 💪☺️
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
GraphQL vs REST vs gRPC

REST — ресурсно-ориентированный HTTP API, обычно JSON по HTTP/1.1. Прост, совместим с любым клиентом, хорош для публичных и простых API.
GraphQL — язык запросов + схема; клиент сам описывает форму данных. Один эндпоинт, строгая схема, гибкость запросов, удобен для фронтенда.
gRPC — RPC-фреймворк на основе HTTP/2 + Protocol Buffers; строгие контракты (.proto), бинарная сериализация, встроенный стриминг. Ориентирован на высокую производительность и внутренние сервисы.



Формат данных

REST → JSON (текстовый, человекочитаемый).
GraphQL → JSON-ответ, но запросы декларативны и строго типизированы схемой.
gRPC → Protocol Buffers (бинарный), компактно, фиксированные поля.
Вывод: protobuf обычно экономит трафик и парсится быстрее; JSON удобнее для дебага и совместимости.

Протокол транспорта

REST → HTTP/1.1 (обычно), можно HTTP/2, но без нативного стриминга.
GraphQL → обычно HTTP/1.1 POST/GET для Query/Mutation; Subscription — WebSocket или HTTP/2 SSE.
gRPC → HTTP/2 по умолчанию, мультиплексирование, потоковые фреймы, двунаправленность.
Вывод: для потоковых сценариев и мультиплексирования gRPC технически лучше.


Типы взаимодействия

REST → запрос/ответ (stateless).
GraphQL → query/mutation/subscription; один запрос может агрегировать много сущностей.
gRPC → unary, server streaming, client streaming, bidirectional streaming (всё на уровне протокола).
Вывод: если нужны сложные стримы и двунаправленные каналы — gRPC.


Типизация и контракт

REST → схема часто нестрогая (OpenAPI/Swagger добавляет контракт).
GraphQL → строгая схема (SDL).
gRPC → строгие контракты (.proto).
Вывод: GraphQL и gRPC обеспечивают статический контракт; REST требует дополнительных инструментов для той же дисциплины.


Производительность (в общих чертах)

gRPC обычно выигрывает по пропускной способности и латентности за счёт бинарной сериализации и HTTP/2.
GraphQL может быть эффективным по числу запросов (агрегация) и по уменьшению round-trip’ов, но JSON+резолверы добавляют накладные расходы.
REST проще и зачастую медленнее при больших объёмах и при множественных запросах с агрегацией.
Вывод: для внутренней коммуникации между сервисами с высокой нагрузкой — gRPC; для клиентского слоя — GraphQL/REST в зависимости от потребностей.


Эволюция API и версияция

REST → часто версионируют (/v1/) или добавляют параметры; ломкость при изменениях.
GraphQL → расширяемость без версий (добавление полей безопасно), депрекация поддерживается.
gRPC → совместимость через правила protobuf (резервирование, добавление новых полей безопасно при соблюдении правил).
Вывод: GraphQL и gRPC дают удобные инструменты для эволюции без жесткой версии.


Инструментальная поддержка и экосистема


REST → универсальная поддержка, простые средства тестирования.
GraphQL → богатая экосистема: GraphiQL, Apollo, Relay, Codegen. Отлично для фронтенда.
gRPC → генерация стубов под любые языки, хорошие SDK для серверов и клиентов; браузерная поддержка требует gRPC-Web.
Вывод: выбор зависит от клиентской среды: браузер напрямую лучше работает с REST/GraphQL; для gRPC нужен шлюз (gRPC-Web) или прокси.



#Java #middle #GraphQL
👍1
Практические сценарии

публичный HTTP API для сторонних клиентов (публичная документация)

Выбор: REST или GraphQL
Почему: совместимость, простота, отсутствие необходимости требованиям к бинарному протоколу.
REST, если API простое, CRUD-ориентированное, нужно кэширование по URL и широчайшая совместимость.
GraphQL, если клиенты (много разных) требуют разные наборы данных и важно уменьшить число запросов.


фронтенд (SPA, мобильные клиенты) с разнообразными представлениями

Выбор: GraphQL
Почему: клиент сам формирует shape ответов; экономия round-trips; отличная интеграция с Apollo/Relay; кодогенерация типов для TS/Swift/Kotlin.

внутренняя связь между микросервисами с высокой нагрузкой

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

real-time (чат, телеметрия, видео/аудио)

Выбор: gRPC (bidirectional) или GraphQL Subscriptions (WebSocket)

Почему: gRPC даёт нативный поток; GraphQL Subscriptions удобны для фронтенда, но требуют инфраструктуры и могут быть сложнее в масштабировании.

интеграция с legacy REST-сервисами

Выбор: GraphQL в качестве BFF (Backend-for-Frontend) или REST-шлюз
Почему: GraphQL может агрегировать несколько REST-вызовов и отдать клиенту нужную структуру.


Почему часто комбинируют: GraphQL для клиентов, gRPC для микросервисов

Это распространённый и рациональный паттерн:
Внутренние сервисы общаются по gRPC (эффективно, типобезопасно, стриминг).
BFF / API Gateway (или отдельный GraphQL-сервер) агрегирует данные из gRPC/REST/БД и предоставляет фронту единый, гибкий интерфейс.
Фронтенд работает с GraphQL (или REST), не заботясь о том, как именно данные доставлены внутри инфраструктуры.


Преимущества паттерна:
Отделение оптимизации внутренней сетевой коммуникации (gRPC) от удобства клиентских API (GraphQL).
Централизация логики агрегации и адаптации под клиентов.
Возможность менять внутреннюю реализацию без ломки фронта.


Пример (псевдокод Java resolver, вызывающий gRPC-stub):
// GraphQL resolver
public class UserResolver {
private final UserGrpc.UserBlockingStub userStub;

public UserResolver(UserGrpc.UserBlockingStub userStub) {
this.userStub = userStub;
}

public User getUser(String id) {
UserRequest req = UserRequest.newBuilder().setId(id).build();
UserResponse resp = userStub.getUser(req); // gRPC call to internal service
return mapToGraphQLUser(resp);
}
}



Детальный разбор преимуществ и ограничений

Удобство разработки
REST: быстро стартовать, понятная модель. Но при сложных клиентских потребностях растёт число эндпоинтов.
GraphQL: позволяет фронтенду быстро изменять данные без координации с бэком, но требует работы со схемой и авторизацией на уровне полей.
gRPC: требует .proto и генерации стабов, но даёт сильную типизацию и меньше рутинного кода при изменениях.


Кеширование
REST: простое кеширование по URL (HTTP caches, CDNs).
GraphQL: кеширование сложнее — операция может возвращать разные поля; решения: persisted queries, apollo cache, CDN на уровне persisted queries/operation id.
gRPC: кеширование на транспортном уровне сложнее; обычно кешируют ответы в сервисах.


Отладка и наблюдаемость
REST: легко отлаживать (curl, браузер).
GraphQL: дебаг через GraphiQL/Apollo Studio; трассировка полей сложнее (нужны field-level metrics).
gRPC: бинарные пакеты труднее смотреть вручную; нужно подходящие инструменты (grpcurl, tshark + protobuf descriptors).


Безопасность и авторизация


REST: стандартные механизмы (OAuth, JWT, TLS).
GraphQL: нужно управлять авторизацией на уровне полей (field-level), чтобы не раскрывать данные; также важны depth-limiting, query complexity limiting, persisted queries.
gRPC: поддерживает mTLS, аутентификацию/авторизацию через metadata; access control реализуется в сервисах.


Количество сетевых вызовов / latency
GraphQL часто уменьшает RTT за счёт агрегации (один запрос вместо множества).
gRPC уменьшает сетевые накладные расходы: меньше байт, лучше TCP connection reuse, HTTP/2 мультиплексирование.



#Java #middle #GraphQL
👍1
Практические шаблоны интеграции (patterns)

1) BFF (Backend-for-Frontend) — GraphQL на фронте + gRPC внутри

GraphQL агрегатор (BFF) вызывает gRPC сервисы, комбинирует ответы и отдаёт клиенту.
Позволяет хранить оптимизированные внутр. контракты и независимую клиентскую схему.


2) API Gateway с трансляцией

gRPC Gateway (прокси) экспонирует REST/JSON поверх gRPC-сервисов или наоборот.
Полезно для совместимости с внешними клиентами.


3) Dual API

Предоставлять одновременно REST (для публичного потребления) и GraphQL (для интерактивного фронта).
Поддерживать один источник данных и разные фасады.

4) Persisted Queries + CDN

Для GraphQL: генерировать хэш-запросов (operationId) и кэшировать на CDN; уменьшает payload и риск DoS.


Частые ошибки

Выбор gRPC для публичного браузерного API без gRPC-Web — приведёт к дополнительной сложности (нужен прокси).
GraphQL без контроля сложности — клиенты могут генерировать тяжёлые запросы (глубокая вложенность). Нужно ставить лимиты.
REST для сложной фронт-логики — приведёт к множеству эндпоинтов и оверхеду в клиенте.
Игнорирование кэширования в GraphQL — потеря преимуществ CDN/edge caching; нужен persisted queries или отдельные REST-эндпоинты для тяжелых ресурсов.



Чек-лист для принятия решения (практический)

Клиенты — браузеры? мобильные? сторонние интеграторы?
браузер/мобильный фронт → GraphQL выгоден;
сторонние сторонние потребители → REST предпочтителен (совместимость).

Нужен ли стриминг / двунаправленная связь?
да → gRPC;
нет → GraphQL/REST.


Высокая нагрузка внутри сети (RTT, пропускная способность)?
да → gRPC;

Требуется гибкость выбора полей клиентом и уменьшение запросов?
да → GraphQL;

Требуется простое кеширование через CDN/HTTP?
да → REST (или реализовать persisted queries для GraphQL).

Нужно строгая схема и codegen для многих языков?
gRPC или GraphQL (оба дают schema/codegen).


Рекомендованные архитектурные сочетания (рецепты)

Внутренние микросервисы (gRPC) + GraphQL BFF + браузерный фронт — оптимальный вариант для больших команд: скорость внутри, гибкость для фронтенда.
REST public API + GraphQL internal BFF for web clients — если нужно максимально простое публичное API, но гибкость для своих фронтенд-команд.
gRPC end-to-end — когда все клиенты контролируются и могут использовать gRPC (например, мобильный клиент с gRPC-Web или нативный клиент).


Пример архитектуры

Сценарий: крупное приложение с веб-клиентом и мобильными приложениями + множество микросервисов.
Внутренние микросервисы: общаются по gRPC (protobuf).
Aggregation Layer: GraphQL BFF. Он:
вызывает gRPC сервисы (stub-ы),
использует DataLoader / batching для борьбы с N+1,
кеширует часто запрашиваемые фрагменты,
реализует field-level авторизацию.
Фронтенд: запрашивает GraphQL; для критичных статических ресурсов (изображения) используется CDN.
Преимущество: фронтенд получает гибкий API, внутренние сервисы остаются быстрыми и типобезопасными.



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

public class Task271125 {
public static void main(String[] args) {
int i = 0;
do {
i++;
if (i == 2) continue;
System.out.print(i + " ");
} while (i < 3 && i > 0);

System.out.print("end: " + i);
}
}


#Tasks
Варианты ответа:
Anonymous Quiz
30%
1 end: 1
10%
1 3 end: 2
40%
1 3 end: 3
20%
1 2 3 end: 3
Вопрос с собеседований

Что делает метод Objects.requireNonNull()? 🤓


Ответ:

Метод Objects.requireNonNull() проверяет аргумент на null и выбрасывает NullPointerException с сообщением при нарушении.

Это позволяет явно гарантировать корректность входных параметров и упростить диагностику ошибок.

Применяется в конструкторах, сеттерах и публичных API.



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


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

Кристиан Керстинг (родился 28 ноября 1973 года в Куксхафене, Германия) — немецкий учёный в области ИИ и машинного обучения, профессор, возглавляющий лабораторию по ИИ и машинному обучению (AIML) в Darmstadt; значимые публикации в probabilistic inductive logic programming.


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

1964 — к Марсу запущена американская автоматическая станция «Маринер-4».


#Biography #Birth_Date #Events #28Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Глава 2. List — списки

Метод get

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


ArrayList: мгновенный доступ через массив

ArrayList реализует список на основе динамического массива, что обеспечивает ему исключительную производительность при операциях доступа по индексу. Внутренняя структура ArrayList построена вокруг массива Object[], который служит непосредственным хранилищем элементов.

Эта архитектура предоставляет несколько ключевых преимуществ для операции get:
Прямая адресация через смещение в памяти
Константное время доступа к любому элементу
Высокая пространственная локальность, благоприятная для кэширования процессора
Минимальные накладные расходы на операцию доступа



Детальный процесс выполнения get(index)

Фаза валидации и проверки границ
Первым и обязательным шагом в выполнении метода get является проверка корректности запрошенного индекса:

Проверка диапазона:

Система убеждается, что указанный индекс находится в пределах от 0 (включительно) до текущего размера списка (исключительно). Эта проверка включает сравнение индекса с полем size ArrayList и при необходимости выброс исключения IndexOutOfBoundsException с информативным сообщением.

Валидация состояния:
Неявно проверяется, что внутренняя структура данных находится в консистентном состоянии и готова к операции чтения.

Фаза непосредственного доступа к элементу
После успешной валидации индекса происходит собственно извлечение элемента:

Вычисление позиции в массиве:
Поскольку ArrayList использует непрерывный блок памяти, позиция элемента вычисляется как прямое смещение в массиве. Для массива elementData и индекса i элемент находится точно в позиции elementData[i].

Извлечение значения:
Происходит чтение ссылки на объект из соответствующей позиции массива. Эта операция компилируется в одну машинную инструкцию доступа к памяти.

Возврат результата:
Найденный объект возвращается вызывающему коду. Если в указанной позиции хранится null, метод возвращает null без дополнительных проверок.

Отсутствие структурных изменений
Важной характеристикой операции get в ArrayList является то, что она не модифицирует внутреннюю структуру данных.

В отличие от операций добавления или удаления, get является read-only операцией, что означает:
Отсутствие необходимости в блокировках для thread-safe доступа (в read-only сценариях)
Нет модификации счетчика изменений (modCount)
Сохранение целостности внутреннего массива



Производительность и оптимизации

Временная сложность
Операция get в ArrayList имеет временную сложность O(1) в худшем случае. Это означает, что время доступа к первому, последнему или любому другому элементу практически идентично и не зависит от размера списка.

Влияние кэширования процессора
Благодаря непрерывному расположению элементов в памяти, ArrayList идеально использует принцип пространственной локальности:

Кэш-линии процессора:
Смежные элементы часто попадают в одну кэш-линию, что делает последовательный доступ чрезвычайно эффективным.

Prefetching:
Современные процессоры могут предсказывать и предзагружать следующие элементы массива, еще больше ускоряя последовательные операции доступа.

Оптимизации на уровне JVM

JIT-компиляция:
HotSpot JVM может агрессивно оптимизировать операции доступа к массиву, включая elimination bounds checking в некоторых сценариях.

Inlining:
Частые вызовы get могут быть inline-ированы, уменьшая overhead вызова метода.


#Java #для_новичков #beginner #List #ArrayList #LinkedList #get
LinkedList: последовательный доступ через цепочку узлов

Архитектурные основы связного списка
LinkedList реализует список на основе двусвязного списка, где каждый элемент хранится в отдельном узле, содержащем ссылки на данные, предыдущий и следующий узлы.

Эта архитектура fundamentally меняет механизм доступа к элементам:

Последовательный доступ вместо прямого
Линейная временная сложность доступа по индексу
Отсутствие преимуществ пространственной локальности
Дополнительные затраты на обход цепочки


Структура узла и организация данных
Каждый узел LinkedList содержит три ключевых компонента:
Node {
E item; // хранимый элемент
Node<E> next; // ссылка на следующий узел
Node<E> prev; // ссылка на предыдущий узел
}
Список поддерживает ссылки на первый (head) и последний (tail) узлы, а также счетчик размера.


Детальный процесс выполнения get(index)


Фаза валидации и стратегического выбора
Как и в ArrayList, первым шагом является проверка корректности индекса:

Проверка границ:
Убеждаются, что индекс находится в диапазоне [0, size-1].

Выбор стратегии обхода:
В зависимости от положения индекса выбирается оптимальная точка начала обхода:
Если индекс находится в первой половине списка (index < size / 2), обход начинается с головы (head)
Если индекс находится во второй половине, обход начинается с хвоста (tail)
Эта оптимизация уменьшает среднее количество шагов обхода с n/2 до n/4.


Фаза последовательного обхода
После выбора начальной точки начинается процесс пошагового перемещения по цепочке узлов:

Инициализация обхода:
Создается временная переменная-указатель, которая устанавливается на начальный узел (head или tail).

Последовательное перемещение:
Для каждого шага обхода:
Если движение от головы, указатель перемещается к следующему узлу (
node.next)
Если движение от хвоста, указатель перемещается к предыдущему узлу (node.prev)
Счетчик текущей позиции обновляется


Достижение целевой позиции:
Процесс продолжается до тех пор, пока текущая позиция не совпадет с запрошенным индексом.

Фаза извлечения и возврата результата
Когда целевой узел найден:

Извлечение элемента:
Из поля item целевого узла извлекается хранимый объект.

Возврат результата:
Объект возвращается вызывающему коду. Как и в ArrayList, если узел содержит null, возвращается null.


Производительность и характеристики доступа

Временная сложность
Операция get в LinkedList имеет временную сложность O(n) в худшем случае, где n — количество элементов в списке. Однако благодаря двунаправленному обходу средняя сложность составляет O(n/4) = O(n).

Зависимость от паттерна доступа
Худший случай:
Доступ к элементу в середине большого списка требует обхода примерно n/2 узлов.

Лучший случай:
Доступ к первому или последнему элементу требует всего одного шага.

Средний случай:
При равномерном распределении запросов среднее количество шагов составляет n/4.

Влияние на производительность

Отсутствие кэширования:
Из-за разрозненного расположения узлов в памяти отсутствуют преимущества кэширования процессора.

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


#Java #для_новичков #beginner #List #ArrayList #LinkedList #get
Сравнительный анализ производительности

Количественные характеристики

Время доступа:
ArrayList: 5-10 наносекунд на операцию (не зависит от размера)
LinkedList: 10-50 наносекунд × количество пройденных узлов


Потребление памяти:
ArrayList: ~4 байта на элемент (в плотно заполненном массиве)
LinkedList: ~24-32 байта на элемент (затраты на узел)


Качественные различия

Пространственная локальность:
ArrayList: Отличная — элементы расположены непрерывно
LinkedList: Плохая — элементы разбросаны по куче


Масштабируемость:
ArrayList: Идеальная — постоянное время независимо от размера
LinkedList: Линейная деградация — время растет пропорционально размеру



Специализированные реализации List

CopyOnWriteArrayList


Механизм доступа:
Использует snapshot массив, что обеспечивает thread-safe доступ без блокировок:
Операция get просто обращается к текущему snapshot массива
Отсутствие блокировок и contention между читателями
Гарантированная consistency во время итерации


Производительность:
Сопоставима с ArrayList для операций чтения, но с дополнительным уровнем indirection.

Vector

Устаревший synchronized доступ:

Все операции, включая get, синхронизированы, что создает излишний overhead в single-threaded сценариях.


Многопоточные аспекты доступа

Потокобезопасность операций чтения

Несинхронизированные реализации:

ArrayList и LinkedList не гарантируют корректность при concurrent модификациях:
Возможность чтения устаревших данных
Риск исключений при структурных изменениях во время доступа
Отсутствие happens-before отношений


Thread-safe альтернативы:
CopyOnWriteArrayList: Идеален для read-heavy workloads
Collections.synchronizedList(): Добавляет синхронизацию к стандартным реализациям
Vector: Устаревшая синхронизированная реализация



Практические рекомендации

Критерии выбора реализации

Выбор ArrayList когда:
Преобладает случайный доступ по индексу
Частые операции получения элементов
Известен или может быть оценен конечный размер списка
Критически важна производительность операций чтени
Память является ограниченным ресурсом


Выбор LinkedList когда:
Преобладают операции вставки/удаления в начала/конца списка
Основной паттерн доступа — последовательная итерация
Размер списка сильно варьируется
Операции доступа по индексу редки или предсказуемы



Влияние современных аппаратных архитектур

Иерархия памяти и кэширование

ArrayList:
Отличное использование L1/L2/L3 кэшей
Эффективный prefetching
Минимальные cache misses


LinkedList:
Частые cache misses из-за random access к памяти
Неэффективное использование prefetcher'а
Высокий penalty при промахах кэша


Влияние на реальную производительность

Разрыв в производительности между ArrayList и LinkedList для операций get может достигать 50-100 раз для больших списков и случайного доступа, что делает правильный выбор реализации критически важным для производительности приложения.


#Java #для_новичков #beginner #List #ArrayList #LinkedList #get
Что выведет код?

import java.util.ArrayList;
import java.util.List;

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

List<Integer> subList = list.subList(1, 3);
list.add(4);

System.out.println(subList.get(0));
System.out.println(subList.get(1));
}
}


#Tasks
Варианты ответа:
Anonymous Quiz
40%
2 3
20%
2 4
20%
3 4
20%
ConcurrentModificationException