Кодекс Буси-до и Java, мало что общего? Те кто занимался серверным программированием в Java, вероятно, знакомы с многопоточностью и проблемами синхронизации доступа к общим данным. Создание "правильных" приложений, которые не путаются в своих же 'synchronize' блоках требует некоторой подготовки от разработчика. Хуже, когда, карта синхронизации усложняется за счет использования чужих библиотек и классов. Так например, при работе с JGroups'овым RPC диспетчером НЕ следует в его callback методах вызывать сам диспетчер, потому что это приводит к гарантированным мертвым блокировкам которые никакой штатный механизм не отловит (я говорю о JMX полезностях из JDK 1.5 и выше). Впрочем, вы сами в состоянии привести множество подобных примеров. Конечно, бывает и путаемся в своих же "семафорах".
И все же deadlock. Что мы обычно делаем в таких случаях? Да - всеми способами стараемся получить дамп потоков ибо только "глоток керосина может спасти смертельно раненного кота". Анализ этого дампа - есть задача банальная и не интересная, тем более скушная, чем больше вы в своей жизни "вылечили" по таким дампам чужих (за свои не так обидно) дедлоков. Вот, кстати, алгоритм анализа дампа потоков.
Так, а причем здесь самураи?
А вот причем - так называется один из тулов для облегчения нашей задачи по анализу дампа: Samurai 2.1.1. На страничке также доступен JNLP запуск для Samurai. Конечно же средств облегчающих задачу анализа предостаточно. Не буду заниматься их классификацией и описанием приведу лишь еще пару ссылок.
1.3 release of TDA -Thread Dump Analyzer
и JNLP запуск для TDA.
Ну и Eclipse plugin Lockness.
Удачи Вам и будьте внимательны.
Комментариев нет:
Отправить комментарий