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

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

Наш канал на RUTube - https://rutube.ru/channel/37896292/
Download Telegram
Бот заряжен и готов выдавать ссылки!

Переходите и просите у него ссылку)


Чтобы избежать ошибок при работе с ботом нажмите /start

@JFB_admin_bot
👍1
GraphQL. Как усложнение упрощает жизнь.

В сегодняшнем видео мы рассмотрели что такое GraphQL.

Сегодня я написал и запустил простой демонстрационный код в котором рассмотрел что такое GraphQL.
🔵 Разобрали в чем отличие от REST и gRPC, как это работает.
🔵 Написали файл shema.graphqls, разобрали какие типы данных в нем применяются.
🔵 Как всегда немного подебажили))

Репозиторий на GitHub ждет Ваших звезд ☺️

Ссылка на Youtube
Ссылка на Рутьюб

Смотрите, ставьте лайки, подписывайтесь на каналы!✌️
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Вопрос с собеседований

Что делает класс AtomicInteger? 🤓


Ответ:

AtomicInteger
обеспечивает атомарные операции инкремента/декремента без блокировок.

Он использует низкоуровневые CAS (compare-and-swap) операции, что быстрее, чем синхронизация.

Это ключевой инструмент при реализации неблокирующих алгоритмов.



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


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

Бернар Шазель (родился 5 ноября 1955 года) — французско-американский учёный в вычислительной геометрии; автор ряда фундаментальных алгоритмических результатов (soft heap, эффективные алгоритмы MST и т.п.).


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

2007 — Компания Google представила открытую мобильную платформу Android.


#Biography #Birth_Date #Events #05Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Типы RPC в gRPC

Одно из ключевых преимуществ gRPC — это гибкость модели обмена данными.
REST традиционно работает в стиле “один запрос — один ответ”.
gRPC, в отличие от него, поддерживает четыре типа взаимодействия, и каждый из них решает свою задачу.



1. Unary RPC (один запрос — один ответ)

Это самый простой и самый распространённый тип — аналог классического REST-вызова.
Клиент отправляет один запрос, сервер обрабатывает его и возвращает один ответ.


Клиент → (один запрос) → Сервер
Сервер → (один ответ) → Клиент


Пример .proto
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
int32 id = 1;
}

message UserResponse {
string name = 1;
int32 age = 2;
}


Сервер (Java)
public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {
@Override
public void getUser(UserRequest request, StreamObserver<UserResponse> responseObserver) {
UserResponse response = UserResponse.newBuilder()
.setName("Alice")
.setAge(30)
.build();

responseObserver.onNext(response);
responseObserver.onCompleted();
}
}


Клиент
UserResponse response = stub.getUser(
UserRequest.newBuilder().setId(1).build()
);
System.out.println(response.getName());


Где применяется:
CRUD-операции (создание, получение, обновление, удаление).
Любые точечные вызовы, где не требуется поток данных.
По сути: это "REST, но бинарный, типобезопасный и в 10 раз быстрее".



2. Server Streaming RPC (поток ответов от сервера)

В этом типе клиент делает один запрос, а сервер возвращает несколько ответов последовательно — поток сообщений.

Клиент → (один запрос) → Сервер
Сервер → (много ответов в потоке) → Клиент


Сеанс продолжается, пока сервер не закончит отправку данных.

Пример .proto
service OrderService {
rpc ListOrders (OrdersRequest) returns (stream Order);
}

message OrdersRequest {
string user = 1;
}

message Order {
string id = 1;
string product = 2;
}


Сервер (Java)
public class OrderServiceImpl extends OrderServiceGrpc.OrderServiceImplBase {
@Override
public void listOrders(OrdersRequest request, StreamObserver<Order> responseObserver) {
for (int i = 1; i <= 3; i++) {
Order order = Order.newBuilder()
.setId("ORD-" + i)
.setProduct("Product " + i)
.build();

responseObserver.onNext(order);
try { Thread.sleep(1000); } catch (InterruptedException ignored) {}
}
responseObserver.onCompleted();
}
}


Клиент

stub.listOrders(OrdersRequest.newBuilder().setUser("Bob").build())
.forEachRemaining(order -> System.out.println(order.getProduct()));


