為了更好的理解併發和同步，我們需要先明白兩個重要的概念:同步和非同步

1、同步和非同步的區別和聯絡

　　所謂同步，可以理解為在執行完一個函式或方法之後，一直等待系統返回值或訊息，這時程式是出於阻塞的，只有接收到

返回的值或訊息後才往下執行其它的命令。

非同步，執行完函式或方法後，不必阻塞性地等待返回值或訊息，只需要向系統委託一個非同步過程，那麼當系統接收到返回

值或訊息時，系統會自動觸發委託的非同步過程，從而完成一個完整的流程。

同步在一定程度上可以看做是單執行緒，這個執行緒請求一個方法後就待這個方法給他回覆，否則他不往下執行(死心眼)。

非同步在一定程度上可以看做是多執行緒的(廢話，一個執行緒怎麼叫非同步)，請求一個方法後，就不管了，繼續執行其他的方法。

　　 同步就是一件事，一件事情一件事的做。 非同步就是，做一件事情，不引響做其他事情。

例如：吃飯和說話，只能一件事一件事的來，因為只有一張嘴。 但吃飯和聽音樂是非同步的，因為，聽音樂並不引響我們吃飯。

對於Java程式設計師而言，我們會經常聽到同步關鍵字synchronized，假如這個同步的監視物件是類的話，那麼如果當一個物件

訪問類裡面的同步方法的話，那麼其它的物件如果想要繼續訪問類裡面的這個同步方法的話，就會進入阻塞，只有等前一個物件

執行完該同步方法後當前物件才能夠繼續執行該方法。這就是同步。相反，如果方法前沒有同步關鍵字修飾的話，那麼不同的物件

可以在同一時間訪問同一個方法，這就是非同步。

在補充一下(髒資料和不可重複讀的相關概念):

髒資料

　　髒讀就是指當一個事務正在訪問資料，並且對資料進行了修改，而這種修改還沒有提交到資料庫中，這時，另外一個事務也訪問這個資料，然後使用了這個資料。因為這個資料是還沒有提交的資料，那麼另外一個事務讀到的這個資料是髒資料(Dirty Data)，依據髒資料所做的操作可能是不正確的。 　　不可重複讀 　　不可重複讀是指在一個事務內，多次讀同一資料。在這個事務還沒有結束時，另外一個事務也訪問該同一資料。那麼，在第一個事務中的兩次讀資料之間，由於第二個事務的修改，那麼第一個事務兩次讀到的資料可能是不一樣的。這樣就發生了在一個事務內兩次讀到的資料是不一樣的，因此稱為是不可重複讀

2、如何處理併發和同步

今天講的如何處理併發和同同步問題主要是透過鎖機制。

我們需要明白，鎖機制有兩個層面。

一種是程式碼層次上的，如java中的同步鎖，典型的就是同步關鍵字synchronized，這裡我不在做過多的講解，

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

另外一種是資料庫層次上的，比較典型的就是悲觀鎖和樂觀鎖。這裡我們重點講解的就是悲觀鎖（傳統的物理鎖）和樂觀鎖。

悲觀鎖(Pessimistic Locking):

悲觀鎖，正如其名，它指的是對資料被外界（包括本系統當前的其他事務，以及來自 外部系統的事務處理）修改持保守態度，因此，

在整個資料處理過程中，將資料處於鎖定狀態。

悲觀鎖的實現，往往依靠資料庫提供的鎖機制（也只有資料庫層提供的鎖機制才能 真正保證資料訪問的排他性，否則，即使在本系統

中實現了加鎖機制，也無法保證外部系 統不會修改資料）。

一個典型的倚賴資料庫的悲觀鎖呼叫：

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();// 執行查詢，獲取資料

query.setLockMode 對查詢語句中，特定別名所對應的記錄進行加鎖（我們為 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 ，開二個視窗來做測試。

表的基本結構如下:

表中內容如下:

開啟兩個測試視窗，在其中一個視窗執行select * from ta for update0

