對於我們開發的網站，如果網站的訪問量非常大的話，那么我們就需要考慮相關的並發訪問問題了。而並發問題是絕大部分的程序員頭疼的問題，但話又說回來了，既然逃避不掉，那我們就坦然面對吧~今天就讓我們一起來研究一下常見的並發和同步吧。為了更好的理解並發和同步，我們需要先明白兩個重要的概念:同步和異步
1、同步和異步的區別和聯系
所謂同步，可以理解為在執行完一個函數或方法之后，一直等待系統返回值或消息，這時程序是出於阻塞的，只有接收到返回的值或消息后才往下執行其它的命令。
異步，執行完函數或方法后，不必阻塞性地等待返回值或消息，只需要向系統委托一個異步過程，那么當系統接收到返回值或消息時，系統會自動觸發委托的異步過程，從而完成一個完整的流程。
同步在一定程度上可以看做是單線程，這個線程請求一個方法后就待這個方法給他回復，否則他不往下執行(死心眼)。
異步在一定程度上可以看做是多線程的(廢話，一個線程怎么叫異步)，請求一個方法后，就不管了，繼續執行其他的方法。
同步就是一件事，一件事情一件事的做。
異步就是，做一件事情，不引響做其他事情。
例如：吃飯和說話，只能一件事一件事的來，因為只有一張嘴。但吃飯和聽音樂是異步的，因為，聽音樂並不引響我們吃飯。
對於Java程序員而言，我們會經常聽到同步關鍵字synchronized，假如這個同步的監視對象是類的話，那么如果當一個對象訪問類里面的同步方法的話，那么其它的對象如果想要繼續訪問類里面的這個同步方法的話，就會進入阻塞，只有等前一個對象執行完該同步方法后當前對象才能夠繼續執行該方法。這就是同步。相反，如果方法前沒有同步關鍵字修飾的話，那么不同的對象可以在同一時間訪問同一個方法，這就是異步。
2、如何處理並發和同步
今天講的如何處理並發和同同步問題主要是通過鎖機制。
我們需要明白，鎖機制有兩個層面。
一種是代碼層次上的，如java中的同步鎖，典型的就是同步關鍵字synchronized，這里我不在做過多的講解，
另外一種是數據庫層次上的，比較典型的就是悲觀鎖和樂觀鎖。這里我們重點講解的就是悲觀鎖（傳統的物理鎖）和樂觀鎖。
悲觀鎖(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 加載進來，所謂數據庫加鎖也就無從談起。
需要注意的是for update要放到mysql的事務中，即begin和commit中，否者不起作用。
至於是鎖住整個表還是鎖住選中的行，
至於hibernate中的悲觀鎖使用起來比較簡單，這里就不寫demo了~感興趣的自己查一下就ok了~
樂觀鎖(Optimistic Locking):
相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數情況下依 靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之
而來的就是數據庫 性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。 如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數
據的基礎上進 行修改時（如更改用戶帳戶余額），如果采用悲觀鎖機制，也就意味着整個操作過 程中（從操作員讀出數據、開始修改直至提交修改結果的全
過程，甚至還包括操作 員中途去煮咖啡的時間），數據庫記錄始終處於加鎖狀態，可以想見，如果面對幾百上千個並發，這樣的情況將導致怎樣的后果。 樂
觀鎖機制在一定程度上解決了這個問題。
樂觀鎖，大多是基於數據版本 Version ）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於數據庫表的版本解決方案中，一般是通
過為數據庫表增加一個 “version” 字段來 實現。 讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提 交數據的版本數據與數據
庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於數據庫表當前版本號，則予以更新，否則認為是過期數據。
3、常見並發同步案例分析
案例一:訂票系統案例，某航班只有一張機票，假定有1w個人打開你的網站來訂票，問你如何解決並發問題(可擴展到任何高並發網站要考慮的並發讀寫問題)
問題，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來顯示）。
解決以上問題后，使用服務器集群來解決單台的瓶頸問題。
之前我將高並發的解決方法誤認為是線程或者是隊列可以解決，因為高並發的時候是有很多用戶在訪問，導致出現系統數據不正確、丟失數據現象，所以想到的是用隊列解決，其實隊列解決的方式也可以處理，比如我們在競拍商品、轉發評論微博或者是秒殺商品等，同一時間訪問量特別大，隊列在此起到特別的作用，將 所有請求放入隊列，以毫秒計時單位，有序的進行，從而不會出現數據丟失系統數據不正確的情況。
經過查資料，高並發的解決方法有倆種:
一種是使用緩存、另一種是使用生成靜態頁面；還有就是從最基礎的地方優化我們寫代碼減少不必要的資源浪費：(
1.不要頻繁的new對象,對於在整個應用中只需要存在一個實例的類使用單例模式.對於String的連接操作,使用StringBuffer或者StringBuilder.對於utility類型的類通過靜態方法來訪問。
2. 避免使用錯誤的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof做條件判斷,盡量使用比的條件判斷方式.使用JAVA中效率高的類,比如ArrayList比Vector性能好。)
總 結：其實我們在開發中都很少考慮這種問題，直接都是先將功能實現，當一個程序員在干到2到3年，就會感覺光實現功能不是最主要的，安全性能、質量等等才是 一個開發人員最該關心的。今天我所說的是高並發。
我的解決思路是：
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 ， 同步關鍵字過多，會不會更導致超時？
跪求大俠提供個解決問題的大概思路！！！
解決思路一：
可以通過第三方redis來實現。
解決思路二：
1、出現重復ID，是因為臟讀了，並發的時候不加 synchronized 比如會出現問題
2、但是加了 synchronized ，性能急劇下降了，本身 java 就是多線程的，你把它單線程使用，不是明智的選擇，同時，如果分布式部署的時候，加了 synchronized 也無法控制並發
3、調用這個方法，出現超時的情況，說明你的並發已經超過了數據庫所能處理的極限，數據庫無限等待導致超時
基於上面的分析，建議采用線程池的方案，支付寶的單號就是用的線程池的方案進行的。
數據庫 update 不是一次加1，而是一次加幾百甚至上千，然后取到的這 1000個序號，放在線程池里慢慢分配即可，能應付任意大的並發，同時保證數據庫沒任何壓力。