[[393851]]

項目每次啟動都要一分多鐘，改一行代碼就要重啟很難受?推薦一款提高工作效率的熱加載JVM插件：JRebel。

JRebel筆者也用很長一段時間了，這貨確實幫我省了不少時間，所以才強烈推薦大家使用。

這是一款實現熱加載的JVM插件，官方也為IDEA提供了JRebel IDEA 插件，使用和安裝也都非常簡單，動動手指就能找到很多安裝教程。

推薦參考這篇文章的破解教程，簡單可用：《JRebel破解最簡單的使用》，鏈接：https://juejin.cn/post/6844903950781677582。

安裝插件后，在idea的左側工具欄可以看到jrebel選項，點開后勾選需要使用jrebel插件的應用，如下圖所示。

勾選后，當前項目的DEBUG一欄會出現有jrebel logo的debug按鈕，如下圖所示。

當我們修改某個類后，如果想要即時生效，可在當前類的編輯窗口中右鍵，選擇Compile And Reload File，如下圖所示。

官網強調JRebel是實現熱加載的JVM插件，那熱加載與熱部署有何不同呢?

• 熱部署：jvm進程不重啟，重新加載整個web應用;
• 熱加載：運行時重新加載類。

我們熟知的Tomcat就是使用熱部署實現不重啟JVM支持多web應用部署以及重新部署，對web應用而言是已經重啟了，而JRebel是使用熱加載實現不重啟應用也能使修改生效。

如果你做過Android應用開發，那么你應該還熟悉一個詞：熱修復。

17年筆者在做Android應用開發的時候熱修復這項技術就非常火，如熱門代表：手Q空間超級補丁技術、微信Tinker、阿里百川HotFix。手Q空間超級補丁技術、微信Tinker在實現原理上都是通過在應用啟動時將新的dex替換舊的dex實現(替換class)，需要應用重啟才生效，阿里百川推出的熱修復HotFix則不同于前兩者，下拉補丁后無需重啟應用就能立即生效。

為什么Android應用開發領域的熱修復可以那么火?不同于WEB應用更新，WEB應用更新用戶是被動接受，而Android版本更新需要用戶主動去更新。而使用熱修復可以實現讓用戶被動接受更新，在應用重啟時神不知鬼不覺的動態修復bug，優化用戶體驗，同時也就減少APP的卸載率。

隨著后端項目不斷臃腫，導致依賴的很多框架初始耗時越來越長，熱加載開始被用于提升后端開發效率，被用到后端開發調試上。當然，也有使用熱加載實現修復線上bug的，但在微服務容器化部署時代，已經體現不出這樣做的價值了。

你可能會說，現在微服務不會很臃腫，本地調試重啟也就幾秒鐘的事情，使用它效率也不明顯。但如果重啟需要重新登錄或者說需要做一些初始化工作就不好說了。

盡管熱加載很實用，它可以幫我們省去大部分改寫代碼的重啟時間。但也并不是所有場景都能使用熱加載替代重啟。

如果我們改動的是Mybatis的SQL、Spring的注解或配置類等，我們依然需要重啟應用。原因很好理解，我們就以依賴Spring和Mybatis框架的應用為例說明。

首先是修改Spring配置類或者一些類上的注解重新編譯熱加載后發現修改并未生效，這是因為Spring只在容器啟動時應用配置類、掃描Bean類時讀取類上的注解等。

其次是Mybatis，無論我們修改的是注解上的Sql還是xml文件中的Sql都不會生效，因為Mybatis初始化時就需要讀取xml文件中的sql或者接口方法上注解的sql來為接口生成代理類，后續不會再用到注解或xml文件，因此動態修改不會生效。

說到Mybatis，筆者找到一款IDEA插件能夠解決修改sql需要重啟應用的問題：【jrebel-mybatisplus-idea-plugin】https://github.com/SweetInk/jrebel-mybatisplus。

關于JRebel的實現原理筆者也不了解，因為找不到更多資料，JRebel也不開源。如果讓我實現一個簡單的熱加載，我也有一個簡單的思路，通過已知的Java Agent和IDEA插件知識，可以通過動態重新加載類的方式完成簡單的方法代碼改寫，也會有應用場景，如修復調試時發現的空指針異常、不涉及其它框架的業務邏輯錯誤、組件邏輯錯誤等，避免過多的應用重啟。

本文轉載自微信公眾號「Java藝術」，可以通過以下二維碼關注。轉載本文請聯系Java藝術公眾號。