1.引言
高并發場景在現場的日常作業中很常見,特別是在互聯網公司中,這篇文章就來通過秒殺商品來模擬高并發的場景,文章末尾會附上文章的所有代碼、腳本和測驗用例,
- 本文環境: SpringBoot 2.5.7 + MySQL 8.0 X + MybatisPlus + Swagger2.9.2
- 模擬工具: Jmeter
- 模擬場景: 減庫存->創建訂單->模擬支付
2.商品秒殺-超賣
在開發中,對于下面的代碼,可能很熟悉:在Service里面加上@Transactional事務注解和Lock鎖,
Spring Boot 基礎就不介紹了,推薦看這個免費教程:
https://github.com/javastacks/spring-boot-best-practice
控制層:Controller
@ApiOperation(value="https://www.cnblogs.com/javastack/archive/2023/05/11/秒殺實作方式——Lock加鎖")
@PostMapping("/start/lock")
public Result startLock(long skgId){
try {
log.info("開始秒殺方式一...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByLock(skgId, userId);
if(result != null){
log.info("用戶:{}--{}", userId, result.get("msg"));
}else{
log.info("用戶:{}--{}", userId, "哎呦喂,人也太多了,請稍后!");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return Result.ok();
}
業務層:Service
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByLock(long skgId, long userId) {
lock.lock();
try {
// 校驗庫存
SecondKill secondKill = secondKillMapper.selectById(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
// 扣庫存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
// 創建訂單
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
// 模擬支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("例外了個乖乖");
} finally {
lock.unlock();
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
對于上面的代碼應該沒啥問題吧,業務方法上加事務,在處理業務的時候加鎖,
但上面這樣寫法是有問題的,會出現超賣的情況,看下測驗結果:模擬1000個并發,搶100商品,


這里在業務方法開始加了鎖,在業務方法結束后釋放了鎖,但這里的事務提交卻不是這樣的,有可能在事務提交之前,就已經把鎖釋放了,這樣會導致商品超賣現象,所以加鎖的時機很重要!
3. 解決商品超賣
對于上面超賣現象,主要問題出現在事務中鎖釋放的時機,事務未提交之前,鎖已經釋放,(事務提交是在整個方法執行完),如何解決這個問題呢,就是把加鎖步驟提前
- 可以在controller層進行加鎖
- 可以使用Aop在業務方法執行之前進行加鎖
3.1 方式一(改進版加鎖)
@ApiOperation(value="https://www.cnblogs.com/javastack/archive/2023/05/11/秒殺實作方式——Lock加鎖")
@PostMapping("/start/lock")
public Result startLock(long skgId){
// 在此處加鎖
lock.lock();
try {
log.info("開始秒殺方式一...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByLock(skgId, userId);
if(result != null){
log.info("用戶:{}--{}", userId, result.get("msg"));
}else{
log.info("用戶:{}--{}", userId, "哎呦喂,人也太多了,請稍后!");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
// 在此處釋放鎖
lock.unlock();
}
return Result.ok();
}
上面這樣的加鎖就可以解決事務未提交之前,鎖釋放的問題,可以分三種情況進行壓力測驗:
- 并發數1000,商品100
- 并發數1000,商品1000
- 并發數2000,商品1000
對于并發量大于商品數的情況,商品秒殺一般不會出現少賣的請況,但對于并發數小于等于商品數的時候可能會出現商品少賣情況,這也很好理解,
對于沒有問題的情況就不貼圖了,因為有很多種方式,貼圖會太多

3.2 方式二(AOP版加鎖)
對于上面在控制層進行加鎖的方式,可能顯得不優雅,那就還有另一種方式進行在事務之前加鎖,那就是AOP,
推薦一個開源免費的 Spring Boot 最全教程:
https://github.com/javastacks/spring-boot-best-practice
自定義AOP注解
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ServiceLock {
String description() default "";
}
定義切面類
@Slf4j
@Component
@Scope
@Aspect
@Order(1) //order越小越是最先執行,但更重要的是最先執行的最后結束
public class LockAspect {
/**
* 思考:為什么不用synchronized
* service 默認是單例的,并發下lock只有一個實體
*/
private static Lock lock = new ReentrantLock(true); // 互斥鎖 引數默認false,不公平鎖
// Service層切點 用于記錄錯誤日志
@Pointcut("@annotation(com.scorpios.secondkill.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();
throw new RuntimeException();
} finally{
lock.unlock();
}
return obj;
}
}
在業務方法上添加AOP注解
@Override
@ServiceLock // 使用Aop進行加鎖
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByAop(long skgId, long userId) {
try {
// 校驗庫存
SecondKill secondKill = secondKillMapper.selectById(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
//扣庫存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
//創建訂單
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("例外了個乖乖");
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
控制層:
@ApiOperation(value="https://www.cnblogs.com/javastack/archive/2023/05/11/秒殺實作方式二——Aop加鎖")
@PostMapping("/start/aop")
public Result startAop(long skgId){
try {
log.info("開始秒殺方式二...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByAop(skgId, userId);
if(result != null){
log.info("用戶:{}--{}", userId, result.get("msg"));
}else{
log.info("用戶:{}--{}", userId, "哎呦喂,人也太多了,請稍后!");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
這種方式在對鎖的使用上,更高階、更美觀!
3.3 方式三(悲觀鎖一)
除了上面在業務代碼層面加鎖外,還可以使用資料庫自帶的鎖進行并發控制,
悲觀鎖,什么是悲觀鎖呢?通俗的說,在做任何事情之前,都要進行加鎖確認,這種資料庫級加鎖操作效率較低,
使用for update一定要加上事務,當事務處理完后,for update才會將行級鎖解除
如果請求數和秒殺商品數量一致,會出現少賣
@ApiOperation(value="https://www.cnblogs.com/javastack/archive/2023/05/11/秒殺實作方式三——悲觀鎖")
@PostMapping("/start/pes/lock/one")
public Result startPesLockOne(long skgId){
try {
log.info("開始秒殺方式三...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByUpdate(skgId, userId);
if(result != null){
log.info("用戶:{}--{}", userId, result.get("msg"));
}else{
log.info("用戶:{}--{}", userId, "哎呦喂,人也太多了,請稍后!");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
業務邏輯
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByUpdate(long skgId, long userId) {
try {
// 校驗庫存-悲觀鎖
SecondKill secondKill = secondKillMapper.querySecondKillForUpdate(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
//扣庫存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
//創建訂單
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("例外了個乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
Dao層
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 將此行資料進行加鎖,當整個方法將事務提交后,才會解鎖
* @param skgId
* @return
*/
@Select(value = "https://www.cnblogs.com/javastack/archive/2023/05/11/SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
}
上面是利用for update進行對查詢資料加鎖,加的是行鎖
3.4 方式四(悲觀鎖二)
悲觀鎖的第二種方式就是利用update更新命令來加表鎖
/**
* UPDATE鎖表
* @param skgId 商品id
* @param userId 用戶id
* @return
*/
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByUpdateTwo(long skgId, long userId) {
try {
// 不校驗,直接扣庫存更新
int result = secondKillMapper.updateSecondKillById(skgId);
if (result > 0) {
//創建訂單
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("例外了個乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
Dao層
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 將此行資料進行加鎖,當整個方法將事務提交后,才會解鎖
* @param skgId
* @return
*/
@Select(value = "https://www.cnblogs.com/javastack/archive/2023/05/11/SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
@Update(value = "https://www.cnblogs.com/javastack/archive/2023/05/11/UPDATE seckill SET number=number-1 WHERE seckill_id=#{skgId} AND number > 0")
int updateSecondKillById(@Param("skgId") long skgId);
}
3.5 方式五(樂觀鎖)
樂觀鎖,顧名思義,就是對操作結果很樂觀,通過利用version欄位來判斷資料是否被修改
樂觀鎖,不進行庫存數量的校驗,直接做庫存扣減
這里使用的樂觀鎖會出現大量的資料更新例外(拋例外就會導致購買失敗)、如果配置的搶購人數比較少、比如120:100(人數:商品) 會出現少買的情況,不推薦使用樂觀鎖,
@ApiOperation(value="https://www.cnblogs.com/javastack/archive/2023/05/11/秒殺實作方式五——樂觀鎖")
@PostMapping("/start/opt/lock")
public Result startOptLock(long skgId){
try {
log.info("開始秒殺方式五...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
// 引數添加了購買數量
Result result = secondKillService.startSecondKillByPesLock(skgId, userId,1);
if(result != null){
log.info("用戶:{}--{}", userId, result.get("msg"));
}else{
log.info("用戶:{}--{}", userId, "哎呦喂,人也太多了,請稍后!");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByPesLock(long skgId, long userId, int number) {
// 樂觀鎖,不進行庫存數量的校驗,直接
try {
SecondKill kill = secondKillMapper.selectById(skgId);
// 剩余的數量應該要大于等于秒殺的數量
if(kill.getNumber() >= number) {
int result = secondKillMapper.updateSecondKillByVersion(number,skgId,kill.getVersion());
if (result > 0) {
//創建訂單
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
}
} catch (Exception e) {
throw new ScorpiosException("例外了個乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 將此行資料進行加鎖,當整個方法將事務提交后,才會解鎖
* @param skgId
* @return
*/
@Select(value = "https://www.cnblogs.com/javastack/archive/2023/05/11/SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
@Update(value = "https://www.cnblogs.com/javastack/archive/2023/05/11/UPDATE seckill SET number=number-1 WHERE seckill_id=#{skgId} AND number > 0")
int updateSecondKillById(@Param("skgId") long skgId);
@Update(value = "https://www.cnblogs.com/javastack/archive/2023/05/11/UPDATE seckill SET number=number-#{number},version=version+1 WHERE seckill_id=#{skgId} AND version = #{version}")
int updateSecondKillByVersion(@Param("number") int number, @Param("skgId") long skgId, @Param("version")int version);
}
樂觀鎖會出現大量的資料更新例外(拋例外就會導致購買失敗),會出現少買的情況,不推薦使用樂觀鎖
3.6 方式六(阻塞佇列)
利用阻塞隊類,也可以解決高并發問題,其思想就是把接收到的請求按順序存放到佇列中,消費者執行緒逐一從佇列里取資料進行處理,看下具體代碼,
阻塞佇列:這里使用靜態內部類的方式來實作單例模式,在并發條件下不會出現問題,
// 秒殺佇列(固定長度為100)
public class SecondKillQueue {
// 佇列大小
static final int QUEUE_MAX_SIZE = 100;
// 用于多執行緒間下單的佇列
static BlockingQueue<SuccessKilled> blockingQueue = new LinkedBlockingQueue<SuccessKilled>(QUEUE_MAX_SIZE);
// 使用靜態內部類,實作單例模式
private SecondKillQueue(){};
private static class SingletonHolder{
// 靜態初始化器,由JVM來保證執行緒安全
private static SecondKillQueue queue = new SecondKillQueue();
}
/**
* 單例佇列
* @return
*/
public static SecondKillQueue getSkillQueue(){
return SingletonHolder.queue;
}
/**
* 生產入隊
* @param kill
* @throws InterruptedException
* add(e) 佇列未滿時,回傳true;佇列滿則拋出IllegalStateException(“Queue full”)例外——AbstractQueue
* put(e) 佇列未滿時,直接插入沒有回傳值;佇列滿時會阻塞等待,一直等到佇列未滿時再插入,
* offer(e) 佇列未滿時,回傳true;佇列滿時回傳false,非阻塞立即回傳,
* offer(e, time, unit) 設定等待的時間,如果在指定時間內還不能往佇列中插入資料則回傳false,插入成功回傳true,
*/
public Boolean produce(SuccessKilled kill) {
return blockingQueue.offer(kill);
}
/**
* 消費出隊
* poll() 獲取并移除隊首元素,在指定的時間內去輪詢佇列看有沒有首元素有則回傳,否者超時后回傳null
* take() 與帶超時時間的poll類似不同在于take時候如果當前佇列空了它會一直等待其他執行緒呼叫notEmpty.signal()才會被喚醒
*/
public SuccessKilled consume() throws InterruptedException {
return blockingQueue.take();
}
/**
* 獲取佇列大小
* @return
*/
public int size() {
return blockingQueue.size();
}
}
消費秒殺佇列:實作ApplicationRunner介面
// 消費秒殺佇列
@Slf4j
@Component
public class TaskRunner implements ApplicationRunner{
@Autowired
private SecondKillService seckillService;
@Override
public void run(ApplicationArguments var){
new Thread(() -> {
log.info("佇列啟動成功");
while(true){
try {
// 行程內佇列
SuccessKilled kill = SecondKillQueue.getSkillQueue().consume();
if(kill != null){
Result result = seckillService.startSecondKillByAop(kill.getSeckillId(), kill.getUserId());
if(result != null && result.equals(Result.ok(SecondKillStateEnum.SUCCESS))){
log.info("TaskRunner,result:{}",result);
log.info("TaskRunner從訊息佇列取出用戶,用戶:{}{}",kill.getUserId(),"秒殺成功");
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
@ApiOperation(value="https://www.cnblogs.com/javastack/archive/2023/05/11/秒殺實作方式六——訊息佇列")
@PostMapping("/start/queue")
public Result startQueue(long skgId){
try {
log.info("開始秒殺方式六...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
SuccessKilled kill = new SuccessKilled();
kill.setSeckillId(skgId);
kill.setUserId(userId);
Boolean flag = SecondKillQueue.getSkillQueue().produce(kill);
// 雖然進入了佇列,但是不一定能秒殺成功 進隊出隊有時間間隙
if(flag){
log.info("用戶:{}{}",kill.getUserId(),"秒殺成功");
}else{
log.info("用戶:{}{}",userId,"秒殺失敗");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
注意:在業務層和AOP方法中,不能拋出任何例外, throw new RuntimeException()這些拋例外代碼要注釋掉,因為一旦程式拋出例外就會停止,導致消費秒殺佇列行程終止!
使用阻塞佇列來實作秒殺,有幾點要注意:
- 消費秒殺佇列中呼叫業務方法加鎖與不加鎖情況一樣,也就是
seckillService.startSecondKillByAop()、seckillService.startSecondKillByLock()方法結果一樣,這也很好理解 - 當佇列長度與商品數量一致時,會出現少賣的現象,可以調大數值
- 下面是佇列長度1000,商品數量1000,并發數2000情況下出現的少賣

3.7.方式七(Disruptor佇列)
Disruptor是個高性能佇列,研發的初衷是解決記憶體佇列的延遲問題,在性能測驗中發現竟然與I/O操作處于同樣的數量級,基于Disruptor開發的系統單執行緒能支撐每秒600萬訂單,
// 事件生成工廠(用來初始化預分配事件物件)
public class SecondKillEventFactory implements EventFactory<SecondKillEvent> {
@Override
public SecondKillEvent newInstance() {
return new SecondKillEvent();
}
}
// 事件物件(秒殺事件)
public class SecondKillEvent implements Serializable {
private static final long serialVersionUID = 1L;
private long seckillId;
private long userId;
// set/get方法略
}
// 使用translator方式生產者
public class SecondKillEventProducer {
private final static EventTranslatorVararg<SecondKillEvent> translator = (seckillEvent, seq, objs) -> {
seckillEvent.setSeckillId((Long) objs[0]);
seckillEvent.setUserId((Long) objs[1]);
};
private final RingBuffer<SecondKillEvent> ringBuffer;
public SecondKillEventProducer(RingBuffer<SecondKillEvent> ringBuffer){
this.ringBuffer = ringBuffer;
}
public void secondKill(long seckillId, long userId){
this.ringBuffer.publishEvent(translator, seckillId, userId);
}
}
// 消費者(秒殺處理器)
@Slf4j
public class SecondKillEventConsumer implements EventHandler<SecondKillEvent> {
private SecondKillService secondKillService = (SecondKillService) SpringUtil.getBean("secondKillService");
@Override
public void onEvent(SecondKillEvent seckillEvent, long seq, boolean bool) {
Result result = secondKillService.startSecondKillByAop(seckillEvent.getSeckillId(), seckillEvent.getUserId());
if(result.equals(Result.ok(SecondKillStateEnum.SUCCESS))){
log.info("用戶:{}{}",seckillEvent.getUserId(),"秒殺成功");
}
}
}
public class DisruptorUtil {
static Disruptor<SecondKillEvent> disruptor;
static{
SecondKillEventFactory factory = new SecondKillEventFactory();
int ringBufferSize = 1024;
ThreadFactory threadFactory = runnable -> new Thread(runnable);
disruptor = new Disruptor<>(factory, ringBufferSize, threadFactory);
disruptor.handleEventsWith(new SecondKillEventConsumer());
disruptor.start();
}
public static void producer(SecondKillEvent kill){
RingBuffer<SecondKillEvent> ringBuffer = disruptor.getRingBuffer();
SecondKillEventProducer producer = new SecondKillEventProducer(ringBuffer);
producer.secondKill(kill.getSeckillId(),kill.getUserId());
}
}
@ApiOperation(value="https://www.cnblogs.com/javastack/archive/2023/05/11/秒殺實作方式七——Disruptor佇列")
@PostMapping("/start/disruptor")
public Result startDisruptor(long skgId){
try {
log.info("開始秒殺方式七...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
SecondKillEvent kill = new SecondKillEvent();
kill.setSeckillId(skgId);
kill.setUserId(userId);
DisruptorUtil.producer(kill);
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
經過測驗,發現使用Disruptor佇列佇列,與自定義佇列有著同樣的問題,也會出現超賣的情況,但效率有所提高,
4. 小結
對于上面七種實作并發的方式,做一下總結:
- 一、二方式是在代碼中利用鎖和事務的方式解決了并發問題,主要解決的是鎖要加載事務之前
- 三、四、五方式主要是資料庫的鎖來解決并發問題,方式三是利用for upate對表加行鎖,方式四是利用update來對表加鎖,方式五是通過增加version欄位來控制資料庫的更新操作,方式五的效果最差
- 六、七方式是通過佇列來解決并發問題,這里需要特別注意的是,在代碼中不能通過throw拋例外,否則消費執行緒會終止,而且由于進隊和出隊存在時間間隙,會導致商品少賣
上面所有的情況都經過代碼測驗,測驗分一下三種情況:
- 并發數1000,商品數100
- 并發數1000,商品數1000
- 并發數2000,商品數1000
思考:分布式情況下如何解決并發問題呢?下次繼續試驗,
著作權宣告:本文為CSDN博主「止步前行」的原創文章,遵循CC 4.0 BY-SA著作權協議,轉載請附上原文出處鏈接及本宣告,原文鏈接:https://blog.csdn.net/zxd1435513775/article/details/122643285
近期熱文推薦:
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆!Java 協程要來了,,,
3.Spring Boot 2.x 教程,太全了!
4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這才是優雅的方式!!
5.《Java開發手冊(嵩山版)》最新發布,速速下載!
覺得不錯,別忘了隨手點贊+轉發哦!
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/552202.html
標籤:其他
上一篇:JScrollPane
下一篇:返回列表
