對于我們開發(fā)的網(wǎng)站，如果網(wǎng)站的訪問量非常大的話芹橡，那么我們就需要考慮相關(guān)的并發(fā)訪問問題了。而并發(fā)問題是絕大部分的程序員頭疼的問題妻枕，

但話又說回來了僻族，既然逃避不掉，那我們就坦然面對吧~今天就讓我們一起來研究一下常見的并發(fā)和同步吧屡谐。

為了更好的理解并發(fā)和同步述么，我們需要先明白兩個重要的概念:同步和異步

** 1、同步和異步的區(qū)別和聯(lián)系**

** ** 所謂同步愕掏，可以理解為在執(zhí)行完一個函數(shù)或方法之后度秘，一直等待系統(tǒng)返回值或消息，這時(shí)程序是出于阻塞的，只有接收到

返回的值或消息后才往下執(zhí)行其它的命令剑梳。

異步唆貌，執(zhí)行完函數(shù)或方法后，不必阻塞性地等待返回值或消息垢乙，只需要向系統(tǒng)委托一個異步過程锨咙，那么當(dāng)系統(tǒng)接收到返回

值或消息時(shí)，系統(tǒng)會自動觸發(fā)委托的異步過程追逮，從而完成一個完整的流程酪刀。

** ** 同步在一定程度上可以看做是單線程，這個線程請求一個方法后就待這個方法給他回復(fù)钮孵，否則他不往下執(zhí)行(死心眼)骂倘。

異步在一定程度上可以看做是多線程的(廢話，一個線程怎么叫異步)巴席，請求一個方法后历涝，就不管了，繼續(xù)執(zhí)行其他的方法漾唉。

同步就是一件事荧库，一件事情一件事的做。異步就是毡证，做一件事情电爹，不引響做其他事情。例如：吃飯和說話料睛，只能一件事一件事的來，因?yàn)橹挥幸粡堊煲“睢５燥埡吐犚魳肥钱惒降男羯罚驗(yàn)椋犚魳凡⒉灰懳覀兂燥垺?/p>

對于Java程序員而言施籍，我們會經(jīng)常聽到同步關(guān)鍵字synchronized居扒，假如這個同步的監(jiān)視對象是類的話，那么如果當(dāng)一個對象

訪問類里面的同步方法的話丑慎，那么其它的對象如果想要繼續(xù)訪問類里面的這個同步方法的話喜喂，就會進(jìn)入阻塞，只有等前一個對象

執(zhí)行完該同步方法后當(dāng)前對象才能夠繼續(xù)執(zhí)行該方法竿裂。這就是同步玉吁。相反，如果方法前沒有同步關(guān)鍵字修飾的話腻异，那么不同的對象

可以在同一時(shí)間訪問同一個方法进副，這就是異步。

在補(bǔ)充一下(臟數(shù)據(jù)和不可重復(fù)讀的相關(guān)概念):

臟數(shù)據(jù)

臟讀就是指當(dāng)一個事務(wù)正在訪問數(shù)據(jù)悔常，并且對數(shù)據(jù)進(jìn)行了修改影斑，而這種修改還沒有提交到數(shù)據(jù)庫中给赞，這時(shí)，另外一個事務(wù)也訪問這個數(shù)據(jù)矫户，然后使用了這

個數(shù)據(jù)片迅。因?yàn)檫@個數(shù)據(jù)是還沒有提交的數(shù)據(jù)，那么另外一個事務(wù)讀到的這個數(shù)據(jù)是臟數(shù)據(jù)(Dirty Data)皆辽，依據(jù)臟數(shù)據(jù)所做的操作可能是不正確的障涯。

不可重復(fù)讀

不可重復(fù)讀是指在一個事務(wù)內(nèi)，多次讀同一數(shù)據(jù)膳汪。在這個事務(wù)還沒有結(jié)束時(shí)唯蝶，另外一個事務(wù)也訪問該同一數(shù)據(jù)。那么遗嗽，在第一個事務(wù)中的兩次讀數(shù)據(jù)之間粘我，由于第二個事務(wù)的修改，那么第一個事務(wù)兩次讀到的數(shù)據(jù)可能是不一樣的痹换。這樣就發(fā)生了在一個事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的征字，因此稱為是不可重復(fù)讀

** **

