-1

過去 5 ～ 6 年間発生していなかったプロダクション コードで突然の問題が発生しました。最大 64 個のスレッドを生成するスレッド プールがあり、64 個のスレッドすべてがデータを読み取り、それMapをさらに処理するために共通に配置します。

読み取りは特定のソースからのすべてのスレッドによって行われ、データが実際にソースから読み取られていることを確認しましたが、1 つの特定のバッチがMap.

コード スニペットを次に示します (機密性の問題のため、コード全体を配置することはできません)。

try {
   <read the data>
    .
    .
    <do processing>
    .
    .
    synchronized(glock) { //glock is a class attribute, Object glock = new Object[];
     map.put(<data that was read>);
     log.debug("bla bla bla")
    }
} catch(Throwable e) { 
     log.error("error") 
  }
  finally {
    log.debug("done")
 }

問題: 特定のスレッドが同期ブロックに入らない、マップに入らない、印刷しない、印刷"bla bla bla"しない"error"が印刷する"done"。

すべてを確認しました...コードに変更はありません。この問題はどこからともなくすぐに現れました。問題は、すべてのクライアントの同意を得ずに運用コードであるため、追加のログを配置できないことですが、それは最後の部分です。

誰かが同様の問題に直面したか、それについて何か知っていますか? 読み取られるデータは巨大で、6000 レコードで、各レコードには最小 0f 30 ～ 40 列のデータがあります。

前もって感謝します。

編集：キャッチThrowableしていないException

4

2 に答える 2

3

あなたが私たちに見せてくれたものから、それは

synchronized(glock){}

「bla bla bla」を印刷せずに、データをマップに配置するときに例外をスローします。のブロックにある
ため、「done」が出力されます。finallytry

于 2012-08-13T11:47:27.020 に答える
2

コードに問題がある可能性は 99% あります。これは、synchronizedブロック内のコードが例外をスローすることを意味しますが、それは表示されません。

通常の犯人は次のとおりです。

  • catch例外を飲み込む空のブ​​ロック (コードの他の場所にある可能性があります)
  • ブロック内のロガーの異常なログcatch構成。たとえば、例外を別のログ ファイルに書き込みます。
  • なんらかの理由でログ メッセージが順番どおりに書き込まれていない (そのため、ERROR 行が予期した場所にない)
  • いくつかの異常な状態 (メモリ不足など) に加えて、回復力のあるコードがログ メッセージの書き込みを妨げています。マップには驚くほどの量のメモリが必要になる場合があります。
  • log標準のJavaロガーではなく、別のものです。

VM にバグが見つかったか、ハードウェアに問題がある可能性はわずか (1% 未満) です。同じ結果が繰り返し得られる場合は、おそらくハードウェアの問題ではありません。

他のすべてが失敗した場合は、本番環境で問題をデバッグする必要があります。もちろん、クライアントは反対します。その時点で、どちらがより重要かを彼らに決定してもらいます。つまり、コードをデバッグしてはならない、またはバグを修正してはならないというルールです。

于 2012-08-13T12:11:23.137 に答える