Раздел 6. Коллекции в Java
Глава 5. Map — отображения (словари)
Интерфейс Map<K, V> — это часть Java Collections Framework (JCF) из пакета java.util, который представляет структуру для хранения ассоциативных данных. В отличие от других коллекций, таких как List или Set, которые хранят отдельные элементы, Map хранит пары, где каждый ключ (K) связан с значением (V). Это позволяет быстро находить значение по ключу, как в словаре или телефонной книге.
Основные понятия:
Ключ (Key): Уникальный идентификатор для доступа к значению. Ключи не могут дублироваться — если добавить пару с существующим ключом, значение перезапишется.
Значение (Value): Данные, ассоциированные с ключом. Значения могут дублироваться.
Пара (Entry): Единица хранения в Map — комбинация ключа и значения.
Map моделирует математическое отображение (mapping), где каждый ключ maps to ровно одно значение. Это делает Map идеальным для сценариев, где нужна ассоциация, например, ID пользователя — профиль, слово — перевод.
Отличия от Collection:
Map не расширяет Collection<E> — это отдельная ветвь JCF.
Collection — последовательность элементов, Map — ассоциативный массив.
В Map нет индексации (нет get(int index)), доступ только по ключу.
Размер Map — количество пар, не элементов.
Generics в Map: <K, V> обеспечивает типобезопасность: ключи одного типа (например, Integer), значения другого (String). Без generics (raw Map) — устарело и небезопасно.
Хранение пар «ключ–значение»: Особенности
Map хранит данные в форме пар, где ключ — уникальный, а значение — связанное с ним. Это позволяет эффективно решать задачи поиска и ассоциации.
Уникальность ключей:
Ключи всегда уникальны: Map не позволяет дубликаты ключей. Если ключ уже существует, значение обновляется.
Уникальность определяется методами equals() и hashCode() (в hash-based реализациях) или compareTo() (в sorted).
Нюанс: Для custom ключей обязательно переопределите equals() и hashCode() — иначе уникальность по ссылке, не по значению.
Дубликаты значений:
Значения могут повторяться: Несколько ключей могут ссылаться на одно значение.
Нюанс: Если значение — mutable объект, изменения в одном месте отразятся везде (по ссылке).
Null в Map:
Ключи: Большинство реализаций позволяют один null-ключ (HashMap, LinkedHashMap), но TreeMap — нет (NullPointerException).
Значения: Null разрешен всегда.
Порядок в Map:
В общем случае нет (зависит от реализации): Не полагайтесь на порядок пар.
Нюанс: Map не упорядочен, как List, но некоторые реализации добавляют порядок.
Размер и емкость:
Размер (size()) — количество пар.
Емкость: В hash-based — initial capacity и load factor (например, 0.75 — при заполнении >75% ресайз).
Производительность:
В среднем O(1) для доступа по ключу в hash-based, O(log n) в tree-based.
Нюанс: Зависит от качества hashCode() — плохие хэши приводят к деградации до O(n).
Полезные советы для новичков
Выбор типов K/V: Ключи — immutable (String, Integer), чтобы избежать изменений, влияющих на хэш.
Custom ключи: Переопределяйте equals/hashCode (IDE поможет: Generate → equals() and hashCode()).
Map vs другие коллекции: Используйте Map для ассоциаций, Set для уникальных элементов, List для последовательностей.
#Java #для_новичков #beginner #Map
Глава 5. Map — отображения (словари)
Интерфейс Map<K, V> — это часть Java Collections Framework (JCF) из пакета java.util, который представляет структуру для хранения ассоциативных данных. В отличие от других коллекций, таких как List или Set, которые хранят отдельные элементы, Map хранит пары, где каждый ключ (K) связан с значением (V). Это позволяет быстро находить значение по ключу, как в словаре или телефонной книге.
Основные понятия:
Ключ (Key): Уникальный идентификатор для доступа к значению. Ключи не могут дублироваться — если добавить пару с существующим ключом, значение перезапишется.
Значение (Value): Данные, ассоциированные с ключом. Значения могут дублироваться.
Пара (Entry): Единица хранения в Map — комбинация ключа и значения.
Map моделирует математическое отображение (mapping), где каждый ключ maps to ровно одно значение. Это делает Map идеальным для сценариев, где нужна ассоциация, например, ID пользователя — профиль, слово — перевод.
Отличия от Collection:
Map не расширяет Collection<E> — это отдельная ветвь JCF.
Collection — последовательность элементов, Map — ассоциативный массив.
В Map нет индексации (нет get(int index)), доступ только по ключу.
Размер Map — количество пар, не элементов.
Generics в Map: <K, V> обеспечивает типобезопасность: ключи одного типа (например, Integer), значения другого (String). Без generics (raw Map) — устарело и небезопасно.
Хранение пар «ключ–значение»: Особенности
Map хранит данные в форме пар, где ключ — уникальный, а значение — связанное с ним. Это позволяет эффективно решать задачи поиска и ассоциации.
Уникальность ключей:
Ключи всегда уникальны: Map не позволяет дубликаты ключей. Если ключ уже существует, значение обновляется.
Уникальность определяется методами equals() и hashCode() (в hash-based реализациях) или compareTo() (в sorted).
Нюанс: Для custom ключей обязательно переопределите equals() и hashCode() — иначе уникальность по ссылке, не по значению.
Дубликаты значений:
Значения могут повторяться: Несколько ключей могут ссылаться на одно значение.
Нюанс: Если значение — mutable объект, изменения в одном месте отразятся везде (по ссылке).
Null в Map:
Ключи: Большинство реализаций позволяют один null-ключ (HashMap, LinkedHashMap), но TreeMap — нет (NullPointerException).
Значения: Null разрешен всегда.
Порядок в Map:
В общем случае нет (зависит от реализации): Не полагайтесь на порядок пар.
Нюанс: Map не упорядочен, как List, но некоторые реализации добавляют порядок.
Размер и емкость:
Размер (size()) — количество пар.
Емкость: В hash-based — initial capacity и load factor (например, 0.75 — при заполнении >75% ресайз).
Производительность:
В среднем O(1) для доступа по ключу в hash-based, O(log n) в tree-based.
Нюанс: Зависит от качества hashCode() — плохие хэши приводят к деградации до O(n).
Полезные советы для новичков
Выбор типов K/V: Ключи — immutable (String, Integer), чтобы избежать изменений, влияющих на хэш.
Custom ключи: Переопределяйте equals/hashCode (IDE поможет: Generate → equals() and hashCode()).
Map vs другие коллекции: Используйте Map для ассоциаций, Set для уникальных элементов, List для последовательностей.
#Java #для_новичков #beginner #Map
👍4
Что выведет код?
#Tasks
import java.util.HashMap;
import java.util.Map;
public class Task291025 {
public static void main(String[] args) {
Map<String, Integer> map = new HashMap<>();
map.put("a", 1);
map.put("b", 2);
map.put("a", 3);
map.putIfAbsent("b", 4);
map.putIfAbsent("c", 5);
System.out.println(map.get("a"));
System.out.println(map.get("b"));
System.out.println(map.get("c"));
System.out.println(map.getOrDefault("d", 6));
}
}
#Tasks
👍1
👍1
Вопрос с собеседований
Что такое strong, soft, weak и phantom ссылки?🤓
Ответ:
Strong — обычная ссылка, объект не собирается GC.
Soft — GC удалит объект при нехватке памяти.
Weak — GC удалит при первой возможности.
Phantom — используется для отслеживания удаления объекта. Эти типы ссылок помогают управлять кэшами и жизненным циклом объектов.
#собеседование
Что такое strong, soft, weak и phantom ссылки?
Ответ:
Strong
Soft — GC удалит объект при нехватке памяти.
Weak — GC удалит при первой возможности.
Phantom — используется для отслеживания удаления объекта. Эти типы ссылок помогают управлять кэшами и жизненным циклом объектов.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
История IT-технологий сегодня — 30 октября
ℹ️ Кто родился в этот день
Андре́й Никола́евич Ти́хонов (17 [30] октября 1906, Гжатск (в настоящее время город Гагарин) Смоленской губернии — 7 октября 1993, Москва) — советский математик и геофизик, академик Академии наук СССР, дважды Герой Социалистического Труда. Основатель факультета вычислительной математики и кибернетики МГУ.
Карло Генрих Сейкин (родился 30 октября 1941 года) — швейцарско-американский компьютерный учёный, профессор Университета Калифорнии, Беркли; пионер в области архитектуры процессоров, компьютерной графики и CAD-инструментов для проектирования электронных схем.
🌐 Знаковые события
1907 — русский физик Борис Розинг в ответ на поданную им 25 июля заявку получил патент № 18076 на «Способ электрической передачи изображений на расстояние», то есть телевидение.
#Biography #Birth_Date #Events #30Октября
Андре́й Никола́евич Ти́хонов (17 [30] октября 1906, Гжатск (в настоящее время город Гагарин) Смоленской губернии — 7 октября 1993, Москва) — советский математик и геофизик, академик Академии наук СССР, дважды Герой Социалистического Труда. Основатель факультета вычислительной математики и кибернетики МГУ.
Карло Генрих Сейкин (родился 30 октября 1941 года) — швейцарско-американский компьютерный учёный, профессор Университета Калифорнии, Беркли; пионер в области архитектуры процессоров, компьютерной графики и CAD-инструментов для проектирования электронных схем.
1907 — русский физик Борис Розинг в ответ на поданную им 25 июля заявку получил патент № 18076 на «Способ электрической передачи изображений на расстояние», то есть телевидение.
#Biography #Birth_Date #Events #30Октября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Как вы себя оцениваете по грейду?
Anonymous Poll
55%
Я наверно даже не джун
27%
Я точно джун
9%
Я уверенный мидл
9%
Сеньор я
👍1
Архитектура gRPC: как всё работает под капотом
gRPC — это современный фреймворк удалённого вызова процедур (RPC, Remote Procedure Call), разработанный Google. Он позволяет приложениям общаться друг с другом как будто они вызывают локальные функции, хотя на самом деле взаимодействие идёт по сети. Чтобы понять, почему gRPC так эффективен, нужно разобрать его архитектуру и то, что происходит «под капотом».
1. Концепция gRPC: RPC-модель нового поколения
RPC (Remote Procedure Call) — это подход, при котором одна программа может вызвать функцию, которая физически исполняется на другом сервере.
В классической модели RPC разработчик просто вызывает метод, а инфраструктура берёт на себя всё — упаковку данных, передачу по сети и распаковку на другой стороне.
gRPC реализует эту идею, но в современном, высокопроизводительном виде — поверх HTTP/2 и с использованием Protocol Buffers для сериализации.
2. Основные участники архитектуры
Клиент (Client)
Это программа, которая инициирует вызов удалённого метода. Она не знает деталей того, как сервер устроен внутри.
Клиент работает с client stub — это локальный объект, который выглядит как обычный класс с методами, но при вызове каждого метода на самом деле выполняется сетевое обращение к серверу.
Сервер (Server)
Это приложение, которое реализует интерфейс, описанный в .proto файле. Сервер принимает запросы от клиентов, обрабатывает их и отправляет ответы.
Client Stub и Server Stub
Что такое Stub
Stub — это «заглушка», или точнее — сгенерированный код, который связывает ваш код с gRPC-инфраструктурой.
Client Stub (клиентская заглушка) — это класс, который содержит методы, соответствующие сервисам, определённым в .proto.
Когда вы вызываете метод stub.buyCar(request), gRPC автоматически:
Сериализует объект request в бинарный формат.
Отправляет его по сети через HTTP/2.
Получает ответ, десериализует и возвращает его как обычный объект Java.
Server Stub — это абстрактный класс, который вы расширяете, чтобы реализовать свою бизнес-логику. Он автоматически принимает входящие вызовы, десериализует данные и вызывает ваш метод.
Пример:
После генерации protoc создаёт классы:
Реализация сервера:
Клиент:
#Java #middle #gRPC
gRPC — это современный фреймворк удалённого вызова процедур (RPC, Remote Procedure Call), разработанный Google. Он позволяет приложениям общаться друг с другом как будто они вызывают локальные функции, хотя на самом деле взаимодействие идёт по сети. Чтобы понять, почему gRPC так эффективен, нужно разобрать его архитектуру и то, что происходит «под капотом».
1. Концепция gRPC: RPC-модель нового поколения
RPC (Remote Procedure Call) — это подход, при котором одна программа может вызвать функцию, которая физически исполняется на другом сервере.
В классической модели RPC разработчик просто вызывает метод, а инфраструктура берёт на себя всё — упаковку данных, передачу по сети и распаковку на другой стороне.
gRPC реализует эту идею, но в современном, высокопроизводительном виде — поверх HTTP/2 и с использованием Protocol Buffers для сериализации.
2. Основные участники архитектуры
Клиент (Client)
Это программа, которая инициирует вызов удалённого метода. Она не знает деталей того, как сервер устроен внутри.
Клиент работает с client stub — это локальный объект, который выглядит как обычный класс с методами, но при вызове каждого метода на самом деле выполняется сетевое обращение к серверу.
Сервер (Server)
Это приложение, которое реализует интерфейс, описанный в .proto файле. Сервер принимает запросы от клиентов, обрабатывает их и отправляет ответы.
Client Stub и Server Stub
Что такое Stub
Stub — это «заглушка», или точнее — сгенерированный код, который связывает ваш код с gRPC-инфраструктурой.
Client Stub (клиентская заглушка) — это класс, который содержит методы, соответствующие сервисам, определённым в .proto.
Когда вы вызываете метод stub.buyCar(request), gRPC автоматически:
Сериализует объект request в бинарный формат.
Отправляет его по сети через HTTP/2.
Получает ответ, десериализует и возвращает его как обычный объект Java.
Server Stub — это абстрактный класс, который вы расширяете, чтобы реализовать свою бизнес-логику. Он автоматически принимает входящие вызовы, десериализует данные и вызывает ваш метод.
Пример:
// .proto файл
syntax = "proto3";
service CarService {
rpc BuyCar (CarRequest) returns (CarResponse);
}
message CarRequest {
string model = 1;
int32 budget = 2;
}
message CarResponse {
string status = 1;
}
После генерации protoc создаёт классы:
CarServiceGrpc.CarServiceImplBase — Server Stub
CarServiceGrpc.CarServiceBlockingStub и CarServiceGrpc.CarServiceFutureStub — Client Stubs
Реализация сервера:
public class CarServiceImpl extends CarServiceGrpc.CarServiceImplBase {
@Override
public void buyCar(CarRequest request, StreamObserver<CarResponse> responseObserver) {
String result = "You bought: " + request.getModel();
CarResponse response = CarResponse.newBuilder()
.setStatus(result)
.build();
responseObserver.onNext(response);
responseObserver.onCompleted();
}
}Клиент:
ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8080)
.usePlaintext()
.build();
CarServiceGrpc.CarServiceBlockingStub stub = CarServiceGrpc.newBlockingStub(channel);
CarRequest request = CarRequest.newBuilder()
.setModel("Tesla Model 3")
.setBudget(50000)
.build();
CarResponse response = stub.buyCar(request);
System.out.println(response.getStatus());#Java #middle #gRPC
3. Роль Protocol Buffers (protobuf)
Protocol Buffers — это бинарный формат сериализации данных, разработанный Google. Он выполняет две функции:
Описание структуры данных (через .proto файл).
Это аналог схемы JSON или XML, но строгий и типизированный.
Сериализация и десериализация (преобразование объектов в компактную бинарную форму и обратно).
Пример .proto файла не только описывает сообщения, но и определяет сервис (то есть API интерфейс).
Почему protobuf — ключевой элемент:
Он компактен: бинарный формат в несколько раз меньше JSON.
Он типобезопасен: при компиляции проверяются типы.
Он быстр: сериализация и десериализация работают на уровне байтов, без парсинга текста.
4. Как происходит сериализация и десериализация
Сериализация — это процесс превращения объекта в поток байтов для передачи по сети.
Десериализация — обратный процесс.
В gRPC:
Клиент вызывает метод stub.method(request).
request сериализуется с помощью Protocol Buffers в бинарный поток.
Поток отправляется через HTTP/2.
Сервер принимает поток, десериализует его обратно в объект CarRequest.
После обработки сервер сериализует ответ (CarResponse) и отправляет обратно.
Важно: gRPC сам управляет сериализацией. Вам не нужно ничего кодировать вручную — всё делает сгенерированный stub.
5. Что делает protoc и зачем нужны плагины
protoc — это компилятор Protocol Buffers. Он принимает .proto файл и генерирует исходный код для нужного языка.
Например:
gRPC добавляет ещё один плагин — --grpc-java_out, который генерирует код для stub'ов.
Таким образом, protoc создаёт:
Классы-сообщения (CarRequest, CarResponse)
gRPC классы (CarServiceGrpc, Stub и ImplBase)
Для каждого языка есть свой плагин:
--grpc-java_out для Java
--grpc-python_out для Python
--grpc-go_out для Go
и т. д.
Это и есть причина, почему gRPC мультиплатформенный — интерфейс описывается один раз в .proto, а код для всех языков генерируется автоматически.
6. Почему gRPC быстрее REST
gRPC построен поверх HTTP/2, а REST — чаще всего поверх HTTP/1.1. Разница принципиальна.
Ключевые причины производительности:
HTTP/2 поддерживает мультиплексирование — можно отправлять несколько запросов в одном соединении без блокировки.
Сжатие заголовков (HPACK) уменьшает накладные расходы.
Бинарная сериализация (protobuf) — меньше данных, быстрее парсинг.
Постоянное соединение — нет затрат на открытие/закрытие TCP для каждого запроса.
Streaming — можно передавать поток данных, а не ждать полного ответа (например, поток логов или большого файла).
7. Суммарно: что происходит при вызове метода в gRPC
Пошагово:
Клиент вызывает метод stub.someMethod(request).
Stub сериализует объект через protobuf.
Сериализованные данные упаковываются в HTTP/2 фрейм и отправляются на сервер.
Сервер принимает фрейм, десериализует данные.
Вызвается метод реализации (ImplBase).
Сервер формирует ответ, сериализует через protobuf.
Ответ отправляется обратно по тому же соединению.
Клиент получает и десериализует ответ.
Для разработчика — это выглядит как обычный вызов функции.
Под капотом же происходит оптимизированное сетевое взаимодействие с минимальными потерями.
#Java #middle #gRPC
Protocol Buffers — это бинарный формат сериализации данных, разработанный Google. Он выполняет две функции:
Описание структуры данных (через .proto файл).
Это аналог схемы JSON или XML, но строгий и типизированный.
Сериализация и десериализация (преобразование объектов в компактную бинарную форму и обратно).
Пример .proto файла не только описывает сообщения, но и определяет сервис (то есть API интерфейс).
Почему protobuf — ключевой элемент:
Он компактен: бинарный формат в несколько раз меньше JSON.
Он типобезопасен: при компиляции проверяются типы.
Он быстр: сериализация и десериализация работают на уровне байтов, без парсинга текста.
4. Как происходит сериализация и десериализация
Сериализация — это процесс превращения объекта в поток байтов для передачи по сети.
Десериализация — обратный процесс.
В gRPC:
Клиент вызывает метод stub.method(request).
request сериализуется с помощью Protocol Buffers в бинарный поток.
Поток отправляется через HTTP/2.
Сервер принимает поток, десериализует его обратно в объект CarRequest.
После обработки сервер сериализует ответ (CarResponse) и отправляет обратно.
Важно: gRPC сам управляет сериализацией. Вам не нужно ничего кодировать вручную — всё делает сгенерированный stub.
5. Что делает protoc и зачем нужны плагины
protoc — это компилятор Protocol Buffers. Он принимает .proto файл и генерирует исходный код для нужного языка.
Например:
protoc --java_out=./build/generated proto/car.proto
gRPC добавляет ещё один плагин — --grpc-java_out, который генерирует код для stub'ов.
protoc --plugin=protoc-gen-grpc-java=path/to/protoc-gen-grpc-java \
--grpc-java_out=./build/generated \
--java_out=./build/generated \
proto/car.proto
Таким образом, protoc создаёт:
Классы-сообщения (CarRequest, CarResponse)
gRPC классы (CarServiceGrpc, Stub и ImplBase)
Для каждого языка есть свой плагин:
--grpc-java_out для Java
--grpc-python_out для Python
--grpc-go_out для Go
и т. д.
Это и есть причина, почему gRPC мультиплатформенный — интерфейс описывается один раз в .proto, а код для всех языков генерируется автоматически.
6. Почему gRPC быстрее REST
gRPC построен поверх HTTP/2, а REST — чаще всего поверх HTTP/1.1. Разница принципиальна.
Ключевые причины производительности:
HTTP/2 поддерживает мультиплексирование — можно отправлять несколько запросов в одном соединении без блокировки.
Сжатие заголовков (HPACK) уменьшает накладные расходы.
Бинарная сериализация (protobuf) — меньше данных, быстрее парсинг.
Постоянное соединение — нет затрат на открытие/закрытие TCP для каждого запроса.
Streaming — можно передавать поток данных, а не ждать полного ответа (например, поток логов или большого файла).
7. Суммарно: что происходит при вызове метода в gRPC
Пошагово:
Клиент вызывает метод stub.someMethod(request).
Stub сериализует объект через protobuf.
Сериализованные данные упаковываются в HTTP/2 фрейм и отправляются на сервер.
Сервер принимает фрейм, десериализует данные.
Вызвается метод реализации (ImplBase).
Сервер формирует ответ, сериализует через protobuf.
Ответ отправляется обратно по тому же соединению.
Клиент получает и десериализует ответ.
Для разработчика — это выглядит как обычный вызов функции.
Под капотом же происходит оптимизированное сетевое взаимодействие с минимальными потерями.
#Java #middle #gRPC