編寫高性能 Java 代碼的最佳實踐

點選上方“芋道源碼”，選擇“設為星标”

管她前浪，還是後浪？

能浪的浪，才是好浪！

每天 8:55 更新文章，每天掉億點點頭發...

源碼精品專欄

• 原創 | Java 2020 超神之路，很肝~
• 中文詳細注釋的開源項目
• RPC 架構 Dubbo 源碼解析
• 消息中間件 RocketMQ 源碼解析
• 資料庫中間件 Sharding-JDBC 和 MyCAT 源碼解析
• 作業排程中間件 Elastic-Job 源碼解析
• 分布式事務中間件 TCC-Transaction 源碼解析
• Eureka 和 Hystrix 源碼解析
• Java 并發源碼

來源：雁驚寒

• 性能名額
• 找出性能瓶頸
• 代碼級别的優化
• 架構改進
• 介紹
• 性能名額
• 找出性能瓶頸
• 代碼級别的優化
• 架構改進

• 

  摘要：本文首先介紹了負載測試、基于APM工具的應用程式和伺服器監控，随後介紹了編寫高性能Java代碼的一些最佳實踐。最後研究了JVM特定的調優技巧、資料庫端的優化和架構方面的調整。

  以下是譯文。

  介紹

  在這篇文章中，我們将讨論幾個有助于提升Java應用程式性能的方法。我們首先将介紹如何定義可度量的性能名額，然後看看有哪些工具可以用來度量和監控應用程式性能，以及确定性能瓶頸。

  我們還将看到一些常見的Java代碼優化方法以及最佳編碼實踐。最後，我們将看看用于提升Java應用程式性能的JVM調優技巧和架構調整。

  請注意，性能優化是一個很寬泛的話題，而本文隻是對JVM探索的一個起點。

  性能名額

  在開始優化應用程式的性能之前，我們需要了解諸如可擴充性、性能、可用性等方面的非功能需求。

  以下是典型Web應用程式常用的一些性能名額：

  • 應用程式平均響應時間
  • 系統必須支援的平均并發使用者數
  • 在負載高峰期間，預期的每秒請求數
  這些名額可以通過使用多種監視工具監測到，它們對分析性能瓶頸和性能調優有着非常大的作用。

  示例應用程式

  我們将使用一個簡單的Spring Boot Web應用程式作為示例，在這篇文章中有相關的介紹。這個應用程式可用于管理者工清單，并對外公開了添加和檢索員工的REST API。

  我們将使用這個程式作為參考來運作負載測試，并在接下來的章節中監控各種應用名額。

  找出性能瓶頸

  負載測試工具和應用程式性能管理（APM）解決方案常用于跟蹤和優化Java應用程式的性能。要找出性能瓶頸，主要就是對各種應用場景進行負載測試，并同時使用APM工具對CPU、IO、堆的使用情況進行監控等等。

  Gatling是進行負載測試最好的工具之一，它提供了對HTTP協定的支援，是HTTP伺服器負載測試的絕佳選擇。

  Stackify的Retrace是一個成熟的APM解決方案。它的功能很豐富，對确定應用程式的性能基線很有幫助。Retrace的關鍵元件之一是它的代碼分析功能，它能夠在不減慢應用程式的情況下收集運作時資訊。

  Retrace還提供了監視基于JVM應用程式的記憶體、線程和類的小部件。除了應用程式本身的名額之外，它還支援監視托管應用程式的伺服器的CPU和IO使用情況。

  是以，像Retrace這樣功能全面的監控工具是解鎖應用程式性能潛力的第一步。而第二步則是在你的系統上重制真實使用場景和負載。

  說起來容易，做起來難，而且了解應用程式目前的性能也非常重要。這就是我們接下來要關注的問題。

  Gatling負載測試

  Gatling的模拟測試腳本是用Scala編寫的，但該工具還附帶了一個非常有用的圖形界面，可用于記錄具體的場景，并生成Scala腳本。

  在運作模拟腳本之後，Gatling會生成一份非常有用的、可用于分析的HTML報告。

  定義場景

  在啟動記錄器之前，我們需要定義一個場景，表示使用者在浏覽Web應用時發生的事情。

  在我們的這個例子中，具體的場景将是“啟動200個使用者，每個使用者發出一萬個請求。”

  配置記錄器

  根據“Gatling的第一步”所述，用下面的代碼建立一個名為EmployeeSimulation的scala檔案：

  class EmployeeSimulation extends Simulation {
      val scn = scenario("FetchEmployees").repeat(10000) {
          exec(
            http("GetEmployees-API")
              .get("http://localhost:8080/employees")
              .check(status.is(200))
          )
      }
      setUp(scn.users(200).ramp(100))
  }
             

  運作負載測試

  要執行負載測試，請運作以下指令：

  $GATLING_HOME/bin/gatling.sh-sbasic.EmployeeSimulation
             

  對應用程式的API進行負載測試有助于發現及其細微的并且難以發現的錯誤，如資料庫連接配接耗盡、高負載情況下的請求逾時、因為記憶體洩漏而導緻堆的高使用率等等。

  監控應用程式

  要使用Retrace進行Java應用程式的開發，首先需要在Stackify上申請免費試用賬号。然後，将我們自己的Spring Boot應用程式配置為Linux服務。我們還需要在托管應用程式的伺服器上安裝Retrace代理，按照下面這篇文章所述的操作即可。

  https://support.stackify.com/hc/en-us/articles/205419575

  申請賬号：

  https://stackify.com/retrace/

  Retrace代理和要監控的Java應用程式啟動後，我們就可以到Retrace儀表闆上單擊AddApp按鈕添加應用了。添加應用完成之後，Retrace将開始監控應用程式了。

  找到最慢的那個點

  Retrace會自動監控應用程式，并跟蹤數十種常見架構及其依賴關系的使用情況，包括SQL、MongoDB、Redis、Elasticsearch等等。Retrace能幫助我們快速确定應用程式為什麼會出現如下性能問題：
  • 某個SQL語句是否會拖慢系統的速度？
  • Redis突然變慢了嗎？
  • 特定的HTTP Web服務宕了，還是變慢了？
  例如，下面的圖形展示了在一段給定的時間内速度最慢的元件。

  

  圖檔

  代碼級别的優化

  負載測試和應用程式監控對于确定應用程式的一些關鍵性能瓶頸非常有用。但同時，我們需要遵循良好的編碼習慣，以避免在對應用程式進行監控的時候出現過多的性能問題。

  在下一章節中，我們将來看一些最佳實踐。

  使用StringBuilder來連接配接字元串

  字元串連接配接是一個非常常見的操作，也是一個低效率的操作。簡單地說，使用+=來追加字元串的問題在于每次操作都會配置設定新的String。

  下面這個例子是一個簡化了的但卻很典型的循環。前面使用了原始的連接配接方式，後面使用了建構器：

  public String stringAppendLoop() {
      String s = "";
      for (int i = 0; i < 10000; i++) {
          if (s.length() > 0)
              s += ", ";
          s += "bar";
      }
      return s;
  }
  
  public String stringAppendBuilderLoop() {
      StringBuilder sb = new StringBuilder();
      for (int i = 0; i < 10000; i++) {
          if (sb.length() > 0)
              sb.append(", ");
          sb.append("bar");
      }
      return sb.toString();
  }
             

  上面代碼中使用的StringBuilder對性能的提升非常有效。請注意，現代的JVM會在編譯或者運作時對字元串操作進行優化。

  避免遞歸

  導緻出現StackOverFlowError錯誤的遞歸代碼邏輯是Java應用程式中另一種常見的問題。如果無法去掉遞歸邏輯，那麼尾遞歸作為替代方案将會更好。

  我們來看一個頭遞歸的例子：

  public int factorial(int n) {
      if (n == 0) {
          return 1;
      } else {
          return n * factorial(n - 1);
      }
  }
             

  現在我們把它重寫為尾遞歸：

  private int factorial(int n, int accum) {
      if (n == 0) {
          return accum;
      } else {
          return factorial(n - 1, accum * n);
      }
  }
  public int factorial(int n) {
      return factorial(n, 1);
  }
             

  其他JVM語言（如Scala）已經在編譯器級支援尾遞歸代碼的優化，當然，對于這種優化目前也存在着一些争議。

  謹慎使用正規表達式

  正規表達式在很多場景中都非常有用，但它們往往具有非常高的性能成本。了解各種使用正規表達式的JDK字元串方法很重要，例如String.replaceAll()、String.split()。

  如果你不得不在計算密集的代碼段中使用正規表達式，那麼需要緩存Pattern的引用而避免重複編譯：

  static final Pattern HEAVY_REGEX = Pattern.compile("(((X)*Y)*Z)*");
             

  使用一些流行的庫，比如Apache Commons Lang也是一個很好的選擇，特别是在字元串的操作方面。

  避免建立和銷毀過多的線程

  線程的建立和處置是JVM出現性能問題的常見原因，因為線程對象的建立和銷毀相對較重。

  如果應用程式使用了大量的線程，那麼使用線程池會更加有用，因為線程池允許這些昂貴的對象被重用。

  為此，Java的ExecutorService是線程池的基礎，它提供了一個進階API來定義線程池的語義并與之進行互動。

  Java 7中的Fork/Join架構也值得提一下，因為它提供了一些工具來嘗試使用所有可用的處理器核心以幫助加速并行處理。為了提高并行執行效率，架構使用了一個名為ForkJoinPool的線程池來管理工作線程。

  JVM調優

  堆大小的調優

  為生産系統确定合适的JVM堆大小并不是一件簡單的事情。要做的第一步是回答以下問題以預測記憶體需求：
  • 計劃要把多少個不同的應用程式部署到單個JVM程序中，例如EAR檔案、WAR檔案、jar檔案的數量是多少？
  • 在運作時可能會加載多少個Java類，包括第三方API的類？
  • 估計記憶體緩存所需的空間，例如，由應用程式（和第三方API）加載的内部緩存資料結構，比如從資料庫緩存的資料、從檔案中讀取的資料等等。
  • 估計應用程式将建立的線程數。

  如果沒有經過真實場景的測試，這些數字很難估計。

  要獲得有關應用程式需求的最好最可靠的方法是對應用程式執行實際的負載測試，并在運作時跟蹤性能名額。我們之前讨論的基于Gatling的測試就是一個很好的方法。

  選擇合适的垃圾收集器

  Stop-the-world（STW）垃圾收集的周期是影響大多數面向用戶端應用程式響應和整體Java性能的大問題。但是，目前的垃圾收集器大多解決了這個問題，并且通過适當的優化和大小的調整，能夠消除對收集周期的感覺。

  分析器、堆轉儲和詳細的GC日志記錄工具對此有一定的幫助作用。再一次注意，這些都需要在真實場景的負載模式下進行監控。

  有關不同垃圾收集器的更多資訊，請檢視這個指南。

  https://stackify.com/what-is-java-garbage-collection/

  JDBC性能

  關系型資料庫是Java應用程式中另一個常見的性能問題。為了獲得完整請求的響應時間，我們很自然地必須檢視應用程式的每一層，并思考如何讓代碼與底層SQL DB進行互動。

  連接配接池

  讓我們從衆所周知的事實開始，即資料庫連接配接是昂貴的。連接配接池機制是解決這個問題非常重要的第一步。

  這裡建議使用HikariCP JDBC，這是一個非常輕量級（大約130Kb）并且速度極快的JDBC連接配接池架構。

  JDBC批處理

  持久化處理應盡可能地執行批量操作。JDBC批處理允許我們在單次資料庫互動中發送多個SQL語句。

  這樣，無論是在驅動端還是在資料庫端，性能都可能得到顯著地提升。* PreparedStatement*是一個非常棒的的批處理指令，一些資料庫系統（例如Oracle）隻支援預處理語句的批處理。

  另一方面，Hibernate則更加靈活，它允許我們隻需修改一個配置即可快速切換為批處理操作。

  語句緩存

  語句緩存是另一種提高持久層性能的方法，這是一種鮮為人知但又容易掌握的性能優化方法。

  隻要底層的JDBC驅動程式支援，你就可以在用戶端（驅動程式）或資料庫端（文法樹甚至執行計劃）中緩存PreparedStatement。

  規模的縮放

  資料庫複制和分片是提高吞吐量非常好的方法，我們應該充分利用這些經過實踐檢驗的架構模式，以擴充企業應用的持久層。

  架構改進

  緩存

  現在記憶體的價格很低，而且越來越低，從磁盤或通過網絡來檢索資料的性能代價仍然很高。緩存自然而然的變成了在應用程式性能方面不能忽視的關鍵。

  當然，在應用的拓撲結構中引入一個獨立的緩存系統确實會增加架構的複雜度，是以，應當充分利用目前使用的庫和架構現有的緩存功能。

  例如，大多數的持久化架構都支援緩存。Spring MVC等Web架構還可以使用Spring中内置的緩存支援，以及基于ETags的強大的HTTP級緩存。

  橫向擴充

  無論我們在單個執行個體中準備了多少硬體，都會有不夠用的時候。簡而言之，擴充有着天生的局限性，當系統遇到這些問題時，橫向擴充是處理更多負載的唯一途徑。這一步肯定會相當的複雜，但卻是擴充應用的唯一辦法。

  對大多數的現代架構和庫來說，這方面還是支援得很好的，而且會變得越來越好。Spring生态系統有一個完整的項目集，專門用于解決這個特定的應用程式架構領域，其他大多數的架構也都有類似的支援。

  除了能夠提升Java的性能，通過叢集進行橫向擴充也有其他的好處，添加新的節點能産生備援，并更好的處理故障，進而提高整個系統的可用性。

  結論

  在這篇文章中，我們圍繞着提升Java應用的性能探讨了許多概念。我們首先介紹了負載測試、基于APM工具的應用程式和伺服器監控，随後介紹了編寫高性能Java代碼的一些最佳實踐。最後，我們研究了JVM特定的調優技巧、資料庫端的優化和架構方面的調整。

  歡迎加入我的知識星球，一起探讨架構，交流源碼。加入方式，長按下方二維碼噢：

  

  已在知識星球更新源碼解析如下：

  

  

  

  

  最近更新《芋道 SpringBoot 2.X 入門》系列，已經 20 餘篇，覆寫了 MyBatis、Redis、MongoDB、ES、分庫分表、讀寫分離、SpringMVC、Webflux、權限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能測試等等内容。

  提供近 3W 行代碼的 SpringBoot 示例，以及超 4W 行代碼的電商微服務項目。

  擷取方式：點“在看”，關注公衆号并回複 666 領取，更多内容陸續奉上。

  兄弟，艿一口，點個贊！????