** 2、如何處理并發(fā)和同步**

** **今天講的如何處理并發(fā)和同同步問題主要是通過鎖機(jī)制娇豫。

我們需要明白匙姜，鎖機(jī)制有兩個層面。

一種是代碼層次上的冯痢，如java中的同步鎖氮昧，典型的就是同步關(guān)鍵字synchronized，這里我不在做過多的講解浦楣，

感興趣的可以參考:http://www.cnblogs.com/xiohao/p/4151408.html

另外一種是數(shù)據(jù)庫層次上的袖肥，比較典型的就是悲觀鎖和樂觀鎖。這里我們重點(diǎn)講解的就是悲觀鎖（傳統(tǒng)的物理鎖）和樂觀鎖振劳。

?悲觀鎖(Pessimistic Locking):** **

悲觀鎖椎组，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)历恐，以及來自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度寸癌，因此，

在整個數(shù)據(jù)處理過程中弱贼，將數(shù)據(jù)處于鎖定狀態(tài)蒸苇。

悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機(jī)制（也只有數(shù)據(jù)庫層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問的排他性哮洽，否則填渠，即使在本系統(tǒng)

中實(shí)現(xiàn)了加鎖機(jī)制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)）。

一個典型的倚賴數(shù)據(jù)庫的悲觀鎖調(diào)用：

?select * from account where name=”Erica” for update

這條sql 語句鎖定了 account 表中所有符合檢索條件（ name=”Erica” ）的記錄氛什。

本次事務(wù)提交之前（事務(wù)提交時(shí)會釋放事務(wù)過程中的鎖）莺葫，外界無法修改這些記錄。Hibernate 的悲觀鎖枪眉，也是基于數(shù)據(jù)庫的鎖機(jī)制實(shí)現(xiàn)捺檬。 ??下面的代碼實(shí)現(xiàn)了對查詢記錄的加鎖：

?String hqlStr ="from TUser as user where user.name='Erica'";

?Query query = session.createQuery(hqlStr);

* * query.setLockMode("user",LockMode.UPGRADE); // 加鎖

?List userList = query.list();// 執(zhí)行查詢，獲取數(shù)據(jù)

?query.setLockMode 對查詢語句中贸铜，特定別名所對應(yīng)的記錄進(jìn)行加鎖（我們?yōu)?TUser 類指定了一個別名 “user” ）堡纬，這里也就是對

返回的所有user 記錄進(jìn)行加鎖。

觀察運(yùn)行期Hibernate 生成的 ?SQL 語句： ??select tuser0.id as id, tuser0.name as name, ?tuser0_.group_id ?as group_id, tuser0.user_type as user_type, tuser0.sex as ?sex ?from t_user tuser0_ where (tuser0_.name='Erica' ) for ?update ?這里 ?Hibernate 通過使用數(shù)據(jù)庫的 ?for update 子句實(shí)現(xiàn)了悲觀鎖機(jī)制蒿秦。 ??Hibernate 的加鎖模式有： ??? LockMode.NONE ： ?無鎖機(jī)制烤镐。 ??? LockMode.WRITE ： ?Hibernate 在 ?Insert 和 ?Update 記錄的時(shí)候會自動獲取 ?? LockMode.READ ： ?Hibernate 在讀取記錄的時(shí)候會自動獲取。 ??以上這三種鎖機(jī)制一般由 ?Hibernate 內(nèi)部使用棍鳖，如 ?Hibernate 為了保證 ?Update ?過程中對象不會被外界修改炮叶，會在 ?save 方法實(shí)現(xiàn)中自動為目標(biāo)對象加上 ?WRITE 鎖。 ??? LockMode.UPGRADE ：利用數(shù)據(jù)庫的 ?for update 子句加鎖渡处。 ??? LockMode. UPGRADE_NOWAIT ： ?Oracle 的特定實(shí)現(xiàn)镜悉，利用 ?Oracle 的 ?for ?update nowait 子句實(shí)現(xiàn)加鎖。 ??上面這兩種鎖機(jī)制是我們在應(yīng)用層較為常用的医瘫，加鎖一般通過以下方法實(shí)現(xiàn)： ??Criteria.setLockMode ?Query.setLockMode ?Session.lock ?注意侣肄，只有在查詢開始之前（也就是 ?Hiberate 生成 ?SQL 之前）設(shè)定加鎖，才會 ??真正通過數(shù)據(jù)庫的鎖機(jī)制進(jìn)行加鎖處理醇份，否則稼锅，數(shù)據(jù)已經(jīng)通過不包含 ?for update ?子句的 ?Select SQL 加載進(jìn)來，所謂數(shù)據(jù)庫加鎖也就無從談起被芳。

