Комментарии 9
И ни слова ни про ReadWriteLock, StampedLock, CountDownLatch... и много чего другого полезного и вкусного.
Ну и блокируемую очередь обычно делают через LinkedBlockingQueue.
И про Loom ни слова
ИМХО. Вполне приличная статья про основы синхронизации потоков в Java.
Это замечательно, что вы знаете про ReadWriteLock, StampedLock, CountDownLatch. Но, если говорить про асинхронность, многопоточность и JMM, то я к вашему списку могу добавить еще несколько десятков "баззвордов". Только стоит ли их все упоминать в статье? Получится сборная солянка, которая окончательно запутает новичка, и не позволит ему усвоить основы.
Статья-то от Отуса. У них на курсах все это есть (полагаю). Не будут же они все выкладывать здесь.
Про быстродействие неплохо бы упомянуть, иначе зачем такой зоопарк
В свете релиза виртуальных потоков стоило отметить, что подходов к synchronized стоит избегать и отдавать предпочтение ReentrantLock. Кроме того ReentrantLock / Condition имеют куда более гибкий и читаемый api.
В свете релиза виртуальных потоков стоило отметить, что подходов к synchronized стоит избегать и отдавать предпочтение ReentrantLock
Недавно пофиксили проблему с synchronized блоками, правда в 23 джаву не вошло. Надеюсь к 25 версии(лтс) увтдеть в основной ветке
Не очень понимаю, почему. У Вас же тогда может быть активны две критических секции одновременно: на разный нитях одного потока ОС. Или я Вас неправильно понимаю?
Ловить в библиотечном коде InterruptedException и вызывать в обработчике interrupt() - хреновая идея. Его вообще не надо ловить. Если уж дошло до того, что блокирующую операцию хотят прервать, то её нужно прервать, и выйти из метода, внутри которого это случилось, позволив вылететь этому InterruptedException из метода. В последнем примере используется BlockingQueue, она так и делает. Не библиотечный код, а приложение должно решать, что делать в случае прерывания операции.
Как синхронизировать потоки в Java