Java监视器有多重？ [英] How heavy are Java Monitors?

问题描述

假设我有一个包含数千个对象的数组，以及可能访问每个对象的少量线程。我想保护对其中一个对象方法的访问。最简单的方法是将该方法声明为 synchronized 。但是，这可能会导致创建数千个监视器，无论它们实现的方式如何。如果这是Win32，我永远不会创建数千个内核对象，如Mutex，但CRITICAL_SECTIONs 可能似乎是合理的。我想知道Java的情况如何。鉴于争用的可能性很低，监视器的使用是否会超过他们所需的大量内存？在Java中使用这种低粒度同步的做法有多常见？

Say I have an array of thousands of objects, and a small number of threads that might access each of the objects. I want to protect the access to one of the objects methods. Easiest way would be to declare that method as synchronized. However, that might result in creating thousands of monitors, whichever way they are implemented. If this were Win32, I'd never create thousands of kernel objects such as Mutex, but CRITICAL_SECTIONs might be plausible. I'm wondering what's the case in Java. Given the chance of contention is low, would the use of monitors impose more than the sheer amount of memory they require? How common a practice is it to use such low granularity synchronization in Java?

（显然有一些解决方法，例如使用更小的同步对象数组，这些对象将被访问使用一些哈希。我不是在寻找一个实用的解决方案，我正在寻找一个洞察力。）

(There are obviously workarounds such as using a much smaller array of synchronization objects, which will be accessed using some hash. I'm not looking for a practical solution, I'm looking for an insight).

推荐答案

你有已经支付（大部分，并且在低争用中）使用Java监视器的惩罚...没有意义不使用它们。特别是在低竞争情况下，它们非常便宜（参见第2.1,2.2,2.3项）这里和这里的第1项），JVM可以优化它们完全是为了一些案件。如果你只是暂时使用对象的监视器，那么JVM会使它足够大（意味着它从位翻转开始，可能会因为简单的争用情况而扩展到堆栈分配的原子标志，并且在持续争用下会分配一个objectmonitor）它;当争用减少时，所有这些都将被展开回到低开销的情况下）并且稍后回收空间。如果锁定这些对象是应用程序方面的正确的东西，我会说它去做。

You have already paid (most of, and in low-contention) the penalty for having the Monitors around by using Java... no sense not using them. Particularly in the low-contention case, they are very cheap (see Items 2.1, 2.2, 2.3 here and Item #1 here), and the JVM can optimize them away entirely for a number of cases. If you only use the object's monitor transiently, the JVM will make it "big enough" (meaning it begins as bit-flipping, might expand for simple contention cases to a stack-allocated atomic flag, and under persistent contention have a objectmonitor allocated for it; all of these will be unrolled back to the low-overhead case as contention abates) and reclaim the space later. To the extent that locking on these objects is the "right thing" on the application side, I'd say go for it.

然而，这里有一种设计气味。锁定这么多物体听起来不太好。此外，如果您有任何顺序锁定条件，您将无法推断潜在的死锁。我建议你用关于应用程序的更多细节来增加你的问题，我们可以问一下锁定大型对象是否正确。

However, there's a design smell here. Locking on so many objects doesn't sound great. Furthermore, if you have any sequential locking conditions, you're not going to be able to reason about potential deadlocks. I suggest you augment your question with more detail about the application, and we can ask whether locking on a large pool of objects is the Right Thing.

这个 Dave Dice的演示提供了有关Java6同步如何工作的有用见解，以及博客条目是同步Java信息的宝库。如果你真的非常关心一个完整的对象监视器结构是多么大（将在竞争情况下发挥作用），代码在这里。 HotSpot内部维基页面也有一些良好的深入信息。

This presentation by Dave Dice gives some useful insight into how Java6 synchronization works, and this blog entry is a treasure trove of sync-on-Java information. If you really, really care about how "big" a full-on objectmonitor structure is (will come into play in the contended case), the code is here. The HotSpot internals wiki page also has some good in-depth information.

这篇关于Java监视器有多重？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！