私たちの Tomcat Web アプリケーションは、数百人のユーザーが使用すると遅く感じます。サーバーはホスティング会社にあり、そのレポートでは帯域幅や CPU のワークロードに問題は示されていません。より簡単なパス。
ThreadLocal ソリューションを使用して同期呼び出しを変更する開発環境でいくつかの人為的なテストを行ったところ、速度が向上しましたが、上司が本番環境でも速度が向上するという証拠を要求することはわかっています。
アプリでスレッドの競合が問題になっているかどうかを確認するにはどうすればよいですか?
最近のJava6JDKに付属しているvisualVMツールのスレッド詳細ビューは、理論の確固たる証拠を提供できると思います。スレッドごとに円グラフが表示され、実行、スリープ、待機、およびモニターで費やされた時間が示されます。最後（赤で表示）はあなたが興味を持っているものです：
より速いと思われる修正バージョンがある場合は、ロード テスター ( JMeterなど) を使用して両方のバージョンをテストしてテストします。有意差がある場合は、それを証明する結果が得られます。
Thareは、自由に使えるオープンソースのJavaプロファイラーの集まりであり、 YourKitのようにお金がかかる可能性のあるものもあります。既存のコードと拡張コードの両方を使用してテストを実行する必要があります。ThreadLocalsを使用することで、一般的に競合を減らすことができますが、最適化を開始する前にベンチマークを実行することも良いと考えてください。
プロファイラーを設定せずに実行できるもう1つの非常に簡単なテストは、アプリの速度が遅いように見える間に、いくつかのスレッドダンプ（ctrl-breakまたはkill -QUIT）を実行することです。短い期間に類似または同じモニターで待機しているいくつかのスレッドを見つけると、遅いスポットをかなり明確に指摘できる場合があります。JavaスレッドダンプアナライザーであるTDAなどのツールを使用して、スレッドダンプをくまなく調べることができます。
繰り返しますが、最適化を開始する前にこの作業を行うことをお勧めします。これは、最適化によって違いが生じる明らかな場所があるかもしれませんが、実際のユーザーの行動が開発者が考慮しないパスをトリガーする可能性があり、これらが実際の問題領域であることが判明する可能性があるためです。
あなたの分析は合理的に聞こえます。たとえば、visualvm（JDK内）をプロセスにアタッチして、時間が費やされている場所を確認できますか？
このように、同期された通話にログを追加できます
//...
long t0 = System.currentTimeMillis();
synchronized(lockObj){
logger.info("T sync :" + (t0 - System.currentTimeMillis()));
//...
}
しかし、これは安くて汚いと感じます。