在現在這個互聯網的時候，所講的併發，高併發通常是指併發訪問，也就是說在某個時間點，有多少個訪問都會同時到來。通常一個系統的日PV在千萬以上，有可能是一個高併發的系統。在有的公司不會完全走技術的路線，而是全靠機器在堆。
“互聯網訂票”、“銀行系統”、“股票交易”、“12306訂票系統”、“電商系統”、“淘寶”、“天貓”等很多系統都是通過併發來實現的，不是所有的秒殺都是秒殺。
話不多說，直接上Xmind：
只有系統的整理知識點，才能找到不足。當然，在學習的過程中如果可以結合案例來學習的話，這樣纔可以更好的吸收這些知識並且運用到工作中，這個纔是我們學習的目的。想提升技術，需要多看書！多看書！多看書！
併發案例（訂票系統的案例）
很多小夥伴都會或多或少的有這樣一種想法：高併發專題學了那麼久，但是，在真正做項目時，仍然不知道如何下手處理高併發業務場景！甚至很多小夥伴仍然停留在只是簡單的提供接口（CRUD）階段，不知道學習的併發知識如何運用到實際項目中，就更別提如何構建高併發系統了！
訂票系統案例：某航班只有一張機票，假定有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">
上面就是小編介紹的一些併發情況和案例，下面是一篇乾貨，需要這份併發資料的朋友，幫忙轉發+關注，後臺私信【學習】二字即可免費獲取領取方式。
乾貨：高併發設計pdf
這份文檔分爲：基礎篇、數據庫篇、緩存篇、消息隊列篇、分佈式服務篇、維護篇、實戰篇七篇。
1--基礎篇：總共分爲六小節
- 主要內容
2--數據庫篇：總共分爲五小節
- 主要內容
3--緩存篇：總共分爲五小節
- 主要內容
上面就是小編介紹的一些併發情況和案例和併發的乾貨pdf，需要這份併發資料的朋友，幫忙轉發+關注，後臺私信【學習】二字即可免費獲取領取方式。
4--消息隊列篇：總共分爲四小節
- 主要內容
5--分佈式服務篇：總共分爲九小節
- 主要內容
6--維護篇：總共分爲七小節
- 主要內容
7--實戰篇：總共分爲四小節
友情提示：上面就是小編介紹的一些併發情況和案例和併發的乾貨pdf，需要這份併發資料的朋友，幫忙點贊這篇文章，點擊小編頭像進入個人主頁或者si xin即可。
- 主要內容
