Rob*_*zer 2 java concurrency synchronized
一个同步比很多同步更好吗?
synchronized(this)
{
CODE1
CODE2 // uncritically code, short duration
CODE3
CODE4 // uncritically code, short duration
CODE5
}
Run Code Online (Sandbox Code Playgroud)
VS
synchronized(this)
{
CODE1
}
CODE2 // uncritically code, short duration
synchronized(this)
{
CODE3
}
CODE4 // uncritically code, short duration
synchronized(this)
{
CODE5
}
Run Code Online (Sandbox Code Playgroud)
以下适用:同步块尽可能小,就像我在第二个示例中编码的那样。
但这在任何情况下都是正确的吗?如果不严格的代码片段在持续时间很短的 enoguh 中,如果我不锁定解锁锁定解锁等,也许我的程序性能更高?
如果有助于性能,JVM 的优化器能够加入相邻的同步块,但它不能做相反的事情,因为拆分它会改变语义。
请参阅 Java SE 6 性能白皮书,2.1.2 锁粗化
有一些锁定模式,其中释放锁定,然后在一段代码中重新获取,中间没有发生可观察的操作。在热点中实现的锁粗化优化技术消除了在这些情况下的解锁和重新锁定操作[...]。它基本上通过扩大现有的同步区域来减少同步工作量。
对 Java 6 的引用表明这甚至不是一个全新的功能
所以如果你知道有不重要的代码并且整个代码都可以临时释放锁(这可能会导致其他线程改变其状态),然后使用多个同步块,告诉 JVM 和人类读者 CODE2 和 CODE4 并不重要。
这遵循让运行时优化器做出正确权衡的典型模式,因为它比我们更了解实际情况,即硬件和实际应用程序行为。
| 归档时间: |
|
| 查看次数: |
69 次 |
| 最近记录: |