您現(xiàn)在的位置： > 技術(shù)沙龍 > 程序設計 > Java > 未分類 > 避免重啟你的應用程序 一
- 相關(guān)軟件
>避免重啟你的應用程序 一 創(chuàng)建者：webmaster 更新時間：2005-05-16 21:55
轉(zhuǎn)自:javaresearch.org
在開發(fā)測試階段，某個功能模塊出錯或者功能需求改變，這時候程序員通常會修改源代碼，然后重新編譯，停止應用程序，重起應用程序。然后檢測修改得功能是否正確，是否滿足需求。很好，這一切在開發(fā)測試階段都沒有問題，無可厚非。不過到了應用正式上線就出現(xiàn)麻煩了。重啟應用會導致系統(tǒng)不可用，或者導致用戶請求、響應丟失。甚至有的系統(tǒng)本生就要求為系統(tǒng)動態(tài)添加功能，在沒有為你的應用添加防止重啟動的策略前，通常能做的是到凌晨2點趁用戶少的時候重啟你的應用或者是暫時切換到備份系統(tǒng)。
如果你的系統(tǒng)也遇到過或者將不可避免的遇到這樣的問題，那在這篇文章里，幾個解決辦法可以供你選擇使用。
一：在啟動前，保存未被處理的請求和未發(fā)給用戶的響應。較好的方式是將接收請求，發(fā)送響應的模塊與你處理應用邏輯的模塊分開設計。如現(xiàn)在的web服務器，可以在你重新部署(redploy)的時候暫把用戶的請求保存到隊列，等到部署成功后在提交給處理邏輯的模塊。又如，接收請求，發(fā)送響應的模塊是不同的應用。與應用邏輯模塊之間通過文件（把請求序列化成一個文件）等方式交換數(shù)據(jù)，這樣在你的邏輯應用重啟后，仍然可以繼續(xù)讀取請求
二：如果更新的功能是純數(shù)據(jù)的，那么，采用動態(tài)配置，避免重啟動。比如，一個web系統(tǒng)，提供reloadConfig界面，重新從配置文件里讀取數(shù)據(jù)。一個java應用程序，你可以在你的應用程序里啟動一個檢測線程，檢測文件是否被改變，如果改變，則自動重新轉(zhuǎn)載配置。如下例子：
public ConfigChecker extends Thread
{
SystemManager sm = null;
long time ;
public ConfigChecker(SystemManager sm) throws ApplicationException
{
this.sm = sm;
time = getConfigFileTime();
}
pulblic void run()
{
while(!interrupted())
{
try
{
long newTime = getConfigFileTime();
if(newTime!=time)
{
time = newTime;
//重新裝載配置
sm.reloadConfig();
}
Thread.sleep(1000*3)
}
catch(Exception ex)
{
return ;
}
}
}
public long getConfigFileTime() throws ApplicationException
{
try
{
File f = new File(sm.getConfigFile());
return f.lastModified()
}
catch(IOException ex)
{
throw new ApplicationException(ex.getMessage())
}
}
}
這種方式適合你要動態(tài)改變的是純數(shù)據(jù)，它要求你應用中的數(shù)據(jù)不能寫死在代碼里，而是通過文件配置。通過重新從配置文件里讀取數(shù)據(jù)避免重啟動
三：如果更新的功能包括應用邏輯，也就是class改變了，那就稍微麻煩點，你需要了解ClassLoader的原理。使用你定制的ClassLoader重新Load 已經(jīng)編譯好的class,就好比你重啟應用一樣。下面將簡單介紹ClassLoader原理，以及舉出一個例子來說明如何避免重啟應用程序
在開發(fā)測試階段，某個功能模塊出錯或者功能需求改變，這時候程序員通常會修改源代碼，然后重新編譯，停止應用程序，重起應用程序。然后檢測修改得功能是否正確，是否滿足需求。很好，這一切在開發(fā)測試階段都沒有問題，無可厚非。不過到了應用正式上線就出現(xiàn)麻煩了。重啟應用會導致系統(tǒng)不可用，或者導致用戶請求、響應丟失。甚至有的系統(tǒng)本生就要求為系統(tǒng)動態(tài)添加功能，在沒有為你的應用添加防止重啟動的策略前，通常能做的是到凌晨2點趁用戶少的時候重啟你的應用或者是暫時切換到備份系統(tǒng)。
如果你的系統(tǒng)也遇到過或者將不可避免的遇到這樣的問題，那在這篇文章里，幾個解決辦法可以供你選擇使用。
一：在啟動前，保存未被處理的請求和未發(fā)給用戶的響應。較好的方式是將接收請求，發(fā)送響應的模塊與你處理應用邏輯的模塊分開設計。如現(xiàn)在的web服務器，可以在你重新部署(redploy)的時候暫把用戶的請求保存到隊列，等到部署成功后在提交給處理邏輯的模塊。又如，接收請求，發(fā)送響應的模塊是不同的應用。與應用邏輯模塊之間通過文件（把請求序列化成一個文件）等方式交換數(shù)據(jù)，這樣在你的邏輯應用重啟后，仍然可以繼續(xù)讀取請求
二：如果更新的功能是純數(shù)據(jù)的，那么，采用動態(tài)配置，避免重啟動。比如，一個web系統(tǒng)，提供reloadConfig界面，重新從配置文件里讀取數(shù)據(jù)。一個java應用程序，你可以在你的應用程序里啟動一個檢測線程，檢測文件是否被改變，如果改變，則自動重新轉(zhuǎn)載配置。如下例子：
public ConfigChecker extends Thread
{
SystemManager sm = null;
long time ;
public ConfigChecker(SystemManager sm) throws ApplicationException
{
this.sm = sm;
time = getConfigFileTime();
}
pulblic void run()
{
while(!interrupted())
{
try
{
long newTime = getConfigFileTime();
if(newTime!=time)
{
time = newTime;
//重新裝載配置
sm.reloadConfig();
}
Thread.sleep(1000*3)
}
catch(Exception ex)
{
return ;
}
}
}
public long getConfigFileTime() throws ApplicationException
{
try
{
File f = new File(sm.getConfigFile());
return f.lastModified()
}
catch(IOException ex)
{
throw new ApplicationException(ex.getMessage())
}
}
}
這種方式適合你要動態(tài)改變的是純數(shù)據(jù)，它要求你應用中的數(shù)據(jù)不能寫死在代碼里，而是通過文件配置。通過重新從配置文件里讀取數(shù)據(jù)避免重啟動
三：如果更新的功能包括應用邏輯，也就是class改變了，那就稍微麻煩點，你需要了解ClassLoader的原理。使用你定制的ClassLoader重新Load 已經(jīng)編譯好的class,就好比你重啟應用一樣。下面將簡單介紹ClassLoader原理，以及舉出一個例子來說明如何避免重啟應用程序相關(guān)文章- 前一則: Java源碼分析：深入探討Iterator模式
- 后一則: Struts控制器組件