Posted on 2005-12-12 09:05
笨笨 閱讀(1834)
評(píng)論(2) 編輯 收藏 所屬分類:
Java
減少全局競(jìng)爭(zhēng)性同步，提高應(yīng)用的垂直擴(kuò)展能力
垂直擴(kuò)展，簡(jiǎn)單的說(shuō)，是當(dāng)單一系統(tǒng)硬件升級(jí)擴(kuò)展時(shí)，如增加CPU，內(nèi)存，應(yīng)用程序能夠隨之線性提高業(yè)務(wù)處理能力。
多線程是服務(wù)端 Java 應(yīng)用的標(biāo)準(zhǔn)處理方式，其優(yōu)點(diǎn)不用贅述。本文要討論的是，如何在設(shè)計(jì)階段降低多線程之間的競(jìng)爭(zhēng)性同步開(kāi)銷。
假設(shè)一個(gè)Web應(yīng)用，需要為當(dāng)前用戶維護(hù)在線用戶信息。此用戶信息列表會(huì)放在 Application 范圍的一個(gè) Map 中，那么我們?cè)黾踊騽h除一個(gè)在線用戶的操作會(huì)是這樣：。
Map clientMap = ...// from Application Context
synchronized(clientMap){
clientMap.put(clientId,clientObject);
}
這是一個(gè)典型的全局同步代碼，當(dāng)并發(fā)線程增加時(shí)，這部分代碼就有可能會(huì)存在潛在垂直擴(kuò)展瓶頸。
最簡(jiǎn)單解決辦法：用 ConcurrentHashMap。
ConcurrentHashMap的多線程下的表現(xiàn)要比HashMap好的多，可以做到隨著線程數(shù)增長(zhǎng)性能基本保持穩(wěn)定。
參見(jiàn)：http://www-128.ibm.com/developerworks/cn/java/j-jtp07233/index.html
對(duì) ConcurrentHashMap 的分析，參見(jiàn)：http://www-128.ibm.com/developerworks/cn/java/j-jtp08223/index.html
在 ConcurrentMap/ConcurrentLinkedQueue 不能幫助我們的情況下，我們需要明確設(shè)計(jì)以避免全局競(jìng)爭(zhēng)。
基本原則是：
1 預(yù)分配，降低爭(zhēng)用出現(xiàn)的頻率。
2 降低鎖的粒度，將全局競(jìng)爭(zhēng)變?yōu)榫植扛?jìng)爭(zhēng)。
預(yù)分配策略示例：
對(duì)于一在線交易處理系統(tǒng)，需要為每個(gè)交易生成交易流水號(hào)，假設(shè)有多臺(tái)交易服務(wù)器按照集群方式配置，同時(shí)提供服務(wù)。那么需要在交易服務(wù)器之間進(jìn)行同步，以保證交易流水號(hào)的正常增長(zhǎng)。
一種處理方式為：在數(shù)據(jù)庫(kù)中保存當(dāng)前交易流水號(hào)的最高值，每臺(tái)機(jī)器一次預(yù)分配1000流水，內(nèi)部采用線程同步進(jìn)行分配，用完再?gòu)臄?shù)據(jù)庫(kù)分配。這里數(shù)據(jù)庫(kù)充當(dāng)了全局存儲(chǔ)和全局同步工具，如果每來(lái)一條交易，就訪問(wèn)一次數(shù)據(jù)庫(kù)，考慮到數(shù)據(jù)庫(kù)同步和事務(wù)的負(fù)擔(dān)，這里會(huì)成為嚴(yán)重的性能瓶頸。
降低鎖粒度策略示例：
1 ConcurrentHashMap 本身就是個(gè)很好的模范。它采用32顆鎖，來(lái)代替普通 HashMap 的單顆對(duì)象鎖。
2 對(duì)于數(shù)據(jù)庫(kù)中并發(fā)大的表，可以考慮將表級(jí)鎖改為行級(jí)鎖，提高并發(fā)性。
暫時(shí)想不起來(lái)示例，有空再補(bǔ)