然後在另外一個視窗執行update操作如下圖:

等到一個視窗commit後的圖片如下:

到這裡，悲觀鎖機制你應該瞭解一些了吧~

需要注意的是for update要放到mysql的事務中，即begin和commit中，否者不起作用。

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

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

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

樂觀鎖(Optimistic Locking): 相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依 靠資料庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之

而來的就是資料庫 效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。 如一個金融系統，當某個操作員讀取使用者的資料，並在讀出的使用者數

據的基礎上進 行修改時（如更改使用者帳戶餘額），如果採用悲觀鎖機制，也就意味著整個操作過 程中（從操作員讀出資料、開始修改直至提交修改結果的全

過程，甚至還包括操作 員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾 百上千個併發，這樣的情況將導致怎樣的後果。 樂

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

樂觀鎖，大多是基於資料版本 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 ），但此時比對資料庫記錄版本時發現，操作員 B 提交的 資料版本號為 2 ，資料庫記錄當前版

本也為 2 ，不滿足 “ 提交版本必須大於記 錄當前版本才能執行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基於

version=1 的舊資料修改的結果覆蓋操作 員 A 的操作結果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷（操作員 A

和操作員 B 操作過程中，都沒有對資料庫資料加鎖），大大提升了大併發量下的系 統整體效能表現。 需要注意的是，樂觀鎖機制往往基於系統中的資料儲存

邏輯，因此也具備一定的局 限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的使用者 餘額更新操作不受我們系統的控制，因此可能

會造成髒資料被更新到資料庫中。在 系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如 將樂觀鎖策略在資料庫儲存過程中實

現，對外只開放基於此儲存過程的資料更新途 徑，而不是將資料庫表直接對外公開）。 Hibernate 在其資料訪問引擎中內建了樂觀鎖實現。如果不用考慮外

部系統對數 據庫的更新操作，利用 Hibernate 提供的透明化樂觀鎖實現，將大大提升我們的 生產力。

User.hbm.xml

2 ． 配置檔案hibernate.cfg.xml和UserTest測試類

hibernate.cfg.xml

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.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 進行更新的時候，我們可以發現，資料庫中的 version 都在遞增。

下面我們將要透過樂觀鎖來實現一下併發和同步的測試用例:

這裡需要使用兩個測試類，分別執行在不同的虛擬機器上面，以此來模擬多個使用者同時操作一張表,同時其中一個測試類需要模擬長事務

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這個類，在到達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、常見併發同步案例分析

案例一:訂票系統案例，某航班只有一張機票，假定有1w個人開啟你的網站來訂票，問你如何解決併發問題(可擴充套件到任何高併發網站要考慮

的併發讀寫問題)

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

絡快慢等）

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

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

象鎖，用於執行緒同步；另外一個層面是資料庫的鎖；如果是分散式的系統，顯然只能利用資料庫端的鎖來實現。

假定我們採用了同步機制或者資料庫物理鎖機制，如何保證1w個人還能同時看到有票，顯然會犧牲效能，在高併發網站中是不可取的。使用hibernate後我們

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

採用樂觀鎖即可解決此問題。樂觀鎖意思是不鎖定表的情況下，利用業務的控制來解決併發問題，這樣即保證資料的併發可讀性又保證儲存資料的排他性，保

證效能的同時解決了併發帶來的髒資料問題。

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">

案例二、股票交易系統、銀行系統，大資料量你是如何考慮的

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

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

再比如，中國移動有上億的使用者量，表如何設計？把所有用於存在於一個表麼？

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

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

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

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

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

此外，我們還得考慮快取

這裡的快取，指的不僅僅是hibernate，hibernate本身提供了一級二級快取。這裡的快取獨立於應用，依然是記憶體的讀取，假如我們能減少資料庫頻繁的訪

問，那對系統肯定大大有利的。比如一個電子商務系統的商品搜尋，如果某個關鍵字的商品經常被搜，那就可以考慮這部分商品列表存放到快取（記憶體中

去），這樣不用每次訪問資料庫，效能大大增加。

