お客様のインストールの1つで、同じ例外が何千回も発生しました。多くの適切にログに記録されたスタックトレース（9332）の後でも、例外の発生はログに記録されますが、スタックトレースはありません。Javaプロセスを再起動した後も、同じことが言えます。今回は17858のスタックトレースがあり、例外が発生しただけです。
ここにも同様の質問がありますが、答えはありません...
log4jの機能ですか、それともバグですか？（私は前者を信じています、なぜなら私は本当に好きなので、それらのapacheの人がすること）
何か案は？
Java 5以降を使用していますか？
次に、次のように表示されます。
サーバーVMのコンパイラーは、すべての「コールド」組み込み例外に対して正しいスタックバックトレースを提供するようになりました。パフォーマンス上の理由から、このような例外が数回スローされると、メソッドが再コンパイルされる場合があります。再コンパイル後、コンパイラは、スタックトレースを提供しない事前に割り当てられた例外を使用して、より高速な戦術を選択する場合があります。事前に割り当てられた例外の使用を完全に無効にするには、次の新しいフラグを使用します。
-XX:-OmitStackTraceInFastThrow
Java5リリースノートの礼儀。
少なくともスタックトレースが実際に同一である場合、私には機能のように聞こえます。これ以上情報を取得せずに、ログを大きくする（したがって検索を困難にする）のはなぜですか？この機能の構成可能性をチェックします...
編集：log4jコードを調べましたが、その痕跡はありません。これは、ロバートの答えが正しいことを強く示唆しています。素晴らしいVM機能IMO:)