一、
1、數(shù)據(jù)庫壓力問題
所有的壓力最終都會反映到數(shù)據(jù)庫方面，一定要對數(shù)據(jù)庫有一個整體的規(guī)劃。
可以按照業(yè)務(wù)、區(qū)域等等特性對數(shù)據(jù)庫進行配置，可以考慮分庫、使用rac、分區(qū)、分表等等策略，確保數(shù)據(jù)庫能正常的進行交易。
2、事務(wù)問題
你采用了兩種類型數(shù)據(jù)庫，一個SQL Server、一個oracle，如果一個交易需要在兩個數(shù)據(jù)庫中操作，那么必須考慮到分布式事務(wù)，你應(yīng)該仔細的設(shè)計你的系統(tǒng)，來避免使用分布式事務(wù)，以避免分布式事務(wù)帶來更多的數(shù)據(jù)庫壓力和其它問題。推薦你采用延遲提交的策略(并不保證數(shù)據(jù)的完整)，來避免分布式事務(wù)的問題，畢竟commit失敗的幾率很低。（某個超大型系統(tǒng)，有3套數(shù)據(jù)庫，也是采用的延遲提交策略，避免分布式事務(wù)帶來的對數(shù)據(jù)庫過大的壓力）。
看到了你在應(yīng)用前端 (weblogic EJB)采用了F5，我個人不是很贊同這個方案，雖然F5是一個好的L4產(chǎn)品，也能基于第7層做負載均衡和容災(zāi)。但是一個有事務(wù)交易的EJB，如果采用了這種方案，把不需要使用分布式事務(wù)的交易變成了分布式交易，試想，一個web如果在一個請求中，訪問了后端兩個EJB，那么L4就會有可能把請求分發(fā)到不同的服務(wù)器上，沒有對事務(wù)維持在一個服務(wù)器中，就不能使用本地事務(wù)。同樣，一個web，訪問后端一個請求，這個請求中需要3個EJB，那么極有可能把這3 個請求分發(fā)到不同的服務(wù)器，又造成了分布式事務(wù)。weblogic是一個好的J2EE產(chǎn)品，對這種有事務(wù)關(guān)聯(lián)的負載均衡，它會優(yōu)先考慮采用一個服務(wù)器里面的應(yīng)用，這樣就采用了本地事務(wù)，提高了響應(yīng)速度，減小了分布式事務(wù)對應(yīng)用和數(shù)據(jù)庫的壓力。
3、web的優(yōu)化
我個人認為，一個商業(yè)的應(yīng)用，硬件的投資可能不是主要的瓶頸，往往可維護性，可擴展性是最主要的問題。
沒有必要采用不成熟的方案，要更多的使用成熟的方案，將靜態(tài)、圖片獨立使用不同的服務(wù)器，對于常態(tài)的靜態(tài)文件，采用E-TAG或者客戶端緩存，google 很多就是這樣干的。對于熱點的功能，考慮使用完全裝載到內(nèi)存，保證絕對的響應(yīng)速度，對于需要頻繁訪問的熱點數(shù)據(jù)，采用集中緩存(多個可以采用負載均衡)，減輕數(shù)據(jù)庫的壓力，比如：很多配置信息，操作員信息等等。
對了，對于幾乎除二進制文件，都應(yīng)該在L4上配置基于硬件的壓縮方案，減少網(wǎng)絡(luò)的流量。提高用戶使用的感知。
4、網(wǎng)絡(luò)問題
你不可能要求所有的使用人員，都和你的服務(wù)器在一個運營商的網(wǎng)絡(luò)內(nèi)，可以考慮采用鏡像、多路網(wǎng)絡(luò)接入、基于DNS的負載均衡。如果有足夠的投資，可以采用CDN(內(nèi)容分發(fā)網(wǎng))，減輕你的服務(wù)器壓力。
二、F5的負載均衡 是必不可少的，他的每秒點擊量能達到將近30萬，并且它有會話的粘性，只要是同一個ip發(fā)過來的請求，它就會把它分到同一臺機器的，不用擔(dān)心分發(fā)錯誤的?，F(xiàn)在的問題是apache和tomcat的能力不平衡，動態(tài)的內(nèi)容壓力太大，不是數(shù)據(jù)庫的壓力，我們的數(shù)據(jù)庫
oracle是RAC群集。性能很好
三、tomcat為什么死掉？當(dāng)時CPU或者內(nèi)存的占用率是多少？看看其中JVM占用了多少？有沒有OOM的錯誤？不可能20臺tomcat只能支撐5000的并發(fā)。。。以前做過單臺的resin峰值到3K都是綽綽有余的。。。把緩存做好，減少動態(tài)查詢
四、
1、F5的使用
F5不光可以做web的負載均衡，也可以做基于第4層的負載均衡。
比如：銀行接口，大部分基于socket通訊的，就可以在前面架設(shè)一套F5設(shè)備，將請求分發(fā)到不同的服務(wù)器上。
大部分使用F5都是在web層次上，如果使用基于源IP地址的策略，有很多客戶端都是基于代理服務(wù)器，這個時候源IP地址是一樣的，其實并沒有把這些用戶給分發(fā)到不同的服務(wù)器上，建議采用基于cookie insert的方式，采用cookie的會話保持策略，loadbalance的算法，需要仔細的結(jié)合自己的應(yīng)用的實際情況來設(shè)置。
2、大并發(fā)的問題
現(xiàn)在你得到了一個大概的系統(tǒng)能承受的并發(fā)，但是還達不到系統(tǒng)的設(shè)計目標(biāo)。
應(yīng)該從應(yīng)用的角度去分析這個問題，web方面，通過工具(httplook)，檢查一下客戶端發(fā)起的請求都是什么響應(yīng)狀態(tài)，如果看到很多304請求狀態(tài)，你需要優(yōu)化你的url緩存，看一下每個url的耗費時間，仔細針對比較慢的進行調(diào)優(yōu)；對于tomcat或者weblogic，在高并發(fā)的情況下，用kill -3 <PID>，獲得ThreadDump(HeapDump需要特殊的設(shè)置)，看一下在高并發(fā)下，jvm的線程到底在干什么，仔細的分析可能對你有幫助。
如果在這些還沒有改善的情況下，應(yīng)當(dāng)去想一想，硬件是否足夠、配置是否合理等等系統(tǒng)級別的問題。
五、似乎在說瓶頸在于tomcat并發(fā)承載能力不夠，但為什么tomcat只能承擔(dān)單機200個并發(fā)？當(dāng)并發(fā)急劇上升的時候，tomcat在執(zhí)行動態(tài)請求的時候，瓶頸在哪里？是哪部分程序，或者哪個環(huán)節(jié)首先導(dǎo)致tomcat失去響應(yīng)的？在davexin描述的刀片硬件上面，tomcat上面如果跑的僅僅是最簡單的jsp頁面，在采用BEA JRockit JVM的情況下，500個并發(fā)也可以達到。
我的推測是瓶頸還是出在EJB遠程方法調(diào)用上！
tomcat上面的java應(yīng)用要通過EJB遠程方法調(diào)用，來訪問weblogic上面的無狀態(tài)SessionBean，這樣的遠程方法調(diào)用一般都在100ms~500ms級別，或者更多。而如果沒有遠程方法調(diào)用，即使大量采用spring的動態(tài)反射，一次完整的web請求處理在本地JVM內(nèi)部的完成時間一般也不過20ms而已。一次web請求需要過長的執(zhí)行時間，就會導(dǎo)致servlet線程被占用更多的時間，從而無法及時響應(yīng)更多的后續(xù)請求。
如果這個推測是成立的話，那么我的建議就是既然你沒有用到分布式事務(wù)，那么就干脆去掉EJB。weblogic也可以全部撤掉，業(yè)務(wù)層使用spring取代EJB，不要搞分布式架構(gòu)，在每個tomcat實例上面部署一個完整的分層結(jié)構(gòu)。
另外在高并發(fā)情況下，apache處理靜態(tài)資源也很耗內(nèi)存和CPU，可以考慮用輕量級web server如lighttpd/litespeed/nginx取代之。
六、tomcat之所以并發(fā)低很可能是由于remote session bean造成的，remote session bean又一次被濫用了，在樓主的這種業(yè)務(wù)情況下，web層和service層根本不需要分開，象樓主這樣分開帶來就是一訪問業(yè)務(wù)層就帶來長時間的遠程請求，確實導(dǎo)致tomcat上servlet資源釋放的問題。那么remote session bean應(yīng)該被用在什么地方呢，without ejb上有寫到金融系統(tǒng)常用ejb。我把他的這句話延伸一下，也就是說當(dāng)業(yè)務(wù)的運行時間遠超過遠程調(diào)用的時間時，我們就可以用remote session bean來把這個業(yè)務(wù)分離出去。而樓主的系統(tǒng)中沒有這種業(yè)務(wù)情況。所以使用remote session bean應(yīng)該來說是一個錯誤的選擇，不過這個錯誤的選擇帶來的危害被大量的硬件所掩蓋，帶來的是成本的提高。而性能上還不如slsb。
所以我覺得如果要改架構(gòu)最便捷的方法是使用slsb，把remote session bean去掉。這樣改造的成本比較低，如果換成spring+hibernate成本就高得多了。也就是說可以 struts+Bean+DAO+helper，然后把weblogic作cluster，任意一個node上都部署相同的應(yīng)用。也就是水平擴展，理論上來講當(dāng)性能不滿足要求時添加node就行了，如果能做成農(nóng)場就更加方便了。當(dāng)然即使非農(nóng)場也沒有關(guān)系，可以用現(xiàn)在在使用的stick分發(fā)。這樣的改造之所以方便是因為把remote session bean改成slsb是很容易的，而且團隊里的人估計對ejb都更加熟悉一點，成本會比較低一點
七、
近段時間正在做購買新硬件和新軟件的預(yù)算，公司高層準(zhǔn)備買weblogic10和oracle 10g，所以請了bea公司的人員和我一塊做測試，經(jīng)過近幾天的測試，測試一下新的系統(tǒng)指標(biāo)1萬個并發(fā)，需要多少軟件和多少硬件能夠支撐，已經(jīng)測試了不同的組合方式，有了不同的結(jié)果，分別如下：
1。1臺weblogic10 能支持900個用戶并發(fā)（沒有用ejb），平均響應(yīng)時間 10秒。
2。1臺weblogic10 Express（相當(dāng)于1臺tomcat，用于發(fā)布jsp應(yīng)用）加1臺weblogic10（發(fā)布ejb應(yīng)用），能支持1000個并發(fā)用戶，平均響應(yīng)時間 9秒，由于本人使用的loadRunner最多支持1000個web并發(fā)，雖然此時weblogic沒有任何錯誤，但是沒辦法再向上壓用戶，所以不知道最高能支撐多少個并發(fā)用戶，很遺憾。
3。1臺weblogic8， 能支持900個用戶并發(fā)（沒有用ejb），平均響應(yīng)時間 11秒。但是沒有weblogic10在同樣時間內(nèi)處理的交易數(shù)量多。可以判定性能不能weblogic10。
4。1臺tomcat4.1加1臺weblogic8，只能支持350個并發(fā)用戶，tomcat就連結(jié)超時，說明此種結(jié)構(gòu)瓶頸在tomcat。
5。1臺tomcat6.14加1臺weblogic8，還不如方案4，tomcat結(jié)超時更多，說明此種結(jié)構(gòu)瓶頸在tomcat。由于還沒有看tomcat6.14的調(diào)優(yōu)資料。所以還請高手給建議。
6。1臺tomcat4.1加1臺weblogic10，性能同樣不佳，問題出現(xiàn)在tomcat性能跟不上。
7。1臺tomcat6.14加1臺weblogic10，性能同樣不佳，問題出現(xiàn)在tomcat性能跟不上。
明天還要做一個weblogic10 cluster測試，等有了測試結(jié)果，再根大家交流。
以上測試機器都為 linux as4 操作系統(tǒng)，2cpu + 2G內(nèi)存，發(fā)現(xiàn)cpu利用率最高占45%，一般就在10%左右，內(nèi)存可以用到1.5G。 loadRunner機器為2cpu + 2G內(nèi)存，window server 2003操作系統(tǒng)。
有以上的結(jié)果，bea公司人員建議購買16-20cpu的licens。機器購買4cpu + 8G內(nèi)存機器4-6臺。前端tomcat增加到50臺。
由于根據(jù)以前的宕機記錄，主要表現(xiàn)在tomcat層，個別高峰時候也出現(xiàn)在F5。故不敢輕易的舍棄無狀態(tài)session bean。由于tomcat做了大部分的業(yè)務(wù)，只有需要數(shù)據(jù)庫的時候才調(diào)用weblogic中間件，由于weblogic的價格還是比較昂貴的，公司以前購買的weblogic licens數(shù)量限制。所以還不能把所有的tomcat換成weblogic。如果有20臺weblogic的licens，我也就不擔(dān)心1萬個并發(fā)了。
八、
坦白說我還從來沒有聽說過大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用使用EJB的先例。為什么大規(guī)模互聯(lián)網(wǎng)應(yīng)用不能用EJB，其實就是因為EJB性能太差，用了EJB幾乎必然出現(xiàn)性能障礙。阿里巴巴和淘寶網(wǎng)那是每天多少億PV的電子商務(wù)網(wǎng)站了，其實也就是用JBoss而已，而且也只是用其web容器(JBoss的web容器就是tomcat)，所以本質(zhì)上還是在用tomcat。
今年年初，RedHat在深圳的HW大客戶在內(nèi)部做過性能對比評測，JBoss4 vs WebLogic 9，在web容器一項的評測當(dāng)中，JBoss4勝出。這個結(jié)果并不令人感到意外，因為web容器的性能說到底無非就是Servlet線程調(diào)度能力而已，Tomcat不像WebLogic那樣附加n多管理功能，跑得快很正常。這一點你只要對比測試一下WebLogic的數(shù)據(jù)庫連接池和C3P0連接池的性能也會發(fā)現(xiàn)類似的結(jié)論，C3P0可要比WebLogic的連接池快好幾倍了。這不是說WebLogic性能不好，只不過weblogic要實現(xiàn)更多的功能，所以在單一的速度方面就會犧牲很多東西。
以我的經(jīng)驗來判斷，使用tomcat5.5以上的版本，配置apr支持，進行必要的tuning，使用BEA JRockit JVM的話，在你們目前的刀片上面，支撐500個并發(fā)完全是可以做到的。結(jié)合你們目前20個刀片的硬件，那么達到1萬并發(fā)是沒問題的。當(dāng)然這樣做的前提是必須扔掉EJB，并置web層和業(yè)務(wù)層在同一個JVM內(nèi)部。
從你上面的發(fā)言來看，你們之所以采用EJB，無非是因為經(jīng)費有限，無法購買充足的weblogic license。所以退而求其次，購買少量的weblogic license，專門跑業(yè)務(wù)層服務(wù)器，用SLSB暴露遠程接口給tomcat調(diào)用。然后部署n十多臺免費的tomcat服務(wù)器跑web。為省錢而采用 EJB到是一個很新鮮的事，但實際上這就是一個很愚蠢的決定。
weblogic的優(yōu)秀更多的體現(xiàn)在他對于J2EE標(biāo)準(zhǔn)優(yōu)秀的支持，各種復(fù)雜的企業(yè)應(yīng)用場景以及傳統(tǒng)的中間件應(yīng)用的豐富而方便的集成手段上。簡單的來說，就是weblogic/websphere是企業(yè)應(yīng)用的首選，特別是強調(diào)事務(wù)的企業(yè)應(yīng)用，例如金融，電信計費。但在互聯(lián)網(wǎng)應(yīng)用方面，weblogic/websphere根本就體現(xiàn)不出有什么能夠超過resin/tomcat的地方，誠然weblogic express的web容器穩(wěn)定性要好于tomcat，但沒有互聯(lián)網(wǎng)企業(yè)在大規(guī)模部署tomcat水平群集的時候，還會為這一點而瘋狂買單購買 weblogic license。
所以我個人很不理解，作為一個互聯(lián)網(wǎng)公司的CTO，怎么會如此迷信weblogic，因為我認識的互聯(lián)網(wǎng)公司高層，沒有什么人愿意用商業(yè)產(chǎn)品，絕大多數(shù)都是用開源的，我不憚揣測他的背景可能來自傳統(tǒng)企業(yè)應(yīng)用出身的吧，呵呵。
九、
這說明瓶頸還不在EJB遠程調(diào)用上，但是問題已經(jīng)逐漸清楚了。為什么weblogic充當(dāng)web容器發(fā)起遠程EJB調(diào)用的時候可以支撐1000個并發(fā)，但是tomcat只能到350個？只有兩個可能的原因：
1、你的tomcat沒有配置好，嚴(yán)重影響了性能表現(xiàn)
2、tomcat和weblogic之間的接口出了問題
上面的帖子其實我也介紹過了，如果只是單純的作為servlet容器來看，tomcat的性能不應(yīng)該比weblogic差，甚至還要更好，所以你可以這樣來擬定測試方案：
在同樣硬件環(huán)境下對比測試tomcat5.5和weblogic10的servlet容器性能，分別寫幾個訪問數(shù)據(jù)庫，和不訪問數(shù)據(jù)庫的JSP頁面測試就可以了，并發(fā)從500往上走，看看哪個throughput更高。記得要調(diào)優(yōu)tomcat5.5，配置apr支持要打開。
如果測試結(jié)果表明tomcat并發(fā)響應(yīng)能力遠遠差于weblogic，那就說明你的tomcat配置有很大的問題，好好鉆研tomcat configuration && performance tuning吧；
如果測試結(jié)果表明tomcat并發(fā)響應(yīng)能力與weblogic相當(dāng)，或者差不多，那么很不幸，問題不在tomcat本身，而是出在了tomcat到 weblogic的接口上。而tomcat是通過weblogic提供的EJB client jar去調(diào)用weblogic的EJB的，那你只好咨詢BEA去尋求解決方案了。
十、
1.基礎(chǔ)配置優(yōu)化
tomcat 6？ tomcat參數(shù)調(diào)優(yōu)?
JRockit JVM? JVM參數(shù)調(diào)優(yōu)？
Apache+Squid 處理靜態(tài)內(nèi)容？
2.業(yè)務(wù)層優(yōu)化
部分功能本地化，而不調(diào)remote session bean?
異步提交操作,JMS？
cache熱點數(shù)據(jù)？
3.展示層優(yōu)化
動態(tài)頁面發(fā)布為靜態(tài)頁面？
Cache部分動態(tài)頁面內(nèi)容？
十一、
對于樓主的問題，以及公司的架構(gòu)方案，我認為你們?nèi)匀辉诜稿e！
誤區(qū)：遇到性能問題的第一件事情就是找硬件和容器的事情!
性能問題的基本上無一例外的都出在寫的程序有問題，滿足不了伸縮性。
好好看看你們的程序吧，不要再給bea打電話了，你得到的建議，基本上都是用不到的。
robin的觀點是對的，我甚至懷疑你們的數(shù)據(jù)庫連接是否有釋放問題的。
增加你們前端的內(nèi)存，多做緩存。hibernate的cache方案不差jdbc對數(shù)據(jù)庫的頻繁使用
html的書寫是否符合w3的規(guī)范
最好在一個服務(wù)器上部署整個應(yīng)用！
十二、
淘寶用的weblogic8,他們的web層使用的Turbine，且大量的使用velocity，由于對事務(wù)要求及其苛刻用到了ejb,也用到 spring很多其他服務(wù)，訪問數(shù)據(jù)庫使用ibatis，他們對weblogic優(yōu)化到的極致加上外面也架了apache,，在如此高并發(fā)的情況，且高度復(fù)雜的搜索。。。，還能保持如此的響應(yīng)速度，確實很不錯。
淘寶的搜索功能說是在的非常強大，不曉得是不是yahoo中國來人做的，一直覺得很神奇
robbin大哥說的還是很有道理，對于大多數(shù)門戶門戶網(wǎng)站，使用EJB確實浪費，購買weblogic的錢可以購買很多硬件來 apache,tomcat負載均衡遠遠勝過于ejb方案的性能。沒有絕對的性能好壞之分，主要還是看你的需求，weblogic永遠是對于銀行，證券，電信的行業(yè)所準(zhǔn)備，他們所使用的硬件對象也絕對不是刀片，雙路至強的硬件這樣的東東。
十三、
經(jīng)過今天修改tomcat的參數(shù)，修改如下：
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" enableLookups="false" redirectPort="8443"
acceptCount="500" maxProcessors="500" minProcessors="500"
maxSpareProcessors="200"
connectionTimeout="20000"
useURIValidationHack="false" disableUploadTimeout="true" />
經(jīng)過測試，并發(fā)人數(shù)是可以達到像robbin所說的一樣，能夠在600人左右，如果壓到并發(fā)700人，就有15%左右的失敗，雖然在調(diào)整上面參數(shù)之后，并發(fā)人數(shù)上去了，但是在同樣的時間內(nèi)所完成的事務(wù)數(shù)量下降了10%左右，并且響應(yīng)時間延遲了1秒左右，但從整體上來說，犧牲一點事務(wù)吞吐量和響應(yīng)時間，并發(fā)人數(shù)能夠提高500，覺得還是值得的。謝謝robbin的建議。
由于本人使用的loadRunner 能支持的獨立client數(shù)量在100個，所以沒辦法對ejb進行單獨的壓力測試。因為我在對前段應(yīng)用調(diào)用ejb時，最多并發(fā)用戶已經(jīng)達到1000個，但是通過監(jiān)控weblogic10中發(fā)布的ejb應(yīng)用和連接池，發(fā)現(xiàn)ejb應(yīng)用等待數(shù)量為0，但是連接池中最多有60個活動連接，有7個連接在等待，因為此時設(shè)置的weblogic連接池最大數(shù)量是60，后來對連接池數(shù)量進行增大到160個，再次進行測試，發(fā)現(xiàn)性能反而不如把連接池數(shù)量調(diào)為60個的時候。問起bea的人，他們也說不清楚原因。
同時對他們所提供的一種更好的jvm進行測試，jvm的名字是 RealTime.發(fā)現(xiàn)性能并沒有太大改善。
我們現(xiàn)在的系統(tǒng)已經(jīng)作了很多的緩存，有全局的，有局部的，都是放到內(nèi)存中的HashMap，靜態(tài)的頁面都是放在apache上的，不過沒有使用 apr， 接下來如果有時間，會測試一下這個咚咚，。
che 前面是F5負載均衡器，在apache后面是tomcat，tomcat在公網(wǎng)上，然后通過內(nèi)網(wǎng)網(wǎng)卡訪問weblogic，weblogic才能訪問數(shù)據(jù)庫，tomcat不能直接訪問數(shù)據(jù)庫的，由于以前的網(wǎng)絡(luò)結(jié)構(gòu)的原因，也有安全的原因，公司還有部分服務(wù)器在北京（無線事業(yè)部）和廣州（老系統(tǒng)，以后會逐漸遷移到上海），雖然現(xiàn)在也有其他的安全方案可以把tomcat放在內(nèi)網(wǎng)，去掉weblogic，但是這種改變是需要時間的，也要考慮平穩(wěn)過渡，所以還請各位理解。至于購買weblogic，公司也是有自己的考慮的。因為以前就是運行在weblogic上的，如果現(xiàn)在不用了，如果出了問題，就很難辦了。
十四、是的，如果調(diào)整參數(shù)，可以達到并發(fā)人數(shù)達到1000以上，但是通過對比同樣壓力下的weblogic和tomcat，發(fā)現(xiàn)tomcat的響應(yīng)時間都比weblogic長，并且tomcat的cpu的占用率達到45%-60%，而同樣的壓力下weblogic的cpu占用只有3%-5%。內(nèi)存都是2G都用了97%，說明主要差別表現(xiàn)在cpu和相應(yīng)時間上，我沒有做tomcat 1000人并發(fā)測試，但是從以前600人并發(fā)的響應(yīng)時間判斷，我覺得響應(yīng)時間可能會超過15秒。所以從綜合各方面性能指標(biāo)考慮，我覺得要找出一個響應(yīng)時間，并發(fā)人數(shù)，完成交易數(shù)量3方面考慮折中，找出一個滿足應(yīng)用響應(yīng)時間和并發(fā)用戶的折中吧，如果是并發(fā)交易量比較大的應(yīng)用，我想應(yīng)該減少并發(fā)用戶，提高單位時間內(nèi)交易數(shù)量來滿足應(yīng)用需求吧。
十五、
又回到了realtime的定義，并不是很快的意思，而是響應(yīng)時間是可預(yù)計的。
而JVM對響應(yīng)時間可預(yù)計性的影響，主要表現(xiàn)在
1.線程調(diào)度受操作系統(tǒng)線程調(diào)度的影響
2.垃圾收集引起的暫停
所以jrockit選擇了動態(tài)垃圾收集，以頻繁的收集來換取每次中斷時間的減少，所以，對吞吐量來說，是反而會下降的。大部分jvm都有吞吐量優(yōu)先，短暫停時間兩種截然不同的垃圾收集算法。
http://www.javaeye.com/topic/117564?page=1