原文地址： http://www.theserverside.com/tt/articles/article.tss?l=ScalingYourJavaEEApplications
?
對(duì)于一個(gè)具備使用價(jià)值的應(yīng)用而言，其使用者有可能會(huì)在一段時(shí)間內(nèi)瘋狂的增長。隨著越來越多的關(guān)鍵性質(zhì)的應(yīng)用在Java EE上運(yùn)行，很多的Java開發(fā)者也開始關(guān)注可擴(kuò)展性的問題了。但目前來說，大部分的web 2.0站點(diǎn)是基于script語言編寫的，對(duì)于Java應(yīng)用可擴(kuò)展能力，很多人都抱著質(zhì)疑的態(tài)度。在這篇文章中，Wang Yu基于他本身在實(shí)驗(yàn)室項(xiàng)目的經(jīng)驗(yàn)來展示如何構(gòu)建可擴(kuò)展的java應(yīng)用，同時(shí)，基于一些在可擴(kuò)展性上做的比較失敗的項(xiàng)目給讀者帶來構(gòu)建可擴(kuò)展java應(yīng)用的實(shí)踐、理論、算法、框架和經(jīng)驗(yàn)。
我一直為一家互聯(lián)網(wǎng)性質(zhì)的實(shí)驗(yàn)室工作，這個(gè)實(shí)驗(yàn)室采用我們公司最新的大型服務(wù)器環(huán)境為合作伙伴的產(chǎn)品和解決方案免費(fèi)做性能測試，我工作的部分就是幫助他們?cè)趶?qiáng)大的CMT和SMP服務(wù)器上進(jìn)行性能調(diào)優(yōu)。
這些年來，我已經(jīng)為不同的解決方案測試了數(shù)十種java應(yīng)用。許多的產(chǎn)品都是為了解決同樣的領(lǐng)域問題，因此這些產(chǎn)品的功能基本都是類似的，但在可擴(kuò)展性上表現(xiàn)的卻非常不同，其中有些不能擴(kuò)展到64 CPU的服務(wù)器上運(yùn)行，但可以擴(kuò)展到20臺(tái)服務(wù)器做集群運(yùn)行，有些則只能運(yùn)行在不超過2 CPU的機(jī)器上。
造成這些差別的原因在于設(shè)計(jì)產(chǎn)品時(shí)的架構(gòu)愿景，所有的具備良好擴(kuò)展性的java應(yīng)用從需求需求階段、系統(tǒng)設(shè)計(jì)階段以及實(shí)現(xiàn)階段都為可擴(kuò)展性做了考慮，所以，你所編寫的java應(yīng)用的可擴(kuò)展能力完全取決于你的愿景。
可擴(kuò)展性作為系統(tǒng)的屬性之一，是個(gè)很難定義的名詞，經(jīng)常會(huì)與性能混淆。當(dāng)然，可擴(kuò)展性和性能是有關(guān)系的，它的目的是為了達(dá)到高性能。但是衡量可擴(kuò)展性和性能的方法是不一樣的，在這篇文章中，我們采用wikipedia中的定義：
可擴(kuò)展性是系統(tǒng)、網(wǎng)絡(luò)或進(jìn)程的可選屬性之一，它表達(dá)的含義是可以以一種優(yōu)雅的方式來處理不斷增長的工作，或者以一種很明白的方式進(jìn)行擴(kuò)充。例如：它可以用來表示系統(tǒng)具備隨著資源(典型的有硬件)的增加提升吞吐量的能力。
垂直擴(kuò)展的意思是給系統(tǒng)中的單節(jié)點(diǎn)增加資源，典型的是給機(jī)器增加CPU或內(nèi)存，垂直擴(kuò)展為操作系統(tǒng)和應(yīng)用模塊提供了更多可共用的資源，因此它使得虛擬化的技術(shù)（應(yīng)該是指在一臺(tái)機(jī)器上運(yùn)行多個(gè)虛擬機(jī)）能夠運(yùn)行的更加有效。
水平擴(kuò)展的意思是指給系統(tǒng)增加更多的節(jié)點(diǎn)，例如為一個(gè)分布式的軟件系統(tǒng)增加新的機(jī)器，一個(gè)更清晰的例子是將一臺(tái)web服務(wù)器增加為三臺(tái)。隨著計(jì)算機(jī)價(jià)格的不斷降低以及性能的不斷提升，以往需要依靠超級(jí)計(jì)算機(jī)來進(jìn)行的高性能計(jì)算的應(yīng)用（例如：地震分析、生物計(jì)算等）現(xiàn)在可以采用這種多個(gè)低成本的應(yīng)用來完成。由上百臺(tái)普通機(jī)器構(gòu)成的集群可以達(dá)到傳統(tǒng)的基于RISC處理器的科學(xué)計(jì)算機(jī)所具備的計(jì)算能力。
這篇文章的第一部分來討論下垂直擴(kuò)展Java應(yīng)用。
如何讓Java EE應(yīng)用垂直擴(kuò)展
很多的軟件設(shè)計(jì)人員和開發(fā)人員都認(rèn)為功能是產(chǎn)品中最重要的因素，而性能和可擴(kuò)展性是附加的特性和功能完成后才做的工作。他們中大部分人認(rèn)為可以借助昂貴的硬件來縮小性能問題。
但有時(shí)候他們是錯(cuò)的，上個(gè)月，我們實(shí)驗(yàn)室中有一個(gè)緊急的項(xiàng)目，合作伙伴提供的產(chǎn)品在他們客戶提供的CPU的機(jī)器上測試未達(dá)到性能的要求，因此合作伙伴希望在更多CPU（8 CPU）的機(jī)器上測試他們的產(chǎn)品，但結(jié)果卻是在8 CPU的機(jī)器上性能反而比4 CPU的機(jī)器更差。
為什么會(huì)這樣呢？首先，如果你的系統(tǒng)是多進(jìn)程或多線程的，并且已經(jīng)用盡了CPU的資源，那么在這種情況下增加CPU通常能讓應(yīng)用很好的得到擴(kuò)展。
基于java技術(shù)的應(yīng)用可以很簡單的使用線程，Java語言不僅可以用來支持編寫多線程的應(yīng)用，同時(shí)JVM本身在對(duì)java應(yīng)用的執(zhí)行管理和內(nèi)存管理上采用的也是多線程的方式，因此通常來說Java應(yīng)用在多CPU的機(jī)器上可以運(yùn)行的更好，例如Bea weblogic、IBM Websphere、開源的Glassfish和Tomcat等應(yīng)用服務(wù)器，運(yùn)行在Java EE應(yīng)用服務(wù)器中的應(yīng)用可以立刻從CMT和SMP技術(shù)中獲取到好處。
但在我的實(shí)驗(yàn)室中，我發(fā)現(xiàn)很多的產(chǎn)品并不能充分的使用CPU，有些應(yīng)用在8 CPU的服務(wù)器上只能使用到不到20%的CPU，像這類應(yīng)用即使增加CPU也提升不了多少的。
熱鎖(Hot Lock)是可擴(kuò)展性的關(guān)鍵障礙
在Java程序中，用來協(xié)調(diào)線程的最重要的工具就是 synchronized這個(gè)關(guān)鍵字了。由于java所采用的規(guī)則，包括緩存刷新和失效，Java語言中的synchronized塊通常都會(huì)其他平臺(tái)提供的類似的機(jī)制更加的昂貴。即使程序只是一個(gè)運(yùn)行在單處理器上的單線程程序，一個(gè)synchronized的方法調(diào)用也會(huì)比非同步的方法調(diào)用慢。
要檢查問題是否為采用synchronized關(guān)鍵字造成的，只需要像JVM進(jìn)程發(fā)送一個(gè)QUIT指令（譯者注：在linux上也可以用kill -3 PID的方式）來獲取線程堆棧信息。如果你看到類似下面線程堆棧的信息，那么就意味著你的系統(tǒng)出現(xiàn)了熱鎖的問題：
..
" Thread-0 " ?prio = 10 ?tid = 0x08222eb0 ?nid = 0x9 ?waiting? for ?monitor?entry?[ 0xf927b000 .. 0xf927bdb8 ]
at?testthread.WaitThread.run(WaitThread.java: 39 )
- ?waiting?to?lock? < 0xef63bf08 > ?(a?java.lang.Object)
- ?locked? < 0xef63beb8 > ?(a?java.util.ArrayList)
at?java.lang.Thread.run(Thread.java: 595 )
synchronized 關(guān)鍵字強(qiáng)制執(zhí)行器串行的執(zhí)行synchronized中的動(dòng)作。如果很多線程競爭同樣的同步對(duì)象，那么只有一個(gè)線程能夠執(zhí)行同步塊，而其他的線程就只能進(jìn)入blocked狀態(tài)了，如果此時(shí)沒有其他需要執(zhí)行的線程，那么處理器就進(jìn)入空閑狀態(tài)了，在這種情況下，增加CPU也帶來不了多少性能提升。
熱鎖可能會(huì)導(dǎo)致更多線程的切換和系統(tǒng)的調(diào)用。當(dāng)多個(gè)線程競爭同一個(gè)monitor時(shí)，JVM必須維護(hù)一個(gè)競爭此monitor的線程隊(duì)列（同樣，這個(gè)隊(duì)列也必須同步），這也就意味著更多的時(shí)間需要花費(fèi)在JVM或OS的代碼執(zhí)行上，而更少的時(shí)間是用在你的程序上的。
要避免熱鎖現(xiàn)象，以下的建議能帶來一些幫助：
盡可能的縮短同步塊
當(dāng)你將線程中持有鎖的時(shí)間盡量縮短后，其他線程競爭鎖的時(shí)間也就變得更短。因此當(dāng)你需要采用同步塊來操作共享的變量時(shí)，應(yīng)該將線程安全的代碼放在同步塊的外面，來看以下代碼的例子：
Code list 1:
synchronized ?(schema)?{
????String?nodeName? = ?(String)nodeTree.get( " nodeName " );
????String?nodeAttributes? = ?(List)nodeTree.get( " attributes " );
???? if ?(nodeName? == ? null )?
???????? return ? false ;
???? else
???????? return ?schema.update(nodeName,nodeAttributes);
}
}
上面的代碼片段是為了當(dāng)更新"schema"變量時(shí)保護(hù)這個(gè)共享的變量。但獲取attribute值部分的代碼是線程安全的。因此我們可以將這部分移至同步塊的外面，讓同步塊變得更短一些：
Code list 2:
????String?nodeName? = ?(String)nodeTree.get( " nodeName " );
????String?nodeAttributes? = ?(List)nodeTree.get( " attributes " );
???? synchronized ?(schema)?{
???????? if ?(nodeName? == ? null )
???????????? return ? false ;
???????? else
???????????? return ?schema.update(nodeName,nodeAttributes);
????}
}
減小鎖的粒度
當(dāng)你使用"synchronized"時(shí)，有兩種粒度可選擇："方法鎖"或"塊鎖"。如果你將"synchronized"放在方法上，那么也就意味著鎖定了"this"對(duì)象。
Code list 3:
????? private ?HashMap?schema;
????? private ?HashMap?treeNodes;
?????
.
????? public ? boolean ? synchronized ?updateSchema(HashMap?nodeTree)?{
?????????String?nodeName? = ?(String)nodeTree.get( " nodeName " );
?????????String?nodeAttributes? = ?(List)nodeTree.get( " attributes " );
????????? if ?(nodeName? == ? null )? return ? false ;
????????? else ? return ?schema.update(nodeName,nodeAttributes);
?????}
????? public ? boolean ? synchronized ?updateTreeNodes()?{
?????????
?????}
}
對(duì)比Code list 2中的代碼，這段代碼就顯得更糟糕些了，因?yàn)楫?dāng)調(diào)用"updateSchema"方法時(shí)，它鎖定了整個(gè)
對(duì)象，為了獲得更好的粒度控制，應(yīng)該僅僅鎖定"schema"變量來替代鎖定整個(gè)對(duì)象，這樣其他不同的方法就可
以保持并行執(zhí)行了。
避免在static方法上加鎖
最糟糕的狀況是在static方法上加"synchronized"，這樣會(huì)造成鎖定這個(gè)class的所有實(shí)例對(duì)象。
at?sun.awt.font.NativeFontWrapper.initializeFont(Native?Method)
- ?waiting?to?lock? < 0xeae43af0 > ?(a?java.lang.Class)
at?java.awt.Font.initializeFont(Font.java: 316 )
at?java.awt.Font.readObject(Font.java: 1185 )
at?sun.reflect.GeneratedMethodAccessor147.invoke(Unknown?Source)
at?sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25 )
at?java.lang.reflect.Method.invoke(Method.java: 324 )
at?java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java: 838 )
at?java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1736 )
at?java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1646 )
at?java.io.ObjectInputStream.readObject0(ObjectInputStream.java: 1274 )
at?java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java: 1835 )
at?java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1759 )
at?java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1646 )
at?java.io.ObjectInputStream.readObject0(ObjectInputStream.java: 1274 )
at?java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java: 1835 )
at?java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java: 452 )
at?com.fr.report.CellElement.readObject(Unknown?Source)
?
當(dāng)使用Java 2D來為報(bào)表生成字體對(duì)象時(shí)，開發(fā)人員放了一個(gè)native的static鎖在"initialize"方法上，不過這是sun JDK 1.4中才會(huì)出現(xiàn)的，在JDK 5.0中，這個(gè)static lock就消失了。
在Java SE 5.0中使用lock free的數(shù)據(jù)結(jié)構(gòu)
在Java中，"synchronized"關(guān)鍵字是一個(gè)較簡單、并且相對(duì)來說比較好用的協(xié)作機(jī)制，不過同時(shí)對(duì)于管理一個(gè)簡單的操作（例如增加統(tǒng)計(jì)值或更新一個(gè)值）來說就顯得比較重量級(jí)了，就像以下的代碼：
Code list 4:
???? private ? int ?totalNumber;
???? public ? synchronized ? int ?getTotalNumber()?{? return ?totalNumber;?}
???? public ? synchronized ? int ?increment()?{? return ? ++ totalNumber;?}
???? public ? synchronized ? int ?decrement()?{? return ? -- totalNumber;?}
}
?
以上的代碼只是用來鎖定非常簡單的操作，"synchronized"塊也是非常的短。但是鎖是非常重量級(jí)（當(dāng)鎖被其他線程持有時(shí)，線程會(huì)去頻繁嘗試獲取鎖）的，吞吐量會(huì)下降，并且同步鎖的競爭也是很昂貴的。
幸運(yùn)的是，在Java SE 5.0或以上版本，你可以在不使用native代碼的情況下使用硬件級(jí)同步語義的wait-free、lock-free的算法。幾乎所有現(xiàn)代的處理器都具有檢測和防止其他處理器并發(fā)修改變量的基礎(chǔ)設(shè)施。這些基礎(chǔ)設(shè)施稱為比較并交換，或CAS。
一個(gè)CAS操作包含三個(gè)參數(shù) -- 一個(gè)內(nèi)存地址，期待的舊的值以及新的值。 如果內(nèi)存地址上的值和所期待的舊的值是同一個(gè)的話，處理器將此地址的值更新為新的值；否則它就什么都不做，同時(shí)它會(huì)返回CAS操作前內(nèi)存地址上的值。一個(gè)使用CAS來實(shí)現(xiàn)同步的例子如下：
Code list 5:
???? int ?oldValue? = ?value.getValue();
???? int ?newValue? = ?oldValue? + ? 1 ;
???? while ?(value.compareAndSwap(oldValue,?newValue)? != ?oldValue)
???????oldValue? = ?value.getValue();
???? return ?oldValue? + ? 1 ;
}
?
首先，我們從地址上讀取一個(gè)值，然后執(zhí)行幾步操作來產(chǎn)生新的值（例子中只是做加1的操作），最后使用CAS方式來將地址中的舊值改變?yōu)樾轮怠Ｈ绻跁r(shí)間片段內(nèi)地址上的值未改變，那么CAS操作將成功。如果另外的線程同時(shí)修改了地址上的值，那么CAS操作將失敗，但會(huì)檢測到這個(gè)操作失敗，并在while循環(huán)中進(jìn)行重試。CAS最好的原因在于它是硬件級(jí)別的實(shí)現(xiàn)并且非常輕量級(jí)，如果100個(gè)線程同時(shí)執(zhí)行這個(gè)increment()方法，最糟糕的情況是在 increment方法執(zhí)行完畢前每個(gè)線程最多嘗試99次。
在Java SE 5.0和以上版本的java.util.concurrent.atomic包中提供了在單個(gè)變量上lock-free和線程安全操作支持的類。這些原子變量的類都提供了比較和交換的原語，它基于各種平臺(tái)上可用的最后的native的方式實(shí)現(xiàn)，這個(gè)包內(nèi)提供了九種原子變量，包括：AtomicInteger；AtomicLong；AtomicReference；AtomicBoolean；array forms of atomic integer、long、reference；和atomic marked reference和stamped reference類。
使用atomic包非常容易，重寫上面code list 5的代碼片段：
Code list 6:
.
private ?AtomicInteger?value? = ? new ?AtomicInteger( 0 );
public ? int ?increment()?{
???? return ?value.getAndIncrement();
}
.
幾乎java.util.concurrent包中所有的類都直接或間接的采用了原子變量來替代synchronized。像
ConcurrentLinkedQueue采用了原子變量來直接實(shí)現(xiàn)wait-free算法，而像ConcurrentHashMap則采用
ReentrantLock來實(shí)現(xiàn)必要的鎖，而ReentrantLock則是采用原子變量來維護(hù)所有等待鎖的線程隊(duì)列。
在我們實(shí)驗(yàn)室中一個(gè)最成功的關(guān)于lock free算法的案例發(fā)生在一個(gè)金融系統(tǒng)中，當(dāng)將"Vector"數(shù)據(jù)結(jié)構(gòu)替換為"ConcurrentHashMap"后，在我們的CMT機(jī)器（8核）性能提升了超過3倍。
競爭條件也會(huì)導(dǎo)致可擴(kuò)展性出現(xiàn)問題
太多的"synchronized"關(guān)鍵字會(huì)導(dǎo)致可擴(kuò)展性出現(xiàn)問題。但在某些場合，缺少"synchronized"也會(huì)導(dǎo)致系統(tǒng)無法垂直擴(kuò)展。缺少"synchronized"會(huì)產(chǎn)生競爭場景，在這種場景下允許兩個(gè)線程同時(shí)修改共享的資源，這有可能會(huì)造成破壞共享數(shù)據(jù)，為什么我說它會(huì)導(dǎo)致可擴(kuò)展性出現(xiàn)問題呢？
來看一個(gè)實(shí)際的例子。這是一個(gè)制作業(yè)的ERP系統(tǒng)，當(dāng)在我們最新的一臺(tái)CMT服務(wù)器（2CPU、16核、128芯）上進(jìn)行性能測試時(shí)，我們發(fā)現(xiàn)CPU的使用率超過90%，這非常讓人驚訝，因?yàn)楹苌儆袘?yīng)用能夠在這款機(jī)器上擴(kuò)展的這么好。但我們僅僅興奮了5分鐘，之后我們發(fā)現(xiàn)平均響應(yīng)時(shí)間非常的慢，同時(shí)吞吐量也降到不可思議的低。那么這些CPU都在干嘛呢？它們不是在忙嗎，那么它們到底在忙些什么呢？通過OS的跟蹤工具，我們發(fā)現(xiàn)幾乎所有的CPU都在干同一件事-- "HashMap.get()"，看起來所有的CPU都進(jìn)入了死循環(huán)，之后我們?cè)诓煌瑪?shù)量的CPU的服務(wù)器上再測試了這個(gè)應(yīng)用，結(jié)果表明，服務(wù)器擁有越多CPU，那么產(chǎn)生死循環(huán)的概率就會(huì)越高。
產(chǎn)生這個(gè)死循環(huán)的根源在于對(duì)一個(gè)未保護(hù)的共享變量 -- 一個(gè)"HashMap"數(shù)據(jù)結(jié)構(gòu)的操作。當(dāng)在所有操作的方法上加了"synchronized"后，一切恢復(fù)了正常。檢查"HashMap"(Java SE 5.0)的源碼，我們發(fā)現(xiàn)有潛在的破壞其內(nèi)部結(jié)構(gòu)最終造成死循環(huán)的可能。在下面的代碼中，如果我們使得HashMap中的entries進(jìn)入循環(huán)，那么"e.next()"永遠(yuǎn)都不會(huì)為null。
Code list 7:
???? if ?(key? == ? null )? return ?getForNullKey();
???? int ?hash? = ?hash(key.hashCode());
???? for ?(Entry < K,V > ?e? = ?table[indexFor(hash,?table.length)];
?????????e? != ? null ;
?????????e? = ?e.next)?{
?????????Object?k;
????????? if ?(e.hash? == ?hash? && ?((k? = ?e.key)? == ?key? || ?key.equals(k)))
???????????? return ?e.value;
????}
???? return ? null ;
}
不僅get()方法會(huì)這樣，put()以及其他對(duì)外暴露的方法都會(huì)有這個(gè)風(fēng)險(xiǎn)，這算jvm的bug嗎？應(yīng)該說不是的，這個(gè)現(xiàn)象很早以前就報(bào)告出來了（詳細(xì)見：
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457
）。Sun的工程師并不認(rèn)為這是bug，而是建議在這樣的場景下應(yīng)采用"ConcurrentHashMap"，在構(gòu)建可擴(kuò)展的系統(tǒng)時(shí)應(yīng)將這點(diǎn)納入規(guī)范中。
非阻塞 IO vs. 阻塞IO
Java 1.4中引入的java.nio包，允許開發(fā)人員在進(jìn)行數(shù)據(jù)處理時(shí)獲取更好的性能并提供更好的擴(kuò)展性。NIO提供的非阻塞IO操作允許java應(yīng)用像其他底層語言（例如c）一樣操作IO。目前已經(jīng)有很多NIO的框架（例如Apache的Mina、Sun的Grizzly）了被廣泛的使用在很多的項(xiàng)目和產(chǎn)品中。
在最近的5個(gè)月內(nèi)，我們實(shí)驗(yàn)室有兩個(gè)Java EE項(xiàng)目測試對(duì)比了基于傳統(tǒng)的阻塞I/O構(gòu)建的服務(wù)器和非阻塞I/O構(gòu)建的服務(wù)器上的性能。他們選擇了Tomcat 5作為基于阻塞I/O的服務(wù)器，Glassfish作為基于非阻塞I/O的服務(wù)器。
首先，他們測試了一些簡單的JSP頁面和servlets，得到如下結(jié)果：（在一臺(tái)4 CPU的服務(wù)器上）
|
Concurrent Users
|
Average Response Time (ms)
|
|
|
Tomcat
|
Glassfish
|
|
|
5
|
30
|
138
|
|
15
|
35
|
142
|
|
30
|
37
|
142
|
|
50
|
41
|
151
|
|
100
|
65
|
155
|
從測試結(jié)果來看，Glassfish的性能遠(yuǎn)低于Tomcat。客戶對(duì)非阻塞I/O能夠帶來的提升表示懷疑，但為什么那么多的文章以及技術(shù)報(bào)告都告訴大家NIO具備更好的性能和可擴(kuò)展性呢？
當(dāng)在更多的場景進(jìn)行測試后，隨著NIO的能力逐步的展現(xiàn)出來，他們改變了觀點(diǎn)，他們做了以下的測試：
1、比簡單的JSP、servlet更為復(fù)雜的場景，包括EJB、數(shù)據(jù)庫、文件IO、JMS和事務(wù)；
2、模擬更多的并發(fā)用戶，從1000到10000；
3、在不同的硬件環(huán)境上進(jìn)行測試，從2 CPU、4 CPU到16 CPU。
以下的圖為在4 CPU服務(wù)器上的測試結(jié)果：
|
|
Figure 1: Throughput in a 4CPU server
傳統(tǒng)的阻塞I/O為每個(gè)請(qǐng)求分配一個(gè)工作線程，這個(gè)工作線程負(fù)責(zé)請(qǐng)求的整個(gè)過程的處理，包括從網(wǎng)絡(luò)讀取請(qǐng)求數(shù)據(jù)、解析參數(shù)、計(jì)算或調(diào)用其他的業(yè)務(wù)邏輯、編碼結(jié)果并將其返回給請(qǐng)求者，然后這個(gè)線程將返回到線程池中供其他線程復(fù)用。Tomcat 5采用的這種方式在應(yīng)對(duì)完美的網(wǎng)絡(luò)環(huán)境、簡單的邏輯以及小量的并發(fā)用戶時(shí)是非常高效的。
但如果請(qǐng)求包括了復(fù)雜的邏輯、或需要和外部的系統(tǒng)（例如文件系統(tǒng)、數(shù)據(jù)庫或消息服務(wù)器）進(jìn)行交互時(shí)，工作線程在其處理的大部分時(shí)間都會(huì)處于等待同步的調(diào)用或網(wǎng)絡(luò)傳輸返回的狀態(tài)中，這個(gè)阻塞的線程會(huì)被請(qǐng)求持有直到請(qǐng)求處理完畢，但操作系統(tǒng)需要暫停線程來保證CPU能夠處理其他的請(qǐng)求，如果客戶端和服務(wù)器端的網(wǎng)絡(luò)狀況不太好的話，網(wǎng)絡(luò)的延時(shí)會(huì)導(dǎo)致線程被阻塞更長時(shí)間，在更糟的狀況下，當(dāng)需要keep-alive的話，當(dāng)前的工作線程會(huì)在請(qǐng)求處理完畢后阻塞很長一段時(shí)間，在這樣的情況下，為了更好的使用CPU，就必須增加更多的工作線程了。
Tomcat采用了一個(gè)線程池，每個(gè)請(qǐng)求都會(huì)被線程池中一個(gè)空閑的線程進(jìn)行處理。"maxThreads"表示Tomcat 能創(chuàng)建的處理請(qǐng)求的最大線程數(shù)。如果我們把"maxThreads"設(shè)置的太小的話，就不能充分的使用CPU了，更為重要的是，隨著并發(fā)用戶的增長，會(huì)有很多請(qǐng)求被服務(wù)器拋棄和拒絕。在此次測試中，我們將"maxThreads"設(shè)置為了1000（這對(duì)于Tomcat來說有些太大了），在這樣的設(shè)置下，當(dāng)并發(fā)用戶增長到較高數(shù)量時(shí)，Tomcat會(huì)創(chuàng)建很多的線程。大量的Java線程會(huì)導(dǎo)致JVM和OS忙于執(zhí)行和維護(hù)這些線程，而不是執(zhí)行業(yè)務(wù)邏輯處理，同時(shí)，太多的線程也會(huì)消耗更多的JVM heap內(nèi)存（每個(gè)線程堆棧需要占用一些內(nèi)存），并且會(huì)導(dǎo)致更為頻繁的gc。
Glassfish不需要這么多的線程，在非阻塞IO中，一個(gè)工作線程并不會(huì)綁定到一個(gè)特定的請(qǐng)求上，如果請(qǐng)求被某些原因所阻塞，那么這個(gè)線程將被其他的請(qǐng)求復(fù)用。在這樣的方式下，Glassfish可以用幾十個(gè)工作線程來處理幾千的并發(fā)用戶。通過限制線程資源，非阻塞IO擁有了更好的可擴(kuò)展性，這也是Tomcat 6采用非阻塞IO的原因了。
|
|
Figure 2: scalability test result
單線程任務(wù)問題
幾個(gè)月前我們實(shí)驗(yàn)室測試了一個(gè)基于Java EE的ERP系統(tǒng)，它其中的一個(gè)測試場景是為了產(chǎn)生非常復(fù)雜的分析報(bào)告，我們?cè)诓煌姆?wù)器上測試了這個(gè)應(yīng)用場景，發(fā)現(xiàn)竟然是在最便宜的AMD PC服務(wù)器上擁有最好的性能。這臺(tái)AMD的服務(wù)器只有兩個(gè)2.8HZ的CPU以及4G的內(nèi)存，但它的性能竟然超過了昂貴的擁有8 CPU和32G內(nèi)存的SPARC服務(wù)器。
原因就在于這個(gè)場景是個(gè)單線程的任務(wù)，它同時(shí)只能被一個(gè)用戶運(yùn)行（并發(fā)的多用戶執(zhí)行在這個(gè)案例中毫無意義），因此當(dāng)運(yùn)行時(shí)它只使用了一個(gè)CPU，這樣的任務(wù)是沒法擴(kuò)展到多個(gè)處理器的，在大多數(shù)時(shí)候，這種場景下的性能僅取決于CPU的運(yùn)行速度。
并行是解決這個(gè)問題的方案。為了讓一個(gè)單線程的任務(wù)并行執(zhí)行，你需要按順序找出這個(gè)操作的過程中從某種程度上來講不依賴的操作，然后采用多線程從而實(shí)現(xiàn)并行。在上面的案例中，客戶重新定義了"分析報(bào)告產(chǎn)生"的任務(wù)，改為先生成月度報(bào)告，之后基于產(chǎn)生的這些12個(gè)月的月度報(bào)告來生成分析報(bào)告，由于最終用戶并不需要“月度報(bào)告”，因此這些“月度報(bào)告”只是臨時(shí)產(chǎn)生的結(jié)果，但"月度報(bào)告"是可以并行生成的，然后用于快速的產(chǎn)生最后的分析報(bào)告，在這樣的方式下，這個(gè)應(yīng)用場景可以很好的擴(kuò)展到4 CPU的SPARC服務(wù)器上運(yùn)行，并且在性能上比在AMD Server高80%多。
重新調(diào)整架構(gòu)和重寫代碼的解決方案是一個(gè)耗時(shí)并且容易出現(xiàn)錯(cuò)誤的工作。在我們實(shí)驗(yàn)室中的一個(gè)項(xiàng)目中采用了JOMP來為其單線程的任務(wù)獲得并行性。JOMP是一個(gè)基于線程的SMP并行編程的Java API。就像OpenMP，JOMP也是根據(jù)編譯指示來插入并行運(yùn)行的代碼片段到常規(guī)的程序中。在Java程序中，JOMP 通過//omp這樣的指示方式來表示需要并行運(yùn)行的部分。JOMP程序通過運(yùn)行一個(gè)預(yù)編譯器來處理這些//omp的指示并生成最終的java代碼，這些 java代碼再被正常的編譯和執(zhí)行。JOMP支持OpenMP的大部分特性，包括共享的并行循環(huán)和并行片段，共享變量，thread local變量以及reduction變量。以下的代碼為JOMP程序的示例：
Code list 8:
c?.?add?(? " ?t?h?i?s? " ?)?;
c?.?add?(? " ?i?s? " ?)?;
c?.?add?(? " ?a? " ?)?;
c?.?add?(? " demo " ?)?;
/ ? / ?#omp?p?a?r?a?l?l?e?l?i?t?e?r?a?t?o?r
f?o?r?(?S?t?r?i?n?g?s?:?c?)
????System?.?o?u?t?.?p?r?i?n?t?l?n?(? " ?s? " ?)?;
就像大部分的并行編譯器，JOMP也是關(guān)注于loop-level和集合的并行運(yùn)算，研究如何同時(shí)執(zhí)行不同的迭代。為了并行化，兩個(gè)迭代之間不能產(chǎn)生任何的數(shù)據(jù)依賴，這也就是說，不能依賴于其他任何一個(gè)執(zhí)行后產(chǎn)生的計(jì)算結(jié)果。要編寫一個(gè)JOMP程序并不是容易的事。首先，你必須熟練使用OpenMP的指示，同時(shí)還得熟悉JVM對(duì)于這些指示的內(nèi)存模型映射，最后你需要知道在你的業(yè)務(wù)邏輯代碼的正確的地方放置正確的指示。
另外一個(gè)選擇是采用Parallel Java。Parallel Java，就像JOMP一樣，也支持OpenMP的大部分特性；但又不同于JOMP，PJ的并行結(jié)構(gòu)部分是通過在代碼中調(diào)用PJ的類來實(shí)現(xiàn)，而不是通過插入預(yù)編譯的指示，因此，"Parallel Java"不需要另外的預(yù)編譯過程。Parallel Java不僅對(duì)于在多CPU上并行有效，對(duì)于多節(jié)點(diǎn)的擴(kuò)展能力上也同樣有效。以下的代碼是"Parallel Java"程序的示例：
Code list 9:
new ?ParallelTeam().execute?( new ?ParallelRegion()
????{
???? public ? void ?run()? throws ?Exception
????????{
???????? for ?( int ?ii? = ? 0 ;?ii? < ?n;? ++ ?ii)
????????????{
???????????? final ? int ?i? = ?ii;
????????????execute?( 0 ,?n - 1 ,? new ?IntegerForLoop()
????????????????{
???????????????????? public ? void ?run?( int ?first,? int ?last)
????????????????????????{
???????????????????????? for ?( int ?r? = ?first;?r? <= ?last;? ++ ?r)
???????????????????????????{
??????????????????????????? for ?( int ?c? = ? 0 ;?c? < ?n;? ++ ?c)
????????????????????????????????{
????????????????????????????????d[r][c]? = ?Math.min?(d[r][c],
????????????????????????????????d[r][i]? + ?d[i][c]);
????????????????????????????????}
????????????????????????????}
????????????????????????}
????????????????????});
????????????????}
????????????}
????????});
擴(kuò)展使用更多的內(nèi)存
內(nèi)存是應(yīng)用的重要資源。足夠的內(nèi)存對(duì)于任何應(yīng)用而言都是關(guān)鍵的，尤其是數(shù)據(jù)庫系統(tǒng)和其他I/O操作頻繁的系統(tǒng)。更多的內(nèi)存意味著更大的共享內(nèi)存空間以及更大的數(shù)據(jù)緩沖，這也就使得應(yīng)用能夠更多的從內(nèi)存中讀取數(shù)據(jù)而不是緩慢的磁盤中讀取。
Java gc將程序員從繁瑣的內(nèi)存分配和回收中解脫了出來，從而使得程序員能夠更加高效的編寫代碼。但gc不好的地方在于當(dāng)gc運(yùn)行時(shí)，幾乎所有工作的線程都會(huì)被掛起。另外，在gc環(huán)境下，程序員缺少調(diào)度CPU來回收那些不再使用的對(duì)象的控制能力。對(duì)于那些幾乎實(shí)時(shí)的系統(tǒng)而言，例如電信系統(tǒng)和股票交易系統(tǒng)，這種延遲和缺少控制的現(xiàn)象是很大的風(fēng)險(xiǎn)。
回到Java應(yīng)用在給予更多的內(nèi)存時(shí)是否可以擴(kuò)展的問題上，答案是有些時(shí)候是的。太小的內(nèi)存會(huì)導(dǎo)致gc頻繁的執(zhí)行，足夠的內(nèi)存則保證JVM花費(fèi)更多的時(shí)間來執(zhí)行業(yè)務(wù)邏輯，而不是進(jìn)行g(shù)c。
但它并不一定是這樣的，在我們實(shí)驗(yàn)室中出現(xiàn)的真實(shí)例子是一個(gè)構(gòu)建在64位JVM上的電信系統(tǒng)。使用64位JVM，應(yīng)用可以突破32位JVM中4GB內(nèi)存的限制，測試時(shí)使用的是一臺(tái)4 CPU/16G內(nèi)存的服務(wù)器，其中12GB的內(nèi)存分配給了java應(yīng)用使用，為了提高性能，他們?cè)诔跏蓟瘯r(shí)就緩存了超過3,000,000個(gè)的對(duì)象到內(nèi)存中，以免在運(yùn)行時(shí)創(chuàng)建如此多的對(duì)象。這個(gè)產(chǎn)品在第一個(gè)小時(shí)的測試中運(yùn)行的非常快，但突然，系統(tǒng)差不多停止運(yùn)行了30多分鐘，經(jīng)過檢測，發(fā)現(xiàn)是因?yàn)間c導(dǎo)致了系統(tǒng)停止了半個(gè)小時(shí)。
gc是從那些不再被引用的對(duì)象回收內(nèi)存的過程。不被引用的對(duì)象是指應(yīng)用中不再使用的對(duì)象，因?yàn)樗袑?duì)于這些對(duì)象的引用都已經(jīng)不在應(yīng)用的范圍中了。如果一堆巨大的活動(dòng)的對(duì)象存在在內(nèi)存中（就像3,000,000個(gè)緩存的對(duì)象），gc需要花費(fèi)很長的時(shí)間來檢查這些對(duì)象，這就是為什么系統(tǒng)停止了如此長乃至不可接受的時(shí)間。
在我們實(shí)驗(yàn)室中測試過的以內(nèi)存為中心的Java應(yīng)用中，我們發(fā)現(xiàn)具備有如下特征：
1、每個(gè)請(qǐng)求的處理過程需要大量和復(fù)雜的對(duì)象；
2、在每個(gè)會(huì)話的HttpSession對(duì)象中保存了太多的對(duì)象；
3、HttpSession的timeout時(shí)間設(shè)置的太長，并且HttpSession沒有顯示的invalidated；
4、線程池、EJB池或其他對(duì)象池設(shè)置的太大；
5、對(duì)象的緩存設(shè)置的太大。
這樣的應(yīng)用是不好做擴(kuò)展的，當(dāng)并發(fā)的用戶數(shù)增長時(shí)，這些應(yīng)用所使用的內(nèi)存也會(huì)大幅度的增長。如果大量的活動(dòng)對(duì)象無法被及時(shí)的回收，JVM將會(huì)在gc上消耗很長的時(shí)間，另外，如果給予了太大的內(nèi)存（在64位JVM上），在運(yùn)行了相對(duì)較長的時(shí)間后，jvm會(huì)花費(fèi)相當(dāng)長的一段時(shí)間在 gc上，因此結(jié)論是如果給jvm分配了太多的內(nèi)存的話，java應(yīng)用將不可擴(kuò)展。在大部分場合下，給jvm分配3G內(nèi)存(通過"-Xmx"屬性)是足夠 (在windows和linux中，32位的系統(tǒng)最多只能分配2G的內(nèi)存)的。如果你擁有更多的內(nèi)存，請(qǐng)將這些內(nèi)存分配給其他的應(yīng)用，或者就將它留給OS 使用，許多OS都會(huì)使用空閑的內(nèi)存來作為數(shù)據(jù)的緩沖和緩存來提升IO性能。實(shí)時(shí)JVM(JSR001)可以讓開發(fā)人員來控制內(nèi)存的回收，應(yīng)用基于此特性可以告訴JVM：“這個(gè)巨大的內(nèi)存空間是我的緩存，我將自己來管理它，請(qǐng)不要自動(dòng)對(duì)它進(jìn)行回收”，這個(gè)功能特性使得Java應(yīng)用也能夠擴(kuò)展來支持大量的內(nèi)存資源，希望JVM的提供者們能將這個(gè)特性在不久的將來帶入到免費(fèi)的JVM版本中。
為了擴(kuò)展這些以內(nèi)存為中心的java應(yīng)用，你需要多個(gè)jvm實(shí)例或者多臺(tái)機(jī)器節(jié)點(diǎn)。
其他垂直擴(kuò)展的問題
有些Java EE應(yīng)用的擴(kuò)展性問題并不在于其本身，有些時(shí)候外部系統(tǒng)的限制會(huì)成為系統(tǒng)擴(kuò)展能力的瓶頸，這些瓶頸可能包括：
- 數(shù)據(jù)庫系統(tǒng)：這在企業(yè)應(yīng)用和web 2.0應(yīng)用中是最常見的瓶頸，因?yàn)閿?shù)據(jù)庫通常是jvm線程中共享的資源。因此數(shù)據(jù)庫執(zhí)行的效率、數(shù)據(jù)庫事務(wù)隔離的級(jí)別將會(huì)很明顯的影響系統(tǒng)的擴(kuò)展能力。我 們看到很多的項(xiàng)目將大部分的業(yè)務(wù)邏輯以存儲(chǔ)過程的方式放在數(shù)據(jù)庫中，而web層則非常的輕量，只是用來執(zhí)行下數(shù)據(jù)的過濾等，這樣的架構(gòu)在隨著請(qǐng)求數(shù)的增長 后會(huì)出現(xiàn)很多的擴(kuò)展性問題。
- 磁盤IO和網(wǎng)絡(luò)IO。
- 操作系統(tǒng)：有些時(shí)候系統(tǒng)擴(kuò)展能力的瓶頸可能會(huì)出現(xiàn)在操作系統(tǒng)的限制上，例如，在同一個(gè)目錄下放了太多的文件，導(dǎo)致文件系統(tǒng)在創(chuàng)建和查找文件時(shí)變得非常的慢；
-
同步logging：這是一個(gè)可擴(kuò)展性的常見問題。在有些案例中，可以通過采用Apache log4j來解決，或者采用jms消息來將同步的logging轉(zhuǎn)為異步執(zhí)行。
這些不僅僅是Java EE應(yīng)用的問題，對(duì)于所有平臺(tái)的所有系統(tǒng)而言同樣如此。為了解決這些問題，需要從系統(tǒng)的各個(gè)層面來從數(shù)據(jù)庫管理員、系統(tǒng)工程師和網(wǎng)絡(luò)分析人員處得到幫助。
這篇文章的第二個(gè)部分將來探討水平擴(kuò)展的問題。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號(hào)聯(lián)系： 360901061
您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺我的文章對(duì)您有幫助，請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請(qǐng)將微信支付二維碼保存到相冊(cè)，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
