Java性能不一致

Question

我有一個用Java編寫的解釋器。 我試圖在解釋器中測試各種優化的性能結果。 為此，我解析代碼，然后在代碼上重復運行解釋器，這一直持續到我得到5次運行，這些運行的差異非常小（下面的時間為0.1秒），取平均值並打印。 解釋器中沒有I / O或隨機性。 如果我再次運行解釋器，我會得到不同的運行時間：

91.8s
95.7s
93.8s
97.6s
94.6s
94.6s
107.4s

我試圖無法使用服務器和客戶端VM，串行和並行gc，大型表和窗口以及linux。 這些是在1.6.0_14 JVM上。 計算機沒有在后台運行的進程。 所以我問可能導致這些大變化的原因是什么，或者我怎么能找出它是什么？

---

由於程序必須迭代到固定點解決方案並且值存儲在散列集中，因此導致實際問題。 運行之間的散列值不同，導致不同的排序，這反過來導致達到解決方案所需的迭代量的變化。

Answer 1

“掛鍾時間”很少是基准測試的良好衡量標准。 現代操作系統極不可能“[沒有在后台運行進程” - - 眾所周知，它可能是將臟塊緩沖區寫入磁盤，因為它決定沒有其他爭用。

相反，我建議使用ThreadMXBean來跟蹤實際的CPU消耗。

Answer 2

你的變化看起來不那么大。 它只是野獸的本質，在操作系統和JVM中，還有其他東西在你的直接控制之外運行，你不可能得到確切的結果。

可能影響運行時的事情：

• 如果您的測試運行正在創建對象（可能對您不可見，在庫調用中等），那么您的重復可能會觸發GC

• 不同的GC算法，規范會有不同的反應，增量gc的閾值不同。 您可以嘗試在每次運行之前運行System.gc（），盡管在您調用它時不能保證JVM（雖然它總是在我使用它時）.T根據您的測試大小，你正在運行多少次迭代，這可能是一件令人不快的（而且幾乎無用的）緩慢的事情。

• 你在測試中做過任何隨機化嗎？ 例如，如果您正在測試整數，則值<| 128 | 可能在內存中處理稍有不同。

最終，我認為不可能得到一個確切的數字，可能你能做的最好的是圍繞結果集群的平均數字。

Answer 3

垃圾收集可能是負責任的。 即使您的邏輯相同，也可能是GC邏輯正在外部時鍾/事件上進行調度。

但我對JVMs GC的實現知之甚少。

Answer 4

這對我來說似乎是一個很大的變化，我會嘗試使用-verbosegc運行。

如果您的流程沒有任何重要的IO，輸出或網絡，您應該能夠將變化小於一秒。

我建議對您的應用程序進行分析，如果您還沒有這樣做，很可能會有很大的節省。