ゴミ回収(1)ゴミ回収のタイミングが予測できないため、GCの影響で測定された実行時間が不正確になる場合がある(2)GCによる測定時間誤差に対応できないポリシー1°GC操作がテスト期間中に実行されないことを確保-verboseでJVM運転時にGCが2°を超えているかどうかを確認GC操作がテスト期間中に複数回実行されていることを確保するという方式がより信頼できる、実際の実行環境に似ているため
動的コンパイル(1)JIT技術によるテストの時間は、解釈実行の時間である可能性もあれば、コンパイル実行の時間である可能性もあり、また、解釈実行方式で実行するコードの速度を2つの混合(2)測定しても意味がない.頻繁に呼び出されるコードはコンパイルされる(3)動的コンパイルが測定結果に誤差をもたらすポリシーを適用してプログラムが十分な時間実行した後にを測定する.
のコードパスの非現実的なサンプリング(1)急進的なコンパイラ最適化は、同じ方法をもたらし、1つの実行条件下で1つの実行方式を生成し、別の実行条件では、例えば、単一スレッドでのみ使用する方法と、マルチスレッドで使用する方法とでは実際の実行方法が異なる(2)解決策は、アプリケーションで実行されるコードパスのセットをできるだけ上書きする.
の非現実的な競争度(1)実際の実行時には、複数のスレッドが計算密集型タスクである可能性があるため、ロックに対する競争はほとんど存在しない.テスト時に複数のスレッドに実行させる単純なタスクは,実行時間が短いため,競合が顕著であり,誤った結論が得られた.
無用コードの除去(1)最適化コンパイルは、結果に影響を及ぼさない無用コード基準テストコードが無用コードであることが多いため、テストされていない可能性が高い.(2)解決策:テスト部分の結果を明示的に使用するがIO操作を導入することができず、このように測定した結果も正確ではない.1つの簡単な操作は、あるオブジェクトのハッシュ値を計算し、if条件として任意の値と比較することであり、成功すれば空文字例 if (myObject.x.hashCode == System.nanoTime()) {
System.out.print(" ");
}
を出力するという操作は衝突することが少なく、プログラムに何の影響も与えない.二つ目は本当に結果を利用しており、テストコードは無駄なコードとして最適化されない.3つのprintメソッドは、printlnが呼び出されるまで出力をキャッシュするので、結果には影響しません.
結果の予測不可能(1)入力されたテストデータが常に規則的なデータである場合、インテリジェントなコンパイラは、実際のテスト(2)解決策で入力されたテストデータを実行せずに結果をキャッシュするランダム数を使用する.