🧵 Multithreading

Короткий ответ wait() — метод класса Object, а sleep() — статический метод класса Thread. wait() служит для межпоточной коммуникации, вызывается только из синхронизированного кода и при вызове освобождает монитор объекта. sleep() просто приостанавливает текущий поток на заданное время и не освобождает удерживаемые блокировки. Как это работает подробнее wait() вне синхронизированного метода или блока бросит IllegalMonitorStateException. Поток переходит в ожидание, пока другой поток не вызовет notify()/notifyAll() на том же объекте либо не истечёт указанный таймаут; без таймаута ожидание может длиться «вечно». sleep() можно вызывать где угодно, он всегда принимает время задержки и удобен для имитации пауз. Пара wait()/notify() — классический механизм схемы «производитель — потребитель» для ожидания наступления условия. Оба метода бросают проверяемое InterruptedException, которое нужно обрабатывать. Пример кода Что использовать на практике Используй wait()/notifyAll(), когда поток должен ждать наступления услови

Читать полностьюjava

sleep() приостанавливает поток и не освобождает монитор, wait() освобождает монитор и ждет notify().

Читать полностьюMultithreading

Короткий ответ Оба механизма обеспечивают взаимное исключение и реентерабельны: поток, уже владеющий монитором или замком, может захватить его повторно. synchronized — встроенная конструкция языка: монитор захватывается при входе в метод или блок и автоматически освобождается при выходе, даже при исключении. ReentrantLock из java.util.concurrent.locks требует явного lock() и освобождения в finally, но даёт больше контроля. Как это работает подробнее Возможности synchronized ограничены: нельзя прервать поток, ожидающий блокировку, нельзя установить таймаут ожидания, нет честной (fair) очереди, а захват возможен только в пределах одного метода или блока. ReentrantLock предоставляет tryLock() (захват без блокировки или с таймаутом), lockInterruptibly() (прерываемое ожидание), честные замки и несколько объектов Condition для тонкого управления ожиданием. Именно tryLock с таймаутом позволяет писать код, устойчивый к deadlock: не получилось захватить блокировку — поток освобождает уже захваченные ресурсы и повторяе

Читать полностьюjava

Короткий ответ Синхронизированные коллекции — это обёртки над обычными коллекциями, создаваемые через Collections.synchronizedList(), synchronizedMap() и т. п., а также исторические Vector и Hashtable: в них каждый публичный метод синхронизирован целиком, все операции захватывают один общий монитор коллекции. Concurrent-коллекции из java.util.concurrent (ConcurrentHashMap, CopyOnWriteArrayList и др.) спроектированы для высокой конкуренции: они используют гранулярную синхронизацию, CAS и слабо консистентные итераторы. Как это работает подробнее Synchronized-коллекции гарантируют потокобезопасность, но создают сильную конкуренцию: чем больше потоков обращается одновременно, тем больше времени они проводят в ожидании общей блокировки, поэтому масштабируемость плохая. Итерироваться по ним нужно внутри собственного блока synchronized, иначе поведение при параллельном изменении недетерминировано. ConcurrentHashMap в современных версиях синхронизирует доступ по корзинам таблицы: операции над разными корзинами не меш

Читать полностьюconcurrent

Короткий ответ Синхронизированный нестатический метод захватывает монитор экземпляра this на всё время выполнения всего метода; статический синхронизированный метод блокирует монитор объекта класса (SomeClass.class). synchronized-блок позволяет указать, какой объект использовать как монитор, и ограничить синхронизацию только нужным фрагментом кода. Как это работает подробнее Пока поток внутри synchronized-метода на this, другой поток не сможет войти ни в один другой synchronized-метод того же объекта. Статические методы синхронизируются между собой на объекте Class, поэтому говорят про «класс-лок» в отличие от «объект-лока». Блок уменьшает время удержания блокировки и снижает конкуренцию (contention), поэтому считается более гибким и, как правило, более производительным: остальной код метода выполняется без блокировки. Монитор в Java реентерабелен: поток, уже владеющий монитором, может повторно войти в синхронизированный код по тому же объекту без взаимной блокировки самого себя. Пример кода Что использовать

Читать полностьюjava

Короткий ответ volatile решает проблему видимости: чтение и запись volatile-переменной выполняются напрямую из основной памяти, а между записью одним потоком и чтением другим устанавливается отношение happens-before. Однако volatile не обеспечивает атомарность: составная операция «прочитать — изменить — записать» вроде counter++ остаётся неатомарной. Атомарные классы из java.util.concurrent.atomic дают атомарные операции без блокировок — на базе аппаратной инструкции CAS. Как это работает подробнее volatile идеален для флагов состояния вроде boolean running, которые один поток выставляет, а другой читает. При counter++ два потока могут одновременно прочитать старое значение и записать результат, «потеряв» одно из увеличений, — даже если поле объявлено volatile. Атомарные классы AtomicInteger, AtomicLong, AtomicReference предоставляют методы getAndIncrement(), addAndGet(), compareAndSet(expected, newValue), реализованные на аппаратной инструкции CAS (Compare-And-Swap). CAS действует оптимистично: compareAndSet

Читать полностьюatomic

ConcurrentHashMap обеспечивает потокобезопасность на уровне отдельных сегментов (в Java 7) или через CAS и synchronized бакетов (в Java 8+)...

Читать полностьюCollections

Короткий ответ Первый способ — создать подкласс Thread и переопределить метод run(). Второй — реализовать интерфейс Runnable и передать экземпляр задания в конструктор Thread. Запускает поток всегда метод start(): именно он создаёт новый поток и внутри него вызывает run(). Как это работает подробнее Наследование от Thread смешивает задачу («что делать») с потоком («где выполнять») и расходует единственное место под наследование. Реализация Runnable считается предпочтительной: Java поддерживает только одиночное наследование, а интерфейс такой проблемы не создаёт; один и тот же объект Runnable можно передать в несколько потоков или в пул. Родственный интерфейс Callable<T>: метод call() возвращает результат и может бросать проверяемые исключения в отличие от void run(). Задачи Callable выполняются не через new Thread(...), а через ExecutorService.submit(), который возвращает Future<T> для получения результата. Пример кода Что использовать на практике Runnable — стандартный выбор: задача отделена от потока, её мо

Читать полностьюcallable

Короткий ответ Главное преимущество — эффективное использование процессорного времени: пока один поток заблокирован (ждёт ввода-вывода, сети или базы данных), другие продолжают выполняться, и CPU не простаивает. На многоядерных машинах потоки выполняются по-настоящему параллельно, что ускоряет вычисления, разбиваемые на независимые части. Как это работает подробнее Второй плюс — отзывчивость приложения: в GUI тяжёлая работа выносится в фоновый поток, и интерфейс не «зависает», а серверные приложения обслуживают тысячи клиентов за счёт пулов потоков, а не отдельного процесса на каждый запрос. Потоки экономичнее процессов: они разделяют память процесса и создаются с меньшими накладными расходами. Асинхронные сценарии — задачи, выполняемые в фоне с последующим получением результата, — естественно реализуются через потоки, ExecutorService и Future. Обратная сторона — гонки за данные, взаимные блокировки (deadlock), накладные расходы на переключение контекста и сложность отладки и тестирования многопоточного кода.

Читать полностьюconcurrency