四、剩餘疑問點：
1.悲觀鎖：顧名思義，認為資料被併發修改的機率非常大，每次修改資料前，都先對資料進行上鎖處理，即用select****for update進行上鎖，而平常使用的synchronized其實也是悲觀鎖的一種應用。
2.樂觀鎖：顧名思義，每次修改前，都認為資料不會造成衝突，只有在修改時，才去檢測資料是否衝突；
1.示例：select * from table where *** for update
2. 鎖級別：for update僅適用於innodb，而innodb預設是行級別的鎖，當有明確指定的主鍵時候，是行級鎖。否則是表級鎖；
3. 注意點：需與事務搭配使用，否則鎖不生效；
事件一：專案經過多人接手，**非常亂，整個下單介面中直接使用了@transactional，而因為本專案中會調很多個系統的介面，這就直接會導致一次事務要經過十秒甚至更多時間才結束，這種場景直接用悲觀鎖時，會導致兩個使用者下同樣的單時，第乙個使用者正常呼叫介面正常下單， 而第二個使用者卻會因為悲觀鎖把該商品資料鎖住而需要等到第乙個使用者下單結束後才會繼續下單流程：
解決方式：單獨將修改庫存這塊放到同乙個方法中，並使用@transactional(propagation = propagation.requires_new)新開乙個事務，進行事務巢狀；
事件二：當我使用@transactional(propagation = propagation.requires_new)多次測試時，發現實際上並沒有開啟新事務：
解決方式：當外層事務與內層事務在同乙個類中時，spring並不會建立乙個新的事務，需要把兩個事務放在不同的類中；
事件三：當我在內層事務中新增一條資料後，在外層事務中查詢不到新增的資料；
解決方式：用@transactional(propagation = propagation.requires_new)新開乙個內層事務去查詢，則能夠查詢出另乙個內層事務新增或修改的資料，即外層事務巢狀了兩個內層事務，上面提到了外層事務不能與內層事務放在同乙個類中，而內層事務跟內層事務則允許放在同乙個類中；
1.事件三中，內層事務已提交（證明點：悲觀鎖會隨著事務的提交而解鎖），但是在外層事務卻查不到內層事務更改的資料，而巢狀的內層事務卻能正常查詢到另乙個內層事務更改的資料；
2.如果悲觀鎖只查詢但不進行其他操作，事務提交後，會不會釋放鎖：答案是會。
ps：第一點以後知道原因再進行補充。
記錄一次使用git悲催的經歷
git是乙個神器，但是前提是要會用它，今天的慘痛經歷告訴了我這一點 我是使用 webstorm 來寫 的，在每次新建乙個檔案的時候它都會問我要不要把這個檔案新增至 git 還可以預設設定，我當然選擇預設了呀，那時我的理解是 在後面我每次儲存檔案的時候 webstorm 都會自動幫我 git add ...
Spring事務（一） Spring事務的使用
事務的經典舉例 某人要在商店使用電子貨幣購買100元的東西，當中至少包括兩個操作 該人賬戶減少100元 商店賬戶增加100元 事務就是要確保以上兩個操作 都能完成 或者 一起取消，否則就會出現100元平白消失或出現的情況。摘自wiki spring事務有兩種方式 程式設計式事務管理 宣告式事務管理 ...
一次事務過程
第二篇 一次事務過程 對於開發人員來說，我們經常做的是啟動乙個事務，執行sql，提交事務。這就完成了我們的工作。但是，就在這些簡單的動作背後，網路和資料庫都做了些什麼呢。我們都想知道。下面以乙個例項來說明。背景 使用者正執行乙個連線到oracle資料庫的客戶端應用程式，是乙個員工檔案管理程式。過程 ...