多くの個人的な経験、逸話的な証拠、およびいくつかの基本的な分析から、Java サーバー (通常は Oracle の 1.6 JVM を実行) は、かなりの量の負荷がかかっている場合 (明らかに、ある程度まで) 応答時間が速くなることが示唆されています。
トラフィックが減少すると、応答時間が再び少し遅くなるため、これは純粋にホットスポットではないと思います。
多くの場合、これはサーバー ログからの応答時間を平均することで実証できます。場合によっては、平均で 20% も速くなり、標準偏差も小さくなります。
なぜそうなのか、誰か説明できますか？それは本当の効果である可能性が高いですか、それとも平均は単に誤解を招くものですか? 私はこれを何年もの間、いくつかの仕事を通して見てきましたが、事実として述べる傾向がありますが、その理由についての説明はありません.
ありがとう、エリック
言葉遣いのためにかなり大きな編集を編集し、全体に詳細を追加します。
いくつかの考え：
ホットスポットは、コードの一部が他の部分よりも大幅に多く実行されているときに開始されます（プログラムのホットスポットです）。これにより、そのコードはその時点から（通常のパスの場合）大幅に高速になります。ホットスポットのコンパイル後の呼び出し率は重要ではないので、これがあなたが言及している効果を引き起こしているとは思わない。
効果は本当ですか？統計で自分をだますのはとても簡単です。あなたがそうだと言っているわけではありませんが、すべての実行が結果に含まれていること、および他のすべての効果（他のプログラム、アクティビティ、監視プログラムなど）がすべての場合に同じであることを確認してください。 topなどのプログラムは、動作に違いをもたらします）。ある場合、データベースのキャッシュがウォームアップすると、アプリケーションのパフォーマンスが大幅に向上しました。同じDBインスタンス上の他のアプリケーションからのメモリ不足がありました。
オペレーティングシステムやCPUが関係している可能性があります。OSとCPUは、メインプログラムが主に実行中から主にI / Oの待機中、またはその逆に移行するときに、メインプログラムの応答性を向上させるために、アクティブとパッシブの両方で次のようなことを行います。
次の理由により、メモリページングの影響に特に敏感なJavaアプリケーション。
これらの考慮事項を考慮すると、メモリ要件が小さい環境よりも、ページミスが発生し、パフォーマンスが低下する可能性がはるかに高くなります。これらは、Javaがしばらくアイドル状態になった後に特に明らかになります。
SolarisまたはMacを使用している場合、優れたdTraceは、アプリケーションに固有のメモリとディスクのページングをトレースできます。JVMには、ページ監視を開始および停止するためのトリガーとして使用できる多数のdTraceフックがあります。
Solarisでは、大きなメモリページ（サイズが1GBを超える場合でも）を使用してRAMに固定できるため、ページアウトされることはありません。これにより、上記のメモリページの問題が解消されます。ディスクキャッシングおよびその他のシステム/メンテナンス/バックアップ/管理アプリ用に、十分な空きメモリを残すことを忘れないでください。他のOSも同様の機能をサポートしていると思います。
TL / DR： OSがプログラムとデータページをディスクから戻し、頻繁に使用するディスクページをディスクキャッシュに配置し、OS命令とデータキャッシュが実行されるため、最新のオペレーティングシステムで現在実行中のプログラムは数秒後に高速に実行されるように見えます。メインプログラムでは「暖かい」傾向があります。この効果はJVMに固有のものではありませんが、一般的なJavaアプリケーションのメモリ要件とガベージコレクションのメモリモデルにより、より顕著になります。