Talk:Java Monitor
From APIDesign
@Synchronized does look good for some cases. However, it does not address (at least not without writing just as much code as doing it without annotations) a second class of monitor usage bugs that I find is very common: Using a single lock for multiple resources. It is very common to see a pattern such as:
public class Foo { private Bar bar; protected synchronized replaceBar() { bar = new Bar(xyz); } public synchronized Bar getBar() { return bar; } public synchronized void addPropertyChangeListener (PropertyChangeListener pcl) { ... } public synchronized void removePropertyChangeListener (PropertyChangeListener pcl) { ... } }
While this code is correct in that it will compile and run as the user expects,
- There is much greater potential for deadlocks, and
- An application with such code can have thread liveness problems
because the same monitor is being used to protect two unrelated resources from access collisions.
-Tim Boudreau
Right, this is the behavior. But it is not flaw of Java Monitor, it is a design decision of the inventor of monitor concept. The appropriate solution would be to put the separate concept into separate records/classes. So Java is using the monitor concept correctly (in this case), but one may treat this as another indication that monitors are not really suitable for OOP.
--JaroslavTulach 12:56, 31 January 2010 (UTC)