物件鎖（lock/synchronized）的注意點：
1.物件鎖可能鎖住的範圍比較大，導致介面效能下降，造成執行緒阻塞；
2.物件鎖的唯一性問題，如果不是全域性唯一鎖（使用spring容器物件或static物件只能保證同一伺服器唯一，不能保證全域性唯一），將起不到鎖的作用，最好使用分布式鎖；
spring事務：
spring事務本質上使用資料庫事務，而資料庫事務本質上使用資料庫鎖，所以spring事務本質上使用資料庫鎖，開啟spring事務意味著使用資料庫鎖；
spring事務實際使用aop攔截註解方法，然後使用動態**處理事務方法，捕獲處理過程中的異常，spring事務其實是把異常交給spring處理；
spring事務只有捕獲到異常才會終止或回滾，如果你在程式中try/catch後自己處理異常而沒有throw，那麼事務將不會終止或回滾，失去事務本來的作用；
spring事務會捕獲所有的異常，但只會回滾資料庫相關的操作，並且只有在宣告了rollbackforclassname="exception"之類的配置才會回滾；
spring事務會回滾同一事務中的所有資料庫操作，本質上是回滾同一資料庫連線上的資料庫操作；
spring事務總結：
spring事務本質上使用資料庫鎖；
spring事務只有在方法執行過程中出現異常才會回滾，並且只回滾資料庫相關的操作；
物件鎖和spring事務的對比：
物件鎖可以保證資料一致性和業務邏輯正確性，但不能保證併發性；
spring事務不能嚴格保證資料一致性和業務邏輯正確性，但具有較好的併發性，因為只鎖資料庫行資料；
建議：如果只有insert操作，可以使用事務；
如果涉及update操作但不涉及其他業務邏輯，可以保守使用事務；
如果涉及update操作及其他業務邏輯，慎用事務，
並且資料庫查詢跟資料庫更新之間盡量間隔較短，中間不宜插入太多其他邏輯，減少資料一致性的風險；
對資料一致性要求不高的情況下可以使用事務結合樂觀鎖，否則建議用鎖；
spring事務為什麼不能保證資料一致性和業務邏輯正確性：
1.如果事務方法拋異常，此時會回滾資料庫操作，但已經執行的其他方法不會回滾，因此無法保證業務邏輯正確性；
2.即使事務方法不拋異常，也不能保證資料一致性（因為事務介面裡的資料庫操作在整個介面邏輯執行結束後才提交到資料庫，在介面最後提交到資料庫的前後很有可能帶來資料一致性的問題），從而不能保證業務邏輯正確性；
spring事務 java鎖機制
1 問題描述 最近再做火車票購票時，在對票類庫存進行扣減，有執行緒安全的問題，遂加鎖lock進行同步，但發現加鎖後並沒有控制住庫存執行緒安全的問題，導致庫存仍被超發。先簡單介紹下，各層的技術架構 中間層框架 springboot 持久層 mybatis mvc框架 spring mvc 存在問題的 ...
spring事務中鎖失效
1 為啥會失效 transactional的實現是基於spring的aop。spring會對其業務方法進行動態 執行前開始事務，然後再執行業務 最後提交事務。大致流程如下圖所示 假設執行緒1線搶到鎖，在解鎖這個時候，這個時候事務還沒有提交，資料庫資料還沒有更新。然後執行緒2獲取到了鎖，讀取的資料可能...
事務和鎖 SQLite
2 事務 transaction 2.1 事務的週期 transaction lifecycles 程 序與事務之間有兩件事值得注意 1 哪些物件在事務下執行 這直接與api有關。2 事務的生命週期，即什麼時候開始，什麼時候結束以及它在什麼時候開始影響別的連線 這點對於併發性很重要 這涉及到sqli...