Где применяется:
Поток обновлений или уведомлений.
Стриминг данных (например, список записей, логи, результаты аналитики).
Долгие вычисления, когда сервер постепенно отдаёт результаты.


Пример из реального мира:
Сервер передаёт клиенту “живой” поток котировок акций или данных из IoT-устройств.


#Java #middle #gRPC #proto
👍2
3. Client Streaming RPC (поток запросов от клиента)

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

Клиент → (много запросов) → Сервер
Сервер → (один ответ) → Клиент


Это удобно, когда клиенту нужно собрать несколько событий или пакетов данных и отправить их вместе.

Пример .proto
service UploadService {
rpc UploadPhotos (stream PhotoChunk) returns (UploadStatus);
}

message PhotoChunk {
bytes content = 1;
}

message UploadStatus {
string message = 1;
}



Сервер (Java)

public class UploadServiceImpl extends UploadServiceGrpc.UploadServiceImplBase {
@Override
public StreamObserver<PhotoChunk> uploadPhotos(StreamObserver<UploadStatus> responseObserver) {
return new StreamObserver<PhotoChunk>() {
int totalBytes = 0;

@Override
public void onNext(PhotoChunk chunk) {
totalBytes += chunk.getContent().size();
}

@Override
public void onError(Throwable t) {
System.err.println("Upload failed: " + t.getMessage());
}

@Override
public void onCompleted() {
UploadStatus status = UploadStatus.newBuilder()
.setMessage("Uploaded " + totalBytes + " bytes")
.build();
responseObserver.onNext(status);
responseObserver.onCompleted();
}
};
}
}


Клиент
StreamObserver<PhotoChunk> requestObserver = asyncStub.uploadPhotos(
new StreamObserver<UploadStatus>() {
@Override
public void onNext(UploadStatus status) {
System.out.println(status.getMessage());
}
@Override
public void onError(Throwable t) {}
@Override
public void onCompleted() {}
}
);

// Отправляем несколько чанков
requestObserver.onNext(PhotoChunk.newBuilder().setContent(ByteString.copyFrom(new byte[1000])).build());
requestObserver.onNext(PhotoChunk.newBuilder().setContent(ByteString.copyFrom(new byte[500])).build());
requestObserver.onCompleted();


Где применяется:
Отправка файлов по частям.
Отчёты, собираемые из нескольких частей.
Потоковое логирование от клиента на сервер.



#Java #middle #gRPC #proto
👍2
4. Bidirectional Streaming RPC (двунаправленный поток)

Самый мощный и сложный тип.
Клиент и сервер одновременно отправляют данные потоками.
Они не ждут завершения друг друга — общение идёт асинхронно в обе стороны.


Клиент ⇄ (двунаправленный поток) ⇄ Сервер

