對于我們開發(fā)的網站，如果網站的訪問量非常大的話，那么我們就需要考慮相關的并發(fā)訪問問題了。而并發(fā)問題是絕大部分的程序員頭疼的問題，但話又說回來了，既然逃避不掉，那我們就坦然面對吧~今天就讓我們一起來研究一下常見的并發(fā)和同步吧。 為了更好的理解并發(fā)和同步，我們需要先明白兩個重要的概念:同步和異步 1、同步和異步的區(qū)別和聯(lián)系 所謂同步，可以理解為在執(zhí)行完一個函數或方法之后，一直等待系統(tǒng)返回值或消息，這時程序是出于阻塞的，只有接收到 返回的值或消息后才往下執(zhí)行其它的命令。 異步，執(zhí)行完函數或方法后，不必阻塞性地等待返回值或消息，只需要向系統(tǒng)委托一個異步過程，那么當系統(tǒng)接收到返回 值或消息時，系統(tǒng)會自動觸發(fā)委托的異步過程，從而完成一個完整的流程。 同步在一定程度上可以看做是單線程，這個線程請求一個方法后就待這個方法給他回復，否則他不往下執(zhí)行(死心眼)。 異步在一定程度上可以看做是多線程的(廢話，一個線程怎么叫異步)，請求一個方法后，就不管了，繼續(xù)執(zhí)行其他的方法。同步就是一件事，一件事情一件事的做。異步就是，做一件事情，不引響做其他事情。 例如：吃飯和說話，只能一件事一件事的來，因為只有一張嘴。但吃飯和聽音樂是異步的，因為，聽音樂并不引響我們吃飯。對于Java程序員而言，我們會經常聽到同步關鍵字synchronized，假如這個同步的監(jiān)視對象是類的話，那么如果當一個對象訪問類里面的同步方法的話，那么其它的對象如果想要繼續(xù)訪問類里面的這個同步方法的話，就會進入阻塞，只有等前一個對象執(zhí)行完該同步方法后當前對象才能夠繼續(xù)執(zhí)行該方法。這就是同步。相反，如果方法前沒有同步關鍵字修飾的話，那么不同的對象可以在同一時間訪問同一個方法，這就是異步。 在補充一下(臟數據和不可重復讀的相關概念):臟數據臟讀就是指當一個事務正在訪問數據，并且對數據進行了修改，而這種修改還沒有提交到數據庫中，這時，另外一個事務也訪問這個數據，然后使用了這個數據。因為這個數據是還沒有提交的數據，那么另外一個事務讀到的這個數據是臟數據(Dirty Data)，依據臟數據所做的操作可能是不正確的。不可重復讀不可重復讀是指在一個事務內，多次讀同一數據。在這個事務還沒有結束時，另外一個事務也訪問該同一數據。那么，在第一個事務中的兩次讀數據之間，由于第二個事務的修改，那么第一個事務兩次讀到的數據可能是不一樣的。這樣就發(fā)生了在一個事務內兩次讀到的數據是不一樣的，因此稱為是不可重復讀 2、如何處理并發(fā)和同步今天講的如何處理并發(fā)和同同步問題主要是通過鎖機制。我們需要明白，鎖機制有兩個層面。一種是代碼層次上的，如java中的同步鎖，典型的就是同步關鍵字synchronized，這里我不在做過多的講解，另外一種是數據庫層次上的，比較典型的就是悲觀鎖和樂觀鎖。這里我們重點講解的就是悲觀鎖（傳統(tǒng)的物理鎖）和樂觀鎖。悲觀鎖(Pessimistic Locking): 悲觀鎖，正如其名，它指的是對數據被外界（包括本系統(tǒng)當前的其他事務，以及來自 外部系統(tǒng)的事務處理）修改持保守態(tài)度，因此，在整個數據處理過程中，將數據處于鎖定狀態(tài)。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能 真正保證數據訪問的排他性，否則，即使在本系統(tǒng)中實現了加鎖機制，也無法保證外部系 統(tǒng)不會修改數據）。 一個典型的倚賴數據庫的悲觀鎖調用： select * from account where name=”Erica” for update 這條 sql 語句鎖定了 account 表中所有符合檢索條件（ name=”Erica” ）的記錄。 本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。 Hibernate 的悲觀鎖，也是基于數據庫的鎖機制實現。 下面的代碼實現了對查詢記錄的加鎖： 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í)行查詢，獲取數據 query.setLockMode 對查詢語句中，特定別名所對應的記錄進行加鎖（我們?yōu)?TUser 類指定了一個別名 “user” ），這里也就是對返回的所有 user 記錄進行加鎖。 觀察運行期 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 通過使用數據庫的 for update 子句實現了悲觀鎖機制。 Hibernate 的加鎖模式有： ? LockMode.NONE ： 無鎖機制。 ? LockMode.WRITE ： Hibernate 在 Insert 和 Update 記錄的時候會自動獲取 ? LockMode.READ ： Hibernate 在讀取記錄的時候會自動獲取。 以上這三種鎖機制一般由 Hibernate 內部使用，如 Hibernate 為了保證 Update 過程中對象不會被外界修改，會在 save 方法實現中自動為目標對象加上 WRITE 鎖。 ? LockMode.UPGRADE ：利用數據庫的 for update 子句加鎖。 ? LockMode. UPGRADE_NOWAIT ： Oracle 的特定實現，利用 Oracle 的 for update nowait 子句實現加鎖。 上面這兩種鎖機制是我們在應用層較為常用的，加鎖一般通過以下方法實現： Criteria.setLockMode Query.setLockMode Session.lock 注意，只有在查詢開始之前（也就是 Hiberate 生成 SQL 之前）設定加鎖，才會 真正通過數據庫的鎖機制進行加鎖處理，否則，數據已經通過不包含 for update 子句的 Select SQL 加載進來，所謂數據庫加鎖也就無從談起。 為了更好的理解select... for update的鎖表的過程，本人將要以mysql為例，進行相應的講解 1、要測試鎖定的狀況，可以利用MySQL的Command Mode ，開二個視窗來做測試。 表的基本結構如下:

