Java deadlock как бороться

Борьба с взаимными блокировками в Java

В жизни обычного программиста редко возникает возможность писать что-то действительно крутое и интересное. Большая часть нашей работы связана лишь со скрупулёзностью, усидчивостью, вниманием и монотонностью. Лишь на собеседованиях можно применить что-либо действительно интересное. Или странное. В этой статье я опишу способ решения проблемы смертельных блокировок (deadlock-ов), который может вам пригодиться при прохождении некоторых собеседований. Предположим, что у нас есть система, работающая со счетами пользователей. Счета пользователей представлены классом Account:

На первый взгляд может показаться, что всё в порядке. Но на самом деле в этом коде спрятана взаимная блокировка. Если вызвать transfer на первом счёте, а затем на втором, то может произойти так, что:

1. Берётся блокировка this на методе synchronized у счёта 1.
2. Происходит переключение потоков.
3. Берётся блокировка this на методе synchronized у счёта 2.
4. Происходит переключение потоков.
5. Поток, уже имеющий блокировку на счёте 1, пытается взять блокировку на счёте 2 в синхронизированном блоке, но блокировка this у счёта 2 уже занята, поэтому поток останавливается до тех пор, пока блокировка счёта 2 не освободиться.
6. Поток, уже имеющий блокировку на счёте 2, пытается взять блокировку на счёте 1 в синхронизированном блоке, но блокировка this у счёта 1 уже занята, поэтому поток останавливается до тех пор, пока блокировка счёта 1 не освободится.
7. Оба потока ждут освобождения блокировок друг друга, чего никогда не произойдёт.

Как избавиться от подобного? В данном случае можно обратить внимание на идентификатор счёта id. Понятное дело, что каждый счёт имеет уникальный идентификатор. Чтобы избежать deadlock-ов мы можем всегда брать блокировки строго в порядке сортировки их идентификаторов, то есть сначала меньший, а затем больший, чем решим проблему взаимных блокировок для этого случая:

Источник

Thread’ом Java не испортишь: Часть III — взаимодействие

Краткий обзор особенностей взаимодействия потоков. Ранее мы разобрали, как потоки синхронизируются друг с другом. В этот раз мы окунёмся в проблемы, которые могут появиться при взаимодействии потоков и поговорим о том, как их можно избежать. Также приведём несколько полезных ссылок для более глубокого изучения.

Вступление

Итак, мы знаем, что в Java есть потоки, о чём можно прочитать в обзоре «Thread’ом Java не испортишь: Часть I — потоки» и что потоки можно синхронизировать между собой, с чем мы разбирались в обзоре «Thread’ом Java не испортишь: Часть II — синхронизация». Пришло время поговорить о том, как же потоки взаимодействуют между собой. Как они делят общие ресурсы? Какие с этим могут быть проблемы?

Deadlock

Самой страшной проблемой является Deadlock. Когда два и более потоков вечно ожидают друг друга — это называется Deadlock. Возьмём пример с сайта Oracle из описания понятия «Deadlock»:

 public class Deadlock < static class Friend < private final String name; public Friend(String name) < this.name = name; >public String getName() < return this.name; >public synchronized void bow(Friend bower) < System.out.format("%s: %s has bowed to me!%n", this.name, bower.getName()); bower.bowBack(this); >public synchronized void bowBack(Friend bower) < System.out.format("%s: %s has bowed back to me!%n", this.name, bower.getName()); >> public static void main(String[] args) < final Friend alphonse = new Friend("Alphonse"); final Friend gaston = new Friend("Gaston"); new Thread(() ->alphonse.bow(gaston)).start(); new Thread(() -> gaston.bow(alphonse)).start(); > > 

Deadlock тут может проявиться не с первого раза, но если у вас выполнение программы повисло, самое время запустить jvisualvm : Если в JVisualVM установлен плагин (через Tools -> Plugins), мы сможем увидеть, где произошёл дедлок:

 "Thread-1" - Thread t@12 java.lang.Thread.State: BLOCKED at Deadlock$Friend.bowBack(Deadlock.java:16) - waiting to lock <33a78231> (a Deadlock$Friend) owned by "Thread-0" t@11 

Поток 1 ждёт лока от потока 0. Почему так выходит? Thread-1 начинает выполнение и выполняет метод Friend#bow . Он помечен ключевым словом synchronized , то есть мы забираем монитор по this . Мы на вход в метод получили ссылку на другого Friend . Теперь, поток Thread-1 хочет выполнить метод у другого Friend , тем самым получив лок и у него. Но если другой поток (в данном случае Thread-0 ) успел войти в метод bow , то лок уже занят и Thread-1 ждёт Thread-0 , и наоборот. Блокировка неразрешимая, поэтому она Dead, то есть мёртвая. Как мёртвая хватка (которую не разжать), так и мёртвая блокировка, из которой не выйти. На тему дедлока можно посмотреть видео: «Deadlock — Concurrency #1 — Advanced Java».