簡單的快取大家可以理解為自己做一個hashmap，把常訪問的資料做一個key，value是第一次從資料庫搜尋出來的值，下次訪問就可以從map裡讀取，而不

讀資料庫；專業些的目前有獨立的快取框架比如memcached 等，可獨立部署成一個快取伺服器。

4、常見的提高高併發下訪問的效率的手段

首先要了解高併發的的瓶頸在哪裡？

1、可能是伺服器網路頻寬不夠

2.可能web執行緒連線數不夠

3.可能資料庫連線查詢上不去。

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

像第一種情況可以增加網路頻寬，DNS域名解析分發多臺伺服器。

負載均衡，前置代理伺服器nginx、apache等等

資料庫查詢最佳化，讀寫分離，分表等等

最後複製一些在高併發下面需要常常需要處理的內容:

儘量使用快取，包括使用者快取，資訊快取等，多花點記憶體來做快取，可以大量減少與資料庫的互動，提高效能。

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

最佳化資料庫查詢語句，減少直接使用hibernate等工具的直接生成語句（僅耗時較長的查詢做最佳化）。

最佳化資料庫結構，多做索引，提高查詢效率。

統計的功能儘量做快取，或按每天一統計或定時統計相關報表，避免需要時進行統計的功能。

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

解決以上問題後，使用伺服器叢集來解決單臺的瓶頸問題。

java高併發，如何解決，什麼方式解決

之前我將高併發的解決方法誤認為是執行緒或者是佇列可以解決，因為高併發的時候是有很多使用者在訪問，導致出現系統資料不正確、丟失資料現象，所以想到 的是用佇列解決，其實佇列解決的方式也可以處理，比如我們在競拍商品、轉發評論微博或者是秒殺商品等，同一時間訪問量特別大，佇列在此起到特別的作用，將 所有請求放入佇列，以毫秒計時單位，有序的進行，從而不會出現資料丟失系統資料不正確的情況。

今天我經過查資料，高併發的解決方法有倆種:

一種是使用快取、另一種是使用生成靜態頁面；還有就是從最基礎的地方最佳化我們寫程式碼減少不必要的資源浪費：(

1.不要頻繁的new物件,對於在整個應用中只需要存在一個例項的類使用單例模式.對於String的連線操作,使用StringBuffer或者StringBuilder.對於utility型別的類透過靜態方法來訪問。

2. 避免使用錯誤的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗效能,除非必要不要使用 instanceof做條件判斷,儘量使用比的條件判斷方式.使用JAVA中效率高的類,比如ArrayList比Vector效能好。)

首先快取技術我一直沒有使用過，我覺得應該是在使用者請求時將資料儲存在快取中，下次請求時會檢測快取中是否有資料存在，防止多次請求伺服器，導致伺服器效能降低，嚴重導致伺服器崩潰，這只是我自己的理解，詳細的資料還是需要在網上收集；

使用生成靜態頁面我想大家應該不模式，我們見過很多網站當在請求的時候頁面的後最已經變了，如“http://developer.51cto.com/art/201207/348766.htm”該頁面其實是一個伺服器請求地址，在轉換成htm後，訪問速度將提升，因為靜態頁面不帶有伺服器元件；在這裡我就多多介紹一下：

一、什麼是頁面靜態化：

簡 單的說，我們如果訪問一個連結 ,伺服器對應的模組會處理這個請求，轉到對應的jsp介面，最後生成我們想要看到的資料。這其中的缺點是顯而易見的：因為每次請求伺服器都會進行處理，如 果有太多的高併發請求，那麼就會加重應用伺服器的壓力，弄不好就把伺服器 搞down 掉了。那麼如何去避免呢？如果我們把對 test.do 請求後的結果儲存成一個 html 檔案，然後每次使用者都去訪問 ,這樣應用伺服器的壓力不就減少了？

