java：圍繞相同的代碼同步與更多同步

Question

一個同步比很多同步更好嗎？

synchronized(this)
{
   CODE1
   CODE2 // uncritically code, short duration
   CODE3
   CODE4 // uncritically code, short duration
   CODE5
}

VS

synchronized(this)
{
   CODE1
}

CODE2 // uncritically code, short duration

synchronized(this)
{
   CODE3
}

CODE4 // uncritically code, short duration

synchronized(this)
{
   CODE5
}

以下適用：同步塊盡可能小，就像我在第二個示例中編碼的那樣。

但這在任何情況下都是正確的嗎？ 如果不嚴格的代碼片段在持續時間很短的 enoguh 中，如果我不鎖定解鎖鎖定解鎖等，也許我的程序性能更高？

Answer 1

如果有助於性能，JVM 的優化器能夠加入相鄰的同步塊，但它不能做相反的事情，因為拆分它會改變語義。

請參閱 Java SE 6 性能白皮書， 2.1.2 鎖粗化

有一些鎖定模式，其中釋放鎖定，然后在一段代碼中重新獲取，中間沒有發生可觀察的操作。 在熱點中實現的鎖粗化優化技術消除了在這些情況下的解鎖和重新鎖定操作[...]。 它基本上通過擴大現有的同步區域來減少同步工作量。

^{對 Java 6 的引用表明這甚至不是一個全新的功能}
因此，如果您知道存在不重要的代碼並且整個代碼都在臨時釋放鎖（這可能會導致其他線程改變其間的狀態），然后使用多個同步塊，告訴 JVM 和人類讀者 CODE2 和CODE4 並不重要。

這遵循讓運行時優化器做出正確權衡的典型模式，因為它比我們更了解實際情況，即硬件和實際應用程序行為。

Answer 2

你沒有提供足夠的信息來回答這個問題。

據推測，CODE1、CODE3 和 CODE5 訪問與其他線程共享的數據，因為如果它們不這樣做，那么使用synchronized將毫無意義。

那么，如果線程 B 在線程 A 執行了 CODE1 但尚未執行 CODE3 或 CODE5 之后嘗試使用共享數據，會發生什么？ 如果在線程 A 執行了 CODE1 和 CODE3 而不是 CODE5 之后線程 B 嘗試使用共享數據會發生什么？ 如果結果可能發生任何不好的事情，那么您需要在同一個同步塊中執行所有三個代碼，而且，無論線程 B 使用相同的共享數據做什么，它也必須在類似的synchronized(this)塊。

---

如果 CODE1、CODE3 和 CODE5 彼此完全獨立，那么我的直覺反應將是使用幾個較小的synchronized塊——尤其是如果五個 CODE 中的任何一個花費了大量時間。 我喜歡保持synchronized塊盡可能短（時間）。

但是如果性能真的很關鍵，那么你應該衡量它並向自己證明哪個是更好的方法。