表中內容如下:

開啟兩個測試窗口，在其中一個窗口執(zhí)行select * from ta for update0 然后在另外一個窗口執(zhí)行update操作如下圖:

等到一個窗口commit后的圖片如下:

到這里，悲觀鎖機制你應該了解一些了吧~ 需要注意的是for update要放到mysql的事務中，即begin和commit中，否者不起作用。 至于是鎖住整個表還是鎖住選中的行至于hibernate中的悲觀鎖使用起來比較簡單，這里就不寫demo了~感興趣的自己查一下就ok了~ 樂觀鎖(Optimistic Locking): 相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數情況下依 靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫 性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。 如一個金融系統(tǒng)，當某個操作員讀取用戶的數據，并在讀出的用戶數據的基礎上進 行修改時（如更改用戶帳戶余額），如果采用悲觀鎖機制，也就意味著整個操作過 程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作 員中途去煮咖啡的時間），數據庫記錄始終處于加鎖狀態(tài)，可以想見，如果面對幾 百上千個并發(fā)，這樣的情況將導致怎樣的后果。 樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基于數據版本 Version ）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基于數據庫表的版本解決方案中，一般是通過為數據庫表增加一個 “version” 字段來 實現。 讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提 交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據 版本號大于數據庫表當前版本號，則予以更新，否則認為是過期數據。 對于上面修改用戶帳戶信息的例子而言，假設數據庫中帳戶信息表中有一個 version 字段，當前值為 1 ；而當前帳戶余額字段（ balance ）為 $100 。 操作員 A 此時將其讀出（ version=1 ），并從其帳戶余額中扣除 $50（ $100-$50 ）。 2 在操作員 A 操作的過程中，操作員 B 也讀入此用戶信息（ version=1 ），并 從其帳戶余額中扣除 $20 （ $100-$20 ）。 3 操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣 除后余額（ balance=$50 ），提交至數據庫更新，此時由于提交數據版本大 于數據庫記錄當前版本，數據被更新，數據庫記錄 version 更新為 2 。 4 操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向數據庫提交數 據（ balance=$80 ），但此時比對數據庫記錄版本時發(fā)現，操作員 B 提交的 數據版本號為 2 ，數據庫記錄當前版本也為 2 ，不滿足 “ 提交版本必須大于記 錄當前版本才能執(zhí)行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基于 version=1 的舊數據修改的結果覆蓋操作 員 A 的操作結果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務中的數據庫加鎖開銷（操作員 A 和操作員 B 操作過程中，都沒有對數據庫數據加鎖），大大提升了大并發(fā)量下的系 統(tǒng)整體性能表現。 需要注意的是，樂觀鎖機制往往基于系統(tǒng)中的數據存儲邏輯，因此也具備一定的局 限性，如在上例中，由于樂觀鎖機制是在我們的系統(tǒng)中實現，來自外部系統(tǒng)的用戶 余額更新操作不受我們系統(tǒng)的控制，因此可能會造成臟數據被更新到數據庫中。在 系統(tǒng)設計階段，我們應該充分考慮到這些情況出現的可能性，并進行相應調整（如 將樂觀鎖策略在數據庫存儲過程中實現，對外只開放基于此存儲過程的數據更新途 徑，而不是將數據庫表直接對外公開）。 Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。如果不用考慮外部系統(tǒng)對數 據庫的更新操作，利用 Hibernate 提供的透明化樂觀鎖實現，將大大提升我們的 生產力。Hibernate 中可以通過 class 描述符的 optimistic-lock 屬性結合 version描述符指定。 現在，我們?yōu)橹笆纠械?User 加上樂觀鎖機制。 1 ． 首先為 User 的POJO classpackage com.xiaohao.test; public class User { private Integer id; private String userName; private String password; private int version; public int getVersion() { return version;}public void setVersion(int version) { this.version = version;}public Integer getId() { return id;} public void setId(Integer id) { this.id = id;}public String getUserName() { return userName;}public void setUserName(String userName) { this.userName = userName;}public String getPassword() { return password;}public void setPassword(String password) { this.password = password;}public User() {} public User(String userName, String password) { super(); this.userName = userName; this.password = password;}} 然后是User.hbm.xml<?xml version="1.0"?><!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="com.xiaohao.test"> <class name="User" table="user" optimistic-lock="version" > <id name="id"> <generator class="native" /> </id> <!--version標簽必須跟在id標簽后面--> <version column="version" name="version" /> <property name="userName"/> <property name="password"/> </class> </hibernate-mapping>注意 version 節(jié)點必須出現在 ID 節(jié)點之后。 這里我們聲明了一個 version 屬性，用于存放用戶的版本信息，保存在 User 表的version中 optimistic-lock 屬性有如下可選取值： ? none無樂觀鎖 ? version通過版本機制實現樂觀鎖 ? dirty通過檢查發(fā)生變動過的屬性實現樂觀鎖 ? all通過檢查所有屬性實現樂觀鎖 其中通過 version 實現的樂觀鎖機制是 Hibernate 官方推薦的樂觀鎖實現，同時也 是 Hibernate 中，目前唯一在數據對象脫離 Session 發(fā)生修改的情況下依然有效的鎖機 制。因此，一般情況下，我們都選擇 version 方式作為 Hibernate 樂觀鎖實現機制。 2 ． 配置文件hibernate.cfg.xml和UserTest測試類 hibernate.cfg.xml<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"><hibernate-configuration><session-factory> <!-- 指定數據庫方言 如果使用jbpm的話，數據庫方言只能是InnoDB--> <property name="dialect">org.hibernate.dialect.MySQL5InnoDBDialect</property> <!-- 根據需要自動創(chuàng)建數據表 --> <property name="hbm2ddl.auto">update</property> <!-- 顯示Hibernate持久化操作所生成的SQL --> <property name="show_sql">true</property> <!-- 將SQL腳本進行格式化后再輸出 --> <property name="format_sql">false</property> <property name="current_session_context_class">thread</property> <!-- 導入映射配置 --> <property name="connection.url">jdbc:mysql:///user</property> <property name="connection.username">root</property> <property name="connection.password">123456</property> <property name="connection.driver_class">com.mysql.jdbc.Driver</property> <mapping resource="com/xiaohao/test/User.hbm.xml" /></session-factory></hibernate-configuration>UserTest.javapackage com.xiaohao.test;import org.hibernate.Session;import org.hibernate.SessionFactory;import org.hibernate.Transaction;import org.hibernate.cfg.Configuration; public class UserTest { public static void main(String[] args) { Configuration conf=new Configuration().configure(); SessionFactory sf=conf.buildSessionFactory(); Session session=sf.getCurrentSession(); Transaction tx=session.beginTransaction();// User user=new User("小浩","英雄");// session.save(user);// session.createSQLQuery("insert into user(userName,password) value('張英雄16','123')")// .executeUpdate(); User user=(User) session.get(User.class, 1); user.setUserName("221");// session.save(user); System.out.println("恭喜您，用戶的數據插入成功了哦~~"); tx.commit(); } }每次對 TUser 進行更新的時候，我們可以發(fā)現，數據庫中的 version 都在遞增。下面我們將要通過樂觀鎖來實現一下并發(fā)和同步的測試用例:這里需要使用兩個測試類，分別運行在不同的虛擬機上面，以此來模擬多個用戶同時操作一張表,同時其中一個測試類需要模擬長事務UserTest.javapackage com.xiaohao.test;package com.xiaohao.test; import org.hibernate.Session;import org.hibernate.SessionFactory;import org.hibernate.Transaction;import org.hibernate.cfg.Configuration; public class UserTest { public static void main(String[] args) { Configuration conf=new Configuration().configure(); SessionFactory sf=conf.buildSessionFactory(); Session session=sf.openSession();// Session session2=sf.openSession(); User user=(User) session.createQuery(" from User user where user=5").uniqueResult();// User user2=(User) session.createQuery(" from User user where user=5").uniqueResult(); System.out.println(user.getVersion());// System.out.println(user2.getVersion()); Transaction tx=session.beginTransaction(); user.setUserName("101"); tx.commit(); System.out.println(user.getVersion());// System.out.println(user2.getVersion());// System.out.println(user.getVersion import org.hibernate.Session;import org.hibernate.SessionFactory;import org.hibernate.Transaction;import org.hibernate.cfg.Configuration; public class UserTest { public static void main(String[] args) { Configuration conf=new Configuration().configure(); SessionFactory sf=conf.buildSessionFactory(); Session session=sf.openSession();// Session session2=sf.openSession(); User user=(User) session.createQuery(" from User user where user=5").uniqueResult();// User user2=(User) session.createQuery(" from User user where user=5").uniqueResult(); System.out.println(user.getVersion());// System.out.println(user2.getVersion()); Transaction tx=session.beginTransaction(); user.setUserName("101"); tx.commit(); System.out.println(user.getVersion());// System.out.println(user2.getVersion());// System.out.println(user.getVersion()==user2.getVersion());// Transaction tx2=session2.beginTransaction();// user2.setUserName("4468");// tx2.commit(); } }