為了更好的理解select... for update的鎖表的過程缰贝，本人將要以mysql為例，進(jìn)行相應(yīng)的講解

需要注意的是for update要放到mysql的事務(wù)中畔濒，即begin和commit中，否者不起作用锣咒。

至于是鎖住整個表還是鎖住選中的行侵状，請參考:

?http://www.cnblogs.com/xiohao/p/4385768.html

至于hibernate中的悲觀鎖使用起來比較簡單，這里就不寫demo了~感興趣的自己查一下就ok了~

** **

** 樂觀鎖(Optimistic Locking): ** ?相對悲觀鎖而言毅整，樂觀鎖機(jī)制采取了更加寬松的加鎖機(jī)制趣兄。悲觀鎖大多數(shù)情況下依 ?靠數(shù)據(jù)庫的鎖機(jī)制實(shí)現(xiàn)，以保證操作最大程度的獨(dú)占性悼嫉。但隨之

而來的就是數(shù)據(jù)庫性能的大量開銷艇潭，特別是對長事務(wù)而言，這樣的開銷往往無法承受。如一個金融系統(tǒng)蹋凝，當(dāng)某個操作員讀取用戶的數(shù)據(jù)鲁纠，并在讀出的用戶數(shù)

據(jù)的基礎(chǔ)上進(jìn)行修改時(shí)（如更改用戶帳戶余額），如果采用悲觀鎖機(jī)制鳍寂，也就意味著整個操作過程中（從操作員讀出數(shù)據(jù)改含、開始修改直至提交修改結(jié)果的全

過程，甚至還包括操作員中途去煮咖啡的時(shí)間）迄汛，數(shù)據(jù)庫記錄始終處于加鎖狀態(tài)捍壤，可以想見，如果面對幾百上千個并發(fā)鞍爱，這樣的情況將導(dǎo)致怎樣的后果鹃觉。樂

觀鎖機(jī)制在一定程度上解決了這個問題。

樂觀鎖睹逃，大多是基于數(shù)據(jù)版本Version ）記錄機(jī)制實(shí)現(xiàn)盗扇。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個版本標(biāo)識唯卖，在基于數(shù)據(jù)庫表的版本解決方案中粱玲，一般是通

過為數(shù)據(jù)庫表增加一個“version” 字段來 實(shí)現(xiàn)。 讀取出數(shù)據(jù)時(shí)拜轨，將此版本號一同讀出抽减，之后更新時(shí)，對此版本號加一橄碾。此時(shí)卵沉，將提 交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)

庫表對應(yīng)記錄的當(dāng)前版本信息進(jìn)行比對，如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫表當(dāng)前版本號法牲，則予以更新史汗，否則認(rèn)為是過期數(shù)據(jù)。對于上面修改用戶帳戶信息

的例子而言拒垃，假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個version 字段停撞，當(dāng)前值為 1 ；而當(dāng)前帳戶余額字段（ balance ）為 $100 悼瓮。 操作員 A 此時(shí)將其讀出

（version=1 ）戈毒，并從其帳戶余額中扣除

100-$50 ）。 2 在操作員 A 操作的過程中横堡，操作員 B 也讀入此用戶信息（ version=1 ）埋市，并 從其帳

戶余額中扣除100-50 ，提交至數(shù)據(jù)庫更新命贴，此時(shí)由于提交數(shù)據(jù)版本大于數(shù)據(jù)庫記錄當(dāng)前版本道宅，數(shù)據(jù)被更新食听，數(shù)據(jù)庫記錄version 更新為 2 。 4 操作員 B 完成了操作污茵，也將版本號加一

（version=2 ）試圖向數(shù)據(jù)庫提交數(shù) 據(jù)（ balance=$80 ）樱报，但此時(shí)比對數(shù)據(jù)庫記錄版本時(shí)發(fā)現(xiàn)，操作員 B 提交的 數(shù)據(jù)版本號為 2 省咨，數(shù)據(jù)庫記錄當(dāng)前版

