解決方法肯定是用檔案鎖了，具體怎麼做看資料庫區的mysql模組下的mysql鎖。
使用檔案鎖，先試試有沒有其他方法，具體如下。
背景知識：資料庫儲存引擎、表鎖、檔案鎖。
資料庫儲存引擎：
如果是mysiam引擎，則它的鎖只能支援表鎖，所以要操作這個表的功能，都會被阻塞。這樣做會拖慢整個**的網速。
舉個例子：
比如：我們下訂單時，要鎖定商品表，那麼**下訂單的人非常多，那麼商品表就一直處於被鎖定的狀態。
這樣其他和商品表有關的操作，就會被阻塞！
而如果是innodb引擎，則它的鎖只能支援行鎖。（查詢速度比較慢）
故使用檔案鎖。
下單流程：
加鎖->當多個人同時購買時，作業系統的底層確保只有乙個客戶在進行操作，其他的只能阻塞。
->先取出商品庫存量，檢查庫存量，下單，減少庫存量。->解鎖
然後其他客戶再操作，流程與上相同。
高併發下的下單功能設計
商品表設計 熱銷商品提供給使用者秒殺，有初始庫存。entity public class seckillgoods implements serializable 秒殺訂單表設計 記錄秒殺成功的訂單情況 entity public class seckillorder implements seri...
專案中遇到併發問題和解決辦法
由於這個模組高併發的機率比較大，所有有些邏輯模組就要採取一些快取技術和排它鎖的使用者，比如 由於專案需求是可以多個人同時砍價，我們又有砍到最低 的限制，所以不進行處理的話很有可能就會超出我們所限制的 所以當使用者砍價砍到最低價的時候就需要用到排它鎖了 直接上 說明砍到最低價 order price ...
低併發下的加鎖問題
高併發下已有很多解決方案，說一說現公司在併發沒太高的實際場景下是怎樣控制併發問題的。首先，採用樂觀鎖的思想，在校驗時間戳或版本中選擇了時間戳，基本思想是 每次更新資料都會更新時間戳為當前系統時間，在更新資料前先將本地時間戳與資料庫裡存的時間戳對比一下，若時間戳一樣則證明沒人改過，可以進行更新操作，否...