Вопросы на собеседовании: Java-разработчик

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

• У каждого процесса изолированное адресное пространство, а потоки одной JVM могут обращаться к общим объектам.
• У каждого потока собственные стек, счётчик команд и кадры вызовов, хотя куча остаётся общей.
• Общая память упрощает обмен данными, но при конкурентном доступе к изменяемому состоянию требует синхронизации.

start() просит JVM создать новый путь выполнения, а run() является обычным вызовом метода в текущем потоке.

• После start() метод run() выполняется в новом потоке, когда планировщик переведёт его к исполнению.
• Прямой вызов run() не создаёт конкурентности и блокирует вызывающий поток до возврата из метода.
• Экземпляр Thread можно запустить только один раз, а повторный start() выбросит IllegalThreadStateException.

Thread.State описывает этап жизненного цикла потока, а не то, занимает ли он процессорное ядро прямо сейчас.

• После start() поток переходит из NEW в RUNNABLE, а после завершения или ошибки в run() попадает в TERMINATED.
• Ожидание занятого synchronized-блока даёт BLOCKED, а Object.wait() или join() без тайм-аута переводит поток в WAITING.
• sleep(), ожидание с тайм-аутом и join() с тайм-аутом дают TIMED_WAITING до истечения времени или другого условия пробуждения.

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

• count++ состоит из чтения, изменения и записи, а не является одной неделимой операцией.
• Два потока могут прочитать одно старое значение, вычислить одинаковый результат и затереть обновление друг друга.
• Операцию нужно защитить общим lock или использовать атомарный счётчик для конкурентных обновлений.

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

• В критической секции под конкретным монитором одновременно может находиться только один поток.
• Освобождение монитора публикует предшествующие записи, а последующий захват делает их видимыми.
• Мониторы Java реентерабельны, поэтому владеющий монитором поток может повторно войти в защищённый им блок без самоблокировки.

Выбор монитора зависит от объекта, указанного формой синхронизации явно или неявно.

• Синхронизированный метод экземпляра блокирует this, поэтому вызовы на разных экземплярах не исключают друг друга.
• Статический synchronized-метод блокирует объект Class, общий для всех экземпляров этого класса в одном загрузчике.
• synchronized-блок захватывает монитор указанного выражения, что позволяет выбрать приватный lock и сузить критическую секцию.

wait и уведомления координируют потоки через монитор объекта, а sleep лишь приостанавливает текущий поток.

• wait() вызывается при удержании монитора и освобождает его, пока поток не проснётся и не захватит монитор снова.
• notify() пробуждает одного произвольного ожидающего, а notifyAll() пробуждает всех, после чего они конкурируют за монитор.
• sleep() не требует и не освобождает монитор, поэтому сон внутри synchronized может зря блокировать другие потоки.
• Условие ожидания проверяют в цикле while из-за ложных пробуждений и возможного изменения условия до повторного захвата.

volatile гарантирует видимость и упорядочивание чтений и записей одной переменной, но не делает составные действия атомарными.

• Запись в volatile-переменную happens-before каждого последующего чтения этой же переменной.
• JVM и процессор не могут переставлять связанные операции памяти через volatile-доступ так, чтобы нарушить эту гарантию.
• volatile подходит для флагов состояния или безопасной публикации неизменяемого значения, если обновление не зависит от старого значения.

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

• Каждый поток может увидеть актуальный counter и всё равно потерять обновление между чтением и записью.
• AtomicInteger.incrementAndGet() выполняет обновление атомарно, обычно через compare-and-set.
• synchronized или Lock лучше подходят, когда инвариант охватывает несколько переменных или операций.

Happens-before гарантирует, что эффекты одного действия будут видны другому действию.

• Порядок программы устанавливает такую связь между более ранними и поздними действиями внутри одного потока.
• Освобождение монитора happens-before его последующего захвата, а запись в volatile-переменную happens-before её последующего чтения.
• Thread.start() публикует предшествующие действия запущенному потоку, а успешный join() публикует действия завершившегося потока ожидавшему.
• Без цепочки happens-before другой поток не обязан видеть записи, даже если в тестах код обычно работает.

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

