java 併發基礎，及案例分析

時間 2019-11-12

標籤 java 併發基礎案例分析欄目 Java 简体版

原文原文鏈接

對於咱們開發的網站，若是網站的訪問量很是大的話，那麼咱們就須要考慮相關的併發訪問問題了，然而併發問題是令咱們大多數程序員頭疼的問題，但話又說回來了，既然逃避不掉，那咱們就坦然面對吧~今天就讓咱們深刻研究一下常見的併發和同步問題吧。html

1、同步和異步的區別和聯繫java

　　　　爲了更好的理解同步和併發的問題，咱們須要先掌握兩個重要的概念：同步、異步mysql

　　　　同步：能夠理解爲在執行完一個函數或者方法後，一直等待系統返回值或消息，這時程序是處於阻塞的狀態，只有接收到系統的返回值或者消息後，纔會繼續往下執行。程序員

　　　　異步：執行完函數或方法後，沒必要阻塞性的等待返回值或消息，只須要向系統委託一個異步過程，那麼系統接收到返回值或消息時，就會自動觸發委託的異步過程，從而完成一個完整的流程。web

　　　　同步在必定程度上能夠看作是單線程，這個線程請求一個方法後，就等待這個方法給他回覆，不然不往下執行（死心眼子）。redis

　　　　異步在必定程度上能夠看作是多線程（廢話，一個線程怎麼叫異步），請求一個方法後就無論了，繼續執行接下來的其餘方法。sql

　　　　同步就一件事、一件事、一件事的作。數據庫

　　　　異步就是作一件事情，不影響作其餘的事情。json

　　　　例如：吃飯和說話是同步的，只能一件事一件事的來，由於只有一張嘴。吃飯和聽音樂是異步的，聽音樂不影響咱們吃飯。緩存

　　對於java程序員來講，咱們常常見到同步關鍵字 synchronized，假如這個同步的監視對象是一個類，當一個對象A在訪問這個類裏面的同步方法，此時另一個對象B也想訪問這個類裏面的這個同步方法，就會進入阻塞，只有等待前一個對象執行完該同步方法後當前對象纔可以繼續執行該方法；這就是同步。

　　相反，若是方法前沒有同步關鍵字修飾的話，那麼不一樣的對象就能夠在同一時間訪問同一個方法，這就是異步。

　　再補充一下，髒數據和不可重複讀的概念：

　　一、髒數據

　　　　髒讀是指：一個事務正在訪問數據，而且對數據進行了修改，而這個修改還有提交到數據庫中，這時另一個事務也訪問這個數據，而後使用了這個數據。由於這個數據是尚未提交的數據，那麼另一個事務讀到的數據是髒數據（Dirty Data），髒數據所作的操做多是不正確的。

　　二、不可重複讀

　　　　不可重複讀是指：在一個事務內，屢次讀同一條數據。這個事務尚未結束時，另一個事務也訪問了該數據，那麼，在第一個事務中兩次讀數據之間，因爲第二個事務的修改，致使第一個事務兩次讀到數據可能不同。這樣就發生了在同一個事務內，兩次讀到的數據是不同的，所以稱爲不可重複讀。

2、如何處理併發和同步

　　今天講的如何處理併發和同步問題主要是經過鎖機制去解決。咱們須要明白鎖機制有兩個層面：

　　第一是代碼層面，如java中的同步鎖，典型的就是同步關鍵字synchronize（還有Lock等）。感興趣的能夠參考: http://www.cnblogs.com/xiohao/p/4151408.html

　　第二是數據庫層面上，比較典型的就是悲觀鎖和樂觀鎖，這裏重點研究一下悲觀鎖（傳統的物理鎖）和樂觀鎖，這兩個鎖：

悲觀鎖（Pessimistic Locking）

　　　　悲觀鎖正如其名，它指的是對數據被外界（包括本系統當前的其餘事務，以及外部系統的事務）的修改持保守狀態，所以，在整個數據處理過程當中，將數據處於鎖定狀態。

　　　　悲觀鎖的實現，通常是依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，不然即便在本系統中實現了加鎖機制，也沒法保證外部系統會修改數據）。

　　　　一個典型的依賴數據庫悲觀鎖調用：select * from account where name='zhangsan' for update;

