場景分析，
保護多個資源之間沒有業務關係
例如支付寶賬戶的針對餘額的操作，和針對賬戶密碼的修改操作。可以為賬戶資源，使用者資源分配不同的鎖來解決併發問題。
public class alipayaccount}}//檢視賬戶中的餘額
public integer getbalance()
}//修改賬戶的密碼
public void updatepassword(string password)
}//檢視賬戶的密碼
public string getpassword()
}}
這裡也可以用一吧鎖來保護balance和password 資源，甚至乾脆用this關鍵字和synchronized關鍵字操作。但是，如果使用乙個鎖物件的話，那麼程式的效能太差了，會導致直接業務各種操作都序列執行，這違背了程式併發遍程的目的
多個資源之間有業務關係
例如，我們使用支付寶進行轉賬操作。假設賬戶a給賬戶b轉賬100，a賬戶減少100元，b賬戶增加100元。兩個賬戶在業務中有直接的業務關係。例如，下面的tansferaccount類，有乙個成員變數balance和乙個轉賬的方法transfer()，**如下所示。
public class tansferaccount}}
在上面的**中，如何保證轉賬操作不會出現併發問題呢？很多時候我們的第一反應就是給transfer()方法加鎖，如下**所示
public class tansferaccount}}
我們仔細分析下，上面的**真的是安全的嗎？！其實，在這段**中，synchronized臨界區中存在兩個不同的資源，分別是轉出賬戶的餘額this.balance和轉入賬戶的餘額target.balance，這裡只用到了一把鎖synchronized(this)。說到這裡，大家有沒有一種豁然開朗的感覺。沒錯，問題就出現在synchronized(this)這把鎖上，這把鎖只能保護this.balance資源，而無法保護target.balance資源。
解決方法：
1：統一給他們傳入乙個鎖資源。在實際的開發中，不同例項在不同的模組中，該方法不顯示
2.：統一使用類鎖。對他們進行處理。
高併發和鎖
面試被問到了這個問題，找了答案，記錄一下 假如有100w個使用者，搶一張票，除了負載均衡的辦法，怎麼支援高併發？修改字段 將庫存欄位number欄位設為unsigned，當庫存為0時，因為字段不能為負數，將會返回false 利用悲觀鎖 不適合高併發 悲觀鎖，也就是在修改資料的時候，採用鎖定狀態，排斥...
mysql悲觀鎖，高併發
1.高併發的時候有2種處理 1 後端進行執行緒安全處理，synchrnoized,還有其他不同粒度的鎖 2 在資料庫設定鎖，當你讀的時候，不允許其他人修改。可以用mysql的悲觀鎖 2.悲觀鎖 select from 表名 for update for update很重要，就是如果你查詢這個事務沒有...
java 高併發 之 鎖
synchronized 是屬於宣告式加鎖，可以修飾乙個 塊 乙個方法 乙個類，乙個靜態方法。修飾乙個 塊 public void test1 int j j,i 修飾乙個方法 public synchronized void test2 int j j,i 修飾乙個類 public static ...