在有些方法里， 比如登陸，一般需要順序調(diào)用多個系統(tǒng)功能才能完成初始化操作.
比如 安全校驗-》獲取用戶權(quán)限-》獲取用戶設(shè)置信息-》獲取系統(tǒng)字典 等等， 在某些EAI模式的應(yīng)用里，這些調(diào)用可能都是遠程調(diào)用，每個調(diào)用時間可能從0.5秒到數(shù)秒不等， 這樣累計下來用戶一個登陸操作，在后臺處理時間可能就有3，4秒，加上網(wǎng)絡(luò)傳輸延時，會主觀上給用戶造成系統(tǒng)很慢的感覺。
在單個方法調(diào)用效率無法改進的前提下，一個簡單的辦法是將調(diào)用方式由串行改為并行，即以多個thread分別去完成方法調(diào)用，最后匯總。
在java 5以前，因為線程的特性限制，必須手工編碼實現(xiàn)線程完成狀態(tài)的調(diào)用檢查。
比如
// thread
public void run() {
......
finished = true;
}
public boolean isFinished() {
return finished;
}
// 以阻塞循環(huán)的方式檢查是否執(zhí)行完畢
while(!remoteCall.isFinished()) {
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
這樣的代碼是繁瑣，較低效率，也容易出錯的，尤其在線程多于2個的時候。而在服務(wù)器方代碼中過多的線程使用又可能會導(dǎo)致內(nèi)存溢出和資源泄露。
今天翻書的時候發(fā)現(xiàn)java 5中的cucurrent包對此進行了改進 繼承自Callable 的類有能力將執(zhí)行結(jié)果返回，并且可以自行檢查執(zhí)行是否結(jié)束。
public class RandomPrimeSearch implements Callable<BigInteger> {
public BigInteger call( ) {
// do operation here
return BigInteger.probablePrime(bitSize, prng);
}
}
FutureTask<BigInteger> task = new FutureTask<BigInteger>(new RandomPrimeSearch(512)); //需要利用泛型模板返回處理結(jié)果
new Thread(task).start( );
BigInteger result = task.get( ); //此處會自動判斷是否執(zhí)行結(jié)束，未結(jié)束會繼續(xù)等待。也可以設(shè)定最大等待時間
//為了提高效率 也可以使用service方式調(diào)用
ExecutorService service = Executors.newFixedThreadPool(5);
Future<BigInteger> prime1 = service.submit(new RandomPrimeSearch(512));
這樣一來，使用這種并發(fā)模式處理代碼就容易多了。程序可以簡單的修改為這樣的結(jié)構(gòu)
remoateCall1 = doRemoteCall1(); // 啟動線程1 將方法處理以封裝到線程中
remoateCall2 = doRemoteCall2(); // 啟動線程2
remoteCall1.get().getUserSetting() ;
remoteCall2.get().getDictionaryList();
....
呵呵，基本和順序執(zhí)行時差不多，代碼修改量比較小。
java 5中引入了線程執(zhí)行服務(wù)ExecutorService 的概念以后， 如果以線程池的方式執(zhí)行線程調(diào)用，資源消耗會大幅度減少，所以不用太擔心并發(fā)處理會產(chǎn)生過多的系統(tǒng)負荷。