• Публикация через volatile-поле, синхронизированную передачу, статический инициализатор или конкурентную коллекцию создаёт нужное упорядочивание.
• Корректно инициализированные final-поля имеют особые гарантии видимости, но это не делает изменяемые объекты по ссылкам неизменяемыми.
• Утечка this из конструктора может открыть доступ к значениям по умолчанию или частично созданному состоянию.

Компилятор, JVM и процессор могут переставлять операции ради производительности, пока поведение одного потока остаётся корректным.

• При гонке данных другой поток может наблюдать записи в неожиданном порядке.
• synchronized, volatile, правила жизненного цикла потоков и конкурентные утилиты вводят ограничения порядка, известные модели памяти.
• Расчёт на тайминги или добавление sleep() не создают видимость и не заменяют отношение happens-before.

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

• Код с захватом нескольких lock в разном порядке может создать циклическое ожидание.
• Единый порядок захвата или один lock для общего инварианта устраняет такой цикл.
• tryLock с тайм-аутом позволяет отказаться от захвата и повторить попытку, но ветка отказа должна освободить все уже полученные lock.

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

• Starvation возможен, если поток постоянно проигрывает конкуренцию за несправедливый lock или ресурсы executor.
• При livelock потоки отвечают друг другу повторными уступками или попытками в синхронном ритме.
• Потоки в deadlock заблокированы циклом зависимостей, а при starvation или livelock их состояние может продолжать меняться.

Lock полезен, когда коду нужно управление захватом, которого не предоставляет конструкция synchronized.

• tryLock поддерживает немедленный отказ или тайм-аут, а lockInterruptibly позволяет отменить ожидание.
• Один Lock может создать несколько очередей Condition, тогда как у монитора объекта только один набор ожидающих.
• Для лексической критической секции synchronized обычно проще, потому что монитор освобождается автоматически даже при исключении.
• Lock после успешного захвата всегда нужно освобождать в блоке finally.

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

• Реентерабельность учитывается счётчиком, поэтому владелец должен вызвать unlock столько раз, сколько успешно вызвал lock.
• Справедливый lock при конкуренции обычно передаёт доступ потоку, ожидающему дольше остальных.
• Справедливость может снижать starvation, но часто уменьшает пропускную способность, а tryLock без тайм-аута может обойти очередь.

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

• Несколько читателей могут одновременно удерживать read lock, но write lock требует исключительного доступа.
• Накладные расходы на lock и конкуренцию могут сделать обычный мьютекс быстрее для коротких секций или частых записей.
• ReentrantReadWriteLock не поддерживает прямое повышение read lock до write lock, и попытка сохранить read lock при повышении может вызвать deadlock.

Атомарные классы сравнивают текущее значение с ожидаемым и заменяют его только при совпадении.

• Неудачный compare-and-set означает вмешательство другого потока, поэтому lock-free алгоритм обычно перечитывает значение и повторяет попытку.
• Операция атомарна и даёт семантику видимости уровня volatile без захвата монитора Java.
• ABA возникает, если значение меняется с A на B и обратно на A, поэтому сравнение видит A, но пропускает промежуточное изменение.
• AtomicStampedReference или AtomicMarkableReference добавляет версию, когда история изменений значима.

AtomicLong хранит одно атомарно читаемое значение, а LongAdder распределяет конкурентные обновления по внутренним ячейкам.

• AtomicLong подходит, когда нужны операции compare-and-set или каждое чтение должно давать единое линеаризуемое значение.
• LongAdder обычно лучше масштабируется для часто обновляемых метрик, потому что потоки конкурируют за разные ячейки.
• LongAdder.sum() объединяет ячейки и не является атомарным снимком на фоне обновлений, поэтому не подходит для логики координации.

ExecutorService отделяет отправку задачи от политики создания, переиспользования, планирования и остановки потоков.

• Переиспользование ограниченного набора workers снижает расходы памяти и переключений контекста по сравнению с отдельным потоком на задачу.
• Executor умеет ставить работу в очередь, отклонять перегрузку, возвращать Future и управлять жизненным циклом.
• Приложение всё равно должно выбрать ёмкость очереди, размер пула, фабрику потоков и политику отказа под свою нагрузку.