Кодекс Буси-до и 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.
Удачи Вам и будьте внимательны.
Новый робот вглядывается в лица людей, поворачивается к ним и запоминает их. Говорить он не может, да и какой спрос с паука? Зато техника, опробованная на этом небольшом создании, пригодится для роботов куда более сложных. Когда мы дойдём до черты, после которой не сможем уверенно отделить имитацию жизни от жизни настоящей?
Часто приходится сталкиваться с множеством "велосипедов" в различных архитектурах которые изобретают и переизобретают вновь. Между тем, такие "архитекторы", зачастую страдают банальной некомпетентностью. Что я имею в виду? А вот, что - когда выдумывается очередной концепт с нуля (как думает аффтар) и при этом, он (концепт) представляет собой убогое подобие некого кастрированного гибрида давно уже существующих и опробованных подходов. Т.е. концепт родился по причине незнания аффтара о существовании уже готовых решений. Готовое решение - это не закодированная функция, класс, ... а - алгоритм, подход, ... Конечно я не рассматриваю такие случаи когда концепт изобретается "сознательно" и по причине не применимости ничего уже существующего (это подразумевает глубокое изучение существующего с анализом недостатков и пр.). 
