👀 Внутреннее устройство LinkedList

LinkedList — это классическая реализация двусвязного списка. На поверхности он выглядит как обычная коллекция, реализующая интерфейсы List, Deque и Queue. Но под капотом это структура узлов (Node), которые связаны друг с другом через ссылки на предыдущий и следующий элемент.

📦 Базовая структура

Каждый элемент списка хранится в отдельном объекте Node<E>, который содержит:

▪️ E item — сам элемент
▪️ Node<E> next — ссылка на следующий узел
▪️ Node<E> prev — ссылка на предыдущий узел

У LinkedList есть два поля:

▪️ first — голова списка
▪️ last — хвост списка

Это позволяет быстро добавлять элементы в начало и конец.

⚡️ Добавление и удаление

— Добавление в начало (addFirst) или конец (addLast) → O(1): меняем ссылки у пары узлов.
— Удаление головы или хвоста также → O(1).
— Вставка или удаление в середине требует сначала дойти до нужного узла → O(n).

🌊 Поиск элемента

— По индексу: список не хранит массив, значит придётся идти по ссылкам.
— Оптимизация: если индекс ближе к голове, обход идёт с first, если к хвосту — с last.
Сложность в среднем — O(n/2), то есть линейная.

📊 Производительность

— Доступ по индексу → O(n).
— Добавление/удаление в начало или конец → O(1).
— Вставка/удаление в середину → O(n).
— Итерация по списку → O(n), но эффективно, так как используется последовательный проход по ссылкам.

⚖️ Важные нюансы

— В отличие от ArrayList, в LinkedList нет операций с массивами и «ресайзинга».
— Но расходует больше памяти: каждый узел хранит не только элемент, но и две ссылки (prev/next).
— Итераторы fail-fast: изменение списка во время обхода бросает ConcurrentModificationException.

🔄 Итераторы и Deque

LinkedList реализует Deque, что делает его удобным для очередей и стеков. Offer, poll, peek работают за O(1). Push/pop превращают список в стек.

🧮 Когда использовать

На практике ArrayList почти всегда быстрее по времени и эффективнее по памяти.
LinkedList может быть полезен только в редких случаях, когда нужны очень частые вставки/удаления в середину коллекции (без итерации по коллекции) и не важен доступ по индексу. В остальных случаях выбирайте ArrayList.

🔗 Документация: OpenJDK — LinkedList source | Официальная JavaDoc (Java 17)

Ставьте 🔥, если хотите такой же пост по другим коллекциям, например CopyOnWriteArrayList.

🐸 Библиотека джависта

#CoreJava

🧩 final vs finally vs finalize()

Казалось бы, три похожих ключевых слова → final, finally, finalize(). А смысл принципиально разный. Давайте разберёмся.

🔹 final

Модификатор, который делает сущность неизменяемой:

▪️ final переменная → нельзя переприсвоить.
▪️ final метод → нельзя переопределить.
▪️ final класс → нельзя наследовать.

Используется для обеспечения immutability и контрактов в коде.

🔹 finally

Блок в try-catch, который выполняется всегда (даже если выброшено исключение).

Гарантирует освобождение ресурсов:

try {
FileReader reader = new FileReader("data.txt");
} catch (IOException e) {
e.printStackTrace();
} finally {
System.out.println("Закрываем ресурсы");
}

🔹 finalize()

Метод класса Object, вызываемый GC перед удалением объекта. Используется редко, считается устаревшим (deprecated с Java 9, удалён в Java 18).

Минус: непредсказуемое время вызова.

Современная альтернатива: try-with-resources или явная очистка.

💡 Вывод

final → контроль изменяемости.
finally → контроль завершения.
finalize() → контроль очистки (но не используйте).

🐸 Библиотека джависта

#CoreJava

🔍 Просто о сложном: Spring Boot

Spring Boot — это не «новый фреймворк», а надстройка над Spring, которая убирает рутину и ускоряет разработку.