那麼靜態頁面從哪裡來呢？總不能讓我們每個頁面都手動處理吧？這裡就牽涉到我們要講解的內容了，靜態頁面生成方案… 我們需要的是自動的生成靜態頁面，當用戶訪問 ,會自動生成 test.html ,然後顯示給使用者。

二、下面我們在簡單介紹一下要想掌握頁面靜態化方案應該掌握的知識點：

1、 基礎- URL Rewrite

什麼是 URL Rewrite 呢 ? URL 重寫。用一個簡單的例子來說明問題：輸入網址 ,但是實際上訪問的卻是 abc.com/test.action,那我們就可以說 URL 被重寫了。這項技術應用廣泛，有許多開源的工具可以實現這個功能。

2、 基礎- Servlet web.xml

如果你還不知道 web.xml 中一個請求和一個 servlet 是如何匹配到一起的，那麼請搜尋一下 servlet 的文件。這可不是亂說呀，有很多人就認為 /xyz/*.do 這樣的匹配方式能有效。

如果你還不知道怎麼編寫一個 servlet ,那麼請搜尋一下如何編寫 servlet.這可不是說笑呀，在各種整合工具漫天飛舞的今天，很多人都不會去從零編寫一個 servlet了。

三、基本的方案介紹

其中，對於 URL Rewriter的部分，可以使用收費或者開源的工具來實現，如果 url不是特別的複雜，可以考慮在 servlet 中實現，那麼就是下面這個樣子： 總 結：其實我們在開發中都很少考慮這種問題，直接都是先將功能實現，當一個程式設計師在幹到1到2年，就會感覺光實現功能不是最主要的，安全效能、質量等等才是 一個開發人員最該關心的。今天我所說的是高併發。我的解決思路是：1、採用分散式應用設計2、分散式快取資料庫3、程式碼最佳化

Java高併發的例子：

✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈

具體情況是這樣： 透過java和資料庫，自己實現序列自動增長。實現程式碼大致如下： id_table表結構, 主要欄位：

id_name varchar2(16); id_val number(16,0); id_prefix varchar2(4); //操作DB public synchronized String nextStringValue(String id){ SqlSession sqlSess = SqlSessionUtil.getSqlSession(); sqlSess.update("update id_table set id_val = id_val + 1 where id_name="+id); Map map = sqlSess.getOne("select id_name, id_prefix, id_val from id_table where id_name="+ id); BigDecimal val = (BigDecimal) map.get("id_val"); //id_val是具體數字，rePack主要是統一返回固定長度的字串；如：Y0000001, F0000001, T0000001等 String idValue = rePack(val, map); return idValue; } //公共方法public class IdHelpTool{ public static String getNextStringValue(String idName){ return getXX().nextStringValue(idName); } }

具體使用者，都是透過類似這種方式：IdHelpTool.getNextStringValue("PAY_LOG");來呼叫。問題： （1） 當出現併發時， 有時會獲取重複的ID； （2） 由於伺服器做了相關一些設定，有時呼叫這個方法，好像還會導致超時。 為了解決問題(1), 考慮過在方法getNextStringValue上，也加上synchronized ， 同步關鍵字過多，會不會更導致超時？跪求大俠提供個解決問題的大概思路！！！

✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈✈

解決思路一：

1、推薦 https://github.com/adyliu/idcenter2、可以透過第三方redis來實現。

解決思路一：

1、出現重複ID，是因為髒讀了，併發的時候不加 synchronized 比如會出現問題2、但是加了 synchronized ，效能急劇下降了，本身 java 就是多執行緒的，你把它單執行緒使用，不是明智的選擇，同時，如果分散式部署的時候，加了 synchronized 也無法控制併發3、呼叫這個方法，出現超時的情況，說明你的併發已經超過了資料庫所能處理的極限，資料庫無限等待導致超時基於上面的分析，建議採用執行緒池的方案，支付寶的單號就是用的執行緒池的方案進行的。資料庫 update 不是一次加1，而是一次加幾百甚至上千，然後取到的這 1000個序號，放線上程池裡慢慢分配即可，能應付任意大的併發，同時保證資料庫沒任何壓力。