java調(diào)用怎么調(diào)用方法區(qū)

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

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

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將弄清楚它可以用更有效的所謂“內(nèi)聯(lián)”代碼代替：

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

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

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

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

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

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

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

更現(xiàn)實的結果如下。 我已經(jīng)運行了所有匯總器實現(xiàn)超過1,000,000次，并丟棄了JIT尚未成功執(zhí)行的運行。

我們可以看到，即使內(nèi)聯(lián)代碼仍然表現(xiàn)最佳，但迭代方法也以相當快的速度飛速發(fā)展。 但是遞歸明顯不同–當?shù)椒▋H以20％的開銷關閉時，RecursiveSummarizer會花費內(nèi)聯(lián)代碼需要完成的340％的時間。 顯然，這是應該注意的事情–使用遞歸時，JVM是無助的，無法內(nèi)聯(lián)方法調(diào)用。 因此，在使用遞歸時請注意此限制。

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

全面披露：本文中使用的測試用例的靈感是由Tomasz Nurkiewicz 博客文章觸發(fā)的。

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

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

java調(diào)用怎么調(diào)用方法區(qū)

總結

以上是生活随笔為你收集整理的java调用怎么调用方法区_Java中的方法调用有多昂贵的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。