Dev Easy Notes

​​Последняя проблема из списка, Deadlock. 🔐
Вероятность того, что вы столкнетесь с такой проблемой в продакшен коде крайне мала, однако стоит хотя бы примерно понимать как искать проблему 🔎, если все таки стрельнет.

☝️Для начала стоит запомнить фразу: "Программа, которая никогда не приобретает более одного замка за один раз, не может столкнуться с взаимной блокировкой, которая инициируется порядком блокировки." Это значит, что когда пишете код, старайтесь делать так, чтобы поток не захватывал более двух замков сразу. Если по другому никак, то проверяйте, чтобы все потоки захватывали замки в одном и том же порядке.

Есть три основных инструмент которые вы можете использовать для того, чтобы найти причину deadlock:
👉 Поточный дамп
👉 API явных замков
👉 Статические анализаторы кода и ревью кода

Вкратце пройдемся по каждому инструменту.

В JVM есть механизм, по которому мы можем получить информацию о том, что делает каждый конкретный поток. Используя этот инструмент можно найти где именно у нас происходит deadlock. Для этого запускаем программу, затем приказываем JVM собрать поточный дамп, обычно для этого есть спец кнопка📌 в IDE. Затем мы получаем некоторый листинг. В листинге нужно найти потоки состояние которых: "waiting to lock monitor". Это знак того, что скорее всего поток ждет ресурс который другой поток не может освободить. В иллюстрации с посту есть пример того, как выглядит этот листинг.

Второй инструмент это использовать явные замки 🔐, т.е объекты типа Lock. В API этих замков есть метод tryLock с timeout ⏲ который мы можем задать. Суть этого метода сводится к тому, что мы просто заменяем обычные методы lock на tryLock с каким-нибудь временем, например 3 секунды. Затем запускаем программу и начинаем тестить, если программа упала 💥, мы явно увидим где конкретно, а дальше уже отталкиваясь от этого можно найти конкретную причину.

Последний инструмент, наверное самый лучший из всех, это наши глаза 👀 и статические анализаторы кода 🤖. На данный момент на рынке очень много линтеров, которые умеют подсказывать о возможных ошибках в многопоточности из коробки. Стоит погуглить их и затащить в свой проект. Ну и конечно никто не отменяет код ревью, очень внимательно проверять места, где используются примитивы многопоточности 🧵. Если мы говорим про Android разработку, то таких мест будет крайне мало, так как Rx и корутины покрывают 90% кейсов. Во всех остальных случаях супер внимательно смотрим не наговнокодил ли коллега👨‍💻 и очень внимательно с максимальной критикой просматриваем свой код.

Этого должно хватить если вы вдруг столкнулись с такой проблемой.

👍6❤1

www.tgoop.com/dev_easy_notes/44

1.22K viewsedited  Jun 13, 2021 at 07:59

​​Последняя проблема из списка, Deadlock. 🔐
Вероятность того, что вы столкнетесь с такой проблемой в продакшен коде крайне мала, однако стоит хотя бы примерно понимать как искать проблему 🔎, если все таки стрельнет.

☝️Для начала стоит запомнить фразу: "Программа, которая никогда не приобретает более одного замка за один раз, не может столкнуться с взаимной блокировкой, которая инициируется порядком блокировки." Это значит, что когда пишете код, старайтесь делать так, чтобы поток не захватывал более двух замков сразу. Если по другому никак, то проверяйте, чтобы все потоки захватывали замки в одном и том же порядке.

Есть три основных инструмент которые вы можете использовать для того, чтобы найти причину deadlock:
👉 Поточный дамп
👉 API явных замков
👉 Статические анализаторы кода и ревью кода

Вкратце пройдемся по каждому инструменту.

В JVM есть механизм, по которому мы можем получить информацию о том, что делает каждый конкретный поток. Используя этот инструмент можно найти где именно у нас происходит deadlock. Для этого запускаем программу, затем приказываем JVM собрать поточный дамп, обычно для этого есть спец кнопка📌 в IDE. Затем мы получаем некоторый листинг. В листинге нужно найти потоки состояние которых: "waiting to lock monitor". Это знак того, что скорее всего поток ждет ресурс который другой поток не может освободить. В иллюстрации с посту есть пример того, как выглядит этот листинг.

Второй инструмент это использовать явные замки 🔐, т.е объекты типа Lock. В API этих замков есть метод tryLock с timeout ⏲ который мы можем задать. Суть этого метода сводится к тому, что мы просто заменяем обычные методы lock на tryLock с каким-нибудь временем, например 3 секунды. Затем запускаем программу и начинаем тестить, если программа упала 💥, мы явно увидим где конкретно, а дальше уже отталкиваясь от этого можно найти конкретную причину.

Последний инструмент, наверное самый лучший из всех, это наши глаза 👀 и статические анализаторы кода 🤖. На данный момент на рынке очень много линтеров, которые умеют подсказывать о возможных ошибках в многопоточности из коробки. Стоит погуглить их и затащить в свой проект. Ну и конечно никто не отменяет код ревью, очень внимательно проверять места, где используются примитивы многопоточности 🧵. Если мы говорим про Android разработку, то таких мест будет крайне мало, так как Rx и корутины покрывают 90% кейсов. Во всех остальных случаях супер внимательно смотрим не наговнокодил ли коллега👨‍💻 и очень внимательно с максимальной критикой просматриваем свой код.

Этого должно хватить если вы вдруг столкнулись с такой проблемой.

BY Dev Easy Notes