我們都去過那兒。 在查看設計不良的代碼的同時，聽聽作者對人們永遠不應該犧牲性能而不是設計的解釋。 而且，您不能說服作者擺脫其500行方法，因為鏈接方法調用會破壞性能。

好吧，這可能在1996年左右是正確的。 但是自那時以來， JVM已經發展成為一款了不起的軟件。 找出它的一種方法是開始更深入地研究虛擬機執行的優化。 JVM應用的技術庫非常廣泛，但是讓我們更詳細地研究其中一種。 即方法內聯 。 通過以下示例最容易解釋：

int sum(int a, int b, int c, int d) {return sum(sum(a, b),sum(c, d)); }int sum(int a, int b) {return a + b; }

當運行此代碼時， JVM將弄清楚它可以用更有效的所謂“內聯”代碼代替：

int sum(int a, int b, int c, int d) {return a + b + c + d; }

您必須注意，此優化是由虛擬機而不是由編譯器完成的。 最初做出此決定的原因并不透明。 畢竟-如果您查看上面的示例代碼-為什么在編譯時可以推遲優化以產生更有效的字節碼？ 但是，考慮到其他不太明顯的情況，JVM是執行優化的最佳位置：

• JVM除了靜態分析外還配備了運行時數據。 在運行時，JVM可以根據最常執行的方法，冗余的負載，何時安全使用副本傳播等做出更好的決策。
• JVM已獲得有關基礎體系結構的信息-內核數，堆大小和配置，因此可以根據此信息進行最佳選擇。

但是，讓我們在實踐中看到這些假設。 我創建了一個小型測試應用程序 ，它使用幾種不同的方法將1024個整數加在一起。

• 相對合理的一種，其中實現只是對包含1024個整數的數組進行迭代，并將結果求和。 InlineSummarizer.java中提供了此實現。
• 基于遞歸的分而治之方法。 我采用原始的1024個元素數組，然后將其遞歸地分成兩半，因此第一個遞歸深度為我提供了兩個512個元素數組，第二個深度為4個256個元素數組，依此類推。 為了將所有1024個元素加在一起，我引入了1023個其他方法調用。 此實現作為RecursiveSummarizer.java附加。
• 天真的分而治之的方法。 這也劃分了原始的1024個元素的數組，但是通過在分開的兩半上調用其他實例方法-即我嵌套了sum512（），sum256（），sum128（），…，sum2（）調用，直到我總結了所有元素。 與遞歸一樣，我在源代碼中介紹了1023個其他方法調用。

我有一個測試班來運行所有這些示例。 最初的結果來自未優化的代碼：

從上面可以看出，內聯代碼是最快的。 而我們引入了1023個其他方法調用的方法則要慢25,000ns。 但是此圖像必須加以警告-它是JIT尚未完全優化代碼的運行快照。 在我2010年中期的MB Pro中，根據實施情況，運行了200到3000次。

更現實的結果如下。 我已經運行了所有匯總器實現超過1,000,000次，并丟棄了JIT尚未成功實現魔術效果的運行。

我們可以看到，即使內聯代碼仍然表現最佳，但迭代方法也以相當快的速度飛速發展。 但是遞歸明顯不同–當迭代方法僅以20％的開銷關閉時，RecursiveSummarizer會花費內聯代碼需要完成的340％的時間。 顯然，這是應該注意的事情–使用遞歸時，JVM是無助的，無法內聯方法調用。 因此，在使用遞歸時請注意此限制。

除了遞歸-方法開銷幾乎不存在。 源代碼中有1023個其他方法調用之間的時間差僅為205 ns。 請記住，那是我們用于測量的那納秒（10 ^ -9 s）。 因此，借助JIT，我們可以安全地忽略方法調用帶來的大部分開銷。 下次當您的同事將笨拙的設計決策隱藏在通過調用堆棧彈出效率不高的語句后面時，請讓他首先完成一個小的JIT崩潰過程 。 如果您希望有能力阻止他將來的荒唐言論，請訂閱我們的RSS或Twitter提要，我們很高興為您提供未來的案例研究。

全面披露：本文所用測試用例的靈感來自Tomasz Nurkiewicz 博客文章 。

參考： Plumbr Blog博客上的JCG合作伙伴 Nikita Salnikov Tarnovski 用Java進行方法調用的成本是多少 ？

翻譯自: https://www.javacodegeeks.com/2013/02/how-expensive-is-a-method-call-in-java.html

總結

以上是生活随笔為你收集整理的Java中的方法调用有多昂贵的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。