スレッドダンプ解析を行うツールを作るか迷う

私が直接関わっているわけではないけど、うちのチームで基盤を構築したシステムにて、非常に危ないトラブルが発生している。ＡＰが大分イケてなくて、基盤を巻き添えにした上で縮退運転まで持ち込まれるという非常に悲惨なトラブルだ。ちなみに、ＡＰは、まったく契約関係のない他社だ。
詳細を書くと刺されそうなので、あまり書けないけど、「自動検出できないデッドロック」に陥る可能性のあるＡＰ処理設計で、デッドロック寸前まで行きかけては、多重度の自動調整によりぎりぎり基盤にて耐えているという状態。
デッドロックと言うと、並行で動作する二つの処理が、異なる二つのロックを、異なる順序で取得しようとして発生することをイメージする。
でも、デッドロックはもう少し違うレイヤーでも発生する。たとえば、Javaだと次のようなケース。

1. スレッド１：リソースを取得しようとする
   1. ロックＡ取得
   2. ロックＢ取得
   3. リソース取得
   4. ロックＢ開放
   5. ロックＡ開放
   6. リソース利用開始
2. スレッド２：リソースを取得しようとする（ＤＢコネクション等）
   1. ロックＡ取得
   2. ロックＢ取得
   3. リソースが空っぽを検知
   4. ロックＢにて待機（ロックＢ開放）
3. スレッド１：リソースを解放しようとする
   1. ロックＡが取れない！！

この場合、並行して動作する二つの処理が、異なる二つのロックを取得することに変わりはないが、同一順序で取得している。Javaのスレッドダンプをとっても、Javaレベルデッドロックとして検知されない。普通のデッドロック解説記事は、だいたい交差する矢印が発生するけど、この状態では、交差する矢印は発生しない。これを何と呼ぶかは知らないので、とりあえず、デッドロックと呼んでいる。（まあ、こんなプログラムを書くのもどうかと思うけど、複数のライブラリを組み合わせると、こんな状況が発生したりするから怖い。昔、SeasarとS2DAOで、これとまったく同じ経験をしてるし。）
今回ぶち当たっているトラブルは、これに非常に近い。リソースがスレッドで、かつスレッドプールのサイズが一定間隔おきに動的に増減するため、とりあえず、なんとか動いている状態だけど、この一定間隔というのがキモで、増減するまでの間は、処理が止まってしまっている状態なのだ。さらに、スレッドプールのＭＡＸになると、止まってしまうという大変残念な状況。
で、このトラブルを解析しようとして、昔、会社で仕事の合間を縫って作ってたスレッドダンプ解析支援ツールを使って解析しようとしたら、なんと、Java6のスレッドダンプの読み込みに失敗するという残念な状況＆異動によるＰＣ初期化でソースが手元にないという残念な状況になった。で、去年ぐらいにスレッドダンプを解析するためのツールをプライベートでも作ってたなあと思ったら、良く考えたらＨＤＤ死亡＆ＰＣ買い替えでそれもソースが手元にないという残念な状況だった。
samuraiとかTDAとか、まあ、世の中にはツールは色々あるけれど、どうしても機能に満足できない。で、いま、またツールを作るかどうか、迷ってる。