　UserTest2.java

package com.xiaohao.test; import org.hibernate.Session;import org.hibernate.SessionFactory;import org.hibernate.Transaction;import org.hibernate.cfg.Configuration; public class UserTest2 { public static void main(String[] args) throws InterruptedException { Configuration conf=new Configuration().configure(); SessionFactory sf=conf.buildSessionFactory(); Session session=sf.openSession();// Session session2=sf.openSession(); User user=(User) session.createQuery(" from User user where user=5").uniqueResult(); Thread.sleep(10000);// User user2=(User) session.createQuery(" from User user where user=5").uniqueResult(); System.out.println(user.getVersion());// System.out.println(user2.getVersion()); Transaction tx=session.beginTransaction(); user.setUserName("100"); tx.commit(); System.out.println(user.getVersion());// System.out.println(user2.getVersion());// System.out.println(user.getVersion()==user2.getVersion());// Transaction tx2=session2.beginTransaction();// user2.setUserName("4468");// tx2.commit(); } }

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

啟動UserTest這個類，在到達10秒的時候，我們將會在UserTest.java中拋出下面的異常:

Exception in thread "main" org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xiaohao.test.User#5] at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1932) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2576) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2476) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2803) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:113) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:185) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133) at com.xiaohao.test.UserTest2.main(UserTest2.java:21)

UserTest2代碼將在 tx.commit() 處拋出 StaleObjectStateException 異 常，并指出版本檢查失敗，當前事務正在試圖提交一個過期數據。通過捕捉這個異常，我 們就可以在樂觀鎖校驗失敗時進行相應處理

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

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

問題，1w個人來訪問，票沒出去前要保證大家都能看到有票，不可能一個人在看到票的時候別人就不能看了。到底誰能搶到，那得看這個人的“運氣”（網絡快慢等）

其次考慮的問題，并發(fā)，1w個人同時點擊購買，到底誰能成交？總共只有一張票。

首先我們容易想到和并發(fā)相關的幾個方案 ：

鎖同步同步更多指的是應用程序的層面，多個線程進來，只能一個一個的訪問，java中指的是syncrinized關鍵字。鎖也有2個層面，一個是java中談到的對

象鎖，用于線程同步；另外一個層面是數據庫的鎖；如果是分布式的系統(tǒng)，顯然只能利用數據庫端的鎖來實現。

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

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

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

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

hibernate中如何實現樂觀鎖：

前提：在現有表當中增加一個冗余字段，version版本號, long類型

原理：

1）只有當前版本號》=數據庫表版本號，才能提交

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

實現很簡單：在ormapping增加一屬性optimistic-lock="version"即可，以下是樣例片段

<hibernate-mapping>

<class name="com.insigma.stock.ABC" optimistic-lock="version" table="T_Stock" schema="STOCK">

案例二、股票交易系統(tǒng)、銀行系統(tǒng)，大數據量你是如何考慮的

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

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

再比如，中國移動有上億的用戶量，表如何設計？把所有用于存在于一個表么？

所以，大數量的系統(tǒng)，必須考慮表拆分-（表名字不一樣，但是結構完全一樣），通用的幾種方式：（視情況而定）

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

2）利用oracle的表拆分機制做分表

3）如果是交易系統(tǒng)，我們可以考慮按時間軸拆分，當日數據一個表，歷史數據弄到其它表。這里歷史數據的報表和查詢不會影響當日交易。

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

此外，我們還得考慮緩存

這里的緩存，指的不僅僅是hibernate，hibernate本身提供了一級二級緩存。這里的緩存獨立于應用，依然是內存的讀取，假如我們能減少數據庫頻繁的訪

問，那對系統(tǒng)肯定大大有利的。比如一個電子商務系統(tǒng)的商品搜索，如果某個關鍵字的商品經常被搜，那就可以考慮這部分商品列表存放到緩存（內存中

去），這樣不用每次訪問數據庫，性能大大增加。

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

讀數據庫；專業(yè)些的目前有獨立的緩存框架比如memcached 等，可獨立部署成一個緩存服務器。

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

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

1、可能是服務器網絡帶寬不夠

2.可能web線程連接數不夠

3.可能數據庫連接查詢上不去。

根據不同的情況，解決思路也不同。

像第一種情況可以增加網絡帶寬，DNS域名解析分發(fā)多臺服務器。負載均衡，前置代理服務器nginx、apache等等數據庫查詢優(yōu)化，讀寫分離，分表等等

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

盡量使用緩存，包括用戶緩存，信息緩存等，多花點內存來做緩存，可以大量減少與數據庫的交互，提高性能。用jprofiler等工具找出性能瓶頸，減少額外的開銷。優(yōu)化數據庫查詢語句，減少直接使用hibernate等工具的直接生成語句（僅耗時較長的查詢做優(yōu)化）。優(yōu)化數據庫結構，多做索引，提高查詢效率。統(tǒng)計的功能盡量做緩存，或按每天一統(tǒng)計或定時統(tǒng)計相關報表，避免需要時進行統(tǒng)計的功能。能使用靜態(tài)頁面的地方盡量使用，減少容器的解析（盡量將動態(tài)內容生成靜態(tài)html來顯示）。解決以上問題后，使用服務器集群來解決單臺的瓶頸問題。Java進階高并發(fā)面試資料后臺私信我666即可獲取。