本也為2 肃弟，不滿足 “ 提交版本必須大于記 錄當(dāng)前版本才能執(zhí)行更新 “ 的樂觀鎖策略，因此零蓉，操作員 B 的提交被駁回笤受。 這樣，就避免了操作員 B 用基于

version=1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作 員 A 的操作結(jié)果的可能敌蜂。 從上面的例子可以看出箩兽，樂觀鎖機(jī)制避免了長事務(wù)中的數(shù)據(jù)庫加鎖開銷（操作員 A

和操作員B 操作過程中，都沒有對數(shù)據(jù)庫數(shù)據(jù)加鎖）章喉，大大提升了大并發(fā)量下的系 ?統(tǒng)整體性能表現(xiàn)汗贫。 ?需要注意的是，樂觀鎖機(jī)制往往基于系統(tǒng)中的數(shù)據(jù)存儲

邏輯秸脱，因此也具備一定的局限性落包，如在上例中，由于樂觀鎖機(jī)制是在我們的系統(tǒng)中實(shí)現(xiàn)摊唇，來自外部系統(tǒng)的用戶余額更新操作不受我們系統(tǒng)的控制咐蝇，因此可能

會造成臟數(shù)據(jù)被更新到數(shù)據(jù)庫中。在系統(tǒng)設(shè)計(jì)階段巷查，我們應(yīng)該充分考慮到這些情況出現(xiàn)的可能性有序，并進(jìn)行相應(yīng)調(diào)整（如將樂觀鎖策略在數(shù)據(jù)庫存儲過程中實(shí)

現(xiàn)，對外只開放基于此存儲過程的數(shù)據(jù)更新途徑岛请，而不是將數(shù)據(jù)庫表直接對外公開）旭寿。Hibernate 在其數(shù)據(jù)訪問引擎中內(nèi)置了樂觀鎖實(shí)現(xiàn)。如果不用考慮外

部系統(tǒng)對數(shù)據(jù)庫的更新操作崇败，利用Hibernate 提供的透明化樂觀鎖實(shí)現(xiàn)盅称，將大大提升我們的 生產(chǎn)力。

Hibernate 中可以通過 ?class 描述符的 ?optimistic-lock 屬性結(jié)合 ?version描述符指定后室。

現(xiàn)在微渠，我們?yōu)橹笆纠械腢ser 加上樂觀鎖機(jī)制。

1 ． 首先為 User 的POJO class

然后是User.hbm.xml

注意version 節(jié)點(diǎn)必須出現(xiàn)在 ID 節(jié)點(diǎn)之后咧擂。 ?這里我們聲明了一個 version 屬性，用于存放用戶的版本信息檀蹋，保存在 User 表的version中 ?optimistic-lock ?屬性有如下可選取值： ?? none 無樂觀鎖 ?? version 通過版本機(jī)制實(shí)現(xiàn)樂觀鎖 ?? dirty 通過檢查發(fā)生變動過的屬性實(shí)現(xiàn)樂觀鎖 ?? all 通過檢查所有屬性實(shí)現(xiàn)樂觀鎖 ?其中通過 ?version 實(shí)現(xiàn)的樂觀鎖機(jī)制是 ?Hibernate 官方推薦的樂觀鎖實(shí)現(xiàn)松申，同時(shí)也 ?是 ?Hibernate 中云芦，目前唯一在數(shù)據(jù)對象脫離 ?Session 發(fā)生修改的情況下依然有效的鎖機(jī) ?制。因此贸桶，一般情況下舅逸，我們都選擇 ?version 方式作為 ?Hibernate 樂觀鎖實(shí)現(xiàn)機(jī)制。

2 ． ?配置文件hibernate.cfg.xml和UserTest測試類

?hibernate.cfg.xml

?UserTest.java

每次對TUser 進(jìn)行更新的時(shí)候皇筛，我們可以發(fā)現(xiàn)琉历，數(shù)據(jù)庫中的 version 都在遞增。

下面我們將要通過樂觀鎖來實(shí)現(xiàn)一下并發(fā)和同步的測試用例:

這里需要使用兩個測試類水醋，分別運(yùn)行在不同的虛擬機(jī)上面旗笔，以此來模擬多個用戶同時(shí)操作一張表,同時(shí)其中一個測試類需要模擬長事務(wù)