В обычном Spring нужно было вручную конфигурировать всё: от DataSource до DispatcherServlet. В Boot это делается автоматически через автоконфигурацию.

🔹 Как работает автоконфигурация

Spring Boot сканирует зависимости и classpath, а затем подключает нужные бины:

— Если у вас есть spring-boot-starter-data-jpa, Boot автоматически создаст EntityManagerFactory, DataSource, транзакционный менеджер.

— Если добавлен spring-boot-starter-web, он поднимет встроенный Tomcat/Jetty и зарегистрирует контроллеры. И так далее.

Магия кроется в аннотации @EnableAutoConfiguration (включается через @SpringBootApplication). Она загружает META-INF/spring.factories → список классов-конфигов → каждый проверяет условия @ConditionalOnClass, @ConditionalOnMissingBean и решает: активироваться или нет.

💡 Почему это работает так гладко

Потому что в Boot сотни готовых конфигураций «на все случаи жизни».

Фактически, это огромная библиотека «если увидишь X — настрой Y».

👀 Подводный слой магии

— Черный ящик

Легко забыть, что именно сконфигурировал Boot. Иногда приходится «копать» в автоконфигурацию, чтобы понять, какой бин реально используется.

— Избыточные зависимости

Подключив Starter, можно случайно притащить половину экосистемы Spring. Это увеличивает время старта и усложняет дебаг.

— Конфликт настроек

Собственная конфигурация может пересечься с автоконфигурацией.

⚡️ Хорошая практика

— Не доверяйте «чёрному ящику»: при старте приложения смотрите Spring Boot Actuator и логи автоконфигурации.

— Знайте про --debug при старте: он показывает, какие автоконфигурации включены или отключены.

— В продакшене лучше контролировать, какие именно стартеры вы тянете. Иногда spring-boot-starter-web приносит в проект в три раза больше, чем реально нужно.

🎯 Итог

Spring Boot — это ускоритель, но не магия. Его сила в автоконфигурациях, а слабость в том, что легко потерять контроль.

Понимание того, как работает @EnableAutoConfiguration и условия @Conditional, отличает разработчика, который «просто пишет на Boot», от того, кто реально управляет приложением.

🐸 Библиотека джависта

#CoreJava

🔥 Задача на алгоритмы: оптимизация расписания задач

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

🔹 Условие

— У вас есть N задач, каждая с временем выполнения t[i].
— Есть K воркеров (потоков, серверов), которые могут выполнять задачи параллельно, но каждый воркер может брать только одну задачу за раз.

Нужно распределить задачи между воркерами так, чтобы время завершения всех задач было минимальным.

💡 Пример:

t = [3, 7, 2, 5, 4]
K = 2

— если раздать задачи просто по очереди, один воркер закончит через 14 секунд, другой — через 7.
— а если распределить умнее (например, [7,3] и [5,4,2]), итоговое время — 10 секунд.

🔹 Уточнения

— N может достигать 10⁴

— K до 100

— Допустимо небольшое отклонение от оптимума (например, ≤5%)

— Требуется O(N log N) или лучше

— Можно предусмотреть балансировку “на лету” при поступлении новых задач

🔹 Вопрос

Какой алгоритм примените для минимизации времени выполнения?

Подумайте о вариантах:

— жадный

— динамическое программирование

— приближённые решения (если N велико)

🔹 Подсказки

— Это классическая NP-трудная задача разбиения множества (Partition Problem)

— На практике часто решается жадным алгоритмом LPT (Longest Processing Time first)

👇🏻 Скелет решения предложили в комментах.

💬 Делитесь своими решениями: какой алгоритм выбрали бы для продакшена, а какой — для интервью?

🐸 Библиотека джависта

#CoreJava

👀 Внутреннее устройство CopyOnWriteArrayList

