私たちのカスタマーインストールの1つに、同じ例外の何千もの発生がありました。よくログに記録されたスタックトレース（9332）の後も、例外の発生は記録されますが、スタックトレースは記録されません。 Javaプロセスを再起動した後、同じこと：今度は17858回のスタックトレースが発生し、その後例外発生自体が発生しました。それは、log4jの機能やバグ同様の質問here、ない答えはありlog4jは同じ例外の（たくさんの）繰り返しの後にスタックトレースを無効にするのはなぜですか？
...
ですか？ （私は、私が本当に好きなので、前者を信じる、それらのアパッチの男は何ですか）
アイデア？
Java 5以降を使用していますか？
次に、あなたが見ている
：VMは今のところ正しいスタックバックトレースを提供するサーバでのコンパイラのすべての「冷たい」、内蔵の例外。パフォーマンス上の理由から、このような例外が数回スローされた場合、メソッドは再コンパイルされる可能性があります。再コンパイル後、コンパイラは、スタックトレースを提供しない事前に割り当てられた例外を使用して、より高速な方法を選択することがあります。 Java 5 release notesの
-XX:-OmitStackTraceInFastThrow
礼儀：完全に事前に割り当てられた例外の使用を無効にするには、この新しいフラグを使用します。
少なくとも、スタックのトレースが本当に同じであれば、私のような特徴があります。それ以上の情報を得ることなく、あなたのログを大きくする（検索するのが難しい）のはなぜですか？この機能の設定可能性を確認します...
編集：私はlog4jコードを見てきましたが、それの痕跡はありません。これはロバートの答えが正しいことを強く示唆する。ニースVM機能IMO :)
お返事ありがとうございます。私は自分のログファイルを大きくしたくありません（そして、私はこの機能が好きです - バグであっても...）。問題は、私は最初にスタックトレースを持たないログエントリを見たことがあり、他のものもあるとは考えられませんでした。私のコード内でバグを見つけようとしたときにはあまり役に立ちませんでした。 –
ありがとうございます。それは正しい答えのように聞こえ、私はそれを再確認して、これを正しいものとして受け入れます。 –
リリースノートにアクセスできなくなりました。最後にアーカイブされたキャプチャは[2012-06-27]（http://web.archive.org/web/20120627040457/http://java.sun.com/j2se）から取得しました。 /1.5.0/relnotes.html）。元のソースを確認したかったにもかかわらず、関連するアイテムの見積もりが完了しました。 – vilpan