Пример .proto
service ChatService {
rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message ChatMessage {
string user = 1;
string text = 2;
}


Сервер (Java)
public class ChatServiceImpl extends ChatServiceGrpc.ChatServiceImplBase {
@Override
public StreamObserver<ChatMessage> chat(StreamObserver<ChatMessage> responseObserver) {
return new StreamObserver<ChatMessage>() {
@Override
public void onNext(ChatMessage message) {
// Эхо-сообщение обратно клиенту
ChatMessage reply = ChatMessage.newBuilder()
.setUser("Server")
.setText("Echo: " + message.getText())
.build();
responseObserver.onNext(reply);
}

@Override
public void onError(Throwable t) {
System.err.println("Error: " + t.getMessage());
}

@Override
public void onCompleted() {
responseObserver.onCompleted();
}
};
}
}


Клиент
StreamObserver<ChatMessage> requestObserver = asyncStub.chat(
new StreamObserver<ChatMessage>() {
@Override
public void onNext(ChatMessage value) {
System.out.println(value.getUser() + ": " + value.getText());
}
@Override
public void onError(Throwable t) {}
@Override
public void onCompleted() {}
}
);

requestObserver.onNext(ChatMessage.newBuilder().setUser("Client").setText("Hello!").build());
requestObserver.onNext(ChatMessage.newBuilder().setUser("Client").setText("How are you?").build());
requestObserver.onCompleted();


Где применяется:
Чаты и видеоконференции.
Онлайн-игры и взаимодействие в реальном времени.
Телеметрия, двунаправленные датчики, IoT.
Главная особенность: оба канала открыты, и клиент, и сервер могут посылать данные независимо друг от друга.



5. Под капотом


Все типы RPC работают поверх HTTP/2, где каждый поток — это отдельный канал в рамках одного TCP-соединения.
gRPC использует этот механизм для организации стримов.
По сути, StreamObserver в Java — это высокоуровневая абстракция над HTTP/2-стримом, обеспечивающая асинхронность и реактивное взаимодействие.



#Java #middle #gRPC #proto
👍3
Что выведет код?

import java.util.TreeMap;

public class Task061125 {
public static void main(String[] args) {
TreeMap<Integer, String> map = new TreeMap<>();
map.put(1, "one");
map.put(3, "three");
map.put(5, "five");
map.put(7, "seven");

System.out.print(map.lowerKey(4) + " ");
System.out.print(map.floorKey(4) + " ");
System.out.print(map.higherKey(4) + " ");
System.out.print(map.ceilingKey(4));
}
}


#Tasks
👍1
Варианты ответа:
Anonymous Quiz
25%
3 3 5 4
50%
3 3 5 5
13%
3 3 4 4
13%
3 4 5 4
👍1
Вопрос с собеседований

Что такое шаблон Singleton? 🤓


Ответ:

Singleton
гарантирует, что класс имеет только один экземпляр.

В Java часто реализуют через enum, так как это потокобезопасно и защищено от сериализации.

Используется для глобальных конфигураций, логгеров, кэшей, соединений.



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


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

Даниэль Крёнинг (родился 6 ноября 1975 года) — немецкий учёный-информатик, профессор в Оксфорде, сооснователь компании Diffblue Ltd; известен работами по формальной верификации микропроцессоров и инструментам автоматического анализа кода.


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

1950 — малая электронная счётная машина (МЕСМ), первая советская ЭВМ с хранимой программой, запустила свою первую программу. Разработанная под руководством Сергея Лебедева в Киеве, МЕСМ была одним из первых компьютеров в Европе и использовалась для научных и военных расчётов, заложив основу для советской компьютерной индустрии.


#Biography #Birth_Date #Events #06Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Раздел 6. Коллекции в Java

Глава 5. Map — отображения (словари)

Основные методы: get - глубокое погружение в механизм поиска элементов

Метод get является одной из фундаментальных операций в интерфейсе Map, выполняющей поиск значения по ключу. Эта операция, несмотря на простоту своего вызова, скрывает за собой сложные и оптимизированные механизмы поиска, которые варьируются в зависимости от внутренней реализации структуры данных. Понимание тонкостей работы метода get позволяет разработчикам не только писать более эффективный код, но и правильно выбирать реализации Map для конкретных сценариев использования.


Философия поиска в Map

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


Общий алгоритм работы get

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

Фаза подготовки и валидации:
Проверка ключа на null (в реализациях, которые это допускают)
Предварительная обработка ключа для оптимизации поиска
Определение стратегии поиска на основе типа Map


Фаза локализации элемента:
Вычисление местоположения элемента в структуре данных
Навигация к целевому сегменту или узлу
Обработка возможных коллизий или неоднозначностей


Фаза сравнения и извлечения:
Последовательное сравнение ключей для точного определения совпадения
Извлечение значения при успешном нахождении элемента
Возврат null или специального значения при отсутствии элемента



Детальный разбор для HashMap

Процесс вычисления хэша и определения бакета
В HashMap поиск начинается с вычисления хэш-кода ключа. Однако система не использует напрямую результат метода hashCode(). Вместо этого применяется дополнительная хэш-функция, которая "размешивает" биты исходного хэш-кода. Этот процесс, известный как "perturbation", помогает компенсировать плохое распределение хэш-кодов и уменьшает вероятность коллизий для ключей с похожими хэш-значениями.


После вычисления улучшенного хэша определяется индекс бакета в массиве. Индекс вычисляется через побитовую операцию AND между хэшем и размером массива минус один. Эта операция эффективна только благодаря тому, что размер массива в HashMap всегда является степенью двойки, что гарантирует равномерное покрытие всех возможных индексов.

Поиск в цепочке коллизий
После определения целевого бакета начинается процесс поиска в цепочке.

Здесь возможны несколько сценариев:
Бакет пуст: Самый быстрый сценарий — система немедленно возвращает null, так как элемент отсутствует.
Бакет содержит один узел: Система проверяет совпадение ключей. Сначала сравниваются хэш-коды (быстрая проверка), затем, если хэши совпали, выполняется проверка ссылочного равенства (==), и только потом — вызов метода equals(). Такой многоуровневый подход оптимизирует производительность.
Бакет содержит несколько узлов: Начинается обход цепочки.

В зависимости от структуры цепочки применяются разные стратегии:
Для связных списков (короткие цепочки) выполняется последовательный обход с проверкой каждого узла
Для красно-черных деревев (длинные цепочки в Java 8+) выполняется бинарный поиск по дереву



#Java #для_новичков #beginner #Map #get
👍1
Оптимизации в современных HashMap

В Java 8 и выше были введены значительные оптимизации для обработки длинных цепочек коллизий. Когда цепочка достигает определенного порога (обычно 8 элементов), она преобразуется из связного списка в красно-черное дерево.


Это преобразование радикально меняет сложность поиска:

В связном списке: O(n) в худшем случае
В красно-черном дереве: O(log n) в худшем случае


Такая оптимизация особенно важна для защиты от атак, основанных на намеренном создании коллизий хэш-кодов.


Особенности LinkedHashMap

В LinkedHashMap процесс поиска наследует всю базовую логику HashMap, но добавляет дополнительное поведение, связанное с поддержанием порядка доступа.


При включенном режиме access-order (когда LinkedHashMap создан с параметром accessOrder = true) успешный вызов метода get приводит к модификации внутренней структуры:
Перемещение элемента в конец: Найденный элемент перемещается в конец двусвязного списка, который поддерживает порядок доступа.

Этот процесс включает:
Разрыв связей между найденным элементом и его соседями в текущей позиции
Обновление ссылок предыдущего и следующего элементов
Установку найденного элемента как нового хвоста списка
Обновление ссылки головы списка, если перемещаемый элемент был первым


Влияние на производительность: Хотя операция перемещения требует дополнительных вычислений, ее стоимость постоянна (O(1)) и не зависит от размера Map. Это делает LinkedHashMap идеальным выбором для реализации LRU-кэшей.


Специфика TreeMap

В TreeMap механизм поиска кардинально отличается от хэш-базированных реализаций, поскольку основан на бинарном дереве поиска:

Алгоритм поиска в красно-черном дереве

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


Сравнение ключей
TreeMap использует один из двух механизмов сравнения ключей:
Естественный порядок: Если ключи реализуют интерфейс Comparable
Внешний компаратор: Если TreeMap создан с предоставленным Comparator


Процесс сравнения может быть сложным и включать множественные вызовы методов сравнения, особенно для составных ключей или кастомных компараторов.

Гарантии производительности
Благодаря свойствам красно-черного дерева, TreeMap гарантирует логарифмическое время поиска O(log n) даже в худшем случае.

Это достигается за счет:
Автоматической балансировки дерева после модификаций
Соблюдения свойств красно-черного дерева
Оптимизированных алгоритмов навигации



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

ConcurrentHashMap

В ConcurrentHashMap механизм поиска оптимизирован для многопоточного доступа:
Неблокирующее чтение: Операция get в большинстве случаев не требует блокировок, что позволяет множеству потоков одновременно читать данные.
Memory consistency: Гарантии согласованности памяти обеспечивают, что поток увидит все завершенные операции put, которые произошли до начала операции get.
Сегментированный доступ: В старых версиях поиск ограничивается одним сегментом, в новых — используются более тонкие механизмы блокировок.


EnumMap

EnumMap предоставляет наиболее эффективный механизм поиска:
Поиск превращается в простую операцию доступа к массиву по индексу
Индекс вычисляется на основе ordinal значения enum
Сложность O(1) с минимальными накладными расходами



IdentityHashMap

Особенность поиска в IdentityHashMap — использование ссылочного равенства (==) вместо equals():
Сравнение ключей происходит по ссылке, а не по содержимому
Хэш-код вычисляется на основе System.identityHashCode()
Полезно для сценариев, где нужно различать объекты по идентичности, а не по состоянию



#Java #для_новичков #beginner #Map #get
👍1
Обработка особых случаев

Работа с null ключами

Разные реализации по-разному обрабатывают null ключи:
HashMap: Специально обрабатывает null ключ, храня его в бакете 0
TreeMap: Не поддерживает null ключи (NullPointerException)
ConcurrentHashMap: Не поддерживает null ключи из-за многопоточных ограничений

Коллизии и равенство ключей

Процесс определения равенства ключей критически важен для корректности поиска.

Система использует комбинацию проверок:
Сравнение хэш-кодов: Быстрая предварительная проверка
Проверка ссылочного равенства (==): Оптимизация для часто используемых ключей
Вызов equals(): Точное определение семантического равенства

Разработчики должны обеспечивать консистентность между hashCode() и equals() — равные объекты должны иметь равные хэш-коды.


Факторы, влияющие на производительность

Для HashMap

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

Для TreeMap
Сбалансированность дерева: Хотя красно-черное дерево гарантирует сбалансированность, степень сбалансированности влияет на константные множители производительности.
Сложность сравнения: Для ключей со сложной логикой сравнения стоимость операции get может значительно возрастать.


Потокобезопасность и видимость изменений

В контексте многопоточного программирования операция get имеет важные семантические особенности:
Несинхронизированные Map: В HashMap, LinkedHashMap, TreeMap операция get не является потокобезопасной при concurrent модификациях. Это может привести к бесконечным циклам, повреждению данных или неконсистентным результатам.
ConcurrentHashMap: Обеспечивает thread-safe операции get без блокировок, но с гарантиями weak consistency — поток может не увидеть недавно добавленные элементы.
Memory barriers: В правильно синхронизированных сценариях операция get обеспечивает happens-before отношения для последующих операций.


Кэширование и оптимизации поиска


Современные JVM применяют различные оптимизации для ускорения операций поиска:
Inline-кэширование: JVM может закэшировать результаты частых операций поиска для одинаковых ключей.
Профилирование вызовов: Сбор статистики о частоте и паттернах доступа для оптимизации горячих путей.
JIT-компиляция: Агрессивная оптимизация и развертывание циклов в критических участках кода.


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

Выбор реализации для различных сценариев

Для частых операций get:
HashMap с хорошими хэш-функциями — лучший выбор
EnumMap — для enum ключей
IdentityHashMap — когда нужна ссылочная семантика


Для отсортированного доступа:
TreeMap — когда нужна сортировка или диапазонные запросы

Для многопоточных сценариев:
ConcurrentHashMap — для высококонкурентного доступа
Collections.synchronizedMap() — для низкой конкуренции


Оптимизация ключей
Неизменяемость: Использование immutable ключей предотвращает изменение хэш-кода и обеспечивает консистентность.

Эффективные equals() и hashCode():

Минимизация вычислений в этих методах
Кэширование хэш-кода для сложных объектов
Использование быстрых алгоритмов сравнения
Правильный размер: Предварительное задание адекватной емкости для HashMap уменьшает необходимость resize операций.

Отладка и мониторинг
Для диагностики проблем с производительностью операции get полезны:
Профилирование: Измерение времени, проводимого в операциях get
Анализ распределения: Для HashMap — мониторинг длины цепочек коллизий
JMX мониторинг: Для стандартных реализаций Map доступна статистика через JMX


#Java #для_новичков #beginner #Map #get
👍1
Что выведет код?

import java.util.Map;
import java.util.HashMap;

public class Task051125 {
public static void main(String[] args) {
Map<String, Integer> map = new HashMap<>();
map.put("a", 1);
map.put("b", 2);
map.put("c", null);

Integer value1 = map.get("a");
Integer value2 = map.get("c");
Integer value3 = map.get("d");
int value4 = map.getOrDefault("d", -1);

System.out.println(value1);
System.out.println(value2);
System.out.println(value3);
System.out.println(value4);
}
}


#Tasks
Варианты ответа:
Anonymous Quiz
82%
1 null null -1
9%
1 0 0 -1
0%
1 null 0 -1
9%
1 0 null -1
Вопрос с собеседований

Чем отличается Factory от Builder? 🤓


Ответ:

Factory
отвечает за создание объекта определённого типа без явного вызова конструктора.

Builder — за пошаговое создание сложного объекта с множеством параметров.

Factory — «что создать», Builder — «как создать».



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