CopyOnWriteArrayList — это потокобезопасная коллекция из пакета java.util.concurrent, которая реализует интерфейсы List и RandomAccess. Она часто воспринимается как «волшебная таблетка» для многопоточности, но под капотом это хитрая стратегия: каждое изменение списка создаёт копию массива.

📦 Базовая структура

Внутри CopyOnWriteArrayList хранит данные в обычном массиве transient volatile Object[] array.

— Все операции чтения (get, iterator, contains) идут напрямую по этому массиву и не требуют синхронизации.

— При модификациях (add, remove, set) создаётся новый массив с учётом изменений, и ссылка array указывает на него.

За счёт этого чтения не блокируются, а итераторы всегда видят снимок состояния (snapshot) на момент создания.

⚡️ Добавление и удаление

— add(E e): берётся текущий массив, копируется в новый на +1 элемент, в конец добавляется e.

— remove(Object o): копия массива создаётся без указанного элемента.

— set(int index, E element): создаётся копия массива, в которой меняется один элемент.

Сложность таких операций — O(n), ведь нужно копировать массив.

🌊 Итераторы

— Итератор у CopyOnWriteArrayList не fail-fast, в отличие от ArrayList и LinkedList.

— Он работает по «снимку» массива, который существовал в момент вызова iterator().

— Изменения, сделанные другими потоками, в процессе обхода не видны.

📊 Производительность

— Чтение (get, contains, iteration) → O(1) / O(n) для поиска очень быстро, так как обращение к массиву.

— Запись (add, remove, set) → O(n), так как требуется копировать массив.

— Итерация → O(n), но без блокировок и с высокой стабильностью в многопоточной среде.

⚖️ Важные нюансы

— CopyOnWriteArrayList идеален для сценариев «много чтений, мало записей».

— Память расходуется щедро: каждый апдейт порождает новую копию массива.

— Если записи происходят часто, использование становится неоправданным.

🧮 Когда использовать

— Подписчики/слушатели событий (например, listeners в UI или логгере).

— Кэш статических данных, где обновления редки.

— Конфигурации, которые меняются редко, а читаются часто.

В большинстве остальных случаев лучше использовать другие структуры (ConcurrentHashMap, Collections.synchronizedList, CopyOnWriteArraySet).

🔗 Документация: официальная JavaDoc (Java 17)

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

🐸 Библиотека джависта

#CoreJava

⌛ Сохраняйте шпаргалку по паттернам проектирования

🐸 Библиотека джависта

#CoreJava

⚡️ Просто о сложном: JIT-компилятор

Чтобы ускорить работу приложения, JVM включает в дело Just-In-Time (JIT) компилятор.

Он превращает часто выполняемый байткод в нативные машинные инструкции прямо во время исполнения.

🔹 Как это работает

— При старте приложения JVM интерпретирует байткод.

— Когда видит, например, что метод вызывается часто (т.н. hot method), — JIT компилирует его в машинный код.

— В следующий раз этот метод исполняется уже как нативный, без интерпретации.

— Всё это происходит «на лету» — поэтому Java-программы разгоняются после первых секунд работы.

🔹 Зачем нужен JIT

Он сочетает плюсы интерпретации и компиляции:

— Быстрый старт приложения (интерпретация).
— Высокая производительность после разогрева (JIT).

🔹 Что он умеет оптимизировать

— Inlining: подставляет код мелких методов прямо в место вызова.

— Escape Analysis: определяет, можно ли объект хранить на стеке вместо heap.

— Loop unrolling: разворачивает циклы для ускорения.

— Dead code elimination: выбрасывает ненужные операции.

— И другие алгоритмы.

⚙️ Как посмотреть, что делает JIT

Включите флаг:

-XX:+PrintCompilation

И увидите, какие методы компилируются во время исполнения.

Интересно почитать про алгоритмы JIT подробнее → ставь 👾

🐸 Библиотека джависта

#CoreJava

👀 Задача с собеса: проверка на палиндром (jun)

Дана строка, нужно определить, является ли она палиндромом.

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

