java高併發情況下sychronized有什麼問題？

作者：由韋哥哥發表于農業時間：2018-05-17

程式設計指北2021-03-31 22:42:38

這不很簡單嗎，synchronized關鍵字鎖的粒度實在太大了，非常影響效能的！

鎖其實是最影響效能的一個點，有鎖就有單點問題，所以儘量在高併發專案中避免synchronized 這樣的悲觀鎖！！

另外，在這裡說下，很多初學者（包括我自己）初期學習多執行緒時都被影片帶偏了。。。

雖然我一直認為培訓班的影片是最適合非科班零基礎入門的，但是在多執行緒方面，無一例外都講得比較糟糕。

有一點感觸很深：很多人學多執行緒，並不是死在後面的volatile、ReentrantLock或者Executor執行緒池，而是最初期在“什麼是鎖”這個問題上就撲街了。

什麼是“鎖”？

“鎖”到底長啥樣？

它鎖定的是執行緒程式碼還是其他什麼東西？

在我看來，這個問題不搞清楚，後面的內容根本學不明白。而一旦搞清楚這些概念，後面很多問題其實也就迎刃而解。

其實“鎖”本身是個物件，synchronized這個關鍵字不是“鎖”。硬要說的話，加synchronized僅僅是相當於“加鎖”這個操作。

所以，所謂的加鎖，嚴格意義上不是鎖住程式碼塊！如果這樣想的話，後面很多問題就沒法解釋了。

補充幾個概念：

互斥的最基本條件是：共用同一把鎖

靜態方法的鎖是所在類的Class物件，普通方法的鎖是this物件

針對同一個執行緒，synchronized鎖可以支援重入

下面通過幾個小案例，加深上面三句話的理解

同一個類中的synchronized method m1和method m2互斥嗎？

t1執行緒執行m1方法時要去讀this物件鎖，但是t2執行緒並不需要讀鎖，兩者各管各的，沒有交集（不共用一把鎖）

部分參考：

https：//www。

cnblogs。com/paddix/p/53

67116。html

同一個類中synchronized method m1中可以呼叫synchronized method m2嗎？

synchronized是可重入鎖，可以粗淺地理解為同一個執行緒在已經持有該鎖的情況下，可以再次獲取鎖，並且會在某個狀態量上做+1操作

子類同步方法synchronized method m可以呼叫父類的synchronized method m嗎（super。m（））？

子類物件初始化前，會呼叫父類構造方法，在結構上相當於包裹了一個父類物件，用的都是this鎖物件

靜態同步方法和非靜態同步方法互斥嗎？

各玩各的，不是同一把鎖，談不上互斥

覺得不錯的話，記得幫我 @程式設計指北點個贊喲~

帆船上種菜2021-04-30 11:57:37

答案都偏了，最大的問題是 synchronized 只對一個jvm有效，都高併發了，你還沒考慮分散式系統？這不就是沒專案經驗的體現嗎

帝國遊俠2021-05-07 11:33:57

sychronized主要有2個問題

1、只能鎖住單個JVM，不能全域性鎖，而實際生產環境，不管什麼應用，都不可能只部署單個例項的，也就說你用sychronized可能存在該鎖的卻沒鎖住的情況

2、高併發下會出現急劇的效能下降，建議你自己做個試驗，隨便寫個服務，查詢資料庫裡某條記錄，正常這個服務響應時間應該在10-20ms這個級別，然後用jmeter做壓力測試，比如50使用者的情況下，平均響應時間是多少；然後在程式碼的某個地方加上sychronized，同樣50使用者併發再次壓測一下。兩個結果一對比，你就知道啥叫“效能急劇下降”了

另外多說一句，生產環境是禁止使用System。out。print的，還有System。err，為啥呢？其中一個主要原因就是print方法內部有sychronized。