UserTest.java

?UserTest2.java

操作流程及簡單講解: 首先啟動UserTest2.java測試類，在執(zhí)行到Thread.sleep(10000);這條語句的時(shí)候拄踪，當(dāng)前線程會進(jìn)入睡眠狀態(tài)蝇恶。在10秒鐘之內(nèi)

啟動UserTest這個類，在到達(dá)10秒的時(shí)候惶桐，我們將會在UserTest.java中拋出下面的異常:

?UserTest2代碼將在 tx.commit() 處拋出 StaleObjectStateException 異 常撮弧，并指出版本檢查失敗，當(dāng)前事務(wù)正在試圖提交一個過期數(shù)據(jù)姚糊。通過捕捉這個異常贿衍，我 們就可以在樂觀鎖校驗(yàn)失敗時(shí)進(jìn)行相應(yīng)處理

** 3、常見并發(fā)同步案例分析**

** 案例一:訂票系統(tǒng)案例救恨，某航班只有一張機(jī)票贸辈，假定有1w個人打開你的網(wǎng)站來訂票，問你如何解決并發(fā)問題(可擴(kuò)展到任何高并發(fā)網(wǎng)站要考慮**

** 的并發(fā)讀寫問題)**

問題忿薇，1w個人來訪問裙椭，票沒出去前要保證大家都能看到有票，不可能一個人在看到票的時(shí)候別人就不能看了署浩。到底誰能搶到揉燃，那得看這個人的“運(yùn)氣”（網(wǎng)

絡(luò)快慢等）

其次考慮的問題，并發(fā)筋栋，1w個人同時(shí)點(diǎn)擊購買炊汤，到底誰能成交？總共只有一張票弊攘。

首先我們?nèi)菀紫氲胶筒l(fā)相關(guān)的幾個方案：

鎖同步同步更多指的是應(yīng)用程序的層面抢腐，多個線程進(jìn)來，只能一個一個的訪問襟交，java中指的是syncrinized關(guān)鍵字迈倍。鎖也有2個層面，一個是java中談到的對

象鎖捣域，用于線程同步啼染；另外一個層面是數(shù)據(jù)庫的鎖宴合；如果是分布式的系統(tǒng)，顯然只能利用數(shù)據(jù)庫端的鎖來實(shí)現(xiàn)迹鹅。

假定我們采用了同步機(jī)制或者數(shù)據(jù)庫物理鎖機(jī)制卦洽，如何保證1w個人還能同時(shí)看到有票，顯然會犧牲性能斜棚，在高并發(fā)網(wǎng)站中是不可取的阀蒂。使用hibernate后我們

提出了另外一個概念：樂觀鎖、悲觀鎖（即傳統(tǒng)的物理鎖）弟蚀；

采用樂觀鎖即可解決此問題蚤霞。樂觀鎖意思是不鎖定表的情況下，利用業(yè)務(wù)的控制來解決并發(fā)問題粗梭，這樣即保證數(shù)據(jù)的并發(fā)可讀性又保證保存數(shù)據(jù)的排他性争便，保

證性能的同時(shí)解決了并發(fā)帶來的臟數(shù)據(jù)問題。

hibernate中如何實(shí)現(xiàn)樂觀鎖：

前提：在現(xiàn)有表當(dāng)中增加一個冗余字段断医，version版本號, long類型

原理：

1）只有當(dāng)前版本號》=數(shù)據(jù)庫表版本號滞乙，才能提交

2）提交成功后，版本號version ++

實(shí)現(xiàn)很簡單：在ormapping增加一屬性optimistic-lock="version"即可鉴嗤，以下是樣例片段

** 案例二斩启、股票交易系統(tǒng)、銀行系統(tǒng)醉锅，大數(shù)據(jù)量你是如何考慮的**

首先兔簇，股票交易系統(tǒng)的行情表，每幾秒鐘就有一個行情記錄產(chǎn)生硬耍，一天下來就有（假定行情3秒一個） 股票數(shù)量×20×60*6 條記錄垄琐，一月下來這個表記錄數(shù)

量多大？oracle中一張表的記錄數(shù)超過100w后 查詢性能就很差了经柴，如何保證系統(tǒng)性能狸窘？