　　　　整條sql鎖定了account表中全部符合檢索條件（name='zhangsan'）的記錄；本次事務提交以前（事務提交會釋放事務過程當中的鎖），外界沒法修改這些記錄。

hibernate的悲觀鎖，也是基於數據庫的鎖機制實現的，下面代碼實現了對查詢記錄的加鎖：

1 String hqlStr ="from TUser as user where user.name='zhangsan' ";
2 Query query = session.createQuery(hqlStr);
3 query.setLockMode("user",LockMode.UPGRADE); // 加鎖
4 List userList = query.list();// 執行查詢，獲取數

query.setLocalMode 對查詢語句中特定別名所對應的記錄進行加鎖（咱們對TUser類制定了一個別名「user」），這也就是對多有返回的記錄加鎖。

觀察容許其的hibernate，生成的sql語句：這裏hibernate經過使用數據庫的 for update 子句實現了悲觀鎖機制

1 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的加鎖機制有：

　　　　　　一、LockMode.NONE：無鎖機制

　　　　　　二、LockMode.WRITE：hibernate 在 insert 和 update 的時候記錄會自動獲取

　　　　　　三、LockMode.READ：hibernate在讀取記錄的時候會自動獲取

　　　　以上這三種鎖機制通常由heibernate內部使用，如hibernate爲保證 update 過程當中對象不會被外界修改，會在 save 方法實現中自動爲目標對象加上 WRITE 鎖。

　　　　　　四、LockMode.UPGRADE：利用數據的 for update 子句加鎖

　　　　　　五、LockMode.UPGRADE_NOWAIT：Oracle 的特定實現，利用 Oracle 的 for update nowait 子句實現加鎖

　　　　上面這兩種鎖機制是咱們應用層較爲經常使用的，加鎖通常經過：Criteria.setLockMode；Query.setLockMode；Session.lock；方法實現。

　　　　須要注意點的是：只有在查詢開始以前（也就是hibernate生成sql以前）設置加鎖，纔會真正經過數據的鎖機制進行加鎖處理，不然，數據已經過不包含 for update 子句的 select sql 加載進來，所謂數據的加鎖也就無從談起。

　　　　爲了更好的理解 select... for update 的鎖表過程，咱們以 mysql 爲例，進行研究

　　　　要測試鎖定的狀態，可利用 mysql 的 Command Mode，開兩個視窗來測試：

表的基本結構以下：

表中內容以下：

開啓兩個測試窗口，在其中一個窗口執行 select * from ta for update;

而後再另一個窗口執行 update 操做：

等到第一個窗口 commit 後：

至此，悲觀鎖的機制，有一些感受了吧，

　　　　須要注意的是 for update 要放到 mysql 的事務中，即 begin 和 commit 之間，不然不起做用。

　　　　至於鎖住整張表仍是鎖住選中的行，請參考：http://www.cnblogs.com/xiohao/p/4385768.html

　　二、樂觀鎖（Optimistic Locking）：

　　　　相對悲觀鎖而言，樂觀鎖機制採起了更加寬鬆的加鎖機制。悲觀鎖大多數狀況下依靠數據庫的鎖機制實現，以保證操做最大程度的獨佔性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事物而言，這樣的開銷是沒法承受的。

　　　　如一個金融系統當一個操做員讀取用戶數，並在讀出的數據上進行修改操做（如更改用戶帳戶餘額），若是採用悲觀鎖機制，也就意味着整個操做過程當中（從讀出數據，修改數據，直到提交數據，甚至還包括操做員中途去煮咖啡的時間），數據庫的記錄始終處於加鎖狀態，能夠想到，若是面對成百上千個併發，這種狀況會致使什麼樣的後果。樂觀鎖的機制在必定程度上解決了這個問題。