Livelock

Если есть Deadlock, то есть ли Livelock? Да, есть ) Livelock заключается в том, что потоки внешне как бы живут, но при этом не могут ничего сделать, т.к. условие, по которым они пытаются продолжить свою работу, не могут выполниться. По сути Livelock похож на deadlock, но только потоки не «зависают» на системном ожидании монитора, а что-то вечно делают. Например:

 import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class App < public static final String ANSI_BLUE = "\u001B[34m"; public static final String ANSI_PURPLE = "\u001B[35m"; public static void log(String text) < String name = Thread.currentThread().getName(); //like Thread-1 or Thread-0 String color = ANSI_BLUE; int val = Integer.valueOf(name.substring(name.lastIndexOf("-") + 1)) + 1; if (val != 0) < color = ANSI_PURPLE; >System.out.println(color + name + ": " + text + color); try < System.out.println(color + name + ": wait for " + val + " sec" + color); Thread.currentThread().sleep(val * 1000); >catch (InterruptedException e) < e.printStackTrace(); >> public static void main(String[] args) < Lock first = new ReentrantLock(); Lock second = new ReentrantLock(); Runnable locker = () -> < boolean firstLocked = false; boolean secondLocked = false; try < while (!firstLocked || !secondLocked) < firstLocked = first.tryLock(100, TimeUnit.MILLISECONDS); log("First Locked: " + firstLocked); secondLocked = second.tryLock(100, TimeUnit.MILLISECONDS); log("Second Locked: " + secondLocked); >first.unlock(); second.unlock(); > catch (InterruptedException e) < e.printStackTrace(); >>; new Thread(locker).start(); new Thread(locker).start(); > > 

Успешность этого кода зависит от того, в каком порядке планировщик потоков Java запустит потоки. Если первым запустится Thead-1 , то мы получим Livelock:

 Thread-1: First Locked: true Thread-1: wait for 2 sec Thread-0: First Locked: false Thread-0: wait for 1 sec Thread-0: Second Locked: true Thread-0: wait for 1 sec Thread-1: Second Locked: false Thread-1: wait for 2 sec Thread-0: First Locked: false Thread-0: wait for 1 sec . 

Как видно из примера, оба потока поочерёдно пытаются захватить оба лока, но им это не удаётся. При этом они не в deadlock, то есть визуально с ними всё хорошо и они выполняют свою работу. По JVisualVM мы видим периоды sleep и период park (это когда поток пытается занять лок, он переходит в состояние park, как мы разбирали ранее, говоря про синхронизацию потоков). На тему лайвлока можно посмотреть пример: «Java — Thread Livelock».

Starvation

Помимо блокировок (deadlock и livelock) есть ещё одна проблема при работе с многопоточностью — Starvation, или «голодание». От блокировок это явление отличается тем, что потоки не заблокированы, а им просто не хватает ресурсов на всех. Поэтому пока одни потоки на себя берут всё время выполнения, другие не могут выполниться:

Супер пример можно посмотреть здесь: «Java — Thread Starvation and Fairness». В этом примере показано, как работают потоки при Starvation и как одно маленькое изменение с Thread.sleep на Thread.wait позволяет распределить нагрузку равномерно.

Race Condition

При работе с многопоточностью есть такое понятие, как «состояние гонки». Это явление заключается в том, что потоки делят между собой некоторый ресурс и код написан таким образом, что не предусматривает корректную работу в таком случае. Взглянем на пример:

 public class App < public static int value = 0; public static void main(String[] args) < Runnable task = () ->< for (int i = 0; i < 10000; i++) < int oldValue = value; int newValue = ++value; if (oldValue + 1 != newValue) < throw new IllegalStateException(oldValue + " + 1 lang-java line-numbers"> Exception in thread "Thread-1" java.lang.IllegalStateException: 7899 + 1 = 7901 at App.lambda$main$0(App.java:13) at java.lang.Thread.run(Thread.java:745) 

 public class App < public static boolean flag = false; public static void main(String[] args) throws InterruptedException < Runnable whileFlagFalse = () -> < while(!flag) < >System.out.println("Flag is now TRUE"); >; new Thread(whileFlagFalse).start(); Thread.sleep(1000); flag = true; > > 

 public class App < public static int value = 0; public static AtomicInteger atomic = new AtomicInteger(0); public static void main(String[] args) throws InterruptedException < Runnable task = () -> < for (int i = 0; i < 10000; i++) < value++; atomic.incrementAndGet(); >>; for (int i = 0; i < 3; i++) < new Thread(task).start(); >Thread.sleep(300); System.out.println(value); System.out.println(atomic.get()); > > 

class KnightUtil < public static void kill(Knight knight1, Knight knight2) < Knight knightMax = knight1.id >knight2.id ? knight1: knight2; Knight knightMin = knight1.id > knight2.id ? knight2: knight1; synchronized(knightMax) < synchronized(knightMin) < knight2.live = 0; knight1.experience +=100; >> > >