再比如，中國移動有上億的用戶量坯认，表如何設(shè)計(jì)翻擒？把所有用于存在于一個表么？

所以牛哺，大數(shù)量的系統(tǒng)陋气，必須考慮表拆分-（表名字不一樣，但是結(jié)構(gòu)完全一樣）引润，通用的幾種方式：（視情況而定）

1）按業(yè)務(wù)分巩趁，比如 手機(jī)號的表，我們可以考慮 130開頭的作為一個表淳附，131開頭的另外一張表 以此類推

2）利用oracle的表拆分機(jī)制做分表

3）如果是交易系統(tǒng)晶渠，我們可以考慮按時(shí)間軸拆分凰荚，當(dāng)日數(shù)據(jù)一個表，歷史數(shù)據(jù)弄到其它表褒脯。這里歷史數(shù)據(jù)的報(bào)表和查詢不會影響當(dāng)日交易。

當(dāng)然缆毁，表拆分后我們的應(yīng)用得做相應(yīng)的適配番川。單純的or-mapping也許就得改動了。比如部分業(yè)務(wù)得通過存儲過程等

此外脊框，我們還得考慮緩存

這里的緩存颁督，指的不僅僅是hibernate，hibernate本身提供了一級二級緩存浇雹。這里的緩存獨(dú)立于應(yīng)用沉御，依然是內(nèi)存的讀取，假如我們能減少數(shù)據(jù)庫頻繁的訪

問昭灵，那對系統(tǒng)肯定大大有利的吠裆。比如一個電子商務(wù)系統(tǒng)的商品搜索，如果某個關(guān)鍵字的商品經(jīng)常被搜烂完，那就可以考慮這部分商品列表存放到緩存（內(nèi)存中

去）试疙，這樣不用每次訪問數(shù)據(jù)庫，性能大大增加抠蚣。

簡單的緩存大家可以理解為自己做一個hashmap祝旷，把常訪問的數(shù)據(jù)做一個key，value是第一次從數(shù)據(jù)庫搜索出來的值嘶窄，下次訪問就可以從map里讀取怀跛，而不

讀數(shù)據(jù)庫；專業(yè)些的目前有獨(dú)立的緩存框架比如memcached 等柄冲，可獨(dú)立部署成一個緩存服務(wù)器吻谋。

4、常見的提高高并發(fā)下訪問的效率的手段

首先要了解高并發(fā)的的瓶頸在哪里羊初？

?1滨溉、可能是服務(wù)器網(wǎng)絡(luò)帶寬不夠

?2.可能web線程連接數(shù)不夠

?3.可能數(shù)據(jù)庫連接查詢上不去。

根據(jù)不同的情況长赞，解決思路也不同晦攒。

像第一種情況可以增加網(wǎng)絡(luò)帶寬，DNS域名解析分發(fā)多臺服務(wù)器得哆。

負(fù)載均衡脯颜，前置代理服務(wù)器nginx、apache等等

數(shù)據(jù)庫查詢優(yōu)化贩据，讀寫分離栋操，分表等等

最后復(fù)制一些在高并發(fā)下面需要常常需要處理的內(nèi)容:

盡量使用緩存闸餐，包括用戶緩存，信息緩存等矾芙，多花點(diǎn)內(nèi)存來做緩存舍沙，可以大量減少與數(shù)據(jù)庫的交互，提高性能剔宪。

用jprofiler等工具找出性能瓶頸拂铡，減少額外的開銷。

優(yōu)化數(shù)據(jù)庫查詢語句葱绒，減少直接使用hibernate等工具的直接生成語句（僅耗時(shí)較長的查詢做優(yōu)化）感帅。

優(yōu)化數(shù)據(jù)庫結(jié)構(gòu)，多做索引地淀，提高查詢效率失球。

統(tǒng)計(jì)的功能盡量做緩存，或按每天一統(tǒng)計(jì)或定時(shí)統(tǒng)計(jì)相關(guān)報(bào)表帮毁，避免需要時(shí)進(jìn)行統(tǒng)計(jì)的功能实苞。

能使用靜態(tài)頁面的地方盡量使用，減少容器的解析（盡量將動態(tài)內(nèi)容生成靜態(tài)html來顯示）作箍。

解決以上問題后硬梁，使用服務(wù)器集群來解決單臺的瓶頸問題。