　　　　樂觀鎖，大可能是基於數據版本（version）記錄機制實現。數據版本：即爲在數據庫增長一個版本標識。在基於數據庫表的版本解決方案中，通常是經過在數據庫表中增長一個 version 字段來實現。讀取數據的時候將此版本號一塊兒讀出，以後更新時候將此版本號加一。此時，將提交數據的版本信息與數據庫表對應記錄的當前本版信息進行對比，若是提交數據的當前本版號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。對於上面修改用戶信息的例子而言，假設數據庫帳戶信息表中有一個 version 字段，當前值爲1，當前帳戶餘額字段 balance 爲 100；此時操做員A將此數據讀出，並從帳戶餘額扣除 50。在操做員 A 操做過程當中，操做員 B 也讀去了該用戶的信息，並從帳戶餘額中扣除 20。這是操做員 A 完成了修改工做，將數據版本信息加一（version = 2），和帳戶扣除後的餘額（balance = 50），提交到數據庫更新，此時因爲提交數據版本大於數據庫記錄的版本號，數據記錄被更新 version 更新爲 2。接着，操做員 B 完成了操做，也將版本號加一（version = 2），試圖提交數據（balance = 80），但此時對比數據庫記錄版本時候發現，數據庫當前本版也爲2，不知足「數據版本必須大於記錄當前版本才能執行更新」的樂觀鎖策略，所以操做員 B 的提交被駁回。這樣就避免了操做員 B 使用基於 vsersion=1 的舊數據修改的結果覆蓋了操做員 A 的操做結果。從例子能夠看出，樂觀鎖的機制避免了長事務中數據庫加鎖數據庫開銷（操做員A和操做員B操做過程當中都沒有對數據庫數據加鎖），大大提高了大併發下系統總體性能的表現，來自外部系統的用戶餘額更新操做不受咱們系統的控制，所以可能會形成在髒數據被更新到數據中，在系統設計階段，咱們應該充分考慮到發送這些狀況的可能性，並進行相應的調整（如將樂觀鎖策略在數據庫存儲過程當中實現，對外只開放基於此存儲過程的數據更新途徑，而不是直接將數據庫表直接對外公開）。

　　　　Hibernate在其數據訪問引擎中內置了樂觀鎖的實現。若是不考慮外部系統對數據庫的更新操做，利用Hibernate 提供的透明化樂觀鎖實現，將大大提高咱們的生產力。

User.hbm.xml ：注意 version 節點必須出如今 ID 節點以後。

 1 <?xml version="1.0"?>
 2 <!DOCTYPE hibernate-mapping PUBLIC
 3         "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
 4         "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
 5  
 6 <hibernate-mapping package="com.ayht.test">
 7     <class name="User"  table="user" optimistic-lock="version" >
 8         <id name="id">
 9             <generator class="native" />
10         </id>
11         <!--version標籤必須跟在id標籤後面-->
12         <version column="version" name="version"  />
13         <property name="userName"/>
14         <property name="password"/>    
15     </class> 
16 </hibernate-mapping>

這裏咱們申明瞭一個 version 屬性，用於存放用戶的版本信息，保存在User表的 version 中，optimistic-lock 屬性有以下取值：

　　none ：無樂觀鎖

　　version ：經過版本機制實現樂觀鎖

　　dirty ：經過檢查發送變更的屬性實現樂觀鎖

　　all ：經過檢查全部屬性實現樂觀鎖

其中經過 version 實現樂觀鎖機制是 Hibernate 官方推薦的樂觀鎖實現，同時也是 Hibernate 中，目前惟一在數據對象脫離Session 發生修改的狀況下依然有效的鎖機制。所以通常狀況下咱們都選擇 version 的方式做爲 Hibernate 的樂觀鎖實現機制。

hibernate.cfg.xml

 1 <!DOCTYPE hibernate-configuration PUBLIC
 2         "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
 3         "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
 4  
 5 <hibernate-configuration>
 6     <session-factory>
 7         <!-- 指定數據庫方言 若是使用jbpm的話，數據庫方言只能是InnoDB-->
 8         <property name="dialect">org.hibernate.dialect.MySQL5InnoDBDialect</property>
 9         <!-- 根據須要自動建立數據表 -->
10         <property name="hbm2ddl.auto">update</property>
11         <!-- 顯示Hibernate持久化操做所生成的SQL -->
12         <property name="show_sql">true</property>
13         <!-- 將SQL腳本進行格式化後再輸出 -->
14         <property name="format_sql">false</property>
15         <property name="current_session_context_class">thread</property>
16      
17         <!-- 導入映射配置 -->
18         <property name="connection.url">jdbc:mysql:///user</property>
19         <property name="connection.username">root</property>
20         <property name="connection.password">123456</property>
21         <property name="connection.driver_class">com.mysql.jdbc.Driver</property>
22         <mapping resource="com/xiaohao/test/User.hbm.xml" />
23     </session-factory>
24 </hibernate-configuration>