💡 Ключевые моменты:

— Необходимо учитывать только буквенные символы, игнорируя пробелы и знаки препинания.
— Сравнение должно быть нечувствительным к регистру.

▪️ Решение:

Эффективное реализация может включать два указателя, движущихся навстречу друг другу от начала и конца строки.

💬 Делитесь своими решениями в комментариях (прячьте под спойлер)

🐸 Библиотека джависта

#CoreJava

🌐 Путешествие URL: что происходит, когда вы вводите адрес сайта

Каждый раз, когда вы набираете https://example.com в браузере — за кулисами запускается целая цепочка событий 👇

1️⃣ Разбор адреса

Браузер делит URL на части:

▪️ https — протокол
▪️ example.com — домен
▪️ /page — путь к ресурсу

2️⃣ Поиск IP

Если IP не сохранён в кеше, браузер спрашивает DNS-сервер: «Где живёт example.com?»

3️⃣ Установление соединения

Создаётся TCP-соединение с сервером по IP и порту (80 для HTTP, 443 для HTTPS).

4️⃣ Запрос ресурса

Браузер отправляет HTTP-запрос: GET /page HTTP/1.1

5️⃣ Ответ сервера

Сервер возвращает HTML, CSS, JS и статус-код (например, 200 OK или 404 Not Found).

6️⃣ Рендеринг страницы

Браузер обрабатывает HTML, применяет стили и выполняет JavaScript.

7️⃣ Шифрование

Если сайт работает по HTTPS, соединение шифруется через SSL/TLS.

8️⃣ Кеширование

Браузер сохраняет ресурсы, чтобы при следующем визите всё грузилось быстрее.

🐸 Библиотека джависта

#CoreJava

⚡️ Просто о сложном: как JIT делает код быстрее

Вы когда-нибудь задумывались, как JIT умеет так ловко оптимизировать код в реальном времени?

Сегодня разберём, какие именно суперспособности JIT даёт вашему коду.

🔹 Инлайнинг методов

Когда JIT обнаруживает, что какой-то метод выполняется слишком часто, он может инлайнить его. Это значит, что весь код метода не будет вызываться отдельно, а его инструкции будут вставляться прямо в место вызова.

Пример:

int sum(int a, int b) {
    return a + b;
}

int result = sum(5, 10);

Стало:

int result = 5 + 10; // JIT инлайнит код метода sum

🔹 Удаление мертвого кода

JIT всегда анализирует, выполняется ли тот или иной участок кода. Если метод или условие никогда не будет вызвано (например, условие, которое всегда ложно), JIT его удаляет.

🔹 Оптимизация циклов

Циклы — частая конструкция, и JIT всегда старается оптимизировать их выполнение. Например, если цикл выполняется много раз, JIT может переработать его для уменьшения количества операций.

🔹 Параллельная компиляция

Если ранее компиляция шла поэтапно, сейчас JIT может компилировать несколько частей программы одновременно. Это не только ускоряет работу компилятора, но и уменьшает задержки при запуске программы.

🔹 Использование final переменных

JIT предполагает, что final переменные не изменяются после инициализации. Это даёт компилятору возможность предсказать их значения и оптимизировать операции с ними.

🔹 Удаление лишних проверок

JIT понимает, какие проверки в коде избыточны. Например, если переменная была уже проверена на null, и это значение не изменяется, JIT может просто игнорировать повторные проверки.

🔹 Классификация горячих и холодных методов

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

🔹 Слияние и удаление дубликатов

Если программа выполняет одинаковые операции несколько раз, JIT сливает их в одну или избавляется от дублирующихся вычислений.

Пример:

int a = 5;
int b = 5;
int c = a + b;
int d = a + b; // Дублирование

JIT может понять, что a + b одинаково для обеих операций, и просто использовать результат из первого вычисления во втором.

💬 Пишите в комменты, какие инструменты ещё разобрать.

🐸 Библиотека джависта

#CoreJava