目前的并發控制機制，悲觀鎖和樂觀鎖，都是基于行來實作，對于一些很多模塊都會訪問并修改的資料（修改的列并不一樣），這種粒度是不夠的，因為不同模塊的業務，修改的欄位并不一定是同一個（或者同一類）。
在這些場景下，基于列的并發就比較有意義了，可以很大的提高并發事務執行能力。本文要介紹的樂觀鎖機制，是基于記憶體實作的，鎖的獲取和并發檢測，完全是在記憶體中，不會和資料庫有任何互動，所以效率會非常高。
首先是增加事務攔截器，在事務開始時登記事務資訊，在事務結束后清除事務資訊
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
// 獲取事務資訊
TransactionStatus transactionStatus = TransactionUtils
.getCurrentTransactionStatus();
TransactionInfo transactionInfo = null;
boolean bind = false;
if (transactionStatus != null && transactionStatus.isNewTransaction()) {
transactionInfo = new TransactionInfo(invocation,transactionStatus);
transactionInfoManager.addTransactionInfo(transactionInfo);
transactionInfo.bindToThread();
bind = true;
try {
TransactionSynchronizationManager
.registerSynchronization(new OptimisticLockTransactionSynchronizationAdapter(
optimisticLockManager, transactionInfo));
} catch (Exception e) {
e.printStackTrace();
}
}
Object rv;
try {
rv = invocation.proceed();
} finally {
if(transactionInfo != null){
transactionInfoManager.removeTransactionInfo(transactionInfo);
}
if (bind) {
transactionInfo.restoreThreadLocalStatus();
}
}
return rv;
}
OptimisticLockTransactionSynchronizationAdapter的代碼如下
public class OptimisticLockTransactionSynchronizationAdapter extends
TransactionSynchronizationAdapter {
private TransactionInfo transactionInfo = null;
private OptimisticLockManager optimisticLockManager;
public OptimisticLockTransactionSynchronizationAdapter(
OptimisticLockManager optimisticLockManager,
TransactionInfo transactionInfo) {
super();
this.transactionInfo = transactionInfo;
this.optimisticLockManager = optimisticLockManager;
}
@Override
public void afterCompletion(int status) {
// 事務完成時，清除事務相關的鎖
optimisticLockManager.releaseTransactionLocks(transactionInfo);
}
}
TransactionInfo為事務資訊類，在當前執行緒會有一個堆疊，每次新建事務時會新生成一個TransactionInfo物件，并且入堆疊。當事務結束后，會將當前TransactionInfo出堆疊，如下圖：
以下是相關的核心類
類 OptimisticLockManager
屬性 private ConcurrentHashMap<String, EntityLocksInfo> entityToLocksMap
public void requestLock(String entity, String rowId,String colId) {
EntityLocksInfo entityLocksInfo = entityToLocksMap.get(entity);
if (entityLocksInfo == null) {
EntityLocksInfo newEntityLocksInfo = new EntityLocksInfo(entity);
entityLocksInfo = entityToLocksMap.putIfAbsent(entity,
newEntityLocksInfo);
if (entityLocksInfo == null) {
entityLocksInfo = newEntityLocksInfo;
}
}
entityLocksInfo.requestLock(rowId,colId);
}
類 EntityLocksInfo
屬性 private ConcurrentHashMap<String, RowLocksInfo> idToRowLocksInfoMap
public void requestLock(String rowId, String colId) {
TransactionInfo transactionInfo = TransactionUtils
.currentTransactionInfo();
if (transactionInfo == null) {
throw new OptimisticLockNoTransactionException();
}
RowLocksInfo rowLocksInfo = idToRowLocksInfoMap.get(rowId);
if (rowLocksInfo == null) {
RowLocksInfo newRowLocksInfo = new RowLocksInfo(entity);
rowLocksInfo = idToRowLocksInfoMap.putIfAbsent(rowId,
newRowLocksInfo);
if (rowLocksInfo == null) {
rowLocksInfo = newRowLocksInfo;
}
}
rowLocksInfo.requestLock(colId);
}
類 RowLocksInfo
屬性 private ConcurrentHashMap<String, OptimisticLock> colIdToLockMap
方法 public void requestLock(String colId);
public void requestLock(String colId) {
TransactionInfo transactionInfo = TransactionUtils
.currentTransactionInfo();
if (transactionInfo == null) {
throw new OptimisticLockNoTransactionException();
}
OptimisticLock existingOptimisticLock = colIdToLockMap.get(colId);
if (existingOptimisticLock == null) {
OptimisticLock newOptimisticLock = new OptimisticLock();
newOptimisticLock.setId(colId);
newOptimisticLock.setTransactionInfo(transactionInfo);
existingOptimisticLock = colIdToLockMap.putIfAbsent(colId,
newOptimisticLock);
if (existingOptimisticLock == null) {
transactionInfo.addLock(newOptimisticLock);
}
}
if (existingOptimisticLock != null) {
if (existingOptimisticLock.getTransactionInfo() != transactionInfo) {
throw new OptimisticLockConflictException(colId,
transactionInfo);
}
}
}
類 OptimisticLock 為真正的所物件，記錄了鎖所屬的物體名，行id，列id，等等
private String entity;
private String rowId;
private String colId;
如何在業務類中使用
在業務manager中注入OptimisticLockManager
例如有一個產品管理系統，現在有3個產品，資料庫中資料如下
id name stock salesAmount
1 intel 9900K 1000 500
2 intel 9700K 1000 300
3 intel 8700K 10 10000
現在有訂單事務，購買intel 9900K，數量10個
那么需要鎖定stock和salesAmount
optimisticLockManager.requestLock("product", "1","stock");
optimisticLockManager.requestLock("product", "1","salesAmount");
然后執行邏輯
update product set stock = stock-10 where id=1;
update product set salesAmount = salesAmount+10 where id=1;
對于入庫單（產品入庫/進貨），入庫intel 9900K，數量10個，只需要修改庫存，而不需要修改銷售量
那么只需要鎖定stock
optimisticLockManager.requestLock("product", "1","stock");
然后執行邏輯
update product set stock = stock+10 where id=1;
這里只是API呼叫說明，此處的訂單事務和入庫事務，其實是不能并發執行（因為修改了共同的列stock），但是其他場景
如果修改的列是不沖突的，那就完全可以并發執行
當多個事務請求同一個表，同一條記錄的同個屬性時，后請求的將會拋出例外（可以將entity,rowId,colId以及事務名字都提示出來），例如上面的2個事務，如果事務2先開始（入庫事務）并且未提交時，事務1（訂單事務）也同時執行，將會提示"入庫操作正在修改id為1的產品記錄的庫存，請稍后重試!"
uj5u.com熱心網友回復：
贊！PS：其實我看不懂 java 。
uj5u.com熱心網友回復：
發錯版塊了吧uj5u.com熱心網友回復：
應該發到哪里，這不是資料庫版塊嗎，
uj5u.com熱心網友回復：
就沒有人討論一下，都沒有這個需求嗎。。不需要用列級的，也可以改成行的樂觀鎖啊，基于記憶體的，效率很高，而且可以提前檢測，而不是等事務要提交時才發現沖突uj5u.com熱心網友回復：
沒說明出處，沒說明使用的框架，也沒給出具體使用的jar包。沒有具體的用于測驗的代碼，無法在本機上測驗，我首先對這些代碼的正確性持懷疑態度。更關鍵的是，不管是效率，功能性，還是方便程度，都不覺得比oracle原生的實作有什么優點。
uj5u.com熱心網友回復：
框架是用的spring，事務代理加個攔截器，用來做事務同步處理。正確性毋庸置疑，我們產品已經在很多專案使用了，你說和原生的資料庫比有什么優點，1，無須最后提交修改時才能檢測，可以提前在記憶體中檢測，比原生的效率高（不會導致執行事務一部分后回滾，浪費不必要的資源）。2，資料庫并不支持列級別的并發，對于有些欄位很多，修改它的業務比較多的表，列級別的并發是有意義的。3，對于沖突，可以知道是和哪些業務沖突（具體的事務和表，欄位），資料庫是不會有這么詳細的資訊的。4，對于有些場景，比如根據父表狀態來對子表進行處理（修改），但不更新父表，此時用資料庫的樂觀鎖無法實作
uj5u.com熱心網友回復：
至于效率，就只取決于ConcurrentHashMap的效率，可以參考這篇文章 https://stackoverflow.com/questions/1378310/performance-concurrenthashmap-vs-hashmap 的測驗結果，add的效率是100萬次/100ms，get效率是100萬次/22ms，remove是100萬次/23ms，對于一般的事務用到的鎖不過幾個或者數十個，也就是說，一秒鐘平均支持數萬個事務毫無問題，這里并不會成為瓶頸。如果一開始就分配系統支持的最大數量的鎖，那么效率將會更高。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/53988.html
標籤：開發
上一篇：mysql安裝