UserTest.java：每次對 TUser 更新的時候，咱們會發現，數據庫的 version 都在遞增。

 1 package com.xiaohao.test;
 2  
 3 import org.hibernate.Session;
 4 import org.hibernate.SessionFactory;
 5 import org.hibernate.Transaction;
 6 import org.hibernate.cfg.Configuration;
 7  
 8 public class UserTest {
 9     public static void main(String[] args) {
10         Configuration conf=new Configuration().configure();
11         SessionFactory sf=conf.buildSessionFactory();
12         Session session=sf.getCurrentSession();
13         Transaction tx=session.beginTransaction();
14 //      User user=new User("小浩","英雄");
15 //      session.save(user);
16 //      session.createSQLQuery("insert into user(userName,password) value('張英雄16','123')").executeUpdate();
17         User user=(User) session.get(User.class, 1);
18         user.setUserName("221");
19 //      session.save(user);
20      
21         System.out.println("恭喜您，用戶的數據插入成功了哦~~");
22         tx.commit();
23     }
24 }

如下咱們將要經過樂觀鎖來實現一下併發和同步的測試用例：咱們準備兩個測試類，分別運行在不一樣的虛擬機上，以此來模擬多個用戶同時操做同一張表，同事一個測試類要模擬一個長事務。

UserTest.java

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()==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 測試類，在執行到 Thread.sleep(10000); 這裏的時候，當前線程會進入到休眠狀態。在10秒內啓動 UserTest.java 類，在到達10秒的時候，UserTest.java 將會拋出下面的異常：

 1 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]
 2     at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1932)
 3     at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2576)
 4     at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2476)
 5     at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2803)
 6     at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:113)
 7     at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
 8     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
 9     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:185)
10     at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
11     at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
12     at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
13     at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383)
14     at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133)
15     at com.xiaohao.test.UserTest2.main(UserTest2.java:21)

UserTest.java 將在 tx.commit(); 處拋出：StaleObjectStateException 異常，並指出版本檢查失敗，當前事務正在準備提交一個過時數據，經過捕捉這個異常，咱們能夠在樂觀鎖效驗失敗時候進行相應的處理。

3、常見併發同步案例分析：

　　案例一：訂票系統案例：某航班只有一張機票，假定有1W我的打開你的網站來訂票，問你如何解決併發問題（可擴展到任何高併發網站要考慮到的併發讀寫問題）

　　問題1：1W我的來訪問，票沒訂出去前要保證你們都能看到有票，不可能一我的在看到票的時候別人就不能看了。

　　問題2：併發1W我的同時點擊購買，總共只有一張票，到底誰能買到。

　　首先咱們容易想到和併發相關的幾個方案：

　　鎖同步更多指的是應用程序層面，多線程進來，只能一個一個的訪問，java 中使用的是 synchronized 關鍵字。鎖也有兩個層面，一個是 java 中談到的對象鎖，用於線程同步；另一個層面是數據庫鎖；若是是分佈式的系統，顯然只能利用數據庫的鎖來實現。

　　假定咱們採用了同步機制或者數據庫物理機制，如何保證1W我的還能同時看到有票，顯然會犧牲性能，在高併發網站中不可取。使用 Hibernate 以後咱們提出了另一個概念：樂觀鎖、悲觀鎖（傳統的物理鎖）。

　　採用樂觀鎖便可解決此問題，樂觀鎖的意思是在不鎖定表的狀況下，利用業務的控制來解決併發問題，這樣既保證數據的併發可讀性、又保證保存數據的排他性。保證性能的同時，解決了併發帶來髒數據的問題。

　　Hibernate 中實現樂觀鎖的方法：

　　注意：在現有表中增長一個冗餘字段，version 版本號，long 類型

　　原理：一、只有當前版本號 >= 數據庫表版本號，才能提交

　　　　　二、提交成功後版本號 version++

　　實現很簡單：在 or-mapping 增長一個屬性 optimistic-lock="version" 便可。一下是樣例片斷：

1 <hibernate-mapping>
2 
3 <class name="com.xiaohao.abc.ABC" optimistic-lock="version" table="T_Stock" schema="STOCK">

