❓ Что такое false sharing в многопоточности Java и как его избежать?

False sharing возникает, когда разные потоки обновляют разные переменные, находящиеся в одной кэш-линии CPU.
Несмотря на отсутствие логической связи, процессор вынужден постоянно инвалидировать кэш, создавая задержки.

Последствия: высокая латентность, падение пропускной способности, резкое ухудшение производительности в hot-paths.

Как избежать:

• Разнести горячие поля по разным кэш-линиям → использовать @Contended (JDK 8+, требует -XX:-RestrictContended).
• Заполнять структуру “паддингом” вручную.
• Перепроектировать алгоритм, чтобы снизить частоту записи.

🐸 Библиотека собеса по Java

#concurrency

❓ Почему String неизменяемый (immutable)?

❌

Потому что StringBuilder — это String для продакшена, а String — только для учебы!

✔️

Основные причины:

1️⃣ String Pool — переиспользование объектов экономит память

2️⃣ Безопасность — используется в критичных местах

3️⃣ Потокобезопасность — можно свободно шарить между потоками без синхронизации

4️⃣ Хеш-код кешируется — ускоряет работу HashMap/HashSet

🐸 Библиотека собеса по Java

#core

✔️ Concurrency-тест: Реализация Thread-Safe Cache

Напишите потокобезопасный кеш с TTL и размером 👇

📦 Задание

Реализуйте ExpiringCache<K, V> — thread-safe кеш с автоматическим удалением устаревших записей.

public class ExpiringCache<K, V> {
    public void put(K key, V value, Duration ttl) { }
    public Optional<V> get(K key) { }
    public void remove(K key) { }
    public int size() { }
}

📋 Требования

1. Функциональность

put() — добавить элемент с TTL (time-to-live)
get() — получить элемент, вернуть Optional.empty() если истёк
remove() — удалить элемент
size() — количество валидных (не истёкших) элементов

2. Потокобезопасность

→ Все операции должны быть thread-safe
→ Минимизировать блокировки (не использовать synchronized на весь объект)
→ Одновременное чтение не должно блокироваться
— Производительность
→ get() должен быть O(1) в среднем случае
→ Автоматическая очистка истёкших записей (passive + active eviction)
→ Не создавать отдельный поток для каждого элемента

3. Ограничения

→ Максимальный размер кеша — 1000 элементов
→ При превышении удалять самые старые записи (LRU)
→ Graceful shutdown при закрытии кеша

Бонус: Добавить метрики (cache hits/misses)

Ставьте → 🔥, если нравится формат. Если нет → 🤔

💬 Пишите решение в комментариях, главное прячьте под спойлер.

🐸 Библиотека собеса по Java

#practise

💬 Обратная связь

Добавили немного юмора к постам. Мнение:

😁 — Забавно, пусть будет
👍🏼 — Нейтрально
🤔 — Неудобно, только отвлекает от сути

🐸 Библиотека собеса по Java

❓ Для чего нужна HashMap?

❌

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

✔️

HashMap — это реализация структуры данных hash table, которая обеспечивает быстрый доступ, вставку и удаление элементов по ключу в среднем за O(1).

Основные сценарии использования:

1️⃣ Кеширование и мемоизация — когда нужен быстрый доступ к часто используемым данным.

2️⃣ Подсчет частоты элементов — классическая задача с O(n) сложностью.

3️⃣ Индексация для быстрого поиска — когда нужно избежать линейного перебора.

🐸 Библиотека собеса по Java

#core

❓ Почему нельзя использовать LocalDateTime для работы с временными метками в распределенных системах?

❌

Потому что LocalDateTime — это местное время, а в распределенных системах все серверы находятся в разных городах! Если один сервер в Москве показывает 15:00, а другой в Владивостоке — 22:00, то база данных не знает, как решить противоречия.

✔️

LocalDateTime не хранит информацию о часовом поясе и смещении относительно UTC, что делает его непригодным для распределенных систем

🐸 Библиотека собеса по Java

#core

❓ В чем разница между fail-fast и fail-safe итераторами?

❌

Fail-fast итераторы — это те, которые быстро падают при первой же ошибке, потому что написаны на скорострельном C++. А fail-safe итераторы работают медленно, зато безопасно, потому что каждый элемент проверяется антивирусом перед возвратом.

✔️

🔹 Fail-fast итераторы:

→ Бросают ConcurrentModificationException при структурном изменении коллекции во время итерации.
→ Проверяют modCount (счетчик модификаций) при каждом вызове next().
→ Используются в большинстве коллекций из java.util (ArrayList, HashMap, HashSet).
→ Работают на оригинальной коллекции.

🔹 Fail-safe итераторы:

→ Работают на копии/снимке коллекции, поэтому не бросают исключений.
→ Используются в java.util.concurrent коллекциях (CopyOnWriteArrayList, ConcurrentHashMap).
→ Могут не отражать актуальное состояние коллекции (weakly consistent).
→ Потребляют больше памяти из-за копирования.

🐸 Библиотека собеса по Java

#core