Библиотека Java разработчика
📚 Лайфхаки, приёмы и лучшие практики для Java-разработчиков. Всё, что ускорит код и прокачает навыки. Java, Spring, Maven, Hibernate. По всем вопросам @evgenycarter РКН clck.ru/3KoGeP
Ko'proq ko'rsatish📈 Telegram kanali Библиотека Java разработчика analitikasi
Библиотека Java разработчика (@bookjava) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 266 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 12 016-o'rinni va Rossiya mintaqasida 63 847-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 266 obunachiga ega bo‘ldi.
13 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 13 ga, so‘nggi 24 soatda esa 3 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 8.59% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 4.32% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 882 marta ko‘riladi; birinchi sutkada odatda 443 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 7 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent string, интерфейс, строка, boot, api kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“📚 Лайфхаки, приёмы и лучшие практики для Java-разработчиков. Всё, что ускорит код и прокачает навыки. Java, Spring, Maven, Hibernate.
По всем вопросам @evgenycarter
РКН clck.ru/3KoGeP”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 14 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
.class файл. Его содержимое рассмотрим позднее.
Теме посвящена глава 8 спецификации.
Класс бывает:
1. Абстрактный – помеченный ключевым словом abstract. Не может иметь экземпляры, может иметь нереализованные абстрактные методы, также с модификатором abstract и без тела. Похож на частично реализованный интерфейс с состоянием, хотя с точки зрения JVM это совсем другая сущность;
2. Внутренний (inner, non-static nested) – объявленный внутри другого класса. Не может иметь статических объявлений. Имеет доступ ко всем внутренностям экземпляра внешнего класса. Если член внешнего класса foo перекрыт членом внутреннего (shadowing), обратиться к внешнему можно с помощью конструкции OuterClassname.this.foo, без перекрытия сработает просто foo. Инстанциируется только от экземпляра внешнего класса: outer.new Inner();
3. Вложенный (nested, inner static) – имеет доступ ко всем статическим членам внешнего класса. В остальном ничем не отличается от обычного класса;
4. Локальный – объявленный внутри метода. Является внутренним классом, в случае объявления в статическом методе без доступа к экземпляру внешнего класса. Не имеет модификаторов доступа;
5. Анонимный – локальный класс, объявленный без имени, непосредственно при инстанциировании, расширением другого класса или интерфейса. В отличие от других вложенных классов, анонимный может расширять только один класс или интерфейс. Не может быть абстрактным или финальным. Лямбда-выражение является сокращенной записью создания объекта анонимного наследника функционального интерфейса;
6. Финальный – с модификатором final, нерасширяемый;
Внутренние и вложенные классы могут иметь несколько уровней вложенности. Модификаторы abstract и final несовместимы, но по отдельности применимы к различным внутренним классам (кроме анонимного). Подробно разные виды вложенных классов рассмотрены в официальном туториале.
#КлассыComparator;
• создания объекта процесса (process object), такого как экземпляры классов Thread, Runnable и подобных;
• в статическом методе генерации;
• инициализации открытого статического поля final, которое соответствует сложному перечислению типов, когда для каждого экземпляра в перечислении требуется отдельный подкласс.'\u0000'(0) до '\uffff'(65535);
🔘 boolean – true или false;
По умолчанию поля примитивных типов принимают нулевые значения: 0, 0L, '\u0000', false. Про особенности работы, способ хранения и специальные значения чисел с плавающей точкой стоит почитать подробнее.
Отдельная интересная тема – boxing/unboxing. Каждый примитивный тип снабжен своей ссылочной версией. Примитивное значение заворачивается и разворачивается из него автоматически при необходимости. Это может приводить к большим затратам на выделение памяти, когда например int индекс цикла используется в качестве значения переменной Object и превращается в Integer без нужды – частая задача на собеседованиях. Еще классы-обертки содержат набор утилитарных методов для их примитивов.
Сколько памяти занимает примитив – вопрос с подвохом. Спецификация требует, чтобы размер был достаточным для всех значений. Конкретный размер определяется реализацией JVM, он может быть больше. Например в 64-bit HotSpot переменная boolean занимает не 1 бит, а 8.
Для полного погружения рекомендуется подробный официальный туториал по примитивным типам.
#КлассыCollections.synchronized*(). Самый общий и самый примитивный способ, создает обертку с синхронизацией всех операций с помощью synchronized.
Если работа с коллекцией состоит в основном из чтения, лучшая в плане производительности альтернатива – CopyOnWriteArrayList, и содержащий его в реализации CopyOnWriteArraySet. Потокобезопасность достигается копированием внутреннего массива при любой модификации, оригинальный массив остается immutable. Program order достигается модификатором volatile на внутреннем массиве.
Третий вариант – использование Concurrent-коллекций:
🔘 Неблокирующие хэш-таблицы ConcurrentSkipListMap, ConcurrentHashMap и ConcurrentSkipListSet (хэш-таблица в основе реализации)
🔘 Неблокирующие очереди ConcurrentLinkedQueue и ConcurrentLinkedDeque
🔘 Большой набор различных блокирующих очередей
#Коллекции
#МногопоточностьCollections.unmodifiable*() для различных типов коллекций. Такой метод вернет read-only обертку над переданной коллекцией. Так же как с Collections.synchronized*(), внутри используется не копия, а оригинальная коллекция.
Другой менее очевидный способ – метод Collections.empty*(). Он возвращает немодифицируемую пустую коллекцию. Попытка добавить элемент как и в случае unmodifiable приведет к UnsupportedOperationException.
#КоллекцииMap можно привести ключи/значения к виду Collection, переложить в новый List и отсортировать с помощью Collections.sort. То же делается с Set. Этот метод конечно же неэффективный, так как потребует полного копирования содержимого.
Эффективный способ – хранить данные уже отсортированными. Для таких реализаций созданы интерфейсы-наследники SortedSet и SortedMap.
Реализации SortedSet дают линейный порядок множества. Элементы упорядочены по возрастанию. Порядок либо натуральный (элементы реализуют интерфейс Comparable), либо его определяет переданный в конструктор Comparator.
Этот интерфейс добавляет методы получения подмножества от указанного элемента (tailSet), до элемента (headSet), и между двумя (subSet). Подмножество включает нижнюю границу, не включает верхнюю.
SortedSet расширяется интерфейсом NavigableSet для итерации по порядку, получения ближайшего снизу (floor), сверху (ceiling), большего (higher) и меньшего (lower) заданному элемента.
Все те же правила применяются к элементам SortedMap/NavigableMap относительно их ключей.
Основными реализациями являются TreeSet и TreeMap. Внутри это самобалансирующиеся красно-чёрные деревья. Их структура и способ балансировки – вопрос достойный отдельного поста. Другая любопытная реализация из java.util.concurrent – ConcurrentSkipListMap.
#КоллекцииHashMap. Реализация подробно рассмотрена во множестве статей, например на хабре.
Нюансы которые стоит повторить и запомнить:
🔘 Общий принцип: внутренний массив table, содержащий бакеты (корзины) – списки элементов с одинаковыми пересчитанными хэш-суммами;
🔘 Пересчет хэш-суммы для умещения int индексов в capacity ячейках table;
🔘 rehash – удвоение размера table при достижении threshold (capacity*loadFactor) занятых бакетов;
🔘 Невозможность сжать однажды раздувшийся table;
🔘 Два способа разрешения коллизий: используемый в HashMap метод цепочек и альтернатива – открытая адресация;
🔘 Варианты для многопоточного использования: пересинхронизированная Hashtable и умная ConcurrentHashMap;
🔘 Оптимизация Java 8: превращение списка в бакете в дерево при достижении 8 элементов – при большом количестве коллизий скорость доступа растет с O(n) до O(log(n));
🔘 Явное использование бакета 0 для ключа null;
🔘 Связь с HashSet – HashMap, в котором используются только ключи;
🔘 Нет гарантий порядка элементов;
Обсуждая этот вопрос на интервью вы обязательно затронете особенности методов equals/hashCode. Возможно придется поговорить об альтернативных хранилищах ключ-значение – TreeMap, LinkedHashMap.Collection – хранилище отдельных значений, Map – хранилище ключ-значение. Отсюда разные методы этих интерфейсов. Если проще, разные сигнатуры методов put и add.
Collection в свою очередь делится на три основных группы, и соответствующих им интерфейса:
🔘 List – упорядоченные списки с возможностью содержания дубликатов и доступа по индексу (random access);
🔘 Queue – обычно FIFO-коллекции, предполагает добавление/удаление элементов с края. Интерфейс-наследник Deque – двусвязная очередь;
🔘 Set – не обязательно упорядоченный набор уникальных (с точки зрения equals) значений;
HashMap можно привести к виду Collection вызвав например keySet(), entrySet() или values().
Большой обзор фреймворка и сравнение эффективности коллекций можно найти в статье на хабре. Для разговора об эффективности нужно понимать что такое О-нотация. Другая статья содержит практические замеры быстродействия (осторожно, старая публикация, Java 6).arraycopy() в Java чтобы объединить два массива в один,
пример пример кода.
Подписывайтесь на канал 👉@coddy_academy
#javafor (String item : arrayList)
if (item.length() > 2)
arrayList.remove(item);
Подвох в том, что итератор ArrayList, который используется в таком варианте цикла for, является fail-fast, то есть не поддерживает итерацию с параллельной модификацией. А параллельная модификация случается даже в одном потоке, что демонстрирует этот пример. Следующий шаг итератора после удаления элемента выбросит ConcurrentModificationException.
Не исключение, но неожиданный результат получится если пользоваться не итератором, а обычным циклом for – при каждом удалении нумерация элементов будет сдвигаться.
Единственный способ удалить элемент из коллекции при обходе, не получив при этом ConcurrentModificationException или неопределенное поведение – удалить с помощью remove() того же инстанса итератора. Вариант ListIterator поможет, если в теле цикла требуется и работа с индексами.
Некоторые коллекции, такие как CopyOnWriteArrayList и ConcurrentHashMap адаптированные под многопоточную среду и имеют fail-safe итераторы.
#Коллекции
Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