　　案例二：股票交易系統、銀行系統，大數據量如何考慮？

　　首先股票交易系統的行情表，每幾秒鐘就有一個行情記錄產生，假定行情3秒一條，一天下來就有股票數量 * 20 * 60 * 6 條記錄，一個月下來這個表數量有多大？數據庫中表的記錄數超過100W後，查詢性能就不好了，如何保證系統性能？

　　再好比：中國移動有上億的用戶量，全部用戶都存在一張表嗎？表如何設計？因此大數據量的系統，必須考慮表拆分（表名不同，表結構徹底同樣），通用的幾種方式：

　　一、按業務拆分，好比手機號的表，能夠考慮130開頭的號碼存在一張表，131開頭的再存一張表，以此類推。

　　二、利用 oracle 的表拆分機制作分表

　　三、若是是交易系統，能夠考慮按時間軸拆分，當日數據一個表，歷史數據保存到其餘表。這裏的歷史數據的報表和查詢不會影響當日交易

　　固然、表拆分後咱們應用程序非作相應的適配，單純的 or-mapping 就得要改動了，好比業務部分得經過存儲過程等。

　　此外、咱們還要考慮緩存，這個緩存不只僅指的是 Hibernate 提供的1、二級緩存。這個緩存獨立於應用，依然是內存的讀取，假如咱們能減小數據庫的頻繁訪問，那對系統性能確定大大有利。好比電子商務系統的商品搜索，若是某個關鍵字的商品常常被搜索，那就能夠考慮把這部分的商品列表存放到緩存中（內存中），這樣不用每次訪問數據庫，使系統性能大大增長。

　　簡單的緩存能夠理解爲一個 hashMap，把常常訪問的數據做爲一個key，value是第一次從數據庫查出的數據，下次訪問就能夠從map中取值，而不讀取數據庫。目前可使用memcached，redis，等。可獨立部署成一個緩存服務器。

　　案例三：搶購秒殺業務的解決方案：

　　以前咱們將高併發解決方案誤認爲能夠用線程或者隊列解決，由於高併發的時候有不少用戶在訪問，致使出現系統數據不正確，丟失數據現象。因此想到的是用隊列解決。

　　其實隊列解決的方式也能夠處理，好比咱們再競拍商品、轉發評論微博、秒殺商品等，同一時間訪問量特別大，隊列再次起到特別的做用，將全部請求放入隊列，以毫秒爲計時單位，有序的進行，從而不回初選數據丟失系統不正確的狀況。

4、常見的高併發下提升訪問效率的方法：

　　首先了解高併發的瓶頸在哪裏

　　一、多是服務器網絡帶寬不夠：能夠增長網路帶寬，DNS域名解析分發多臺服務器。

　　二、多是web線程鏈接數不夠：負載均衡，前置代理服務器 negix、Apache 等等。

　　三、多是數據庫鏈接查詢上不去：數據庫查詢優化、讀寫分離，分表等等。

　　如下列出一些在高併發下常常須要處理的內容：

　　一、儘可能使用緩存，包括用戶信息緩存，經常使用信息緩存，多花點內存來作緩存，能夠大量減小與數據庫的交互，提升性能。

　　二、用 jprofile 等工具找出性能瓶頸，減小額外的開銷。

　　三、優化數據庫庫查詢語句，減小直接使用 Hibernate 等工具生成查詢語句（只針對耗時長的語句作優化）。

　　四、數據庫結構，使用索引，提升查詢效率。

　　五、統計的功能儘可能做緩存，或按天天一統計或者定時統計相關報表，避免須要時進行統計的功能。

　　六、能使用靜態頁面的地方儘可能使用靜態頁面，減小容器的解析（儘可能將動態的內容生成 html 來顯示）。

　　七、解決以上問題以後，儘可能使用服務器集羣來解決單臺服務器的瓶頸。　

　　高併發的解決方案有以下兩種：

　　第一：使用緩存；第二：生成靜態頁面；

　　還有就是從最基礎的地方優化咱們寫的代碼，減小沒必要要的資源浪費：

　　一、不要頻繁 new 對象；對於在整個應用中只須要存在一個實例的類，使用單例模式；對於 String 的拼接操做，使用 StringBuffer 或者 StringBuilder；對於 utility 類型的類經過靜態方法來訪問。

