一、熱部署與熱載入

在應用執行的時升級軟體，無需重新啟動的方式有兩種，熱部署和熱載入。

對於Java應用程式來說，熱部署就是在伺服器執行時重新部署專案，熱載入即在在執行時重新載入class，從而升級應用。

二、實現原理

熱載入的實現原理主要依賴java的類載入機制，在實現方式可以概括為在容器啟動的時候起一條後臺執行緒，定時的檢測類檔案的時間戳變化，如果類的時間戳變掉了，則將類重新載入。

對比反射機制，反射是在執行時獲取類資訊，通過動態的呼叫來改變程式行為； 熱載入則是在執行時通過重新載入改變類資訊，直接改變程式行為。

熱部署原理類似，但它是直接重新載入整個應用，這種方式會釋放記憶體，比熱載入更加乾淨徹底，但同時也更費時間。

三、在java中應用

1.生產環境

熱部署作為一個比較靈活的機制，在實際的生產上運用還是有，但相對很少，熱載入則基本沒有應用。分析如下

• 一、安全性

熱載入這種直接修改jvm中位元組碼的方式是難以監控的，不同於sql等執行可以記錄日誌，直接位元組碼的修改幾乎無法記錄程式碼邏輯的變化，對既有程式碼行為的影響難以控制，對於越注重安全的應用，熱載入帶來的風險越大,這好比給飛行中的飛機更換髮動機。

• 二、適用的情景

技術大部分是跟需求掛鉤的，而需要熱部署的情景很少。

1. 頻繁的部署並且啟動耗時長的應用
2. 無法停止服務的應用

在生產中，並沒有需要頻繁部署的應用，即使是敏捷，再快也是一週一次的迭代，並且通過業務劃分和模組化程式設計，部署的代價完全可以忽略不計，對於現有的應用，啟動耗時再長，也並非長到無法忍受，如果真的這麼長，那更應該考慮的是如何進行模組拆分，分散式部署了。

對於無法停止服務的應用，比如現在的雲端計算平臺這樣分散式應用，採用分批上線也可以滿足需求，類似熱部署方案應該是放在最後考慮的解決方案。

2.開發環境

在生產中，不會有頻繁的部署並且啟動耗時長的應用，但由於雲端計算的興起，熱部署還是有其應用。 而熱載入有點玩火，太危險了。但在開發和debug中，頻繁啟動應用卻隨處可見，熱載入機制可以極大的提升開發效率。這兩種機制，在開發中還有另外一種稱呼--開發者模式。

對於大型專案：往往啟/停需要等待幾分鐘時間。更浪費時間的是，對於一個類中的方法的除錯過程，如果修改多次，需要反覆的啟停伺服器，浪費的時間更多。

以目前的crm專案為例，其啟動時間為5m，以一天debug重啟十次，一個月工作20天來算，每年重啟耗時25人日，如果能完全使用熱載入，每年節省重啟時間近1人月。

crm pool啟動耗時

1.struts2熱載入

在struts2中熱載入即開發者模式，在struts.xml配置

從而當更改struts.xml檔案後不需要重新啟動伺服器就可以進行程式除錯。

2.開發時使用tomcat熱載入

tomcat本身預設開啟了熱部署方式，但熱部署是直接重新載入整個應用，耗時跟重啟伺服器差不多，我們需要的其實是熱載入，即修改了哪個class，只重新載入這一個class，這樣耗時幾乎為0。 對於tomcat5.x 以上版本，均已支援一定程度上得熱載入，但這種方式只針對程式碼行級別的，也就是說如果新刪方法，註解，類，或者變數時是無效的，只能重啟，這是我目前在公司開發時用的方式，可以顯著降低debug時的重啟次數，提高開發效率

1.將tomcat server.xml檔案的**context reloadable** 值置為**false** 或者在web modules中編輯取消Auto reloading選項。

OR  2.修改eclipse中的server配置

這樣做可以在在修改程式碼之後，不會自動重啟伺服器，而只加載程式碼，新增一行java程式碼ctrl+s後直接重新整理頁面或呼叫介面即可看到效果，無需重啟tomcat。

3.遠端debug中使用tomcat熱載入

tomcat的熱載入機制不僅可以在本地debug時，tomcat的遠端除錯也支援熱部署，通過eclipse debug遠端到遠端tomcat上，修改原生代碼，ctrl+s後直接重新整理頁面後呼叫介面，即可發現遠端tomcat已將原生代碼進行了熱載入。

4.jrebel外掛方式

jrebel外掛可以進行更徹底的熱載入，不僅包括類，甚至支援spring 等配置檔案的熱載入，但公司專案開發環境複雜，目前在eclipse中配置一直沒有成功，只能使用tomcat自帶的熱載入機制。

總結

在實際生產中熱部署在雲端計算中運用挺多，但熱載入沒有，而在開發中，熱載入可以顯著的提升工作效率，強烈推薦使用熱載入方式，不僅tomcat，大多數其他servlet容器也支援這種方式，大家可以自行搜尋相關技巧。