前言 在單體架構的秒殺活動中，為了減輕DB層的壓力，這裡我們採用了Lock鎖來實現秒殺用戶排隊搶購。然而很不幸的是儘管使用了鎖，但是測試過程中仍然會超賣，執行了N多次發現依然有問題。輸出一下代碼吧，可能大家看的比較真切： 代碼寫在service層，bean預設是單例的，也就是說lock肯定是一個對象 ...
前言
在單體架構的秒殺活動中，為了減輕DB層的壓力，這裡我們採用了Lock鎖來實現秒殺用戶排隊搶購。然而很不幸的是儘管使用了鎖，但是測試過程中仍然會超賣，執行了N多次發現依然有問題。輸出一下代碼吧，可能大家看的比較真切：
@Service("seckillService")
public class SeckillServiceImpl implements ISeckillService {
/**
* 思考：為什麼不用synchronized
* service 預設是單例的，併發下lock只有一個實例
*/
private Lock lock = new ReentrantLock(true);//互斥鎖 參數預設false，不公平鎖
@Autowired
private DynamicQuery dynamicQuery;
@Override
@Transactional
public Result startSeckilLock(long seckillId, long userId) {
try {
lock.lock();
//這裡、不清楚為啥、總是會被超賣101、難道鎖不起作用、lock是同一個對象
String nativeSql = "SELECT number FROM seckill WHERE seckill_id=?";
Object object = dynamicQuery.nativeQueryObject(nativeSql, new Object[]{seckillId});
Long number = ((Number) object).longValue();
if(number>0){
nativeSql = "UPDATE seckill SET number=number-1 WHERE seckill_id=?";
dynamicQuery.nativeExecuteUpdate(nativeSql, new Object[]{seckillId});
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(seckillId);
killed.setUserId(userId);
killed.setState(Short.parseShort(number+""));
killed.setCreateTime(new Timestamp(new Date().getTime()));
dynamicQuery.save(killed);
}else{
return Result.error(SeckillStatEnum.END);
}
} catch (Exception e) {
e.printStackTrace();
}finally {
lock.unlock();
}
return Result.ok(SeckillStatEnum.SUCCESS);
}
}代碼寫在service層，bean預設是單例的，也就是說lock肯定是一個對象。感覺不放心，還是列印一下 lock.hashCode()，輸出結果沒問題。由於還有其他事情要做，最終還是帶著疑問提交代碼到碼雲。
追蹤
如果想分享代碼並使大家一起參與進來，一定要自薦，這樣才會被更多的人發現。當然，如果有交流群一定要留下聯繫方式，這樣討論起來可能更方便。項目被推薦後，果然加群的小伙伴就多了。由於項目配置好相應參數就可以測試，並且每個點都有相應的文字註釋，其中有心的小伙伴果然註意到了我寫的註釋<這裡、不清楚為啥、總是會被超賣101、難道鎖不起作用、lock是同一個對象>，然後提出了困擾自己好多天的問題。
碼友zoain說，測試了好久終於發現了問題，原來lock鎖是在事物單元中執行的。看到這裡，小伙伴們有沒有恍然大悟，反正我是悟了。這裡，總結一下為什麼會超賣101：秒殺開始後，某個事物在未提交之前，鎖已經釋放(事物提交是在整個方法執行完)，導致下一個事物讀取到了上個事物未提交的數據，也就是傳說中的臟讀。此處給出的建議是鎖上移，也就是說要包住整個事物單元。
AOP+鎖
為了包住事物單元，這裡我們使用AOP切麵編程，當然你也可以上移到Control層。
自定義註解Servicelock：
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Servicelock {
String description() default "";
}自定義切麵LockAspect:
@Component
@Scope
@Aspect
public class LockAspect {
/**
* 思考：為什麼不用synchronized
* service 預設是單例的，併發下lock只有一個實例
*/
private static Lock lock = new ReentrantLock(true);//互斥鎖 參數預設false，不公平鎖
//Service層切點 用於記錄錯誤日誌
@Pointcut("@annotation(com.itstyle.seckill.common.aop.Servicelock)")
public void lockAspect() {
}
@Around("lockAspect()")
public Object around(ProceedingJoinPoint joinPoint) {
lock.lock();
Object obj = null;
try {
obj = joinPoint.proceed();
} catch (Throwable e) {
e.printStackTrace();
} finally{
lock.unlock();
}
return obj;
}
}切入秒殺方法：
@Service("seckillService")
public class SeckillServiceImpl implements ISeckillService {
/**
* 思考：為什麼不用synchronized
* service 預設是單例的，併發下lock只有一個實例
*/
private Lock lock = new ReentrantLock(true);//互斥鎖 參數預設false，不公平鎖
@Autowired
private DynamicQuery dynamicQuery;
@Override
@Servicelock
@Transactional
public Result startSeckilAopLock(long seckillId, long userId) {
//來自碼雲碼友<馬丁的早晨>的建議 使用AOP + 鎖實現
String nativeSql = "SELECT number FROM seckill WHERE seckill_id=?";
Object object = dynamicQuery.nativeQueryObject(nativeSql, new Object[]{seckillId});
Long number = ((Number) object).longValue();
if(number>0){
nativeSql = "UPDATE seckill SET number=number-1 WHERE seckill_id=?";
dynamicQuery.nativeExecuteUpdate(nativeSql, new Object[]{seckillId});
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(seckillId);
killed.setUserId(userId);
killed.setState(Short.parseShort(number+""));
killed.setCreateTime(new Timestamp(new Date().getTime()));
dynamicQuery.save(killed);
}else{
return Result.error(SeckillStatEnum.END);
}
return Result.ok(SeckillStatEnum.SUCCESS);
}
}所有的工作完成以後，我們來測試一下代碼，意料之中，再也沒有出現超賣的現象。然而，你以為就這麼結束了麽？細心的碼友IM核米，又提出了以下問題：Spring 里的切片在未指定排序的時候，兩個註解是隨意執行的。如果事務在加鎖前執行的話，是不是就會產生問題？
首先，由於自己實在沒有時間去取證，最終還是碼友IM核米完成了自問自答，這裡引用下他的解釋：
我說的沒錯，但 @Transactional 切片是特殊情況
1）多 AOP 之間的執行順序在未指定時是 ：undefined ，官方文檔並沒有說一定會按照註解的順序進行執行，只會按照 @ Order 的順序執行。
可參考官方文檔： 可以在頁面里搜索 Command+F「7.2.4.7 Advice ordering」https://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-ataspectj-advice-ordering
2）事務切麵的 default Order 被設置為了 Ordered.LOWEST_PRECEDENCE，所以預設情況下是屬於最內層的環切。
可參考官方文檔： 可以在頁面里搜索 Command+F「Table 10.2. tx:annotation-driven/ settings」 https://docs.spring.io/spring/docs/3.0.x/reference/transaction.html#transaction-declarative-txadvice-settings
總結
經驗真的很重要，踩的坑多了也變走成了路
不要吝嗇自己的總結成果，分享交流才能夠促使大家共同進步
最好不要懷疑久經考驗的Lock鎖同志，很有可能是你使用的方式不對
思考
為什麼沒有用synchronized？
代碼案例：從0到1構建分散式秒殺系統