　　二、避免使用錯誤的方式退出，如 Exception 能夠控制方法退出，可是 Exception 要保留 stacktrace 消耗性能；除非必要，不要使用 instanceOf 作條件判斷，儘可能使用比的方式作判斷；使用 java 中效率高的類，例如 ArrayList 比 Vector 性能好。

　　使用緩存好比 redis ，在應用啓動期間先把用戶數據封裝爲 json 格式的字符串，以 hash（哈希）類型加載到 redis 內存中。訪問的時候就能夠直接從 redis 中獲取到用戶信息，redis的性能不用質疑是很是好用的，這裏就不在多說了。這樣就大大減小了訪問數據庫的頻次，從而提高系統性能。

　　生成靜態頁面我想你們應該不陌生，咱們見過不少網站在請求的時候頁面地址後綴已經改變了，如：https://www.cnblogs.com/xxx/p/8026575.html，該頁面實際上是一個服務器請求地址，再轉換成 html 以後，訪問速度將提高，由於靜態頁面將不帶有服務器組件。請看如下介紹：

　　一、什麼是生成靜態頁面

　　　　簡單的說，若是咱們訪問一個鏈接，服務器對應的模塊會處理這個請求，轉到對應的 jsp 頁面，最後生成咱們想要看到的數據。這其中的缺點是顯而易見的，由於每次請求服務器都會處理，若是有太多高併發處理，那麼就會加劇服務器的壓力，弄很差就把服務器 down 掉了。那麼如何去避免呢，若是咱們吧 test.do 請求後的結果保存成一個 html 文件，每次用戶去訪問，會自動生成 test.html 而後顯示給用戶。

　　二、下面簡單介紹一下頁面靜態化的知識點：

　　　　一、基礎：URL Rewirte

　　　　URL 重寫：簡單的說：輸入網址，但實際上訪問的是：abc.com/test.action 那麼我就能夠說 URL重寫了。這項技術應用普遍，有許多開源工具能夠實現這個功能。

　　　　二、基礎：Servlet web.xml

　　　　若是你還不知道 web.xml 中一個請求和 servlet 是如何匹配到一塊兒的，那麼請搜索一下 servlet 文檔。這可不是亂說呀，有不少人認爲 /zxy/*.do 這樣的匹配方式能有效。

　　三、基本方案介紹：

　　　　請求 index -> URL Rewriter -> 請求 index.action -> 處理 .action 的 servlet -> 若是靜態頁面存在直接返回，不然請求 index.do 到 Struts servlet -> 生成靜態頁面返回。

　　　　其中，對於 URL 重寫的部分，可使用開源的工具來實現，若是 URL 不是特別複雜，能夠考慮在 servlet 中實現，那麼就是下面這個樣子：

　　　　總結：其實在開發中咱們不多考慮這種問題，直接都是現將功能實現，當一個程序員幹了 1 - 2 年的時候，就會感受光實現功能不是最主要的，安全性能，可靠性，可用性，擴展性等纔是一個開發人員最該關心的。

　　　　今天所說的高併發：咱們的解決思路是：一、採用分佈式應用設計；二、分佈式緩存數據庫；三、代碼優化；

　　再來一個 java 高併發的例子：

　　具體狀況是：經過 java 和數據庫本身實現序列自增：

　　id_table 表結構，主要字段：

1 id_name  varchar2(16);
2 id_val  number(16,0);
3 id_prefix  varchar2(4);

　　java 代碼大體以下：

 1 //操做DB 
 2 public synchronized String nextStringValue(String id){
 3     SqlSession sqlSess = SqlSessionUtil.getSqlSession();
 4     sqlSess.update("update id_table set id_val = id_val + 1 where id_name="+id);
 5     Map map = sqlSess.getOne("select id_name, id_prefix, id_val from id_table where id_name="+ id);
 6     BigDecimal val = (BigDecimal) map.get("id_val");
 7     // id_val是具體數字，rePack主要是統一返回固定長度的字符串；如：Y0000001, F0000001, T0000001等
 8     String idValue = rePack(val, map); 
 9     return idValue;
10   }
11    
12 //公共方法
13 public class IdHelpTool{
14     public static String getNextStringValue(String idName){
15         return getXX().nextStringValue(idName);
16     }
17 }